приходит один аутист из команды, и говорит

Почему аутист, а не технический специалист?

Потому что это примерно одно и то же.

Почему тогда куча контор используют лисп?

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

Кроме как пойти в какую-то быдлоконторку у программиста, инженера, исследователя нет что ли других вариантов?

Все же не в «какую-то», а в гугл. Это далеко не какая-то контора, а очень даже некакая-то.

Разрабатывать вебню без макросов и repl - это вообще катастрофа, я пробовал - хорошо что ушел от туда без посттравматического синдрома

Разрабатываю вебню на JS с REPL. Что я делаю не так?

В чем проблема найти специалиста в вебе и обучить его clojure? Очень многие кложуристы это бывшие питоно-джангисты и рельсовики, если что

Если ты конкретно мне как руководителю пишешь, то у меня такой проблемы вообще нет, я могу научиться и научить. Но эта проблема есть у 95% руководителей.

А теперь сравни это с объемом кода на питоне/JS.

python более популярный, соответственно на нем больше кода. К чему эти закидоны?

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

У них нет машинного кода и нет ассемблера.

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

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

Конечно, потому что байткод он продукт компиляции и для человека плохо читаем

Логи systemd тоже нечеловекочитаемы? И что, ты декомпилируешь/дизасембелируешь логи systemd при чтении?

java для кложи это низкоуровневый язык, на котором реализована кложа, и которая имеет к нему доступ на уровне более менее нормального интеропа. Для питона С - это внешний язык, который подключается чужеродно через cffi, к тому же небезопасный

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

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

В кложе использование джава библиотек, это просто фича (потому что just as planned и уже много написано, не выкидывать же на помойку)

Ты не задумывался над тем, почему никто не реализовал еще кложу на C/C++ или еще чем-то низкоуровневом? Кложа довольно глубоко интегрирована в жаву и использует стандартные функции жавы. Это ее плюс и минус. И минус как раз в том, что нельзя просто оторвать кложу от жавы и использовать как самостоятельный язык. Даже в случае ClojureScript это было сделано переносом на другую библиотеку, и не без потерь по пути.

для питона использование С-модулей это всегда гемор и не идиоматично

Я тоже так думал. А потом мне показали генератор прокладок Python-C/C++. И я согласился с тем, что таки использование модулей на C/C++ — это просто. Да, некрасиво, да, неидеоматично. Но просто.

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

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

Да, тот же SBCL написан в основном на самом лиспе

Не только sbcl, почти все лиспы так. Но, повторюсь, хоть это и круто - это не самое важное

У питона добрая половина библиотеки тоже на самом питоне писана. Вопрос же не в существовании этого факта, а в конкртеном соотношении. В SBCL лиспа много, а других реализациях лиспа меньше. А вот ибо нефик ядро на динамическом языке писать.

но другие компиляторы более активно перекладывают низкоуровневые фичи на низкоуровневые языки.

И это очевидный минус, о чем и речь. Надо объяснять почему?

Не нужно объяснять: это такой же минус. как и плюс.

К тому, что программирование — это тупо труд. Нудный и долгий, из тысяч и миллионов человекочасов.

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

Но в основном принято оценивать труд «труженников» так

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

Владимир 123

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

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

Щ-утка

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

Поэтому то пушки создали …

Владимир 123

Вообще на лиспе я смогу написать гораздо больше чем на питоне, хотя бы потому-что на лиспе я писать буду, а на питоне - нет.

Ты очень старнный вопрос задаешь, я не понимаю описываемого сценария. Типа «я отключился, а оно пусть пока повисит»? Нет, при отключении отладчика выполнение возобновляется, а если исключение необработано, то возобновляется завершение работы программы.

например: вывалились в отладчик, нашли ошибку, исправили в REPL, перезапустили сей monkey patching. после чего продолжили с того места на котором вывалились в ошибку – которая теперь не возникает. и поехали дальше как обычно.

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

Если ловить исключение при самом его создании, то там еще ничего не отмотано и можно просто выйти обратно в нормальное выполнение.

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

к вопросу о порождающем тензорном пространстве "кластера метапарадигм"

к вопросу о порождающем тензорном пространстве кластера метапарадигм

Справедливо говорить, что лисп не дает каких-то волшебных сверхспособностей.

first class object это такой вполне себе конкретный объект, парадигма, понятие – напросте на которое можно указать пальцем. впрочем, пребывающий бОльшую часть своего времени исключительно на метауровне существования.

прежде всего, несколько определений. мультипарадигменным языком программирования назовём такой, который позволяет программировать задачи на этом языке, используя невозбранно встроенные в него «из коробки» парадигмы программирования, модели мышления, способы думать о задаче. иначе (напросте) говоря, в среду исполнения/компилирования этого языка погружены парадигмы программирования – как first class objects. то есть, first class парадигмы позволяют выражать задачу с нужной точки зрения (здесь мы помним, что качество моделирования выражается в том числе и целью, задачей моделирования – и точкой зрения/viewpoint с которой моделирование достаточно). иными словами, first class парадигмы, погружённые непосредственно в сам язык невозбранно приводят к моделированию лучшего качества – модели могут непосредственно, невозбранно использовать все возможности среды или языка программирования – как first class citizen. ежели для реализации сего действа в выбранной конкретной надобно сначала как следует поднапрячься, от безысходности: точно так как в милые бранятся – только тешатся, сиречь возбранно – парадигму и ея реализацию сию не след считать воистину встроенной изначально, сызнова, невозбранно достигнув желаемого.

если парадигмы – это модели мышления, то что же такое суть метапарадигмы? парадигмы, описывающие, порождающие другие парадигмы. иными словами, метапарадигма суть порождающее пространство, создающее новые парадигмы – на стыке оных. к примеру, функционально-объектное (goo, dylan functional objects; haskell typeclasses) или логически-объектное (logtalk=prolog+smalltalk;datalog=data/entity POD+prolog) программирование.

это может быть более наглядно представлено на примерах – языков и метаязыков, полезных моделей.

к примеру, вот есть парадигма грамотного программирования (неграмотный перевод надмозгами: литературное программирование).

среда грамотного программирования по сути является порождающей метасистемой: к примеру, funnelweb fw-utf8 по сути является макросредой интерпретирующего типа, на уровне парадигмы грамотного программирования поддерживающей идеологию single source и программирование в формате блогозаписей:

• вместо того, чтобы начинать с кода заканчивая описанием (подстраиваясь под логику и ход изложения кода или описания, навязываемого структурой программы на языке программирования) – начнём разработку рассказывая в бложике удивительные истории виртуальному собеседнику.

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

*** гипотезой здесь является доказательство полезности требования, необходимости реализации той или иной фичи. экспериментом – конкретная проработка высокоуровневой архитектуры, взаимодействия и сценариев использования, заканчивающаяся тестами и конкретной структурой низкоуровневого API. обработка результатов эксперимента, замеры производительности и эффективности, бенчмаркинг, профилирование и оптимизация – результатами испытаний по некоторой методике.

** во-вторых, структура и последовательность изложения может быть любая, в которой удобно думать – программирование в порядке потока сознания

• в-третьих, разработка и кода, и документации ведётся single source, из единого источника. что полуавтоматически упрощает проблему трудоёмкости обновления документации когда код изменился. теперь мы программируем короткими блогозаписями, содержащими кододанные (описание замысла). развёрнуто выражаем мысль и замысел: что это и зачем. после чего приводим краткий, афористичный и лаконичный код только по делу. когда нужно внести изменения – прежде всего начинаем с описания замысла, причины и смысла этих изменений.

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

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

• в-шестых, но не последних – упрощается развёртывание (см. презентации rigidus про Literate Deployment, Literate DevOps).

итак, грамотное программирование – это довольно высокоуровневая парадигма программирования (или, скорее: метапарадигма). среда, натурально её поддерживающая по сути реализует работу с двумя потоками, материализацию из потока сознания single source в два порождающих холона: код и документация. документация описывается на нормальном языке документирования (например, TeX/LaTeX, SILE, pandoc, lout, scribe, troff) и представляется в бумагоподобных форматах (pdf,PostScript, djvu; на худой конец, ebook, html+svg). и код, и документация – принципиально гипертекстова: можно изучать блоки кода, маленькими смыслосодержательными кусочками, путешествуя по гиперссылкам. также это книга – у которой есть индекс, содержание, глоссарий (в которых и следует искать переменные, функции, классы и объекты). наконец, она может быть интерактивной (в духе Emacs org-mode C-c C-c блоков кода или интерактивного исполнения примеров из Jupyter Notebook).

эта среда как метасистема видит и понимает весь код целиком, и всю документацию целиком.

по команде tangle способна материализовать код в отдельные файлы. по команде weave – материализовать логическую документацию (на языке вроде TeX) в отдельные файлы порождающие физические документы (вроде PDF, PS, djvu).

при этом сплетённая через сильное колдунство weave документация может содержать графики, тесты, выхлопы порождённые квантово запутанными заклинанием tangle блоками кода, результаты их выполнения.

классическое средство CWEB Дональда Кнута поддерживает только один язык программирования C/C++ (что определяется встроенным pretty printer ом и построением глоссариев и индексов) и только один язык документирования – TeX.

более универсальное средство типа funnelweb, noweb, progdoc, fanlge – поддерживает любую комбинацию языков программирования и документирования. в частности, разрабатываемая программа может быть мультиязычной, в том числе – мультипарадигменной.

достигается это отказом от pretty print (или делегированием во внешние highlight) и упрощением индексирования; возможностью вставлять описание на языке документирования непосредственно – или сгенерированное из некоторого метаязыка, подмножества разных языков документирования.

само такое средство по структуре своей устроено как интерпретатор небольшого языка (или скорее, языка). есть блоки документации и блоки кода. блоки кода можно добавлять к предыдущим с тем же названием. можно разбивать на несколько include файлов, определять макросы и подстановки.

интерпретатор грамотного языка метапрограммирования поддерживает все эти команды разметки – и конкретные действия и процессы, вроде tangle или weave.

архитектурно разные средства грамотного программирования реализованы по-разному, что имеет свои преимущества или недостатки. так, интерпретатор funnelweb был переписан с Ады (где, по-видимому использовались параллельные процессы и tasks на Си реализацию); noweb был изначально написан на Icon с goal-oriented execution и порождающими конкурентными ковыражениями (и позволял расширять проходы и пре/постпроцессинг элементарно); некоторые другие реализации были написаны на скриптовых языках программирования.

каждая реализация имеет свои преимущества и недостатки. так, например реализация в среде скриптового языка с батарейками по сути позволяет использовать все преимущества обработки метапарадигменных объектов вроде блоков кода/документации готовыми библиотеками и фреймворками.

реализация в виде ковыражений – элементарно распараллеливается и расширяется.

реализация в виде метациклического вычислителя, например метациклического интерпретатора на каком-то простом языке (вроде пролога или лиспа) – элементарно расширяется (и такие расширения автоматически работают с метапарадигмами как first class objects, first class citizen)

в частности, любопытна реализация подобного средства на простых лиспах вроде picolisp, kernel, txr, lua.

также любопытна реализация например на смоллтоке – легко пользуясь MVC паттерном можно было бы изобразить литературно-грамотную IDE, выполняющую сборки и материализации вроде tangle/weave одной кнопкой.

реализация в виде многостадийных метавычислителей типа MetaOcaml, MetaLua или Lua+Terra, Template Haskell также вызывает определённый интерес. в частности, могут ли блоки кода быть полноценными AST-макросами, которым можно делать quote/unquote/splice. судя по всему, выходит, что подобное вполне себе возможно.

в плане направления расширения подобного универсального средства поддержки грамотного программирования напрашивается следующее.

вперво, отчего же мы можем обрабатывать только модели кода и документации, но не модели данных? например, yacc-подобная грамматика. это по сути порождающая метамодель. при существующей реализации, мы имеем файлы (которые могут порождать другие файлы, например, грамматика код парсера – но это не важно) и команды make weave/make tangle. при этом жизненный цикл процесса разработки в виде edit, hack-hack-hack, compile, run, test, rinse & repeat – расширяется двумя командами, make tangle для обновления кододанных и make weave для обновления грамотной документации, использующей сии кододанные.

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

допустим, это всё – теперь не файлы, а некоторые объекты, лежащие в многопользовательской и имманентно конкурентной объектно-ориентированной базе данных.

GUI визуализация таких объектов или метаобъектов – теперь может использовать какой-то паттерн типа MVC, MVVM или реактивного программирования и прочего livecodig эдакой литературно-грамотной IDE.

текстовое представление (например AST или CST) – может вполне себе использоваться одновременно и независимо на ряду с графическим.

языки моделирования и метамоделирования могут быть чётко выражены – например, yacc грамматики, PEG грамматики, парсер комбинаторы вроде PetitParser под смоллток или парсеры вроде META либо пратт-подобные парсеры.

это всё метаметаязыки. порождающие конкретные метаязыки (например, модели данных вроде SQL, OQL либо STEP EXPRESS). порождающие конкретные парсеры, разбирающие языки (конкретный входной файл или объект).

такие связи семантической фреймовой сети представления знаний можно выразить явно. или неявно, в виде пролог-подобного наподобие Datalog или LogTalk языка запросов.

из полезных фич также видится явная поддержка сборки вариантов и Literate DevOps.

подобное можно описать двумя литературно-грамотными документами: одно на DevOps, другое на саму систему.

в общем, в виде краткого резюме по этому этапу себе уяснили: средство литературно-грамотного программирования – это порождающая метасистема, работающая с двумя потоками метаязыков: документирования и кодирования. которую можно расширить в три: моделей данных, выделенных явно. можно добавить также команды помимо tangle и weave – например lint и witchcraft – волшебного заклинания, которое порождает из метамоделей модели конкретные метафизически, а из моделей – сам моделируемый ими информационный объект, в физическом смысле.

эта метасистема поддерживает особую, литературно-грамотную уличную магию парадигму программирования – из единого источника single source, парадигму программирование в блогозаписях в порядке потока сознания.

скорее всего, судя по её универсальной порождающей силе – даже метапарадигму.

средствами реализации сей метапарадигмы выступают процессы её материализации: weave, tangle (и будем надеяться, witchcraft) – выраженные в довольно общем, метапарадименно выражаясь, способе и виде конструирования.

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

так, например, в реализации языка LEDA и сопуствующей ему документации описывается пример, когда подобная мультипарадигменность, встроенная в сам язык вполне себе уместна – некоторая информационная система, вычисляющая на графах (упс, кто сказал AST?)

там узлы этих графов описываются как классы с методами, то есть, объектно-ориентированно. функции, обрабатывающие эти графы представлены функционально – то есть, как функционально-объектное программирование. запросы, реализованные на этих графах, на этой сетевой БД – представлены логически – то есть, как логически-объектное программирование.

то есть, вот это по сути и есть механизм порождения тензорного пространства кластера метапарадигм , порождающего мультипарадигмы квантово запутанного через сильное литературно-грамотное колдунство вроде tangle/weave/witchcraft – посредством реализации порождающих сии абстрактные вельми метапарадигмы кода, документации,данных поддерживающим механизмом весьма частных парадигм, таких как функциональное, логическое, объектно-ориентированное, наконец – но и их метисов, сиречь, функционально-объектно-ориентированное и логически-объектно-ориентированное.

ALL YOUR BASES BELONGS TO US. RESISTANCE IS FUTILE. YOU WILL BE ASSIMILATED.

BEWARE.

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

к примеру, реализацию FunnelWeb в виде форка fw-utf8 как интерпретирующую среду, поддерживающую(Literate DevOps) и порождающую(Literate programming) метасистему с метапарадигмой грамотного программирования вполне себе можно воспринимать как реализацию интерпретатора некоторого языка (или, скорее метаязыка) литературно-грамотного метапрограммирования.

обозначим сей (мета)язык как M¹ (TeX: $ M^1 $) , а исходную реализацию его интерпретатора (последнего актуального форка fw-utf8) на языке Си – как M¹₀ (TeX: $ M^1_0 $)

будем последовательно её расширять: расширяя язык и переписывая реализацию интерпретатора в реализации на более других чем Си языках: как M¹₀, M¹₁, M¹₂, M¹₃, … (TeX: $ M^1_0, M^1_1, M^1_2, M^1_3, \dots $ ) .

этот процесс можно представить в виде свёртки тензоров:

M¹ = свёртка (M¹₀, M¹₁, M¹₂, M¹₃) обратной тензорному произведению M¹₀ ⊗ M¹₁ ⊗ M¹₂ ⊗ M¹₃ (тут ⊗ = (x) )

иными словами, вдругорядь:

общеабстрактная метапарадигма порождённая явлена как предел расширения частных реализаций ёё интерпретаторов

1. обозначим, к примеру исходную реализацию fw-utf8 на Си как M¹₀.

2. в качестве M¹₁ к примеру можно взять реализацию подобной funnelweb среды (соответствующей определению языка M¹) на более другом языке, например связке Lua+Terra.

здесь в метасистеме M¹₁ реализующей метаязык L=Lua, использующей базовый язык B=Terra можно будет явно выделить базовый и мета уровень, на разных языках реализации:

M¹₁ = L¹₁ ⊛ B¹₁ , где ⊛ = (*)

в отличие например от исходной реализации на Си:

M¹₀ = ∅ ⊛ B¹₀ = 0 ⊛ B¹₀ = L¹₀ ⊛ B¹₀,

иными словами, в базовой реализации всё реализовано на базовом языке Си = B¹₀ и полностью отсутствует метауровень, метаязык L¹₀ = 0 = ∅

3. в качестве другой интересной реализации, например M¹₂ = L¹₂ ⊛ B¹₂ возьмём языки: базовый B¹₂ = Ocaml (+кодогенерация в LLVM), его метаязык L¹₂ = MetaOcaml (+ боянистые скобки [| ... |] CST CTFE макросов.

4. в качестве очередной интересной реализации, например M¹₃ = L¹₃ ⊛ B¹₃ возьмём языки: базовый B¹₃ = Rust (+кодогенерация в LLVM), его метаязык L¹₃ = макросы (+ боянистые скобки [| ... |] CST CTFE макросов = AST_макрос_раста!(текстовое_представление_параметров_макроса) ).

наподобие peg::parser!(...) времени компиляции.

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

в чём же их общее свойство? попытаемся конкретизировать.

возьмём, к примеру

5. в качестве очередной интересной реализации, например M¹₄ = L¹₄ ⊛ B¹₄ возьмём языки: базовый B¹₄ = мультипарадигменный язык LEDA (в реализации LEDA/C), его метаязык L¹₃ = используемые им парадигмы (+ боянистые скобки [| ... |] CST CTFE макросов = AST_макрос_раста!(текстовое_представление_параметров_макроса) = ооп ⊗ функциональное ⊗ логическое ).

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

к примеру, B¹₄ = LEDA как метаязык = M²

у которого в свою очередь могут быть разные реализации:

M² = свёртка (M²₀, M²₁, M²₂, M²₃, M²₄)

где к примеру M²₀ = реализация интерпретатора LEDA рефенсная на Си как LEDA/C, M²₁ = LEDA/Oberon, M²₂ = LEDA/Ocaml, M²₃ = LEDA/Lisp, M²₄ = LEDA/Rust и т.п.

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

в свою очередь, M²₀ = L²₀ ⊛ B²₀ где базовый язык B²₀ = сишка, его метаязык L²₀ = отсутствует.

и т.д. и т.п. по всем реализациям.

что же видно на примере применения (мультипарадигменного мета)языка LEDA для реализации исходного кластера метапарадигм грамотного программирования ? что для реализации метаязыка грамотного программирования (и общеабстрактных метапарадигм, в него погружённых) посредством его механизмов реализации (частноупотребительных конкретных парадигм мультипарадигменного языка LEDA) используется самая простая реализация – в виде интерпретирующей VM.

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

нужно владеть техниками эффективной трансляции каждой конкретной частной парадигмы:

• функциональной через TCO, αβη-редукции, CPS преобразования, реализацию этих C.

• логической через WAM-машину прологову (либо более эффективную в смысле LIPS model checking наподобие linear temporal logic), унификацию, урезание леща бэктрекингового

• для объектно-ориентированной классической хватит и какого-нибудь Оберона.

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

напросте следует заменить, что вовсе даже не обязательно делать всё полностью самому (как в реализации LEDA/C исключительно в силу безблагодатности метаязыка метаСи выстроенного в пустоту над базовой сишкой).

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

напросте говоря, нам вовсе не нужно реализовать свой оптимизатор функциональной парадигмы в LEDA/MetaOcaml – спустим её на уровнень базовой Ocaml реализации. а вот WAM-машину прологову или что там заместо неё всё одно придётся реализовывать на MetaOcaml. думается всё же, что это будет несколько проще чем на последнем базовом Си в силу более функциональной природы первого.

эта песня может быть вечной. если (не|"") заменить батарейки.

яь кончилъ.

эта песня может быть вечной. если (не|"") заменить батарейки.

следовательно, вот они требования:

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

• во-вторых, достаточная смысловая мощь порождающих концепций.

так, достаточно интересной реализацией думается вариант LEDA/Lisp или LEDA/kernel bronze age lisp.

возьмём, к примеру

6. в качестве очередной интересной реализации, например языка bronze age kernel lisp M³ = L³₀ ⊛ B³₀ возьмём языки: базовый B³₀ = мультипарадигменный язык Lisp LEDA (в реализации kernel/???), его метаязык, внезапно он же: L³₀ = используемые им парадигмы (+ боянистые скобки [| ... |] CST CTFE макросов = AST_макрос_раста!(текстовое_представление_параметров_макроса) = ооп ⊗ функциональное ⊗ логическое = kernel vau-expressions and first class macroses, environments, парадигмы).

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

теперь базовый метаязык грамотного метапрограммирования M¹ = M³ тоже лисп =

расширяемый метапрог на себе самом

осталось проработать его гипертекстовые и тексто-графические представления.

например, посредством ATN сетей, описывающих невозбранно грамматику тыкалки с проводочкаме = порождающих интерактивную интегрированную среду, состоящую сам на себе из сложносочинённых квадратиков и жгутиков, пестиков и тычинок.

так вот он какой – сам как есть кластер метапарадигм металиспа.

такова его порождающая синекдоха метапрогова.

например: вывалились в отладчик, нашли ошибку, исправили в REPL, перезапустили сей monkey patching. после чего продолжили с того места на котором вывалились в ошибку – которая теперь не возникает. и поехали дальше как обычно

Да, чисто теоретически на VS можно это сделать.

а как после этого перейти в другое исключение, в другой рестарт, в другой condition сигнального протокола ошибок?

«А где здесь шморгалка»? Таких понятий в CLR просто нет.

Почему аутист, а не технический специалист?

Потому что это примерно одно и то же.

Технический специалист учитывает разносторонние нюансы при выборе технологического стека. И если он предлагает CL - значит, его и надо использовать.

Если смотреть на общее число контор, то число контрол, пользующих лисп ничтожно мало.

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

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

Лисп выбирают именно потому, что сроки реализации _важны_. Какая разница для своих нужд или для коммерческих целей компании?

Нужны будут программисты — научим, как ты говоришь. Так же booking учит себе перловиков — для них поддержка существующей системы, даже неэффективная, все равно лучше, чем переписывать эту систему.

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

Кроме как пойти в какую-то быдлоконторку у программиста, инженера, исследователя нет что ли других вариантов?

Все же не в «какую-то», а в гугл. Это далеко не какая-то контора, а очень даже некакая-то.

Google и есть быдлоконтора, как и большинство корпораций.

Разрабатывать вебню без макросов и repl - это вообще катастрофа, я пробовал - хорошо что ушел от туда без посттравматического синдрома

Разрабатываю вебню на JS с REPL.

Где у тебя там репл, в консольке браузера?

Что я делаю не так?

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

то у меня такой проблемы вообще нет, я могу научиться и научить. Но эта проблема есть у 95% руководителей.

Ну, то есть это не техническая проблема, от слова совсем.

Каким бы ты ни был гением — ты не сможешь за год отработать так же, как миллион человекочасов.

Это и не нужно.

А готовый софт — это почти единственный способ ускорять разработку.

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

Ты не задумывался над тем, почему никто не реализовал еще кложу на C/C++ или еще чем-то низкоуровневом?

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

Кложа довольно глубоко интегрирована в жаву и использует стандартные функции жавы. Это ее плюс и минус. И минус как раз в том, что нельзя просто оторвать кложу от жавы и использовать как самостоятельный язык. Даже в случае ClojureScript это было сделано переносом на другую библиотеку, и не без потерь по пути.

Сам себе противоречишь - опять же усилиями достаточно небольшого сообщества кложу перенесли на JS, очевидно, не без нюансов, но ведь они были заранее известны. Следующий перенос кложи, в том или ином виде, вангую будет на платформу CL. Есть проекты по переносу на python-экосистему, но они не столь популярны, просто потому что профита не так много, как от кложи овер js и jvm. И вообще распространением лиспа - питон станет просто не нужен.

И я согласился с тем, что таки использование модулей на C/C++ — это просто. Да, некрасиво, да, неидеоматично. Но просто.

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

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

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

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

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

но другие компиляторы более активно перекладывают низкоуровневые фичи на низкоуровневые языки.

И это очевидный минус, о чем и речь. Надо объяснять почему?

Не нужно объяснять: это такой же минус. как и плюс.

Нет, это только минус. В лиспе тоже есть CFFI, но его не надо использовать на каждый чих.

Технический специалист учитывает разносторонние нюансы при выборе технологического стека. И если он предлагает CL - значит, его и надо использовать

Не разносторонние, потому что он аутист. Потому что помимо технических ньюансов есть социоэкономические ньюансы, в которых он ничерта не понимает. Именно потому ютьюб работает на питоне, и при этом в свое время уделал гугловый видеосервис, писанный на Java/C++. (Справедливости ради, гугл писан на Python+C).

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

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

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

Лисп выбирают именно потому, что сроки реализации _важны_. Какая разница для своих нужд или для коммерческих целей компании?

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

Нужны будут программисты — научим, как ты говоришь. Так же booking учит себе перловиков — для них поддержка существующей системы, даже неэффективная, все равно лучше, чем переписывать эту систему.

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

Живущие в нужном месте, согласные работать за приемлимые деньги. При ЗП х2-3, конечно, много кто туда понаедет, но бюджету фирмы поплохеет.

Все же не в «какую-то», а в гугл. Это далеко не какая-то контора, а очень даже некакая-то.

Google и есть быдлоконтора, как и большинство корпораций

Да, быдлоконтора, но не какая-то. Там есть небольшое число талантливых людей.

Разрабатываю вебню на JS с REPL

Где у тебя там репл, в консольке браузера?

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

Не разносторонние, потому что он аутист.

Это ты сам придумал.

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

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

Лисп выбирают именно потому, что сроки реализации _важны_. Какая разница для своих нужд или для коммерческих целей компании?

Потому что на питоне можно переплатить известному посреднику и получить 99% рабочее решение

Какая разница на чем будет писать «посредник»?

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

Это тоже не проблемы бизнеса, который аутсорсит разработку.

Живущие в нужном месте, согласные работать за приемлимые деньги. При ЗП х2-3, конечно, много кто туда понаедет, но бюджету фирмы поплохеет.

В офис можно набрать только коре тим, остальных на удаленке.

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

Ну о чем я и говорю.

Какая разница на чем будет писать «посредник»?

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

Посредник ни на чем не пишет, он только занимается подбором более-менее способных кодеров на рынке и их перепродажей

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

Посредник ни на чем не пишет, он только занимается подбором более-менее способных кодеров на рынке и их перепродажей

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

Потому что весь верх рынка так работает. Да, ты на каком-то заводе можешь устроиться на 30 тыр и делать внутризаводской проект на лиспе. Или во фриланс, делать проекты с бюджетом 5 тыр. Но это еще печальнее, чем бодишопы, хоть и составляет большую часть рынка, чем бодишопы.

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

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

Ты структуру рынка оцениваешь что ли по странам снг и прочим индонезиям, куда сливают весь легаси?

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

В первую очередь это внутренние отделы (например, в банках и во всяких амазонах)

Амазонов не так много в мире. Как правило, в современном мире держать огромный штат айтишников — это слишком затратно. Даже какие-нибудь IBM/Oracle/MS отдает часть работы на аутсорс — это всё вместе составит таки большую часть рынка. Но это ни разу не собственные програмисты, это индусы из бангладеша, который работают в подчинении у отдела ведущих программистов откуда-то из силиконовой долины.

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

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

Где? Есть мало других вариантов, более интересных и оплачиваемых. Есть много других вариантов, более унылых и неоплачиваемых. Потому что бизнес не умеет находить программистов — потому нужны посредники. Как правило, хорошие програмисты не умеют себя продавать, а продающиеся не являются хорошими програмистами. Самые доходные сектора для того же Microsoft нынче — это облака и консалтинг, где MS найдет на рынке программистов для вас и даже выполнит ваш проект за вас руками этих индусов. А потом еще в нагрузку продадут свои платные сервисы/подписки. Конечно же лучших кодеров MS оставит себе, а среднячки пойдут вам. Это вроде как не бодишоп, но как бы на самом деле бодишоп. Так работает весь рыночек, потому что интернет, потому что большое предложение низкоквалифицированной раб силы.

Python твой в 2010 умер, все на лисп переходят, в том числе и тырпрайз. Я еще помню как на днях был на конференции (работаю в крупной компании over3000 сотрудников), решаем вопрос об архитектуре системы. Мои коллеги че-то пиздели про хайлоад и плюсы, но у меня уже было пару козырей в рукаве. Так что я встал и говорю - все хуйня, ребят, в 2к21 все четкие пацаны на лиспе хуярят, так что давайте выбросим весь тот зашквар, на котором сейчас пыхтит продакшн. Смело заявления, но оно сработало. Пол бюджета тупо вылили на переписывание инфраструктуры на всякие лиспы, каждый прогер выбирал свой любимый диалект и на нём писал, даже босс подключился и сказал «Бля какой хуйней мы занимались, вот где живет дух старой школы, пацаны».

Печально там у вас в Злой Параллельной Вселенной, нет работы кроме галер. Хорошо, что я не воспользовался порталом в свое время. А ведь предлагали!

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

Понт, Джеймс Понт…

«Бля какой хуйней мы занимались, вот где живет дух старой школы, пацаны».

У вас в отделе кадров, скорее всего, поступающих на работу проверяют на то умеют ли они материться …

Это только в XXI веке можно представить себе Джеймса Бонда инвалидом и не будем ещё говорить кем.

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

Introduction To The Medley Lisp Environment

Back in the ’70s and ’80s Lisp workstations were an important development. A portable version of one of those environments was created at that time called Medley. The source code to that original system has been made open-source, ported, and modernized, and is available on GitHub. This introduction is about that system.

Medley originally supported Interlisp (an older dialect of Lisp) but grew to support Common Lisp as well. Medley, therefore, is a software development environment that embodies Interlisp and Common Lisp.

у него же:

• Portable Utah Standard LISP

• объектная система Dynace :

fully meta-class based (like Smalltalk or CLOS)

dynamic binding and dispatching through generic functions (like CLOS)

written in standard C

using classes involves no new syntax elements to standard C

похоже на смоллток (оттуда иерархия классов/метаклассов) + мультиметоды как в MOP и CLOS

на этом можно какой-то LittleSmalltalk запилить, с незначительными накладными расходами на ООП

Little Smalltalk

до кучи :

• spry через Nim

• nntp

• little smalltalk

• gh: little smalltalk

• PLOB

• Zoku Talk

InterLisp

gh: InterLisp

https://interlisp.org/

один из предков CommonLisp (второй известный – MacLisp из Project Mac/Multics Lisp – ??? на PL/I ???)

Лол, мне показалось, или сейчас на моё сообщение ответило АЖ ДВА АУТИСТА, только один из которых с синдромом Аспергера? Я сейчас даже ведь не шучу.

структурный редактор из InterLisp

отсюда про структурный редактор (SEdit из Medley, InterLisp) – Inspiring a future Clojure editor with forgotten Lisp UX

history-of-lisp-parens – посмотри в papers публикации

например, editors >> Interlisp Teletype Editor Try it here! > LISPF4

У меня на рабстве проект self-hosted, например. Как правило, если ты не бомж из подворотни, то рано или поздно твой проект переходит на self-hosted, будь то gitlab или что-то другое.

SDL2 переезжает на GitHub

разрабы SDL2 были князями, а стали бомжами, получается

Как лисп оно совсем никому не интересно

если бы кложура не была лиспом - кложуры бы не было

Меня больше всего удивляет то, что находятся фанаты ClojureScript, которое в мире JS вообще ни к селу ни к городу

я не знаю, на чём ещё можно писать фронт, чтобы не выгореть к 30 годам

Если бы это был какой-нить ML (привет F#), то без скобочек это было бы менее и более востребовано.

в клжс скобочек чуть ли не меньше, чем в самом JS (особенно учитывая лаконичность самого языка)

Что я потерял из лиспа?

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

Напоминаю, что сами разрабы Clojure не поощрают применение макросов

not true, они не поощрАют написание новых макросов без особой необходимости, это как бы обычная лисповая практика, просто в Clojure учли старые ошибки и потому делают на этом акцент. А так-то в clojure.core макросов огого сколько.

макросы у них существуют только во время компиляции

в любом лиспе макросы - compile-time

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

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

И у руби выше, и у F# выше. Потому что предложение меньше и ответственности больше. Есть большая размница между говномикросервисом на питоне и какими-то финансами на F#.

мне, как кложуристу, всё равно, что является причиной, следствие от этого не изменится

Как лисп оно совсем никому не интересно

если бы кложура не была лиспом - кложуры бы не было

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

Меня больше всего удивляет то, что находятся фанаты ClojureScript, которое в мире JS вообще ни к селу ни к городу

я не знаю, на чём ещё можно писать фронт, чтобы не выгореть к 30 годам

Аргумент засчитан. Однако, в плане производительности этот аргумент не катит — наймем другую JS-мартышку.

в клжс скобочек чуть ли не меньше, чем в самом JS (особенно учитывая лаконичность самого языка)

document.location.href.length

пишется как

(.. js/document -location -href -length)

Что я потерял из лиспа?

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

Зачем мне гомоиконность? Я не буду работать с пользовательской картинкой или другими данными и с исходным кодом программы одними функциями — для них все равно нужны разные инструменты. Более того, лисп — это про бесконечное создание DSL. Какая мне разница, будут ли данные из разных DSL-ей гомоиконны или нет?

not true, они не поощрАют написание новых макросов без особой необходимости, это как бы обычная лисповая практика, просто в Clojure учли старые ошибки и потому делают на этом акцент. А так-то в clojure.core макросов огого сколько

Да, в clojure.core на макросах описывается сам язык вместо того, чтобы прибить подобные конструкции гвоздями к языку. Правда, если ты захочешь сделать DSL, который сильно отличается от лиспа, то макросы тебе не помогут. А если DSL будет не DSL, а просто легкая модификация штатного лиспа — то зачем тебе макросы вообще? Макросы позволяют обходить ограничения языка, вроде переменного числа аргументов, но в том же хаскеле переменное число аргументов есть безо всяких макросов.

в любом лиспе макросы - compile-time

Там ниже было обсуждение о том, что вообще-то не в любом. Но в CL и Clojure — да, compile-time-only.

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

Если бы это был какой-нить ML (привет F#), то без скобочек это было бы менее и более востребовано.

https://reasonml.github.io/

Следующий перенос кложи, в том или иновиде, вангую будет на платформу CL

А зачем? Так то порты энтузиастов «в одну морду» не следующие, они давно уже есть на джитхабе. Ажиотажа не вызвали.

А зачем?

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

Так то порты энтузиастов «в одну морду» не следующие, они давно уже есть на джитхабе. Ажиотажа не вызвали.

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