GHC 9.10.1

А чо зашкворного-то?

шкворец != зашквар

А чо зашкворного-то?

Маленький шкворец – очень зашкворно. Предлагаю вот увеличить.

• Хаха ты зашквор!
• Нет ты! Ты шкворец.

Судя по комментам, на хачкель всем наплевать.

4.2

Чем больше скор, тем глубже зашквар.

Просто Хаскел стал продакшонреди язычком, как Жабка, и его больше неинтересно обсуждать.

Пока нет Томми - низачот.

как Жабка

Жабка везде и всюду, в каждой дырке, и даже если там Котлин, это просто улучшенная Джава. Хаскеллю до джавовского продакшн-рэди - как улитке от Москвы до Пекина.

Слишком часто ломают совместимость в базовых вещах. С каждой новой версией хаскеля опять какая-нибудь хрень переписана, переделана, переосмыслена… Боюсь даже проверять, что здесь сломали. Полный антипод лиспа в этом отношении - там все стабильно как часы. Может быть, в смолтоке также стабильно

Слишком часто ломают совместимость в базовых вещах. С каждой новой версией хаскеля опять какая-нибудь хрень переписана, переделана, переосмыслена… Боюсь даже проверять, что здесь сломали. Полный антипод лиспа в этом отношении - там все стабильно как часы. Может быть, в смолтоке также стабильно

Чо? Я тут как-то раз недавно портировал проект на 100500 строк с GHC 8.6 на GHC 9.4. Поломок никаких не было. Изменения, ломающие обратную совместимость, случаются раз в 10 лет и о них предупреждают сильно заранее, включая два релиза с ворнингами. Как, например, с MonadFail было.

Ну вот. А я вот только-только четвёртую зажёг.

Ага, MonadFail, сопоставление с образцом (в одном случае стало нельзя лишние пробелы, а иначе не скомпилирует), pure вместо return, Monad обязательно от Applicative. Не помню, может, еще что-то было. Не так чтобы напрягало, но постоянно убирал или ошибки компиляции, или предупреждения.

При этом беру свой старый полузаброшенный код на лиспе (килобайт 800), которому больше десяти лет. Компилирую новым SBCL или ClozureCL. И что? Все прекрасно собирается и работает.

И что еще порадовало. Расчехлил уже постаревший купленный LispWorks, который все еще бодрячком. Он тоже прекрасно собрал код. Единственное, пришлось убрать два определения типов для bordeaux-threads. Видимо, их для красоты ввели позже как в bordeaux-threads, так и в новеньких LispWorks, и ни на что эти два объявления типов не влияют.

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

Ага, MonadFail, сопоставление с образцом (в одном случае стало нельзя лишние пробелы, а иначе не скомпилирует), pure вместо return, Monad обязательно от Applicative.

Ага. Два с половиной изменения. О которых предупреждали сильно заранее. Прямо как я и написал.

При этом беру свой старый полузаброшенный код на лиспе (килобайт 800), которому больше десяти лет. Компилирую новым SBCL или ClozureCL. И что? Все прекрасно собирается и работает.

Ну так Haskell в отличие от CL развивается.

А что вы называете «развитием»? Что касается языка, то в лиспе еще в 80-90е после нескольких десятилетий развития был сделан такой огромный задел, который позволяет языку оставаться современным и в 2024. Ну, вот что такого появилось в языкостроении со сборкой мусора, чего не было предусмотрено в лиспе?!

К примеру, в Scala решили проблему ромбовидного множественного наследования через линеаризацию списка базовых классов, но был ли Одерский первым? Нет, конечно. Это решение появилось много ранее в Common Lisp.

ADT в хаскеле и прочих ML. Если не брать вложенные образцы, то есть, взять тот уровень, который умеет котлин сейчас, то в лиспе это довольно легко делается через гетерогенные списки, а списки в динамическом лиспе уже гетерогенны по определению. Дальше кладем в голову списка тег как ключевое слово. Натравливаем ecase на тег, а дальше разбираем оставшийся хвост списка через destructuring-bind, получая хороший, простой и удобный аналог паттерн-матчинга. Кода совсем чуть-чуть, а фактически тот же ADT в естественном идиоматическом для лиспа стиле кода.

Меня смущало, можно ли асинхронщину запилить на лиспе. Оказывается, что уже сделали и довольно симпатичным образом.

Поэтому не совсем понимаю, что вы называется под «не-развитием».

Из интересного, что заметил, так это в AllegroCL появился бэкенд через javascript - вполне в тренде современной моды. Жаль только, что AllegroCL коммерческий, да и сейчас из-за санкций не продадут

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

Линейные и зависимые типы.

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

Проблема в том, что стандартный Common Lisp – полное говно и лютая ссанина, и поэтому каждому лисперу приходится изобретать свой язычок и пилить на нём что ему вздумается, расширяя его по мере необходимости, потому что другого выбора у лиспера просто нет. Разве что выкинуть лисп, но какой же это лиспер тогда?

ADT в хаскеле и прочих ML.

Это не новое. ML появился 51 год назад.

если не брать вложенные образцы, то есть, взять тот уровень, который умеет котлин сейчас

Сравнивать лисп с выкидышем жабы – мощная заява на победу, когда речь идёт о современных фичах ЯП. Жабисты отстают в развитии лет на 20-30, так что не удивительно, что они на одном уровне с CL, который как раз появился 30+ лет назад.

Какой ты смешной!

Не очень представляю себе, что такое линейные типы, да и надо ли, а вот что касается зависимых типов… Тут, в общем, такое дело, вся эта движуха последние лет 20 касается во многом постоянной переделки статически типизированных языков. Понимаешь? Это статика! Может быть, поэтому лисп до сих пор так живуч и вполне современен в 2024 году, что это динамика. Уловил мысль?

Не очень представляю себе, что такое линейные типы, да и надо ли

Лисперам не надо. У них скобочки есть.

Тут, в общем, такое дело, вся эта движуха последние лет 20 касается во многом постоянной переделки статически типизированных языков. Понимаешь? Это статика! Может быть, поэтому лисп до сих пор так живуч и вполне современен в 2024 году, что это динамика. Уловил мысль?

Да. Ты не шаришь, это вполне понятно.

Но тот факт, что на дохлом ныне пердле я кода вижу больше, чем на вечно живом лиспе, очень многое говорить о живости лиспа. Всё это имеет отношение только к CL, если что, потому что та же схема используется во все поля в хвост и в гриву, только лисперы её за лисп не признают почему-то. А жаль. Схема – весьма приятный язычок.

Причем, common lisp - это не просто динамика, а такая динамика, которая приспособлена для масштабирования при написании кода. Тот же Lisp-N, который так ругают схемеры, в первую очередь придуман для автоматической проверки кода

А, вот, и схема вылезла. Написал выше

Причем, common lisp - это не просто динамика, а такая динамика, которая приспособлена для масштабирования при написании кода.

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

Но вообще, лисперы – они как веганы из мира программирования. Из каждой щели лезут, чтобы рассказать, как их выбор является наилучшим, но почему-то всегда всё сводится к пустому спуску газов в ближайший водоём.

Я имел в виду, что Lisp-N помогает автоматически отлавливать многие опечатки и ошибки при написании кода, что было бы невозможно в Lisp-1 (схема) и том же питоне (хотя, может, для питона чего и придумали)

Меня смущало, можно ли асинхронщину запилить на лиспе. Оказывается, что уже сделали и довольно симпатичным образом.

Можно подробнее? Надеюсь ты не про cl-async.

Да, про него, хотя в lisp cookbook другая библиотека. В лиспе с асинхронщиной дела не имел. Кстати, что обычно используется? Я так понимаю, зависит от выбора или веб-движка, или rest-библиотеки?

Кстати, что обычно используется?

Есть несколько библиотек, все они не совместимы друг с другом, т.к. нет никакого стандарта, или хотя бы соглашения. И всё это разумеется не совместимо со стандартным вводом-выводом. Сами библиотеки находятся на уровне POC, т.е. реализуют принцип, как правило на сокетах, и на этом всё. Готовых батареек для работы с различными внешними сервисами практически нет. Конкретно cl-async плох тем, что он использует libuv, т.е. однопоточен.

В общем, в каждом конкретном случае нужно смотреть, что есть и быть готовым пилить значительную часть низкоуровневой обвязки самому. Поэтому на практике более реально использовать очередь обработки и пул потоков обработчиков. Наподобие как в голанге. А не асинхронщину с async/await.

Я тут как-то раз недавно портировал проект на 100500 строк с GHC 8.6 на GHC 9.4.

Сдаётся мне, что новость всё же надо писать тебе. Люди, далёкие от Хаскеля и ФП вообще, просто в терминологии утонут.

Ох, грустно. Спасибо за информацию!

Вообще в компилируемом языке все эти async/await нетривиальная штука. Для этого нужны полноценные продолжения (call/cc) в каком-то виде (короутины, зелёные потоки, акторы и т.п.), а в CL их нет и макросами тут не отделаешься. Это должно быть в базе языка, т.к. нужно манипулировать состоянием процессора/стека.

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

Продолжения можно сделать, хотя рестарты будут мешать

Об том и речь. Есть библиотека, но там нельзя даже unwind-protect не то что рестарты.

Если ограничиться только unwind-protect и handler-case с раскруткой стека, но исключив полностью рестарты, то сделать можно. Пример - так были сделаны асинхронные вычисления в F#. А вот, что делать с рестартами - ума пока не приложу

асинхронные вычисления в F#

Насколько я понимаю там тоже нет цикла событий (event loop). Т.е. это просто неблокирующие операции плюс пул потоков. В ЛИСПе такое конечно тоже возможно, я про это и говорил. Но это не тот async/await как в ноде, и что делает cl-async, или cl-cont.

Подход в F# похож на cl-cont.Только используются три продолжения вместо одного: продолжение для обычного поток вычисления и по одному продолжению на unwind-protect и handler-case, соответственно.

Еще важный момент. Cl-cont разбирает формы до винтиков, что приводит часто к неэффективному коду, а в F# можно те же циклы обрабатывать как отдельную сущность, что приводит к оптимизации.

Ну, ладно, асинхронщина - тема сложная, и фиг знает, как ее делать правильно

Хаскель - бесполезное, тупое, академическое прямо в самом прямом смысле, дерьмо, годное только на то чтобы писать диссеры. В 2024 году, для него нет ни нормального отладчика, ни IDE.

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

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

Закопайте это говно, короче.

чья бы корова не мычала)))

на hcaptcha, кстати, петушок.

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

а в CL их нет и макросами тут не отделаешься

async/await можно сделать макросами, но там два сложных момента.

Две problems. Первая - нужен code walker, и раскрытие всех макросов, это решаемо. Но дальше - нетривиальная обработка специальных операторов. Так, к примеру, языки типа C#, ввиду своей тупости и примитивности, имеют довольно мало control flow конструкций, которые приходилось бы обрабатывать. Исключения, скажем. Try-catch-finally. И у тех, не сразу появилась поддержка async/await.

В лиспе все чуть более сложно, т.к. есть escape continuations, через block/return-from, но есть также catch и throw, т.е. динамический NLX, ну и не совсем понятно что делать с conditions и рестартами. Можно конечно их перебрасывать, но не совсем понятно как. Это главная проблема, т.е. как это совместить с control flow.

Никаких специальных расширений компилятора тут наверное не нужно, да и они в любой реализации в принципе есть, т.к. компиляторы CL как правило написаны на самом CL, и расширяемы прямо в рантайме.

То есть, проблема с async/await скорее концептуальная, как я сказал.

Можно конечно тупо сказать что - вот дескать все это дело в async не будет работать, но это не совсем красиво.

А, и еще непонятно что с динамическими переменными делать, даже на концептуальном уровне. Вобщем, как и с любым динамическим контекстом выполнения, как я сказал.

Забавно, что при всём при этом он всё ещё популярнее Common Lisp.

Первая - нужен code walker

компиляторы CL как правило написаны на самом CL, и расширяемы прямо в рантайме.

Как бы не нужно, но нужно, т.к. такой code walker это фактически расширение компилятора новый компилятор по уровню сложности.

ну и не совсем понятно что делать с conditions и рестартами

Ничего не надо делать. async/await это те же зелёные потоки, вид сбоку. Обычные потоки в CL есть, т.е. на уровне «что делать» там всё понятно. Есть хоть одна нормальная реализация зелёных потоков? Не на cl-cont. Вроде как нету.

Есть хоть одна нормальная реализация зелёных потоков?

Вроде у старых LispWorks были, когда ещё SMP не было широко доступно.

нет, естественно. Только на форумах, среди аутистов

Как бы не нужно, но нужно, т.к. такой code walker это фактически расширение компилятора новый компилятор по уровню сложности.

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

async/await это те же зелёные потоки, вид сбоку

Естественно, нет.

Это синтаксический сахар над фючерами/тасками. Никаким образом это к легковесным тредам не относится, таски могут абстрагировать IO операции и тому подобное.

Все что я описал относится именно к этому сахару. А так, запилить сами таски это один вечер. Ну или можно просто мою интеграцию с дотнетом взять, и там дотнетовские таски использовать.

Естественно, нет

Что нет когда да.

Это синтаксический сахар над фючерами/тасками

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

А ты похоже про тот async/await который именно сахар над неблокирующими операциями. Так не про это речь. Я про async/await как в ноде.

лисперы её за лисп не признают почему-то

Когда не выгодно не признают, когда выгодно, то признают

С кложей тоже самое

Над продолжениями

Нет. И продолжения это наркомания, которая нахер не нужна нормальной платформе.

Тоже самое.

И даже небо и даже Аллах.

Нет. Мыслить категориями «все есть продолжение» это наркомания.

нодовские фючеры это частный случай дотнетовских Task

нодовские фючеры это частный случай дотнетовских Task

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

Таск это тупо кусок кода, завёрнутый в фьючер.

Нет, это не так. Таск может абстрагировать вообще че угодно, начиная хотя бы с IO операции, которая никакой код в юзерспейсе не запускает.

А эвентлуп это частный случай реализации шедулера тасков, которые запускают код.

в WPF или WinForms есть евентлуп, и там если таски запускаются из UI треда, используется шедулер, основывающийся на этом эвентлупе.

Можно свои шедулеры делать, никто не запрещает.

await это блокирующая операция

Ты вообще что-то совсем не понимаешь. await это тупо Task.ContinueWith(() => { … })

Нода по сравнению с дотнетом, это смешная детская песочница