Зачем нужен эфшарф?

Но понять в каких случаях может пригодиться этот цирковой аналог скалы для стыдной планеты дотнета пока невероятно трудно.

NIH?

Разъясните, пожалуйста, как диванный теоретик, диванному теретику, что вы обнарежили похожего в этих настолько различных ЯП?

Так по приколу же.

этот цирковой аналог скалы

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

для стыдной планеты дотнета

ага, теперь понятно, почему сравнение со скалой

Это скорее ненужный эрзац-окамль для безумной планеты дотнета.

Суть всех подобных тредов: «Язык X не нужен, в нем нет фичи Fy, к которой я привык в языке Y!». Здесь вам не тут, а фшарп — не скала. Это недоокамль.

Наоборот, скала - это недоаналог эфшарпа.

Спроси у Профессора.

Раскройте мысль если не трудно

Я уже много-много раз писал. Порядком устал повторять. Сейчас почти вся мoлодежь фапает на Scala, и совершенно не воспринимает критику в ее адрес.

1. В Scala отсутствует адекватный синтаксический сахар для монад и моноидов в отличие от F#, в котором это присутствует. Пример полезной монады: F# async workflow. В Scala имитируется обычно через плагин продолжений. Пример полезного моноида в F#: последовательность с ключевым словом yield (есть такое еще в C# и, кажется, в питоне, но в F# последовательность можно возвращать как значение в любом месте кода).

2. В Scala совершенно дурацкие коллекции: методы вместо функций, из-за чего, кстати, возникает известный конфуз с невозможностью полноценно использовать Stream в цикле for. Кто видел, как эти коллекции устроены изнутри, тот в цирке не смеется.

3. С последним перекликается частое злоупотребление трейтами в Scala. Некоторые считают это проявлением очень плохого стиля проектирования. Одерский считает, видимо, иначе. На эту тему был конфуз в совместном интервью Дона Сайма, Армстронга и Одерского. Первые двое разошлись во мнении с третьим - говорили прямо противоположные вещи (сейчас искать пруф мне очень лень).

Да, добавлю еще такой пункт:

4. Как продолжение проблемы злоупотребления трейтами (в библиотеке коллекций). Могу ошибиться в точности формулировки, но по-моему стандартная библиотека Scala не влезает в дальвик из-за ограничения в последнем, кажется, максимально допустимого количество методов.

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

Тайпклассов нет.

И слава богу.

Вот модулей нормальных нет — это проблема.

2. В Scala совершенно дурацкие коллекции: методы вместо функций, из-за чего, кстати, возникает известный конфуз с невозможностью полноценно использовать Stream в цикле for. Кто видел, как эти коллекции устроены изнутри, тот в цирке не смеется.

Чем f# в данном случае лучше?

Мне нравятся, как сделаны коллекции в F#. Их совсем не так много как в Scala, но сделаны они по уму (как почти все получается у Дона Сайма). Есть сами типы для коллекций отдельно. Есть модули, которые предоставляют функции для работы с коллекциями. Наконец, есть partial application (или как там называется фигня с inline-оператором (|>)), которая делает очень удобным применение этих функций.

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

В Scala же очень многое завязано на то, что вызываются не отдельные функции, а методы самого типа (flatMap, map, foreach, filter и т.п.). При этом нередко применяются довольно жуткие трюки с implicits, чтобы ограничить применимость методов.

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

В Scala же это именно методы. Коллекций до фига, по-моему даже перебор с перебором. Чтобы не переписывать эти методы по тысячу раз для каждого нового класса, они их наследуют через трейты. И тут начинается полный абзац. Ты только посмотри какая у них там иерархия наследования у коллекций! Только не в учебниках, а именно в коде Scala. В учебниках многое скрашивают. В общем, жуть полная. А о том, к чему приводит злоупотребление трейтами, я уже писал выше.

Я считаю, что коллекции в Scala - пример очень плохого проектирования. У меня есть подозрение, что многие скаловские библиотеки скатываются к подобному плохому проектированию, ибо язык позволяет. Это тот случай, где было бы лучше, если бы язык больше сдерживал и ограничивал фантазию программистов.

лаконичность по сравнению с C#. Действительно удобные коллекции, паттерн-матчинг, карринг, type extensions(удобно, если не использовать из C# , к примеру) + легко юзать с интерпрайзовым C#(у нас используется для алгоритмов + C# + WPF). Но главное !!!лаконичность!!!. Это с т.з. рядового программиста, пишу и поддерживаю несколько средних проектов на F#, меня всё устраивает, ну почти всё

Но человеческих тайпклассов всё-равно нет