На этом и закончим, пожалуй.

Точнее не пропогандируют а в отличае от большинства они не делят на чистое ООП и ФП. Такое деление только на низком уровне есть.

Вообщем еще раз извиняюсь

== Вы просто в силу того что не знаете то о чем говорите думаете что они убивают ФП на всякий случай я ничего подобного не говорил. И чтобы раставить точки над ё - право называть идиотами кого бы то ни было столь же не зыблемо, как и ваше право кого бы то ни было уважать. Тут конечно вопрос в аргументации, но я не думаю что такая дисскуссия будет здесь уместной. Просто каждый отсанется при своём мнение а желающий сами проанализируют является ли Фаулер идиотом или великим гуру как его позиционируют

тяжелый сегодня день какой-то

не конструктивненько, давайте лучше про монады

Давайте лучше код писать. :)

уже вечер, отдыхать тоже нужно когда-то :)

Окай, код для петов писать

https://www.youtube.com/watch?v=7Zlp9rKHGD4

Помните задачу про температуру ? Можно на сайте замутить сборник таких задач с предложением решений и голосовалкой за лучшее решение.

@Mblkolo Пожалуйте. :)

Я вкатился вот с каким волнующим меня вопросом: кто-нибудь ощутил профит от F# ?

В чем профит должен выражаться

?

это не спор о том, какой язык лучше, а вопрос о том, где F# полезнее для разработчик C#. Исхожу из того что универсальных языков нет.

Расширяет арсенал навыков, позволяет писать более чистый код, имхо

это абстрактно. я поизучал интерактивные примеры на http://fsharp.org/learn.html Погуглил что-то типа "F# на практики", но пока не понял где я это смогу использовать.

С ходу профиты могу назвать такие: проще код, меньше шансов ошибиться.

слышал что C# многословаен по сравнению с F#

@Mblkolo Использовать можно для тех же задач, что и C#. Но нужно учитывать, что могут разные инструменты использоваться, или например, в некоторых местах поддержка F# не такая крутая как у C#.

такая мысль: Я могу взять свою лабиринт на сокетах, переписать на F# и понять что было лучше, а что хуже. А могу спросить здесь, где кто-нибудь полюбому уже проходил такой путь :)

это не спор о том, какой язык лучше, а вопрос о том, где F# полезнее для разработчик C#. Исхожу из того что универсальных языков нет.

создавать динамические запросы в EF

@Mblkolo Мы можем быть немного предвзяты. :) Лучше самому попробовать. Просто ответ на твой вопрос довольно большой и сложный. Обычно упоминают самое простое: меньше кода, почти нет проблем с null, удобно описывать предметную область в типах, сложно испортить хорошо написанный код.

Много всего, и у всех разный опыт. :)

Ну а может у кого-то есть истории успеха, типа "переписал/написал на F# и так хорошо получилось", в идеале с ссылкой на репу ?

Я вкатился вот с каким волнующим меня вопросом: кто-нибудь ощутил профит от F# ?

Ну, я у себя в коде использовал units of measure и поймал несколько неприятных багов в физической симуляции.

Любой инструмент, который думает за меня, и позволяет такие проблемы выловить — хороший.

Оба языка для общих задач, с# довольно мощный сам по себе, так что сходу не увидеть плюсов, кроме как в краткости синтаксиса. В целом язык подталкивает к более корректному коду, даже если писать в ООП стиле, например заставляет использовать интерфейсы, а не конкретные реализации. Например type ILogger = abstract member Log: 't -> unit type LoggerClass() interface ILogger// не помню синтаксис имплементации интерфейса member Log s -> printfn "%A" let logger = LoggerClass() logger.Log(1) // не существует т.к. Надо привести к интерфейсу ILogger, но обычно явно никто не приводит и используют let log (logger:ILogger) obj = logger.Log obj

Сразу не поймёшь, почему такое "неудобство" это хорошо, но когда приучаешься программировать на интерфейсах, то понимаешь, что избежал кучи ошибок

Оба языка для общих задач, с# довольно мощный сам по себе, так что сходу не увидеть плюсов, кроме как в краткости синтаксиса. В целом язык подталкивает к более корректному коду, даже если писать в ООП стиле, например заставляет использовать интерфейсы, а не конкретные реализации. Например type ILogger = abstract member Log: 't -> unit type LoggerClass() interface ILogger// не помню синтаксис имплементации интерфейса member Log s -> printfn "%A" let logger = LoggerClass() logger.Log(1) // не существует т.к. Надо привести к интерфейсу ILogger, но обычно явно никто не приводит и используют let log (logger:ILogger) obj = logger.Log obj

@Mblkolo

И это только один из многих плюсов

слышал что C# многословаен по сравнению с F#

зато не ломаешь себе голову всякими <|> <%>

и прочими радостями

я за многословность в этом контексте

зато не ломаешь себе голову всякими <|> <%>

Этого можно и избежать

зато не ломаешь себе голову всякими <|> <%>

обычно все эти <|> описаны сверху модуля, и сильно сокращают код. А вот в API библиотек их уже стараются не вставлять, дублируют computation expression'ами

Любой инструмент, который думает за меня, и позволяет такие проблемы выловить — хороший.

А вот это прям удваиваю

@neftedollar спасибо

Кто-нибудь тестил новый Xamarin Live Player? Что-то он с F# отказывается работать, только C#.

У кого-нибудь был опыт разработки под Unity на F#?

У кого-нибудь был опыт разработки под Unity на F#?

Я вроде узнавал в свое время, он его не поддерживает.

Я вроде узнавал в свое время, он его не поддерживает.

Ну вообще через какие-то костыли сделать можно

Хотя официальной поддержки, конечно же, нет

вовсе нет. достаточно рефлективно найти всех потомков класса и проанализировать проверку их в switch

вы предлагаете делать в рантайме компиль тайм чек с помощью рефлекшена? Звучит странно. А можно узнать идею как вы делаете в Roslyn это?

Тему с DU обсудили вроде. Вот мне еще понравилось, что замыкания в Fsharp сериализуются. Это например позволило мне на одной из работ сделать весьма интересную вещь. Через компутейшн експрешшн можно описать функцию с тербованиями к среде выполнения типа колчисетво памяти свободной, нагрузка на cpu, загруженный в память большой датасет. Тоесть функция исполняется и как только у нее есть требование дальше исполняться с определенным условием, она прерывается и сообщает рантайму требование. Рантайм находит подходящую ноду в кластере, сериализует замыкание и передает ее в рантайм другой ноды.

До этого все было описано с помощью стандартных паттернов распределенных приложений и это был геморой.

Прадва сейчас есть акка нет и орлеанс, так что немного уже не в кассу. Хотя теже акторы можно использовать как рантайм для вышеописанной системы.

У кого-нибудь был опыт разработки под Unity на F#?

https://github.com/bryanedds/Nu

это конечно, не unity

Это 2D :)

нуок

@Dolfik https://developer.xamarin.com/guides/cross-platform/urho/fsharp-and-urhosharp/

кстати, на monogame fsharp отлично ложится

@fvnever --warnaserror:25

Не позволяет компилировать incomplete pattern matches.

@azazeo Где взял стикеры с Ленойдроид? :)

В споре о SRP и SOLID + plugins (расширяемая архитектура), где можно реально увидеть примениние Reader вместо DI на большом комлексном разрешении зависимостей? Или не получится без Хаскель?

В споре о SRP и SOLID + plugins (расширяемая архитектура), где можно реально увидеть примениние Reader вместо DI на большом комлексном разрешении зависимостей? Или не получится без Хаскель?

> примениние Reader вместо DI Это первый шаг. На втором, ты понимаешь что нужно Dependency Rejection, а не DI ? Я реально вташил Reader в уже написанный проект и смотрел как он размазывается по иерархие вызовов. (прав был Эрик Майер, что засунув один раз монаду - она расползется по всей программе) В итоге выкинул все на фиг и переписываю на pure domain.

вы предлагаете делать в рантайме компиль тайм чек с помощью рефлекшена? Звучит странно. А можно узнать идею как вы делаете в Roslyn это?

Нет. Тут речь о проверке кода с помощью стат. анализатора Roslyn в виде расширения для VS2017 либо standalone. Я не предлагаю, лично я для таких целей использовал бы FCS. вот выяснил сегодня что там, где я работаю, его применяют для анализа деструтуризации типов-сумм в теле операторов switch в C# коде.

Нет. Тут речь о проверке кода с помощью стат. анализатора Roslyn в виде расширения для VS2017 либо standalone. Я не предлагаю, лично я для таких целей использовал бы FCS. вот выяснил сегодня что там, где я работаю, его применяют для анализа деструтуризации типов-сумм в теле операторов switch в C# коде.

FSC FSharp Compiler Service? Его применяют?)

конечно, в райдере же например

для плагинов

была статья автора ionide где он это описывал

ну и вообще для кодогенерации динамической

http://kcieslak.io/Dynamically-extending-F-applications

ERROR: S client not available

Блин, такая печаль. Используешь AppSettingsTypeProvider, а его ConnectionStrings нельзя использовать с SQLProvider =/

постоянно натыкаюсь на это и постоянно расстраиваюсь

> примениние Reader вместо DI Это первый шаг. На втором, ты понимаешь что нужно Dependency Rejection, а не DI ? Я реально вташил Reader в уже написанный проект и смотрел как он размазывается по иерархие вызовов. (прав был Эрик Майер, что засунув один раз монаду - она расползется по всей программе) В итоге выкинул все на фиг и переписываю на pure domain.

Смотрел про Dependency Rejection. Идея для меня слилась в вынесении зависимостей максимально вверх. Так это и так понятно в функционалке. А вот как это делать на микро уровне. Пример. Есть набор контрактов в десяти билиотеках. Их сериализатором пропихивают в очередь MQ. MQ то же не один. Сериализаторов несколько. Опора идет на типы объектов. Меняется топология. Ее надо унести в настройки, поскольку система дышит. Минимально надо реализацию Convertible, Serializable, Routable трейтов на каждом объекте, как вижу сейчас. Надо эту реализацию конфигурировать. Вот и не знаю как впихать более менее в управляемом виде. Знаю как с трейтами в Scala и Хаскеле. А как без них - просто уперся

Смотрел про Dependency Rejection. Идея для меня слилась в вынесении зависимостей максимально вверх. Так это и так понятно в функционалке. А вот как это делать на микро уровне. Пример. Есть набор контрактов в десяти билиотеках. Их сериализатором пропихивают в очередь MQ. MQ то же не один. Сериализаторов несколько. Опора идет на типы объектов. Меняется топология. Ее надо унести в настройки, поскольку система дышит. Минимально надо реализацию Convertible, Serializable, Routable трейтов на каждом объекте, как вижу сейчас. Надо эту реализацию конфигурировать. Вот и не знаю как впихать более менее в управляемом виде. Знаю как с трейтами в Scala и Хаскеле. А как без них - просто уперся

для таких систем наверное DI с интерфейсами и много много тестов

Смотрел про Dependency Rejection. Идея для меня слилась в вынесении зависимостей максимально вверх. Так это и так понятно в функционалке. А вот как это делать на микро уровне. Пример. Есть набор контрактов в десяти билиотеках. Их сериализатором пропихивают в очередь MQ. MQ то же не один. Сериализаторов несколько. Опора идет на типы объектов. Меняется топология. Ее надо унести в настройки, поскольку система дышит. Минимально надо реализацию Convertible, Serializable, Routable трейтов на каждом объекте, как вижу сейчас. Надо эту реализацию конфигурировать. Вот и не знаю как впихать более менее в управляемом виде. Знаю как с трейтами в Scala и Хаскеле. А как без них - просто уперся

Извини, мне сложно осознать твою проблему (много букв ? - видимо накипело), тк я в основном мобильный девелопер.

Тему с DU обсудили вроде. Вот мне еще понравилось, что замыкания в Fsharp сериализуются. Это например позволило мне на одной из работ сделать весьма интересную вещь. Через компутейшн експрешшн можно описать функцию с тербованиями к среде выполнения типа колчисетво памяти свободной, нагрузка на cpu, загруженный в память большой датасет. Тоесть функция исполняется и как только у нее есть требование дальше исполняться с определенным условием, она прерывается и сообщает рантайму требование. Рантайм находит подходящую ноду в кластере, сериализует замыкание и передает ее в рантайм другой ноды.

"Вот мне еще понравилось, что замыкания в Fsharp сериализуются. " - это как же они сериализуются?

А это сервер, в кластере. С микросервисами. Здоровый (размер). Самое то для функционалки. И народ не против. Но как опыта не хватает, что ли.

Конкретно в F#

Конкретно в F#

в F# ad-hock полиморфизма нет. и видимо никогда не будет

Вся команда .NET. На C# получается уже непотребно. На F# лучше, но как без рук плавать...

@ruzzke_mir Не совсем корректно. Ad hoc полиморфизм есть, нету трейтов/тайпклассов.

Я тут по этому поводу уже шумел. Их ДЕЙСТВИТЕЛЬНО не хватает.

Вся команда .NET. На C# получается уже непотребно. На F# лучше, но как без рук плавать...

тогда может все же reader?

Для Reader опять же не хватает монадных трансформеров

Для Reader опять же не хватает монадных трансформеров

https://tech.jet.com/blog/2016/06-16-inversion-control-f/ посмотрите тут, у ребят тоже микросервисная архитектура

@ruzzke_mir Не совсем корректно. Ad hoc полиморфизм есть, нету трейтов/тайпклассов.

Как минимум обсуждения не прекращаются: https://github.com/fsharp/fslang-suggestions/issues/243#issuecomment-303387800

Получается какой то недо функционал, с кучей интерфейсо и их размазанной реализацией ?

"Вот мне еще понравилось, что замыкания в Fsharp сериализуются. " - это как же они сериализуются?

https://stackoverflow.com/questions/29062716/why-are-f-closures-serializable

https://stackoverflow.com/questions/29062716/why-are-f-closures-serializable

Посмотри на MBrace

Посмотри на MBrace

Мбрейс я смотрел.

Теоретически, при равных рефах, мжно поробовать кинуть асинки

Использовать Reader для DI по мне так сомнительная идея. Я сам как то думал на эту тему и пришел к выводу что fp это чистые функции и надо просто описать ast как DU далее все это описываем через копутейшн експрешшенс далее функции генерят Ast который уже попадает в интерпретатор.

Использовать Reader для DI по мне так сомнительная идея. Я сам как то думал на эту тему и пришел к выводу что fp это чистые функции и надо просто описать ast как DU далее все это описываем через копутейшн експрешшенс далее функции генерят Ast который уже попадает в интерпретатор.

Но есть проблемы 1 это скорость 2 сложность

@ruzzke_mir Не совсем корректно. Ad hoc полиморфизм есть, нету трейтов/тайпклассов.

то, что есть, выглядит примерно так let inline updateTable(table: ^T when ^T : (member Update : SqlConnection option*SqlTransaction option*int option -> int)) = (^T : (member Update : SqlConnection option*SqlTransaction option*int option-> int) (table, None, None, None)) И имеет много досадных ограничений

@ruzzke_mir Да, я знаю.

Опять же натягиваем DSL без макросов - как то не айс

Надо радоваться, что без макросов. :)

Старое описалово мое подхода тут. Но там уже в ретроспективе я понял что слишком нагородил, ну и устарело как всегда http://hodzanassredin.github.io/2016/02/12/ddd_with_dsl_monad.html

Вот тут я совсем не согласен. Чуть чуть изменить тайп провайдеры - и макросы есть.

Вам хочется поддерживать код с макросами?

А вы пробовали? Я поддерживал, с гигиеной. В команде. С DSL. Кода стало в 5 раз меньше. А страх -это естественно. Зато - copy-paste в замену. И на 34000 файлах поддержка.

И это небольшой проект. Так и до 150000 доходило. И в каждом копи -пейст. Команду надо, извините, дрессировать в хорошем смысле ?