И результат точно был лучше чем альтернативные DSL? Или ситуация аналогична разработке интернет-магазина Полом Грэмом?

Альтернатив на тот момент не было.

Ситуация, впрочем, в некотором роде, была аналогичной: более мощный язык позволял от паровоза даже убегать.

Самое сильное впечатление от CL после C++ осталось такое: на C++ долго-долго проектируешь, потом начинаешь писать, вскрываются косяки в архитектуре, которые очень больно исправлять, а с некоторого момента и вообще невозможно исправить без перепроектирования, и потом в продакшене это амно адским адом себя ведёт. CL из-за своей чрезвычайной гибкости позволяет переобуваться прямо в прыжке и разворачивать архитектуру на 180 градусов. В продакшене CL тоже ведёт себя прилично: если нормально написано и прогнанно через тесты, то проблем очень мало.

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

Причём, более «приземлённый» С++ работал крайне плохо и в плане производительности, т.к. сплошные слои плохо реализованных абстракций на таких же слоях, из-за невозможности малой кровью упростить архитектуру. Стек-трейсы на 90 фреймов, и всё такое. И вообще, хорошая производительность в большом проекте - это, в основном, достаточно серьёзное понимание архитектуры железа, а не просто более низкоуровневый язык.

То есть контрпример к своему утверждению ты сам привёл.

Нет, ты как-то невнимательно читаешь мое утверждение. Проблема именно в этом.

Если задача «написать DSL для VHDL», то их много: HML, JHDL, ScalaHDL, asip-dsl, …. Если задача «написать DSL для VHDL с синтаксисом Common Lisp», то, разумеется, решить её проще на лиспе.

Изначальный свой же вопрос помнишь вообще? :) Я привел пример, и задача там была не просто написать DSL. Большинства из тобой приведенных вариантов в то время не существовало, и с вероятностью 99% они вообще не про решение тех задач. И в итоге там было несколько синтаксисов.

Легаси, я ж написал это как опцию.

Common Lisp нынче такое же легаси.

Нет.

Или ситуация аналогична разработке интернет-магазина Полом Грэмом?

Аналогична в чем? Какие еще ты приведешь примеры успешных конструкторов (!) интернет-магазинов на конец 90х? Сколько из них купили за 50M баксов?

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

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

только теоркат, только хардкор!

докторская д.ф-м.н.

КОВАЛЁВ Сергей Протасович ТЕОРЕТИКО-КАТЕГОРНЫЕ МОДЕЛИ И МЕТОДЫ ПРОЕКТИРОВАНИЯ БОЛЬШИХ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ

год защиты 2013

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

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

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

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

отдельные главы про «Отображение алгоритмов на архитектуру вычислительных систем» и про «Формальная технология проектирования вычислительных систем» из раздела «АЛГЕБРАИЧЕСКИЕ МЕТОДЫ ПРОЕКТИРОВАНИЯ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ».

и далее про формализацию АОП (в смысле теории категорий).

""" Основой для формализации аспектно-ориентированного подхода служит семантика трассирования, которую в настоящей работе мы строим из конструкций в формальных технологиях проектирования. Зафиксируем произвольную формальную технологию проектирования AR = 〈c-DESC, Conf, sig, r-DESC〉, обозначим через ε коединицу сопряжения sig* ⊣ sig. Ясно, что трассируемость сильно нарушается при трансформациях (хрестоматийным примером является реализация алгебраической спецификации программы на алгоритмическом языке программирования). При интеграции, напротив, обычно обеспечивается хотя бы частичное трассирование (здесь примером служит прямая сумма множеств в категории Set, при построении которой элементы каждой компоненты снабжаются ее меткой). Поэтому возможность трассирования результата трансформации r : S → T к источнику (в направлении от T к S) означает, что143 обращение ее направления, т.е. теоретико-категорная дуализация, превращает ее в действие по интеграции – в c-DESC-морфизм rop : T → S (ср. разд.2.5).
"""

и т.п.

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

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

про то, как синтезировать систему с требуемыми свойствами.

какое-то осмысление есть, про то, что там строго (мета)математически происходит, в суровом энтерпрайзе-то. а не тупо ad hoc и в продакшн.

у него даже презентация на эту тему есть: С. П. Ковалёв – теория категорий как математическое обоснование MBSE (на slideshare)

обзор от А. И. Левенчука, президента INCOSE (ранее) «математики системного подхода» (системноинженерного) – там в конце ссылка на автореферат этой диссертации, если не убрали. впрочем, на сайте автора этой докторской тоже когда-то можно было автореферат скачать и ознакомиться. или по выходным данным поискать.

очень интересная работа. в духе В. М. Глушкова, Цейтина про «систему алгоритмических алгебр», только через теорию категорий. всё так формально теоркатегорно и умозрительно логично и красиво.

и полезная практически.

Значит нужен инструмент для построения изоморфизмов между примерами кодами

а ты говоришь – LitProg метапрог.

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

UCSD Pascal, вот тебе вдобавок к P4

UCSD P-system

UCSD P-system Museum

Так себе аргумент. Будто бы в сишкоплюсах сегфолтов не возникает посреди игры.

В питоне реально сложно делать статический анализ. mypy/pytype помогают, но они хуже, чем даже typescript. Это дофига осложняет работу с достаточно большими проектами (скажем, >50-100k sloc).

А сравнивать это всё надо не с плюсами, а с более нормальными языками. Тот же шарп там, свифт или rust.

Пайтон конечно. Рапидный девелопмент, байт-код компайлинг, изи дебаггинг и рефакторинг.

Интересно, что мешает сказать вот так:

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

?

Мешают сарказм и чувство хьюмора.

с более нормальными языками.
Тот же шарп там, свифт или rust.

А, вы из тех, всё понятно теперь.

В питоне реально сложно делать статический анализ. mypy/pytype помогают

Это дофига осложняет работу с достаточно большими проектами

Кто же вас заставляет писать на таком неудобном для вас языке… Или вы мазохисты и вам это нравится/привыкли?

Понимэйшн.

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

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

Ну тут уж вы сами виноваты в неудачном выборе ЯП.

Не ЯП, а команды. И выбрать питон для одного из сотен стартапов — вполне ок решение, никто же не ожидает, что оно внезапно выживет и разрастётся из proof-of-concept в 5 килострок кода до монстра в 1кк.

никто же не ожидает, что оно внезапно выживет и разрастётся из proof-of-concept в 5 килострок кода до монстра в 1кк.

Вот всегда так. Делаем сейчас, а думаем потом.

откуда есть пошёл "текстовый" файл.

а не только лишь пить бинарный.

скандалы, интриги... расследования!!!

отсюда ноги растут:

The P4 set can be compiled with any ISO standard compiler. P4 itself compiles a subset of standard Pascal, with the following omissions/changes:

...

Only files of type «text» can be used, and then only the ones that are predefined by P4, which are «input», «output», and two special files defined so that P4 can compile itself.

FAQ про UCSD: отсюда из PUG, сорцы про PL/0 plzero.pas — ну не PL/1, но тоже недоалголишка.

Not designed to be a practical language, it is, however, a full compiler example.

кстати, в standart pascal read/write это операторы, а не функции. потому что с переменным числом параметров и форматами. это тоже из PL/1 ещё пошло, там правда ещё более законфигувыристо, в райнтайм недоинетпретатор (или P4: пере pint.pas-рантайм екстендер- недо-pcom.pas недокомпилятор) упрятано (тот самый малый недоязык, интерпретатор которого стремится вырваться наружу, лол).

книжка по P4

понятно теперь, откуда в MSDOS файлы «текстовые» на Ctrl-Z оканчивающиеся. оказывается вот откуда ноги растут — из Pascal-P:

P-machine Pascal was designed to be a proper subset of pre-standard Pascal. Therefore, P-machine Pascal will have all the differences that exist between 1972 Pascal above and the 1982 standard, except concerning those features that are missing from P-machine Pascal, and the following additional changes/subsetting:

...

3. Only files of type «text» can be used, and then only the ones that are predefined by P4, which are «input», «output», and two special files defined so that P4 can compile itself.

...

Q. What was the «p-machine»?:

The P-machine was a bootstrap kit designed to make porting a Pascal compiler faster. It didn't implement the entire Pascal language, because it didn't need it for its own use. For example, it was restricted to text only input and output because the Pascal source, and even the intermediate code in an assembly like format, was all in text. The P-machine was designed to bootstrap itself as a compiler, that's all. It was never designed to define a subset of Pascal.

однако же, повелось. IronBug, вот что надо было тому дедушке ответить. что это не только из MSDOS, а из костыльной бутстрап-реализации интерпретирующего недокомпилятора паскаля P4 (оно же байткод UCSD оно же недоJVM) ещё повелось, да так все и забыли про заглушку. и ввели отдельный термин — поди ж ты, текстовый файл. так в input, output. как в затычке P4 вместо недокомпилятора байткод P-кода.

по идее все файлы — бинарные блобы. даже текстовые. потому что это тупо неструктурированный набор байт. а содержимое зависит от интерпретации (включая кодировки). вот какие-нибудь ресурсные форки в NTFS/HFS+ или там *.odc в BlackBox Component Pascal обероне или там глобалы в мумсе — уже прообраз структурированности (хотя схемы нет, так что структура там динамически типизирована — ad hoc, давно и неправда).

И выбрать питон для одного из сотен стартапов — вполне ок решение, никто же не ожидает, что оно внезапно выживет и разрастётся из proof-of-concept в 5 килострок кода до монстра в 1кк.

+1, вот не было ж никогда такого – и вот опять.

в этом смысле, более разумнее структурировать скриптуху в какой-то AdaScript: SparForte : примеры батарейки

потому что всё со временем и так превращается в говно скриптуху, обмазанное скриптухой через скриптуху. хоть оно питон, хоть бейсик, хоть паскакаль (который давно из этого выполз ещё из JVM UCSD P-system) с адой (где всё-таки нормальный компилятор и оптимизатор, тот же gcc, модульность, раздельная компиляция).

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

а вторая недоскриптуха – динамически типизированное (это ещё полдела) плохо структурированная в пакеты (а вот тут клиника) говно, и не лечится.

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

то во втором это питон-через-сишку, pypy, и прочий «сру» недокомпилятор недопитона с сишными DLL-ками.

и полная жопа с архитектурой, масштабируемостью, скрытыми в рантайме локами (ау, GIL во все поля?)

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

за что пистон наш не берётся – всё превращается в говно.

а если за говно берётся – то просто тратит меньше сил.

путь не всегда перемещение

бутстрап бутстрапа путее бутстрапа

путь http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html познавателен из хексов в почти …

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

т.е простейший инфиксный(чур от форта чур от лиспо-схемо синтаксивов) самораскручиватель лаконичней

это все переменные есть аргументы функций

так как памяти МНОГО (как и CPUraw) то по спецификации есть концевая рекурсия по первой реализации - нет :)

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

т.е по теореме Боема условное и вызовы достаточно.

зы. на 54 строки самосебя генерация помещается.

бутстрап бутстрапа путее бутстрапа

даосистее и внутренне алхимичней

город закрыли то?

Я ещё не кушал сегодня. Вот поем - и прочитаю твою работу на соискание учёной степени.