Haskell Foundation ставит цель компилировать код десятилетней давности без изменений

Есть это памятное видео С. П. Джонса, где он знаменито говорит «Haskell бесполезен». Я люблю Haskell, но мне хотелось бы, чтобы он был универсальным, как C, C++, JavaScript, Rust и C#. Под этим я подразумеваю: его можно было бы использовать для создания приложений для десктопа, мобильных устройств и веба. JavaScript можно использовать для столь многого: он питает весь веб, работает на node и позволяет любому создавать cli и делиться кодом с вебом, а также с мобильными устройствами через React Native, на десктопе с Electron и подобными вещами, он позволяет делать плагины для невесть чего, он позволяет писать вещи для GNOME Shell... C и C++, возможно, лежат в основе всего в мире, и когда теория струн наконец будет увидена, окажется, что она написана на C. И их можно компилировать в Web и почти во всё в мире. Rust — это замена этим двум, а C# переизобрёл себя, когда увидел Mono, и теперь работает даже в браузере. Каждый раз, когда я вижу Haskell, я задаюсь вопросом, что ещё я могу сделать, кроме создания CLI-приложений, и это заставляет меня выбирать что-то другое, что даёт мне больше переиспользования кода и интересных приложений.

Если бы у меня было видение для Haskell, оно было бы о том, чтобы он был полезным. Академические исследования и создание компиляторов — это круто, несколько cli-штук тут и там — тоже круто, но почему мы не можем строить на нём музыкальные плееры, игровые движки, flutters и веб-страницы? Язык гораздо более элегантный и красивый, чем все эти JS/C-подобные языки, и я действительно хотел бы использовать его для того, чем я занимался. Я знаю о Servant/Yesod/IHP/Miso/Reflex для веба, GTK/M […]

hasufell был замечательным человеком в мире Haskell. У него очень ясные идеи насчёт всяких вещей и так далее.

Кроме того, то, что я теперь могу создавать на Haskell с помощью компьютера, — это эпично. Ранее на этой неделе я поднял то, что, как я считаю, является одним из лучших, если не лучшим, читателем-писателем формата step-файлов практически по всем осям. Некоторые C-реализации на 20–30 процентов быстрее на самых больших возможных CAD-сборках, которые я мог попробовать.

Важная ось, которую люди упускают из виду: основной способ масштабирования LLM для лучшего кодирования — это метрические мегатонны трассировок обучения с подкреплением, а проверка типов, которая является навороченной, даёт более дешёвый и быстрый цикл обратной связи для обучения.

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

У него недостаточно дополнительной ценности поверх таких конкурентов, как Rust. Вместо этого больше внимания привлекают другие, более значимые синергии с кодирующими агентами, например автономная формальная верификация. Такие языки, как Lean, открывают целую новую категорию инженерии, а Haskell — нет. Так что он застрял в сложной середине: он слишком непохож, чтобы оправдать себя относительно своих выгод, но недостаточно непохож, чтобы захватить новые возникающие возможности.

Хотя я согласен, что время компиляции — большая проблема, я думаю, что основное внимание следует уделить именно инкрементальной сборке, потому что, учитывая, сколько работы приходится выполнять компилятору Haskell, вполне ожидаемо, что полная сборка будет довольно медленной.

Но у инкрементальной сборки нет причин быть медленной, если область изменений настолько мелкозерниста, как уровень функций и типов.