Все нравится, кроме дебагинга.

В проде C# использую уже третий месяц.

А проект большой?

Большой

Самое странное, я смотрел около айтишное интервью Тинькова на РБК и он там старательно избегал упоминания Scala. Плюс слушал подкаст с разработчиками из Тинькова и у меня сложилось впечатление что Scala туда проникла случайно, а самому владельцу бизнеса какбы все равно на чём у них пишут.

Ведь изначально банк был вообще покупной. А потом когда там появились штатные программисты, так получилось что они были скалистых и все понеслось. Так мне кажется и нужно двигать язык. Как я говорил сейчас IT это "набрать готовых решений и склеить их своей бизнес логикой", почему бы на это не взять F#

10 прожектов в солюшене

все летает

Много удобств. Очень нравится live редактирование при поиске по ctrl+shift+f

10 прожектов в солюшене

Это не очень большой. Меня скорее интересует что-то около 100 проектов в солюшене и 1кк строк кода. С таким его пробовали?

Такого продакшена у меня нету =(

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

Ведь изначально банк был вообще покупной. А потом когда там появились штатные программисты, так получилось что они были скалистых и все понеслось. Так мне кажется и нужно двигать язык. Как я говорил сейчас IT это "набрать готовых решений и склеить их своей бизнес логикой", почему бы на это не взять F#

Я немножко писал продакшен на скала) Там центральная идея - боль, боль во всём. Мне кажется ими там движет подсознательная тяга к прокрастинации. Днями напролет писать интерфейсы, потом писать код, склеивающий свои интерфейсы, потом адаптеры делать из чужих интерфейсов в свои, думать, какой тип поставить: +Req или -Req, сочинять flatMap для собственной реализации Future. Это активность, которую трудно зафейлить - по крайней мере, провал будет виден далеко не сразу, и вообще психологически легко от него дистанцироваться, найдя проблему в чем-нибудь другом)

Я немножко писал продакшен на скала) Там центральная идея - боль, боль во всём. Мне кажется ими там движет подсознательная тяга к прокрастинации. Днями напролет писать интерфейсы, потом писать код, склеивающий свои интерфейсы, потом адаптеры делать из чужих интерфейсов в свои, думать, какой тип поставить: +Req или -Req, сочинять flatMap для собственной реализации Future. Это активность, которую трудно зафейлить - по крайней мере, провал будет виден далеко не сразу, и вообще психологически легко от него дистанцироваться, найдя проблему в чем-нибудь другом)

Ну таким почти в любом языке можно заниматься, если честно.

А райдер нормально F# поддерживает?

А райдер нормально F# поддерживает?

- repl нет, рефакторинг вообще не работают, core clr нет (вроде) + подсветка ошибок есть

Да только недавно начал. Я сам вот первый проект запустил. Ребята его под линуксом и вендой собрали. Я первопроходец по части мака и райдера =)

Сейчас вот при вас тестирую =)

Я удивлен, что он вообще собирает без проблем.

Ну таким почти в любом языке можно заниматься, если честно.

только в _принципиально_ академических. В простых (а Скала на много сложнее Хаскеля), или легких в изучении, или стройных и красивых языках таким трудно заниматься. В F# например

- repl нет, рефакторинг вообще не работают, core clr нет (вроде) + подсветка ошибок есть

"repl нет" - как можно вообще хоть что-то произвести без repl я хз)

только в _принципиально_ академических. В простых (а Скала на много сложнее Хаскеля), или легких в изучении, или стройных и красивых языках таким трудно заниматься. В F# например

Я бы не сказал. Посмотри, например, на реализацию монад и тайпклассов в FSharpPlus. Были бы нормальные возможности в языке - это сделали бы куда проще. Проблема скалы в community, а не в самом языке. Типа, ой чуваки, а давайте в следующей мажорной версии ОРМ обернём все запросы в свою доморощенную монаду IO с дополнительной поддержкой контроля побочных эффектов, а потом посмеёмся над теми, кто будет на эту следующую версию переходить.

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

полагаешь FSharpPlus кто-то использует? таки нет, это эксперимент такой курьёзный имхо. чтобы использовать монады как абстракцию в F# достаточно коробочных средств. Отсутствие тайп-классов - это не есть та проблема, из за которой ЯП сильно страдает в данном случае. Если оценить объём доп. повторяющегося кода, который пишется из за их отсутсвия, так это ерунда в сравнении с проблемами, которые потенциально создали бы тайп-классы. Ты наверное просто не читал обсуждения этой темы с Доном Саймом, оч рекомендую ознакомиться

Ну таким почти в любом языке можно заниматься, если честно.

это делают действительно очень умные люди и грамотные инженеры в тинькофф если что) отнюдь не дураки

полагаешь FSharpPlus кто-то использует? таки нет, это эксперимент такой курьёзный имхо. чтобы использовать монады как абстракцию в F# достаточно коробочных средств. Отсутствие тайп-классов - это не есть та проблема, из за которой ЯП сильно страдает в данном случае. Если оценить объём доп. повторяющегося кода, который пишется из за их отсутсвия, так это ерунда в сравнении с проблемами, которые потенциально создали бы тайп-классы. Ты наверное просто не читал обсуждения этой темы с Доном Саймом, оч рекомендую ознакомиться

О! Было бы интересно почитать это обсуждение. Если не сложно, можешь сказать по каким ключевым словам это можно нагуглить?

полагаешь FSharpPlus кто-то использует? таки нет, это эксперимент такой курьёзный имхо. чтобы использовать монады как абстракцию в F# достаточно коробочных средств. Отсутствие тайп-классов - это не есть та проблема, из за которой ЯП сильно страдает в данном случае. Если оценить объём доп. повторяющегося кода, который пишется из за их отсутсвия, так это ерунда в сравнении с проблемами, которые потенциально создали бы тайп-классы. Ты наверное просто не читал обсуждения этой темы с Доном Саймом, оч рекомендую ознакомиться

Кстати, вот, например, как можно в F# описать, например, функцию, которая будет абстрагирована от монады, которая внутри используется?

По моему скромному мнению. Субъективно в России скала "популярное" уже сейчас. Например потому что есть компании состав ядра на скалу например банк Тинькофф. В моем понимания популярность измеряется возможностью заработать на любимом инструменте. Скала позволяет это сделать уже сегодня. Но для сообщества F# в том числе в России это серьёзный вызов. Как сделать так что бы бизнес-люди увидели в F# мощную энергию в виде возможности построения бизнеса на этой технологии.

Разумный текст

Кстати, вот, например, как можно в F# описать, например, функцию, которая будет абстрагирована от монады, которая внутри используется?

Поясни вопрос.

Поясни вопрос.

Ну, например, я хочу в библиотеке написать generic функцию, которая будет работать для любой монады, которую я ей передам. Как пример, sequence :: Monad m => [m a] -> m [a] из Control.Monad в хаскеле.

Ну, например, я хочу в библиотеке написать generic функцию, которая будет работать для любой монады, которую я ей передам. Как пример, sequence :: Monad m => [m a] -> m [a] из Control.Monad в хаскеле.

В f# работает другой подход. Монаду надо будет развернуть, и потом внутри твоего бинда надо будет применить ф-цию

В f# работает другой подход. Монаду надо будет развернуть, и потом внутри твоего бинда надо будет применить ф-цию

Хмм... не очень понимаю как это поможет, например, для указанной мной функции. Она принимает на вход список монад, bind'ит их последовательно и выдает монаду со списком. Где мы будем тут разворачивать монаду? И какой будет функция для внутренностей бинда? Нет ли в какой-нибудь библиотеке примера подобной реализации?

Хмм... не очень понимаю как это поможет, например, для указанной мной функции. Она принимает на вход список монад, bind'ит их последовательно и выдает монаду со списком. Где мы будем тут разворачивать монаду? И какой будет функция для внутренностей бинда? Нет ли в какой-нибудь библиотеке примера подобной реализации?

Ф-Цию надо строить по-другому, прост.

Ф-Цию надо строить по-другому, прост.

Ну вот меня и интересует где можно посмотреть пример такого подхода, если знаешь, где его можно посмотреть.

Ну вот меня и интересует где можно посмотреть пример такого подхода, если знаешь, где его можно посмотреть.

Я о таком не задумывался. т.к. Никогда не задумывался о тайпклассах. так что чходу не скажу

О! Было бы интересно почитать это обсуждение. Если не сложно, можешь сказать по каким ключевым словам это можно нагуглить?

ишшуи Visual F# про добавление в язык ad-hock полиморфизма

Кстати, вот, например, как можно в F# описать, например, функцию, которая будет абстрагирована от монады, которая внутри используется?

1) ни как 2) через ООПшные интерфейсы 3) задав для функции собственное вычислительное выражение, аналог do-нотации в Хаскель

@DogeShibu https://github.com/fsharp/fslang-suggestions/issues/243

Type classes и HKT -- это не самые важные сейчас вещи. Куда важнее поддержка .Net Core, улучшение поддержки со стороны IDE, наличие библиотек и доделка существующих языковых конструкций.

Type classes и HKT -- это не самые важные сейчас вещи. Куда важнее поддержка .Net Core, улучшение поддержки со стороны IDE, наличие библиотек и доделка существующих языковых конструкций.

именно так

Так можно же с помощью inline сэмулировать тайпклассы. С этим можно жить.

Pavel Это хак. :)

Главное, что работает :)

Но кто-то, кажется, это использует.

И даже пытается lightweight HKT соорудить.

Так можно же с помощью inline сэмулировать тайпклассы. С этим можно жить.

нет, нельзя ни съэмулировать ни нормально использовать

Почему? Инлайн функция неплохо с этим справляется.

Pavel Инлайн функция справляется с простеньким ad hoc поведением.

Но это не type classes, которые решают expression problem.

И даже FSharpPlus это не совсем то.

Почему? Инлайн функция неплохо с этим справляется.

Плохо справляется, не расширяемо. Если б инлайны учитывали extension-методы — тогда было бы нормально, а пока нет.

Ну то есть я не могу стороннему разработчику разрешить расширить мой тайпкласс для стороннего же типа.

Видимо, вот это и есть "expression problem".

Да, это оно. :)

Почему? Инлайн функция неплохо с этим справляется.

потому что 1) весь встраиваемый код должен быть в одной сборке 2) надо указывать жуткие констрайнты на каждое использование 3) это всё равно не GADT

Если кому-то будет вечером скучно, можно почитать про попытки захакать HKT. https://robkuz.github.io/Higher-kinded-types-in-fsharp-Intro-Part-I/

В реальных больших системах все равно типы предметной области расширяются в основном с помощью ООП интерфейсов, а стат. гарантии заменяются тестами. Это удобнее и проще для энтерпрайза

Тайп-классы щас стали болше холиварной темой чем практической. Мало кто представляет зачем они на практике нужны кроме учоных категорщиков. Но почти все уверены, что их поддержка необходима просто "чтобы было"

А какие реальные проблемы они решают?

Vasily The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).

Как обычно, расширение поведения и возможных типов данных.

А какие реальные проблемы они решают?

ну например сделать функцию show,которая будет принимать любой тип, реализующий некоторый тайп-класс, и возвращать строку

А,ясно,сову на глобус,значится

и чтобы всё компилятором проверялось

В c# extension вроде похожи

Или это не про то?

А,ясно,сову на глобус,значится

ну почему же, это удобно. Вот в F# есть Option.bind, Result.bind, Async.bind Seq.bind и т.д., - это не удобно, они все делают в сущности одно и то же. А в хаскеле - Control.Monad

ERROR: S client not available

Или это не про то?

не про то

Vasily Похоже, но чуть мощнее. В случае C# extensions ты не можешь потребовать, чтобы тип реализовывал какие-то экстеншены. То есть экстеншены никак в типе не отражаются.

Я правильно понимаю, что это вроде паршиал классов в разных сборках?

Ну и расширение дефолтного поведения интерфейса

То,что называется mixin

Я правильно понимаю, что это вроде паршиал классов в разных сборках?

нет. Это - определить функцию, которая работает с любым типом, удовлетворяющем некоторым требованиям

Я правильно понимаю, что это вроде паршиал классов в разных сборках?

Да, очень похоже.

нет. Это - определить функцию, которая работает с любым типом, удовлетворяющем некоторым требованиям

То, что ты описал, примерно и делает inline. А к тайпклассам ещё добавляется требование, чтоб можно было их реализовать в любом месте кода, в т.ч. в другой сборке (это и есть expression problem, насколько я понимаю).

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

Интересно, generative type provider может расширить существующий тип?

То, что ты описал, примерно и делает inline. А к тайпклассам ещё добавляется требование, чтоб можно было их реализовать в любом месте кода, в т.ч. в другой сборке (это и есть expression problem, насколько я понимаю).

"реализовать в любом месте кода" логически следует из "любой тип"

"реализовать в любом месте кода" логически следует из "любой тип"

Ладно, для меня это вообще не связанные фразы, так что я просто не понял.

Проблема уровня il

Точнее cle

Clr

Разрешить объявлять типы в разных сборках

Нужно просто понимать, что если в языке А есть фича Б, то из этого вовсе не следует, что фича Б будет уместна и полезна в языке В. Это же касается например требований добавить дженерики в Го, те же тайп-классы в elm, гарантии не нуля в JS и т..п

Если я все правильно понял

По поводу уместности-реальной пользы не особо вижу

Меня больше удивляет, как часто это тема всплывает в F# комьюнити. :)

Хоть вводи счетчик "Дней без обсуждения необходимости type classes и HKT в F#: 0"

Хоть вводи счетчик "Дней без обсуждения необходимости type classes и HKT в F#: 0"

Надо добавить как-то с этим бороться!

С моей точки зрения фича красивая с точки зрения реализации, но адовая в продакшне с т.з. поддержки/изменений в коде

Т.е. в большом проекте она еще внесет неуправляемой сложности

Кстати, поглядел вчерашнюю статью, которую @ruzzke_mir линковал, там как раз проблема генериков через квотейшны обходится

let (deductionColumns : ColumnSpec<Deduction> list) = [ <@ fun (d) -> d.Date @> , [ showAlways ] , [ editAlways ] <@ fun (d) -> d.SectionCode @> , [ showForRevised ] , [ editWhenNil ] <@ fun (d) -> d.Amount @> , [ showForRevised ; showForGovt ] , [ editWhenNil ; editWhenDateIsPresent ] ]

type ColumnSpec<'T> = (Quotations.Expr * IsColumnVisible * IsColumnEditable<'T>)

Элегантное решение, кстати

Vasily А можно ссылку? Я пропустил.

https://medium.com/cleartax-engineering/code-as-data-structuring-business-rules-in-f-34cf05f083a2

Спасибо.

До меня наконец-то дошло, зачем там квотейшны