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
Тайпклассы это тоже "хотим хаскель, не знаю почему". Они необходимы в хаскеле, потому что там другого ничего нет. Но в языках типа котлин и даже скалы, их применение ограничено
Forwarded from Nikita Vilunov
Некоторые люди считают что чистый ФП код выполняется на чистом ФП процессоре?
Forwarded from p0lunin (#GoatLivesMatter)
хм, а кто-то пытался оптимизировать ФП код в императивный через... созданием из чистого кода нечистый? например, заменить все бинды к IO на обычный вызов функции в каком-то IR. По каким-то хитрым правилам преобразовывать иммутабельные операции в мутабельные, когда есть 100% гарантия, что существует только одна ссылка на экземпляр. Ну и к этому скорее всего нужен еще no-gc менеджемнт памяти, скорее всего.
Forwarded from p0lunin (#GoatLivesMatter)
Чтобы писать было просто, сделали переусложненный веб
Код будем генерировать нейросеточками, киберпанк который мы заслужили
Forwarded from Woof
Чтобы что то купить надо чтобы это что то кто то написал
Forwarded from Deleted Account
один иф и тем более без була это так и должно быть