Forwarded from Р С
кто то модный пишет на котах и зио ну молодцы. преклоняюсь перед смелостью владельцев денег которые это пропустили.
Forwarded from Р С
дали возможность потрогать стаду гиков новую игрушку за свой (не их) счет )
Forwarded from 𝛈 µ
Еще десять лет назад я сделал наблюдение - больше всего про кешлайны кукарекают тупые петухи, неспособные две строчки кода написать
Forwarded from Pasha Finkelshteyn
Потому что в котлиновском паттерн-матчинге сложность O(1), а в скале она вообще непредсказуема
Forwarded from Слава
Диай - это такой особенный способ сделать в рантайме то, что не может сделать компилятор в compile-time, по причине ограниченности оного компилятора (читай: тупости). Иначе говоря, чтобы оно собиралось нормально, а при запуске падало. Или даже не при запуске, а при обработке одного из запросов.
Forwarded from p0lunin [BPL]
Спорить что хаскель и Идрис неприменимы в продакшен среде глупо. А все что неприменимо в продакшене - игрушки.
Forwarded from Маjко
Взять к примеру F#. Всё, что можно написать на F# можно написать на C#. А на F# написать можно очень немногое из того, что позволяет C#. Зато писать на F# сможет НЕпрограммист, а математик, физик, химик или иной инженер.
Forwarded from p0lunin [BPL]
Важно. Разработка ведётся на ОО языках, а не на языках для доказывания теорем.
Forwarded from p0lunin [BPL]
Это подразумевалось, поскольку фреймворки доступны только в ОО языках.
Forwarded from Alexander Granin
Когда я говорил, что ФП - это the next big thing, надо мной смеялись, улюлюкали. Мол, кому эта ерунда нужна. И это в годах 2011-2015, когда нужность ФП уже была видна невооруженным глазом.
Когда я говорил, что Rust станет следующим мейнстримным языком, мне особо не верили. Да и сейчас плюсовики противятся многие. Но он станет, - в перспективе нескольких лет.
Когда я говорил, что Rust обгонит Haskell и поставит нужность оного под сомнение (вместе со Scala+Kotlin+Go), противились уже хаскеллисты. И сейчас смеются, улюлюкают. Мол, причем тут эти языки, у нас свой путь, своя атмосфера.
Но эти же мои прогнозы означают и обратное. Ничто из других языков не получит такой же популярности, в том числе и Idris. Как бы ни хотелось пишущим на нем считать, что он может куда-то продвинуться, предпосылок для этого нет. Его ценности, обозреваемые индустрией снаружи, идут вразрез с тем, что оной нужно. Не нужны 99% компаний ни полная корректность, ни мощные системы типов, ни доказательства теорем. Сам майндсет, который выражает Idris, не нужен, и в немалой степени потому, что этот майндсет почти полностью вложен в майндсет Haskell, который, как мы видим, тоже не особо привлекает индустрию. Но Haskell еще можно спасти, - путем радикальной смены ценностей, - а вот насчет Idris я вовсе не уверен
Когда я говорил, что Rust станет следующим мейнстримным языком, мне особо не верили. Да и сейчас плюсовики противятся многие. Но он станет, - в перспективе нескольких лет.
Когда я говорил, что Rust обгонит Haskell и поставит нужность оного под сомнение (вместе со Scala+Kotlin+Go), противились уже хаскеллисты. И сейчас смеются, улюлюкают. Мол, причем тут эти языки, у нас свой путь, своя атмосфера.
Но эти же мои прогнозы означают и обратное. Ничто из других языков не получит такой же популярности, в том числе и Idris. Как бы ни хотелось пишущим на нем считать, что он может куда-то продвинуться, предпосылок для этого нет. Его ценности, обозреваемые индустрией снаружи, идут вразрез с тем, что оной нужно. Не нужны 99% компаний ни полная корректность, ни мощные системы типов, ни доказательства теорем. Сам майндсет, который выражает Idris, не нужен, и в немалой степени потому, что этот майндсет почти полностью вложен в майндсет Haskell, который, как мы видим, тоже не особо привлекает индустрию. Но Haskell еще можно спасти, - путем радикальной смены ценностей, - а вот насчет Idris я вовсе не уверен
Forwarded from Антон
Здравствуй, {UserName}!
Я глянул ту библиотеку (Laguage-extensions).
В качестве преамбулы к рецензии на эту библиотечку я бы привел слова евангелиста F#, который перефразировав известный анекдот про морскую свинку и женщину-математика сказал, что функциональное программирование также не имеет ничего общего ни с функциями ни с программированием.
Я не знаю кто уж написал эту бибилиотку, но данная библиотечка очень напоминает, чей-то курсач, целью которого было сделать из благородного полнофункционального C# обрезанный, ограниченный в возможностях функциональноподобный инструментарий, чтобы упростить для людей владеющих лишь только функциональным подходом вхождение в хоть какое-то, кривое, косое, ущербное, но написание каких-нибудь программок на неизвестном им C#.
Ряд абстракций этой библиотеки уже сильно устарели и имеются в актуальном C#, и нулабле для ссылочных типов, и кортежи, и swith по очень гибким условиям, и записи, и значимые типы.
На мой взгляд данная библиотечка малополезна для корпоративных информационных систем, не позволяет повысить читаемость кода, качество его сопровождения и скорость разработки. Людям не знакомым с функциональным подходом применение этой библиотеки в общих проектах будет сильно мешать читаемости, сопровождаемости и скорости доработки такого кода. В условиях Аджайла, когда необходимо коллективное владение кодом, и когда полностью рабочий код принято постоянно рефакторить каждый раз когда он сколько-нибудь утрачивает ясность и легкочитаемость для КАЖДОГО программиста команды, привнесение в код дополнительной функциональщины было бы вредно. Как говорится: "keep it simple stupid".
Поэтому лучше придерживаться только стандартных языковых конструкций, стандартных фреймворков и SOLID. Этого уже более чем достаточно для информационных систем разрабатываемых в {CompanyName}. Даже до этого уровня качества кода в {CompanyName} ещё очень-очень далеко. Не достигнув этого уровня качества, привносить функциональщину я бы НЕ стал. У нас тут даже с применением стандартного .Net Core трудности возникают у некоторых сильно опытных программистов, не говоря уже о чем-то большем...
В данной библиотеке действительно есть несколько отдельных классов и расширяющих методов часто полезных и применяемых даже в наших простых информационных системах. Однако нет никакой проблемы скопировать несколько необходимых и требующихся для дела классов из своего предыдущего проекта. Лично я бы применил полдюжины написанных мной под себя классов, но НЕ стал бы тащить в проект всю эту библиотеку с пачкой лишних и непонятных для многих коллег абстракции, ряд из которых к тому же и устарели.
Если когда-нибудь в {CompanyName} возникнет необходимость в разработке действительно сложного ПО, которое даже с применением DDD НЕ будет умещаться в головах разработчиков, то тогда вместо нестандартных компромиссных костылей, я бы наиболее сложную бизнес-логику написал просто на нормальном общепринятом F#, который очень хорошо совместим с C#. При этом я бы доверил бы сопровождение этой особо сложной бизнес-логики людям владеющим не только C#, но и F#. Только я более чем уверен, что для информационных систем разрабатываемых {CompanyName} даже DDD не понадобится, как минимум в течении ближайших десяти лет.
В завершении хотел бы отметить, что всё выше описанное лишь моё впечатление. Если в твоем проекте тебе действительно требуется большая часть классов этой библиотечки, то конечно же стоит её применить!
Если же нужны какие-то частные вещи, например, такие как System.Reactive.Linq или Microsoft.EntityFrameworkCore.DynamicLinq, то в место компромиссного "всё в одном" я бы лучше применил несколько специальных бескомпромиссных пакетов максимально хорошо удовлетворяющий конкретную потребность,
В самом конце рецензии могу дать крамольную рекомендацию - если хочется большей функциональщины, то имеет смысл рассмотреть возможность применения в своем сервисе C#9 на проде. Да, сейчас это нестандартно и может быть неудобно и непонятно многим коллегам, но через полгода, когда им придется сопровождать твой код, C#9 будет уже стандартом. (smile) Поэ
Я глянул ту библиотеку (Laguage-extensions).
В качестве преамбулы к рецензии на эту библиотечку я бы привел слова евангелиста F#, который перефразировав известный анекдот про морскую свинку и женщину-математика сказал, что функциональное программирование также не имеет ничего общего ни с функциями ни с программированием.
Я не знаю кто уж написал эту бибилиотку, но данная библиотечка очень напоминает, чей-то курсач, целью которого было сделать из благородного полнофункционального C# обрезанный, ограниченный в возможностях функциональноподобный инструментарий, чтобы упростить для людей владеющих лишь только функциональным подходом вхождение в хоть какое-то, кривое, косое, ущербное, но написание каких-нибудь программок на неизвестном им C#.
Ряд абстракций этой библиотеки уже сильно устарели и имеются в актуальном C#, и нулабле для ссылочных типов, и кортежи, и swith по очень гибким условиям, и записи, и значимые типы.
На мой взгляд данная библиотечка малополезна для корпоративных информационных систем, не позволяет повысить читаемость кода, качество его сопровождения и скорость разработки. Людям не знакомым с функциональным подходом применение этой библиотеки в общих проектах будет сильно мешать читаемости, сопровождаемости и скорости доработки такого кода. В условиях Аджайла, когда необходимо коллективное владение кодом, и когда полностью рабочий код принято постоянно рефакторить каждый раз когда он сколько-нибудь утрачивает ясность и легкочитаемость для КАЖДОГО программиста команды, привнесение в код дополнительной функциональщины было бы вредно. Как говорится: "keep it simple stupid".
Поэтому лучше придерживаться только стандартных языковых конструкций, стандартных фреймворков и SOLID. Этого уже более чем достаточно для информационных систем разрабатываемых в {CompanyName}. Даже до этого уровня качества кода в {CompanyName} ещё очень-очень далеко. Не достигнув этого уровня качества, привносить функциональщину я бы НЕ стал. У нас тут даже с применением стандартного .Net Core трудности возникают у некоторых сильно опытных программистов, не говоря уже о чем-то большем...
В данной библиотеке действительно есть несколько отдельных классов и расширяющих методов часто полезных и применяемых даже в наших простых информационных системах. Однако нет никакой проблемы скопировать несколько необходимых и требующихся для дела классов из своего предыдущего проекта. Лично я бы применил полдюжины написанных мной под себя классов, но НЕ стал бы тащить в проект всю эту библиотеку с пачкой лишних и непонятных для многих коллег абстракции, ряд из которых к тому же и устарели.
Если когда-нибудь в {CompanyName} возникнет необходимость в разработке действительно сложного ПО, которое даже с применением DDD НЕ будет умещаться в головах разработчиков, то тогда вместо нестандартных компромиссных костылей, я бы наиболее сложную бизнес-логику написал просто на нормальном общепринятом F#, который очень хорошо совместим с C#. При этом я бы доверил бы сопровождение этой особо сложной бизнес-логики людям владеющим не только C#, но и F#. Только я более чем уверен, что для информационных систем разрабатываемых {CompanyName} даже DDD не понадобится, как минимум в течении ближайших десяти лет.
В завершении хотел бы отметить, что всё выше описанное лишь моё впечатление. Если в твоем проекте тебе действительно требуется большая часть классов этой библиотечки, то конечно же стоит её применить!
Если же нужны какие-то частные вещи, например, такие как System.Reactive.Linq или Microsoft.EntityFrameworkCore.DynamicLinq, то в место компромиссного "всё в одном" я бы лучше применил несколько специальных бескомпромиссных пакетов максимально хорошо удовлетворяющий конкретную потребность,
В самом конце рецензии могу дать крамольную рекомендацию - если хочется большей функциональщины, то имеет смысл рассмотреть возможность применения в своем сервисе C#9 на проде. Да, сейчас это нестандартно и может быть неудобно и непонятно многим коллегам, но через полгода, когда им придется сопровождать твой код, C#9 будет уже стандартом. (smile) Поэ
Forwarded from Антон
тому, лучше применить C#9, чем устаревшую и бесперспективную language-ext.
Forwarded from M B
Да, со скалой нужно быть очень аккуратным, особенно если важна производительность
Forwarded from M B
Можно написать collectionOfCollections.flatmap().size вместо collectionOfCollections.map(_.size).sum
Forwarded from A64m AL256m qn<cores> I0
да, в жаве куча "объектов" не объекты, потому что оопе это шиза которой на практике следовать невозможно да и не нужно
Forwarded from Alexander Nozik
Тайпклассы это тоже "хотим хаскель, не знаю почему". Они необходимы в хаскеле, потому что там другого ничего нет. Но в языках типа котлин и даже скалы, их применение ограничено