https://jetbrainsuniverse.timepad.ru/event/682524/

Про сложность ФП и F#. Тут нужно обращаться к мастерам религиозных проповедей. :) Например, к докладу "Simple Made Easy" Рича Хикки. Ты говоришь, что ФП и F# — это сложно, а потом показываешь пример, который требует понимания "partial application, currying, bind, pipelines". В этом смысле сложность противопоставляется понятию easy/familiarity. Это сложно, потому что непривычно, незнакомо. Kotlin делает ставку на привычность, он хорошо заходит тем, кто знает Java или C#. Стиль кода на F# изменяется в процессе обучения, ознакомления. Никто не запрещает писать в привычном C# или Python стиле, мутабельно, со стейтфул ООП иерархиями, не задумываясь о сайд-эффектах, внедряя кучи зависимостей. В итоге можно услышать законное "фи" от товарищей. Но кого это волнует, когда нужно решить задачу? ;) В чем профит? Когда ФП язык становится знакомым и привычным, то сложность (в смысле complexity) уменьшается: композиция, иммутабельность, чистота, dependency rejection, DDD — это действительно хорошие идеи. Все это можно испортить неидиоматичным кодом, бороться можно чтением: - fsharpforfunandprofit.com - http://blog.ploeh.dk @forcewake

Все, я закончил с писаниной на сегодня. :)

Люди, а что - на F# нет генератора статических сайтов?

Люди, а что - на F# нет генератора статических сайтов?

FsBlog, Fornax. Кажется, оба неживые. :(

Люди, а что - на F# нет генератора статических сайтов?

могу посоветовать nuxt =) https://nuxtjs.org/guide#static-generated-pre-rendering-

могу посоветовать nuxt =) https://nuxtjs.org/guide#static-generated-pre-rendering-

не хочу ЖС

вот какой-то DocFX нашёл

а не, оно в основном для документации

Насчёт dsl, кстати,нормальным путем ещё будет написание type provider, который строит типы на базе простого языка правил, например

Насчёт dsl, кстати,нормальным путем ещё будет написание type provider, который строит типы на базе простого языка правил, например

Сложно. :)

Но там надо что-то думать с динамической компиляцией сборок

Но там надо что-то думать с динамической компиляцией сборок

А что думать?

А что думать?

Ну если правила в рантайме менять

Поменял- перекомпилил сборку

А часто возникает необходимость?

Про сложность ФП и F#. Тут нужно обращаться к мастерам религиозных проповедей. :) Например, к докладу "Simple Made Easy" Рича Хикки. Ты говоришь, что ФП и F# — это сложно, а потом показываешь пример, который требует понимания "partial application, currying, bind, pipelines". В этом смысле сложность противопоставляется понятию easy/familiarity. Это сложно, потому что непривычно, незнакомо. Kotlin делает ставку на привычность, он хорошо заходит тем, кто знает Java или C#. Стиль кода на F# изменяется в процессе обучения, ознакомления. Никто не запрещает писать в привычном C# или Python стиле, мутабельно, со стейтфул ООП иерархиями, не задумываясь о сайд-эффектах, внедряя кучи зависимостей. В итоге можно услышать законное "фи" от товарищей. Но кого это волнует, когда нужно решить задачу? ;) В чем профит? Когда ФП язык становится знакомым и привычным, то сложность (в смысле complexity) уменьшается: композиция, иммутабельность, чистота, dependency rejection, DDD — это действительно хорошие идеи. Все это можно испортить неидиоматичным кодом, бороться можно чтением: - fsharpforfunandprofit.com - http://blog.ploeh.dk @forcewake

Шикарный пост!

Про сложность ФП и F#. Тут нужно обращаться к мастерам религиозных проповедей. :) Например, к докладу "Simple Made Easy" Рича Хикки. Ты говоришь, что ФП и F# — это сложно, а потом показываешь пример, который требует понимания "partial application, currying, bind, pipelines". В этом смысле сложность противопоставляется понятию easy/familiarity. Это сложно, потому что непривычно, незнакомо. Kotlin делает ставку на привычность, он хорошо заходит тем, кто знает Java или C#. Стиль кода на F# изменяется в процессе обучения, ознакомления. Никто не запрещает писать в привычном C# или Python стиле, мутабельно, со стейтфул ООП иерархиями, не задумываясь о сайд-эффектах, внедряя кучи зависимостей. В итоге можно услышать законное "фи" от товарищей. Но кого это волнует, когда нужно решить задачу? ;) В чем профит? Когда ФП язык становится знакомым и привычным, то сложность (в смысле complexity) уменьшается: композиция, иммутабельность, чистота, dependency rejection, DDD — это действительно хорошие идеи. Все это можно испортить неидиоматичным кодом, бороться можно чтением: - fsharpforfunandprofit.com - http://blog.ploeh.dk @forcewake

Мне нравится что дискуссия переходит уже в формат блог постов)

Насчёт dsl, кстати,нормальным путем ещё будет написание type provider, который строит типы на базе простого языка правил, например

Так недавно же @gsomix постил ссылку

А часто возникает необходимость?

Ну тут фиг знает, на самом деле. Но из более-менее практических задач,в которых это может потребоваться, например, построение воркфлы

Идея в том, что, изменяя метаданные, получаем кусок кода, который эти данные нормально процессит

Но это больше в скриптинге нужно

И правда модный сайт сделали. http://websharper.com/

Только сейчас посмотрел. :)

И скриншоты из vscode. Отлично!

Про сложность ФП и F#. Тут нужно обращаться к мастерам религиозных проповедей. :) Например, к докладу "Simple Made Easy" Рича Хикки. Ты говоришь, что ФП и F# — это сложно, а потом показываешь пример, который требует понимания "partial application, currying, bind, pipelines". В этом смысле сложность противопоставляется понятию easy/familiarity. Это сложно, потому что непривычно, незнакомо. Kotlin делает ставку на привычность, он хорошо заходит тем, кто знает Java или C#. Стиль кода на F# изменяется в процессе обучения, ознакомления. Никто не запрещает писать в привычном C# или Python стиле, мутабельно, со стейтфул ООП иерархиями, не задумываясь о сайд-эффектах, внедряя кучи зависимостей. В итоге можно услышать законное "фи" от товарищей. Но кого это волнует, когда нужно решить задачу? ;) В чем профит? Когда ФП язык становится знакомым и привычным, то сложность (в смысле complexity) уменьшается: композиция, иммутабельность, чистота, dependency rejection, DDD — это действительно хорошие идеи. Все это можно испортить неидиоматичным кодом, бороться можно чтением: - fsharpforfunandprofit.com - http://blog.ploeh.dk @forcewake

По гайдлайнам ещё кстати не рекомендуется всякие операторы-рыбки добавлять, из-за читаемости и новых людей

По гайдлайнам ещё кстати не рекомендуется всякие операторы-рыбки добавлять, из-за читаемости и новых людей

Злоупотребление ими это слишком, да

И правда модный сайт сделали. http://websharper.com/

Интересно, какую нагрузку держит

Чем там Антон Молдован пользовался на докладе, чтобы сайт нетфеста свалить? :)

Чем там Антон Молдован пользовался на докладе, чтобы сайт нетфеста свалить? :)

Гатлинг

Но надо же референсное железо и все такое

Я больше про перформанс вебшарпера, чем про конкретный сайт)

А, тю.

Неправильно понял.

А есть какой-нить способ создания, не знаю, именнованных дженерик констрейнтов или че-нить такого? У меня есть вот такая лапша: let get<'ResourceId when 'ResourceId: struct and 'ResourceId: comparison and 'ResourceId: (new: unit -> 'ResourceId) and 'ResourceId:> ValueType> connectionString (resourceId: 'ResourceId) = И ровно такая же пачка констрейнтов используется еще в паре мест. Можно как-нить избежать копипасты?

также, имхо, странно, что компилятор заставляет указывать и 'a: struct и a:> ValueType. Но если убрать одно из двух - ругается

также, имхо, странно, что компилятор заставляет указывать и 'a: struct и a:> ValueType. Но если убрать одно из двух - ругается

Это не баг?

Это не баг?

ну я не знаю. Для меня выглядит багом, но можт я чего не догоняю. Вот с вами удивлением и поделился)

А есть какой-нить способ создания, не знаю, именнованных дженерик констрейнтов или че-нить такого? У меня есть вот такая лапша: let get<'ResourceId when 'ResourceId: struct and 'ResourceId: comparison and 'ResourceId: (new: unit -> 'ResourceId) and 'ResourceId:> ValueType> connectionString (resourceId: 'ResourceId) = И ровно такая же пачка констрейнтов используется еще в паре мест. Можно как-нить избежать копипасты?

Блин, никак. Надо бы снова поднять обсуждение алиасов для ограничений.

Это не баг?

я еще думал, что (new: unit -> 'a) должен поглощаться страктом. Но, видимо, хоть для платформы это равнозначно, для фшарпа не всегда справедливо, например, в случае [<Struct>] DU

Блин, никак. Надо бы снова поднять обсуждение алиасов для ограничений.

ишью на гитхабе или как и где такие обсуждения поднимаются?

ишью на гитхабе или как и где такие обсуждения поднимаются?

https://github.com/fsharp/fslang-suggestions/issues/456

https://github.com/fsharp/fslang-suggestions/issues/456

о, он вот так предлагает https://gist.github.com/dsyme/bfed2eed788c7ba58ccc

Я правда не понял, где там его аргументация против этого предложения

о, он вот так предлагает https://gist.github.com/dsyme/bfed2eed788c7ba58ccc

Это не работает для дженериков в определении типов, вон там @blumu пишет

Подскажите, чего не хватает в старенькой статье о вышеупомянутых *Computation Expressions* и *монадах* ? https://habrahabr.ru/post/108184/ [выдерска из статьи: "Помимо асинхронных вычислений монады позволяют реализовать другие вкусности, такие как list comprehension, continuation, превращение грязных функций в чистый блок, через который неявно протаскивается состояние, и множество других. " ]

> Цель этой заметки — введение в асинхронное программирование и computation expressions в Nemerle ?

Подскажите, чего не хватает в старенькой статье о вышеупомянутых *Computation Expressions* и *монадах* ? https://habrahabr.ru/post/108184/ [выдерска из статьи: "Помимо асинхронных вычислений монады позволяют реализовать другие вкусности, такие как list comprehension, continuation, превращение грязных функций в чистый блок, через который неявно протаскивается состояние, и множество других. " ]

Я не понял, в чем вопрос.

> Цель этой заметки — введение в асинхронное программирование и computation expressions в Nemerle ?

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

Я не понял, в чем вопрос.

Что нужно добавить, чтобы лучше понимать как всё устроено на F# (новичкам ФП, если хотите)

Это не работает для дженериков в определении типов, вон там @blumu пишет

да, хреново. Никак не выходит

Что нужно добавить, чтобы лучше понимать как всё устроено на F# (новичкам ФП, если хотите)

Есть отличная серия статей: https://fsharpforfunandprofit.com/series/computation-expressions.html

Есть отличная серия статей: https://fsharpforfunandprofit.com/series/computation-expressions.html

Спасибо, ознакомлюсь!

Спасибо, ознакомлюсь!

Там весь сайт целиком стоит почитать.

я еще думал, что (new: unit -> 'a) должен поглощаться страктом. Но, видимо, хоть для платформы это равнозначно, для фшарпа не всегда справедливо, например, в случае [<Struct>] DU

хорошая замена (new: unit -> 'a) - использовать Unchecked.default<'a> на структурах - -1 условие

хорошая замена (new: unit -> 'a) - использовать Unchecked.default<'a> на структурах - -1 условие

Ага, вариант. Но я хотел без грязных приемов, хотя тут достаточно безопасно

Привет.

Привет!

Привет!

Вот! Поведение не бота)

Привет!

Привет)

Хех, я глянул, что сюда всякие интересности выкладывают, вот и присоединился)

https://twitter.com/jrlarsen/status/973883266729168896?s=09

https://github.com/fsharp/fslang-design/commit/4e3c03cd7a46227cc291d2cd334e4bf721a483d3

https://github.com/dotnet/cli/issues/8697 Наконец ответили, что пофикшено)

https://github.com/dotnet/cli/issues/8697 Наконец ответили, что пофикшено)

Уиии!! ?

Привет.

Здравствуй

Почему в F# discriminated unions (и в частности Option) реализованы как классы, а не как структуры?

Nullable в C# - структура

Это хороший вопрос.

Потому что раньше F# вообще не умел в создание структур. К тому же когда вышел 4.1 у некоторых бурлило от того, что структурный Result в ряде случаев оказался медленее Choice.

Мне кажется, что об этом просто не задумывались (struct option, struct choice), когда проектировали.

Но профит от смены ref на value не всегда очевидный, иногда его может и не быть.

Я тут RFC писал, частично захватывающий этот вопрос (про Option). https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1039-struct-representation-for-active-patterns.md

Потому что раньше F# вообще не умел в создание структур. К тому же когда вышел 4.1 у некоторых бурлило от того, что структурный Result в ряде случаев оказался медленее Choice.

Только не структур вообще, а struct DU/records/tuples.

потому что в общем случае DU рекурсивные

Не знал.

Мне кажется, что об этом просто не задумывались (struct option, struct choice), когда проектировали.

Option в виде класса тормозной выходит. На C# запилил два вида Option (оба - структуры), один обертывает nullable, второй reference. Универсальный можно, но будет оверхед для ссылочных типов. Над выводом типов и различением перегрузок в C# обрыдался.

Option в виде класса тормозной выходит. На C# запилил два вида Option (оба - структуры), один обертывает nullable, второй reference. Универсальный можно, но будет оверхед для ссылочных типов. Над выводом типов и различением перегрузок в C# обрыдался.

Про перфоманс чего-либо есть стандартный ответ в стиле Акиньшина — зависит. :)

На нынешней работе аллокации без нужды есть абсолютное зло :)

Я столкнулся первый раз с этой проблемой, когда коллега 50 лярдов опшнов в памяти держал (нада)

Я столкнулся первый раз с этой проблемой, когда коллега 50 лярдов опшнов в памяти держал (нада)

Как решил?

На нуллаблы переделали

На нуллаблы переделали

Можно же свой struct option сделать

Зачем, если это Nullable?

Nullable менее удобен

Потому что можно! Чтоб матчинг использовать и все такое

Да просто для единообразия, на самом деле

Зачем, если это Nullable?

У Nullable дизайн овно. Value может бросить исключение и этим все сказано

У Nullable дизайн овно. Value может бросить исключение и этим все сказано

Защититься через myNullable.HasValue?

/shrug