GHC 8.8.1

Вполне себе рабочая лошадка без лишних наворотов.

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

Ссылка не репрезентативная. Там результаты зависят от левой пятки администратора.

Я просто сейчас Elm ковыряю - божественная штука для фронтенда, React+Redux здорового человека. Удивительно прямо как это может быть, чтобы фронтенд было писать приятно. Полное решение проблемы фронтенда без возни в помойке говнофрнймворков, в которых все отваливается.

Пишут что на основе Haskell+OCaml. Куда не гляну - обрезанный Haskell. Так как я OCaml не знаю, то вот интересно что там такого уникального

OCaml и ML разницы не так много

Как-то хотел писать именно на SML, но слишком он далекий от современного человека. Особенно когда вкладывают модуль в модуль и еще раз в модуль чтоб положить туда единственный тип t и передать в функтор, бррр...

Elm, может, и прикольная штука. Но для фронтенда мне зашёл вообще ClojureScript. Ну с подобным типа реакта. Но норм, в общем - https://youtu.be/VNRVKcSQQFc

Ну есть специфичные вещи, конечно. :)

Это вообще тренд - в старые языки добавлять элементы ML, новые сразу делать на основе. C++, C#, F#, Kotlin, Swift, Rust.

Влияние именно хаскеля - в Rust, Python, Scala. Это в основном ленивость и тайпклассы.

Вот я покажу короткий пример что такого особенного мне дает Elm.

Но иногда я хочу писать код на ноуте, на котором ChromeOS. Годами мне все подходило, так как я просто заходил по SSH на машину и писал там код. В ChromeOS сейчас подвезли линукс внутри, я мог бы там все настроить, но я не хочу два линукса поддерживать.

Возвращаясь к Elm. Многие пишут web приложения на нем. Я пишу десктопное в WebkitGTK. Тоесть мне нужны иксы, которые у меня на десктопе. Тоесть трюк с SSH не работает, пробрасывать иксы будет слишком тормозно. И я этого не делаю…

Я просто пишу код часами не запуская приложение. В Elm компилируется только код который не бросает исключений, только код, в котором все возможные варианты паттерн матчинга обработаны. Я могу взять и перелопатить 5 файлов, потом сделать чтобы код собрался и он только соберется если с большой вероятностью корректен.

Elm

Убожество, запрещающее удобство кодинга. Ваяйте сайты на https://reasonml.github.io/ а для любителей фана есть http://www.purescript.org/

Убожество, запрещающее удобство кодинга.

Вроде бы наоборот, позволяющее удобство кодинга. А с ReasonML/Pure, которые языки общего назначения по сути, которые транспилируются в JS все равно будешь терпеть муки приклеивания очередного React или GovnoJS.

В Elm, язык - Elm. DOM - Elm, CSS - Elm, Redux - Elm. Архитектура приложения - Elm Architecture. Книгу одну прочитал - и вперед. Если попытаешься прочитать вторую - не выйдет, там то же самое, ты уже знаешь 100%, иди пиши код

У ReasonML все же есть очень хороший юзкейс - мигрирование существующих приложений более мягкое. Можно заменять JS функции по одной, потому что язык не навязывает архитектуру. Что кто-то бы назвал, например я - не предлагает архитектуру, совсем. Elm предлагает простую и понятную

Да, специально. У меня он дает ускорение процентов на 20-30-40% в зависимости от задачи.

Я ничего не понял, из того, что ты написал.

Интересно. А они то убрали как раз потому что пришли к выводам что выигрыш в производительности не стоит свеч

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

В идеальном мире все пишут только на Idris и ATS.

Ну ФП языки это вообщем те, кому за это все спасибо нужно сказать, но не факт что нужно пользоваться.

Мы дошли до того, что код в ФП стиле на расте работает быстрее чем цикл с индексом, и все ФП вытирается в ноль. Но концепцию ФП приходилось обкатывать годами на всех этих Лиспо/Хаскеллях чтобы потом взять практичную часть

Idris и ATS

Идея хорошая. Реализация не рабочая. Их автора не умеют кодить, только статьи писать и могут.

Почему не rust+wasm вместо elm?

Ответ один - взаимодействие c DOM. WASM хорошо работает когда он внутри себя работает ощутимое время. А когда он после сотни инструкций бежит сериализировать Rust строку в JavaScript строку, то это наоборот не окупается.

Кстати книжка по WebAssembly у меня следующая по списку. Прямо вся книжка о самом этом наборе инструкции и деталях взаимодействия

Умение кодить при дизайне ЯП пользы никакой не несёт, скорее даже вредит.

всячески рекомендую
Graham Hutton, Programming in Haskell, 2nd edition https://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/1316626229/
ёмко, лаконично, последовательно и по делу, стиль изложения напоминает университетские учебники (кто не привык к такому чтению, может будет и сложновато)
предварительных знаний никаких не надо, вся математика появится по ходу изложения (вторая часть книги, в районе функторов-монад), вот и получите представление, что именно она из себя представляет, и интересно ли вам дальше углубляться в хаскель

Они убрали под тем предлогом, что Rust - язык системного программирования, а значит, должен по умолчанию использовать системный алокатор.

Почему у меня такое ускорение? Это особенность моей дисциплины. Нужно создавать лавину краткоживущих объектов. Вот здесь jemalloc и выстреливает.

Умение кодить при дизайне ЯП пользы никакой не несёт, скорее даже вредит.

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

Какие-то сферические в вакууме рассуждения...

В моем случае Haskell дает два огромных профита:

1) простота создания моделей;

2) контролируемость эффектов IO.

Второе важно, потому что у меня в ходе вычислений могут быть откаты. Не буду вдаваться, почему такое происходит. Это отдельная тема. Скажу лишь, что контролируемость в разы повышает уверенность в правильности и достоверности вычислений.

Сложно ли осилить Haskell, и по каким книгам, ресурсам учили его вы?

Не слишком. Учил по срачам на ЛОРе.

Какая математика требуется для письма на нём?

Школьного курса будет достаточно. Бонусом будет чтение википедии про абстрактную алгебру, чтобы понимать откуда многие концепты вылезли.

Ну ты просто не гоняешь гигабайты в рантайме. А я просто интересуюсь в основном обработкой звука и 3Д.

Может тогда просто Arena allocator и вперед? Вообще будет молниеносно

https://doc.rust-lang.org/1.1.0/arena/struct.TypedArena.html

То что сходу нагуглил, может есть лучше библиотеки. Вон интерфейс как лопата

Он всё так же требует минимум полгига места для самого себя и минимум два гига для зависимостей каких-нибудь самых простых проектов?

Elm — неинтероперабельное тормозилово. Я всё сказал.

а как же пандок https://ru.wikipedia.org/wiki/Pandoc ?
функциональный язык же, преобразовать из одного формат в другой - прямо идеальная задача под него
что-то вроде f(формат1) = формат2, нужно реализовать f (причем никакого IO и прочих отвлечений)

Если бы ты пруф на тормозилово подкинул, тогда бы все сказал. А пока что куда ее глянь, это самый быстрый one-directional binding во всей фронтенд экосистеме

А вот насчёт интероперабельльности то да, очень контроллирующая штука

Это вообще тренд - в старые языки добавлять элементы ML, новые сразу делать на основе. C++

Что из ML добавили в С++?

это самый быстрый one-directional binding во всей фронтенд экосистеме

Быстрее вот этого васяскрипта, написанного 3 года назад?

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

Не знаю, что dave имел в виду под «ядром», но рантайм у OCaml очень маленький. В этом треде Croco спрашивал о статической сборке, и я показывал ему пример на OCaml.

Спасибо за идею! Поизучаю

Ну ты просто не гоняешь гигабайты в рантайме. А я просто интересуюсь в основном обработкой звука и 3Д.

Гигабайты и гоняю, но там не числа, а объекты.

там не числа, а объекты

Ну значит не сильно торопишься. А то закодил бы объекты числами, чтоб быстрее ехало

Ну я говорю о том, что одного человека в любом случае не хватит на создание нормального ЯП и его компилятора. Нужно минимум 2 человека — дизайнер и имплементатор.

Нужно минимум 2 человека

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

И каналы из crossbeam. Они быстрее и они multiple producer - multiple consumer.

Но это все идеи для улучшений стандартной библиотеки в будущем

xmonad, xmobar, ..

Но где ПО здорового человека? ;)

Правда, я иногда совсем тебя не понимаю...

Мне даже страшно представить аудиоплеер на сабже

А в чём, собственно, проблема?

Ах, он же не для этого!

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

Правда, я иногда совсем тебя не понимаю

Забей. Задачи разные. Если бы я кодил бизнесс-логику, с базой данных там возился, то хаскель бы сгодился.

Что из ML добавили в С++?

Вывод типов, (шаблонные) лямбды, новые объявления функций, optional, variant. В C++20 - шаблонные функции с auto, концепты. Паттерн-матчинг обсуждают, и structured bindings им навеяны.

Но в большей степени - с каждым новым стандартом ощущение от программирования на крестах всё больше ML-подобное. Субъективно.

Емнип, ты в области моделирования физических явлений разрабатываешь?
Если не секрет, работаешь в НИИ каком или в частной компании?

Я на Elm не ваял, ничего сказать не могу. :) Но ClojureScript зашёл.

C ClojureScript проще, что это не десктопное приложение. Я откуда угодно захожу и пишу, оно там докомпиливает что надо и прямо в браузере всё обновляет. И всё сразу видно. Так вот на ходу прям ваяешь.

Поддержка профилирования на 64-битных системах с Windows.

Очень полезная информация для ЛОРа