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

Та же фигня с аппликативом

как это будет выглядеть в без класса типов

Именно поэтому в Elm трэш, угар и неполный набор базовых функций от коллекции к коллекции

есть ли какая-то гарантия наличия Functor если у меня есть Monad или Applicative?

если нету классов типов и обобщения

mapM, concatMap, foldMap - вот эти все комбинаторы писать каждый раз для любого подходящего типа? Это и долго и error prone (мало ли как там взбредет автору очередной либы map реализовать)

Именно поэтому в Elm трэш, угар и неполный набор базовых функций от коллекции к коллекции

так в хаскеле то же самое. имплементация каждый раз для fmap разная

mapM, concatMap, foldMap - вот эти все комбинаторы писать каждый раз для любого подходящего типа? Это и долго и error prone (мало ли как там взбредет автору очередной либы map реализовать)

хотя вот это вот да

fmap разный, а вот комбинаторы один раз написаны

переписывать пришлось бы

так в хаскеле то же самое. имплементация каждый раз для fmap разная

её писать не обязательно, она выводится

её писать не обязательно, она выводится

ты про derived?

имплементация для fmap, но не для комбинаторов

ну да

fmap, это "интерфейс". Его надо реализовать (или вывести). Это позволит "писать на интерфейсах, а не на реализациях" - одна из основных best practices в ООП :)

ты про derived?

ага

Проблема не только в функторе. В Elm я не могу сделать Map с произвольным ключем - вот это реальный фейл! Потому что нет Eq, Ord и прочих Hash

И вот отсутствие тахих приземлённых тайпклассов дико раздражает

а как там сделано?

как в окамле?

или контейнеры не полиморфные?

а там нельзя руками словарики попередавать?

В Elm только встроенные типы (примитивы) могут быть ключами и сравниваться на равенство. Даже кортежи не могут

а понял, готовый map

ясно

Map

или контейнеры не полиморфные?

контейнеры полиморфные по значению и "магические" по ключу - ключ может быть любого типа, но из списка возможных

аааа

ну нельзя же так.

"Котята терпят, колются, но продолжают жрать кактус"

Причем хэшируемость и проверка на эквивалентность есть для пользовательских типов есть уже много где и давно, но нет, Эвану виднее, поэтому в Elm нету (прямо как с Пайком в Го)

Садизм какой-то

Такой Elm точно не нужен

В итоге единственны вариант - класть функцию a -> Key прямо в мапу. Либо тупо таскать в аргументе (так делают в паре либ. Пример: http://package.elm-lang.org/packages/careport/elm-avl/1.0.0/Avl-Dict)

вы забываете, что Elm - не язык общего назначения, это язык под конктерный юзкейс. Без тайпклассов больно, но в 95% случаев они и не нужны. Эван просто не хочет ради 5% сильно усложнять язык, хоть прекрасно понимает, что они нужны (а жс-еры въедут в тайпклассы далеко не сразу)

а жс-еры въедут в elm ?

им и на js хорошо

ну почему нет, элм намного проще js

ну у них должна быть какая-то мотивация, если же они уже js-еры, какая им разница, что elm проще?

я сидел полгода в слаке элма, там большая часть пришла из js и хаскель не знают

их мотивация - убрать undefined is not a function)

пиар компания про 0 ошибок в рантайме и "как редакс, только писать проще из-за иммутабельности, паттерн-метчинга" работает как надо

ну, хорошо если так.

но с другой стороны - в окамле нет тайпклассов, а полиморфные коллекции есть

без хаков на уровне языка

В итоге на Эльме куча вещей даже из его же юзкейса деляется ну очень неудобно

Но да, "просто зато"

Purescript❤️

а жс-еры въедут в elm ?

Опыт показывает, что матерятся, но плывут

это опыт программирования в целом

/me начал прослеживать тенденцию в комментариях @jagajaga : ]

Опыт показывает, что матерятся, но плывут

Как-то очень медленно. В JS-react чате ~3k людей, а в Elm < 100

Привет. Какой плагин ставить на VS Code для Хаскеля, может кто посоветовать?

Как-то очень медленно. В JS-react чате ~3k людей, а в Elm < 100

Нас спасает технофашистские методы работы

Привет. Какой плагин ставить на VS Code для Хаскеля, может кто посоветовать?

haskerro > haskelly

'>' переход или сравнение?

а жс-еры въедут в elm ?

Почему нет? Въезжают и радуются. Столько костей же сломали без статической проверки типов. Тайпскрипт –– не панацея. А элм всё скажет, всё расскажет, место в коде покажет. Надо лишь попробовать.

'>' переход или сравнение?

сравнение

Как-то очень медленно. В JS-react чате ~3k людей, а в Elm < 100

Потому как официальный пруд, где они водятся и нерестятся, это эльмослак - там тысячи их

Почему нет? Въезжают и радуются. Столько костей же сломали без статической проверки типов. Тайпскрипт –– не панацея. А элм всё скажет, всё расскажет, место в коде покажет. Надо лишь попробовать.

кстати, да. ограниченность статической системы типов даёт больше возможностей для диагностики ошибок. это как в го, только в го нужно interface {} делать, что совсем больно

Даёт больше возможностей допустить ошибки по причине невозможности достаточно хорошо закодировать домен, вы хотите сказать?

Иначе Брейнфак всё бы зарулил - там один тип только и есть, вот уж где точно "легко диагностировать ошибки" :)

malbolge

Не, malbolge, это уже спецолимпиада. Типа Perl6

Ну вообще про весь этот элм уже давно сказано: Formal methods will never have a significant impact until they can be used by people that don’t understand them. Ну, вот мы и пришли, собственно.

Элм выучить проще жс-а в разы с нуля.

Даёт больше возможностей допустить ошибки по причине невозможности достаточно хорошо закодировать домен, вы хотите сказать?

ну в хаскеле обычно получаешь ошибку что нет инстанса там то там то. хотя в большинстве случаев поможет не определение инстанса а подстановка нужно аргумента (легко запутаться когда применение через пробел записывается)

Даёт больше возможностей допустить ошибки по причине невозможности достаточно хорошо закодировать домен, вы хотите сказать?

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

haskerro > haskelly

Haskerro работает хорошо, спасибо

Haskerro работает хорошо, спасибо

пишет тип для сущности?

пишет тип для сущности?

При наведении курсора - да :)

кстати, для этого нет хоткея как в идее?

При наведении курсора - да :)

Значит ок. Просто у меня не сразу всё встало.

А как же рефлекс для фронта?)

Слушайте, а тип Void -> a населен?

Боттомом как минимум :)

я знаю про absurd, но я не очень понимаю, как может существовать функция, которая ничего не принимает

ну, если бы не было bottom

absurd :: Void -> a она не ничего не принимает, а принимает ничего

absurd a = let x = absurd a in x

только она вернёт боттом

ну это не удивительно

нужно может быть если есть, например какая-нить бесконечная функция, типа forever blabla её логично сделать тип m Void, но если вдруг по каким-то причинам надо её композить с другой, например всякими примитивами из async то там иногда нужно вызывать absurd

Слушайте, а тип Void -> a населен?

Конечно, потому что это id :)

Void можно рассматривать как forall a. a

эм...

newtype Void = Void { absurd :: forall a. a } data Void написать изоморфизм - упражнение читателю

это то понятно, вот "потому что это id" как-то неочевидно, что так

это id up to isomorphism

То есть для одного из возможных определений Void это просто unwrapping ньютайп-конструктора

Конечно, потому что это id :)

хм, разве?

не существует же функции Void -> Void

как и любой другой a -> Void

id