clojure после common lisp - насколько омерзительно и в чём именно?

Спасибо, добавил в закладки. Интересно, если написать пошаговый отладчик для clojure, такой же, как существует в Lispworks, можно ли это монетизировать? Я твёрдо убеждён, что такой отладчик (мне) нужен. Но вот нужен ли он настолько, чтобы сесть и начать его делать? Это я уже менее убеждён.

А, тут пишут, что есть:

https://www.reddit.com/r/Clojure/comments/80al23/how_do_i_do_breakpoints_stepbystep_debugging_in/

И была ещё статья про Intellij, хотя уже куда-то делась.

Помните историю про Вила

К стыду своему. Реквестирую оригинал.

я ответил тебе про Вавилон

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

Так что сегодня, нижайше прошу, будь ко мне снисходителен, я мог тайные смыслы не уловить. Но если тебе показалось, что скобки Вавилон это со зла (либо от АНБ), то зря. Я уверен (при всей своей скептичности), что твой проект для взлёта нуждается в идеологии (в хорошем смысле этого слова), а не в лиспе, скобках или скорости компиляции. И моя вавилоно-пирамидо-хрень это скорее «этапы трудного пути», а не скобки от АНБ.

Ну обычно для таких целей логарифмическая принимается. :) Но не это важно. Важно то, что на CL можно работу найти. И на Clojure работу можно найти, но легче, чем на CL. Но на яве не просто находишь работу, а ещё и выбираешь.

В CL весьма фигово с запуском внешних программ

UIOP прекрасно запускает. Правда, не знаю какой смысл ты вкладываешь в слово «фигово».

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

Как раз нет проблем. Во всяком случае сейчас UIOP и всё такое. Хочешь синхронно запускай, хочешь асинхронно. Но таки да, раньше было с этим хуже. Помню, юзал external-program для этих целей. С ней норм было.

Разные скобки для семантически разных вещей.

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

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

Посмотрим, что будет дальше, с отладкой, трассировкой, большими приложениями и всем таким прочим.

Из всего прочего бесит скудный компилятор. В SBCL или CCL он в разы мощнее.

В CL весьма фигово с запуском внешних программ (если только за 3-4 года моего отсутствия не починили).

https://common-lisp.net/project/asdf/uiop.html#UIOP_002fRUN_002dPROGRAM

https://gitlab.common-lisp.net/qitab/inferior-shell

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

(run-program '("sed" "s/a/b") :input "input.txt" :output "output.txt")

если написать пошаговый отладчик для clojure, такой же, как существует в Lispworks

Не знаю, какой в Lispworks, но в CIDER кложевый отладчик есть, похожий на edebug из емакса.

из серии «собираюсь жениться - отговорите»

Пятый том «Гаргантюа и Пантагрюэля» дочитал? :)

Вот ЯОС собирается за 2 минуты, запускается за 5 секунд.

На живом железе, как отдельная ОС?

На CL с работой в моём случае всю дорогу было туго, я его обычно притаскивал с собой, и только в одном случае проект изначально был на CL. Бессмысленная борьба фанатизма против благосостояния. Может быть, это зависит от страны и ещё от чего-нибудь. Во всяком случае, вчера на hh было ноль вакансий по «Common Lisp» и что-то 26 по «Clojure». Это по логарифмической шкале сам понимаешь на каком расстоянии.

Вил - это какой-то идол из Библии, чуть ли не из Вавилона, но за мат тут трут, аккуратнее будь. Удачи в делах, потом обсудим. Кстати, ЯОС поставлен на паузу, враги могут радоваться, а недосоратнички - поразмыслить о своём поведении.

Перенаправить в файл можно, но баш делает гораздо больше. Там проблемы были на каждом шагу: текущая директория, код возврата, взаимодействие с EMACS (он как-то плохо влиял, пришлось писать специальную стороннюю программу, чтобы запускать bat-файлы), кодировки. Гора из костылей росла, росла, но до полноценного функционала так и не доросла.

Я собираю ЯОС под офтопиком. 2 минуты 40 секунд ЯОС в режиме приложения пересобирается себя же как приложение. В ходе этого пересобирается ядро, компилятор, гуй, IDE, сетевой стек и даже убогий веб-браузер. Под линуксом, кажется, она собирается чуть быстрее. Сборка образа ОС дольше, т.к. ещё нужно запаковать архивы и создать образ диска - ещё секунд 20.

За менее чем 5 секунд она запускается в режиме приложения под офтопиком и даже открывает файлы в редакторе (что включает в себя их грам. разбор и подготовку «Intellisense»).

На Zybo Z7-10 c флешки загрузку не замерял, по ощущениям - 5-10 секунд.

Под VirtualBox x86 загружается 25 секунд. На физическом железе никогда не запускал.

Под офтопиком не особо интересно.

Zybo Z7-10

Погуглил. Это железяка на ARM для отладки ПЛИСов? Т.е. ЯОС именно на кортексе запускается, или я чего-то не понимаю?

в Lispworks можно ставить брекпойнты на любой скобке, а также во время сеанса отладки заходить в макросы (они раскрываются по месту).

Неа, это откуда-то из СМИ шуточка пришла 100 лет назад.

спалили в Страсбурге датацентр

Почему-то в сочетании со словом на букву «м» первым делом вспоминается анекдот про «мой друг сервер уронил»…

Под онтопиком в режиме приложения пересборка себя 2м 36сек, запуск и выход (при том мышью не с первого раза попал в подтверждение выхода) 7 секунд. В Zybo Z7-10 ЯОС вообще не запускается, я пока успел запустить только A2, дальше дело техники, но трудоёмкость переноса может быть порядка недель, запланировано не ранее чем на лето, а сейчас вообще буду заниматься кложей и ЯОС буду максимум раз в неделю копать по часу-два, чтобы не забыть совсем, что к чему. A2 запускается на кортексе, но видеокарта реализована на ПЛИС.

Рабле всё равно был ещё раньше :)

A2 запускается на кортексе, но видеокарта реализована на ПЛИС.

Интересно. Прошивка для ПЛИС самописная или что-то открытое? И как полученный комбайн в сравнении с той же Raspberry Pi (да, тупонубовопрос, но я в эмбедщине и есть полный нуб)?

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

Я в эмбедщине не больше тебя разбираюсь. Вопрос предлагаю адресовать на oberoncore.ru - у меня была очень простая задача - создать предпосылки для запуска штатной тестовой сюиты на хоть каком-то одном ARM процессоре, чтобы предотвратить гниение компилятора.

A2 может гораздо больше в теории. Она вообще позволяет делать «софт» для ПЛИС с помощью Active Cells. «Виртуальные детали» на ПЛИС какими-то другими средствами делаются, не A2, там есть проприетарные Vivaldo, Vitis, но я не осилил пробраться через грабли и костыли и даже hello world до конца не довёл.

Под малину запустить за 2 дня не смог и я так и не понимаю, существует ли сборка под неё или это просто заготовка. У них в A2 всё так. Очевидно, там надо уже лезть в программирование.

Если бы специалист, который всё это реализовывал, Алексей Морозов, не помог бы, я бы и с Zybo вряд ли справился. Там было отличие в часах в зависимости от модели и поначалу ничего вообще не работало. Он обнадёжил, научил, баг поправил, да ещё и от денег отказался, дай Бог ему здоровья.

Естественно, что машина на ПЛИС - более богатая чем малина. Жрёт она 12 ватт - возможно, это не сильно больше, чем малина. Но там больше гибкости.

26 по «Clojure»

Из них на Clojure вакансии 2, наверное. В остальных упоминается, типа, знаешь что-нибудь из Scala, Clojure - это плюс.

2/0 = 26/0

\lim_{x \to 0} \frac{2}{x}\frac{x}{26} = 0.0769…

Clojure вроде не Java, а динамическая лапша для изнасилования JVM беспощадным давлением на reflection

Не путать с Jython — у Clojure есть компиляция, которая выкидывает большую часть reflection-а. Правда, все равно Clojure, как правило, бегает на порядок медленнее жавы, но тут уж ничего не поделать — такова цена динамики с персистентными структурами данных, когда на каждое изменение элемента массива

Clojure> (assoc [1 2 3] 1 5)
[1 5 3]

у тебя формируется частичная копия дерева (в данном случае дерево одноуровневое и копия полная).

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

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

Ну и как? Просто было освоить чужой код?

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

Грустные вещи ты пишешь, как бы мне не разочароваться в этой кложе через некоторое время. А что, там иммутабельность безальтернативна?

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

Вот это и проблема. Говнокод индусов на питоне читать примерно так же тяжело, как в проекте на лиспе, где «культура авторов была весьма и весьма на высоте». Write-only наклонность убила CL. Бывалые лисперы рассказывали страшилки про то, как в одном проекте некоторую фичу никак не могли полноценно реализовать, потому что каждый приходивший программист просто переписывал фичу заново.

Грустные вещи ты пишешь, как бы мне не разочароваться в этой кложе через некоторое время. А что, там иммутабельность безальтернативна?

Персистентные структуры данных не безальтернативны, можно использовать самые обычные объекты жавы, но смысла тогда в языке особого не остается, поскольку получается просто синтаксически извраженная форма записи кода на Java. А основная проблема жавы как раз в том, что она сильно опирается на объекты.

Если бы вместо жавы фундаментом был какой-нибудь ML, то смысла бы возникло сильно больше, поскольку ML умеет компилироваться в высокоэффективные машинные коды даже для достаточно сложных структур. В случае JVM ты можешь лишь помолиться богу и надеяться, что JIT-компилятор достаточно эффективно выполнит escape analysis, засунет локальные данные из контейнеров в регистры и вообще не тронет кучу. Данная проблема — это примерно половина всей мотивации создания языка Go. То есть, в Go быстрые эффективные функции, оперирующие локальными переменными большую часть времени, которые иногда отдают эти данные в кучу, где работа с ними идет уже через GC — такое поведение в Go идет из коробки, оно заложено в язык. В JVM же это магия, чудо, которое должна сделать JVM, причем, во время выполнения — AOT она даже не может толком угадать, кто кого и когда вызовет из бесконечного сплетения взаимосвязанных объектов, дергаемых на каждый чих.

Основное назначение Clojure — это все-таки упрощение разработки какой-то достаточно малопроизводительной и ответственной логики. Причем, здесь сразу возникает возможность в любой момент вернуться опять в жаву для написания более быстрых алгоритмов, при этом сохраняя надежность выполнения, в отличие от сишных расширений питона. Именно поэтому почти в каждой вакансии по Clojure требуют знание Java — обычно на этой жаве таки действительно придется писать, а не просто разбирать чужой код. Хотя и чужой код тоже придется читать, по точно той же причине.

Вот это и проблема. Говнокод индусов на питоне читать примерно так же тяжело, как в проекте на лиспе, где «культура авторов была весьма и весьма на высоте».

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

Серьёзные заявления, а есть какой-нибудь пруф про кучи и escape analysis?

Ну мне кажется, слишком смелые выводы ты делаешь, не зная о проекте ничего

Ну давай, расскажи мне, что у лисперов нет склонностей к написанию write-only кода.

Серьёзные заявления, а есть какой-нибудь пруф про кучи и escape analysis?

Escape analysis гуглится, работу JIT-компилятора гуглится. Если спросишь про что-то чуть более конкретное, то можно будет конкретнее ответить. Основной принцип оптимизации выполнения JIT-компилятором, без которого вообще вся компиляция не имела бы смысла, примерно как не имеет смысла AOT-компиляция для жавы — это инлайн и скаляризация. Чтобы сделать инлайн и скаляризацию, нужно знать, какие поля используются и кем. У жавы очень сложные взаимосвязи между объектами, самих объектов много, потому попытка скомпилировать в виде плоской функции все-привсе комбинации вызовов спокойно выдадут бинарник на десятки гигабайт.

Ну не на 0.

А что, там иммутабельность безальтернативна?

Есть альтернатива в виде STM, но как-то в этом плане грустно всё. А что, иммутабельность сильно тебя беспокоит? Это же даже прикольно. Но невесела безальтернативность. Но альтернатива есть в виде интеропа с явой.

Ну давай, расскажи мне, что у лисперов нет склонностей к написанию write-only кода.

А сколько ты видел проектов на лиспе?

Я частично понял по ключевым словам, к-рые ты назвал, поэтому сделаю более узкий вопрос: ты что ли хочешь сказать, что Го умеет создавать объект на стеке, если компилятор с помощью escape анализа видит, что объект умрёт при выходе из этой функции? Мне просто интересно, нельзя ли это применить к активному оберону, там, правда, тоже есть наследование и виртуальные методы, так что может не прокатить именно по названной тобой причине.

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

Да, безальтернативность гнетёт мя.

Ну давай, расскажи мне, что у лисперов нет склонностей к написанию write-only кода.

А сколько ты видел проектов на лиспе?

Видеть-то я видел немало, корректнее был бы вопрос «в скольки я активно участвовал» — это количество было бы нулевым.

ты что ли хочешь сказать, что Го умеет создавать объект на стеке, если компилятор с помощью escape анализа видит, что объект умрёт при выходе из этой функции?

Не совсем, но да, и делается это AOT:

https://golang.org/doc/faq#stack_or_heap

«When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.

In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.»

Мне просто интересно, нельзя ли это применить к активному оберону, там, правда, тоже есть наследование и виртуальные методы

К сожалению, не знаком с активным обероном.

Спасибо за цитатку, теперь понял.

Видеть-то я видел немало, корректнее был бы вопрос «в скольки я активно участвовал» — это количество было бы нулевым.

Ну видел это активно разбирал.

Видеть-то я видел немало, корректнее был бы вопрос «в скольки я активно участвовал» — это количество было бы нулевым.

Ну видел это активно разбирал

По моему опыту, новичок с поверхностным знанием языка при наличии умственных способностей может понять состояние проекта, по крайней мере частей, с которыми он активно работает, примерно за 1-2 месяца. То есть, примерно тогда, когда он более-менее осваивается, и его «что тут написано?» превращается «какой мудак додумался так писать код?». Я понимаю, что тут есть мастера, которые с ходу могут сказать «вот это подходит по шаблону, а это — не подходит, так нельзя писать», но это несерьезно.

У меня лично нет подобного опыта даже по Clojure, которую я все-таки какое-то время изучал, но я склонен считать, что Clojure при своем создании учла прошлые ошибки лиспа, и потому стала одним из немногих востребованных диалектов. Я действительно хочу узнать, насколько реальна склонность к write-only у лисперов, но пока что не получил ни подтверждения, ни опровержения. Не в последнюю очередь потому, что все лисперы в один голос бьют себя в грудь и рассказывают, что лучше лиспа человечество до сих пор ничего не придумало. По косвенным же признакам такая тенденция должна была иметь место.

Мне в прошлом треде про Clojure вообще какой-то анон выставил ультиматум — он мне ответит на вопрос, только если я перестану что-то писать про лисп. Норм подход, да? Но я сомневаюсь, что он мне сможет ответить на вопрос: почему CPython выжил, Ruby медленно и мучительно умирает, а CL уже гниет?

Я действительно хочу узнать, насколько реальна склонность к write-only у лисперов,

Ну как пример, полновесные идентификаторы, которые чётко описывают смысл поименованной сущности, в лиспе приняты уже очень давно, а явистам понадобилась целая книжка «чистый код» для этого.

почему CPython выжил, Ruby медленно и мучительно умирает, а CL уже гниет

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