но какой смысл их запрещать, тем более, что это одно и то же?

и они уже есть

в Котлине вроде поднимают движуху за фп, есть arrow https://github.com/arrow-kt/arrow и вроде создатели продвигают тайпклассы https://github.com/Kotlin/KEEP/pull/87 в компилятор

Елизаров просто зашёл в чат kategory и такой вау, классный движ. го сделаем нормальные тайпклассы. ну написали там пропозал и дальше я перестал следить но делаю ставку на то что их не запилят

а было какое-то обсуждение? Никто там не написал что если запретить большие кортежи, то просто будут писать (1,(2,(3,4))) ?

или тогда вложенные кортежи запретят?

ага, запретят

их же ещё придётся в джс и нетив таргет запилить

это было бы логично.

а было какое-то обсуждение? Никто там не написал что если запретить большие кортежи, то просто будут писать (1,(2,(3,4))) ?

только слухи и какие-то намёки в коммитах в репу компилера

Считается, что если ты делаешь кортеж длиннее трёх элементов, то тебе уже нужен record

И нельзя сказать, что я строго не согласен...

а не считается, что это не дело авторов языка решать, что тебе нужно, а что нет?

А кому ещё решать то? :)

разработчикам

У Elm есть Эван. "Ему - виднее"

очередной Гвидо?

Гвидо прогрессивнее

Elm - не язык общего назначения и не язык полной свободы. И никогда не был. Это фреймворк с элементами языка

их же ещё придётся в джс и нетив таргет запилить

так это просто будет передача объектов в функции через параметер, зачем в бекенде-то для этого поддержка?

это прям как с эрлангом

привет. может кто-нибудь посоветовать обширный туториал по применению ленивого мап, ленивого редьюс, и всего такого с примерами для человека, который знает, как в целом знает, как работает ленивый мэп? (это же "стримы" вроде называется?) (оффтопик-вопрос - если это не похож на пайпы в юниксе, то можете ли посоветовать самый внятный туториал по пайпам в юниксе?)

в общем, это работает, только если предментная область известна, ограничена и формализована

про фронт этого никак не скажешь

поэтому пустое. это язык общего назначения, чего бы они там не говорили

так это просто будет передача объектов в функции через параметер, зачем в бекенде-то для этого поддержка?

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

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

Елизаров просто зашёл в чат kategory и такой вау, классный движ. го сделаем нормальные тайпклассы. ну написали там пропозал и дальше я перестал следить но делаю ставку на то что их не запилят

12 дней назад апдейтнули слегка топик, сказали что активно работают над Proof-of-concept для джитбрайнс, на что Елизаров сказал, что заебись ребята, тут еще си-шарписты подтягиваются с пропозалом #164 https://github.com/dotnet/csharplang/issues/164

но ни одного языка с тайпклассами, естественно, нет

но ни одного языка с тайпклассами, естественно, нет

лол

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

блин даже как-то интересно стало.

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

к F# уже и reference implementation сделали. ещё не вмержили, естественно.

уже и этому пейперу по которому сделали года два или три

да

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

конфликтуют

тайпклассы это всего лишь некие захаренные рекорды с особой зависимостью

там ООП изрядно так ада привносит

хотя в хаскеле и так оно вроде запрещается. нельзя имплементить для [a] и [Int] одновременно, примерно то же самое

хотя фшарп умеет всё, что умеет сишарп, плюс функциональщину

хотя в хаскеле и так оно вроде запрещается. нельзя имплементить для [a] и [Int] одновременно, примерно то же самое

емнип в F#-ном пропозале никак не собираются бороться за когерентность, т.е. это будут скалистые имплициты со всеми вытекающими

хотя в хаскеле и так оно вроде запрещается. нельзя имплементить для [a] и [Int] одновременно, примерно то же самое

overlappable + overlapping вроде как могут такое позволить (но это не точно)

ну я помню хотел сделать инстансы для a и Show a => a и что-то не осилил

ну я помню хотел сделать инстансы для a и Show a => a и что-то не осилил

это другое

одно дело оверлап по голове инстанса (справа от =>) - это работает, а оверлапа по контексту (слева от =>) нет

контекст вообще в выборе инстанса не участвует

а можно с лямбдаботом как-нибудь поговорить не черзе irc?

ну и локально тоже как-то не хочу

вроде был try haskell

https://www.tryhaskell.org/

А можно соориентировать как вам никс для пакедж менеджмента пригождается? То есть стека казалось бы для всего хватает, extra-deps там к чему угодно можно указать. ну наверное в никсе есть собранные билды (или нет?), что ещё полезного?

есть же не-хаскельные зависимости, к примеру

это ок. да. норм поинт

кэширование

нууу - а стек не кэширует?

ну кабал просто

без никса - нет

Все как кирилл сказал + гарантия что в рантайме не будут пропущены зависимости и возможность прибить версии всего вплоть до glibc.

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

reproducible builds что называется

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

Все как кирилл сказал + гарантия что в рантайме не будут пропущены зависимости и возможность прибить версии всего вплоть до glibc.

как можно пропустить зависимости в рантайме?

элементарно, спроси у админов

если забыл в deb-пакете указать зависимость от so?

Админу пакет приехал, новая версия задепендилась на новую версию openssl. Приложение передернул и взорвалось.

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

если не указано в пакете или версия не точная

ну рантайм это когда приложение запускаешь

если у тебя .so нет нужной или не та версия, то ты об этом узнаешь запустив приложение

самая клёвая штука это кэши возможность указать внешние зависимости, как выше сказали

Опять на Э-г псите, черти? ))

У нас кстати, норм заходит.

что именно заходит и куда?

эрланг, в работу?

эрланг работу работать, программист отдых отдыхать ! )) упс, спалился

@IvanovPvl почему не скала - я думаю, из-за бессмысленной сложности скалы. т.е это непростая задача, когда основным принципом делается "что бы не как в хаскеле"

В Скале фактически два языка: better java и недо-haskell, и стыкуются они друг с другом хреново, причём не только и не столько по коду, сколько по требуемому складу ума. (ненастоящий скалист, воспринимать со здоровой долей скепсиса)

-> Scala аки звено для миграции джавистов: Java > Scala > Haskell :]

Только не многие доходят.

-> Scala аки звено для миграции джавистов: Java > Scala > Haskell :]

недавно стало так: Java -> Kotlin -> Scala -> Haskell

Шок! Коварные жетбрейнс препятствуют переходу жавистов на хаскель!

-> Scala аки звено для миграции джавистов: Java > Scala > Haskell :]

Ой ли?

Я бы так был уверен, когда мне дадут солид для фп. А то претендентов много

Проблема-то не в чистоте, а в продуктивности в конце-концов

Секс с тайпером в случае скалы да, комплементарен. Да, недохаскель

Но это и делает скалу скалой

недавно стало так: Java -> Kotlin -> Scala -> Haskell

только давление упало и из скалы все обратно в яву через котлин пошло

Котлин - говнина

Давайте скажем честно

Он сложнее скалы

я под Android кодю и тут как-то не до скалы было, Котлин хоть какая-то отдушина

Котлин - говнина

конечно, и не только котлин

И скала говнина

И хаскель говнина

Кстати

я под Android кодю и тут как-то не до скалы было, Котлин хоть какая-то отдушина

у скалы трабла с рантаймом, не всякий раз прогвард справлялся

баньте его

у скалы трабла с рантаймом, не всякий раз прогвард справлялся

И не только это

Но вот с тезисом о безусловном превосходстве хаски я бы поспорил

В некоторых аспектах однозначно