Ты просто не прошел путь граблей и не почувствовал это на своей шкуре.

Взрослым виднее, наверное. Размер и количество граблей другое.

Если ты пишешь библиотеку, то лучше всё же 100% покрытие иметь.

Ты жопоскриптист?

Люблю посреди игры полюбоваться на AssertionError, ага. Или что там у вас в петонах на этот случай предусмотрено.

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

А поведение обязательно изменится.

И при каждом таком изменении нужно будет вручную тестировать все, что теоретически могло быть затронуто изменением. В особо запущенных с точки зрения модульности случаях (aka Big Ball of Mud) вручную перетестировать нужно все. При каждом изменении.

И каждое написание теста потребует некоторое время.

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

Ты жопоскриптист

Как будто что-то плохое.

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

Нет, если знаешь, что поведение метода не изменилось (т.е. он возвращает те же данные того же типа)

Изменил метод — проверяешь только его.

Метод вовсе не обязательно является чистой функцией.

Которое в перспективе сэкономит тебе гораздо больше времени на ручном тестировании.

Это еще зависит от того, кто и как пишет тест.

И, вероятно, сохранит немало волос на жопе.

Наверное, ты имеешь ввиду тест на возвращаемые данные, иначе я б и тестам не особо доверял.

Меня в питоне тоже не радуют бэктрейсы, тут особенно надо всё проверять.

Это еще зависит от того, кто и как пишет тест

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

Впрочем, признаю, что не понимал как работают тесты. После некоторого просветления я понял, что ошибался. Мне казалось, что тесты пишут с учетом структуры метода, но на деле всё оказалось проще. Тестируется только выхлоп метода (или функции).

В таком случае покрыть все методы будет несложно.

, то какой ЯП меньше всего ресурсов при разработке будет потреблять

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

ресурсы компьютера? ресурсы среды разработки? ресурсы разрабатываемой программы?

ресурсы программиста на понимаемость программы и maintainability?

Если реально исходить из самого минимального.

ассемблер: masm32.com, качаем masm32v11r.zip (4.77 Mb), распаковываем => 51 Mb с библиотеками, SDK, примерами. берём текстовый редактор оттуда (qeditor.exe 37 kb, topgun.exe 22kb) – получаем IDE. как бы блокнот, но технически оно полнофункционально эквивалентное емаксу, но гораздо компактнее. то есть: qeditor.exe расширяется скриптами на своей скриптухе, примерно похожей тоже на ассемблер, и/или DLL-ками. например, перемещаться по тексту, поиск/замена, выделить строку, получить текущую строку в текстовую переменную, сложить число и числовую переменную, сложить/умножить/разделить числовые переменные.

логика и jmp на логику – в этой скриптухе такие же как в ассемблере.

вообще, скриптуха функционально эквивалентная елиспу из емакса, но гораздо проще. при этом есть переменная типа указатель и функции LoadLibrary/GetProcAddress из DLL в указатель/вызов функции по указателю/FreeLibrary.

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

то есть, ну как бы блокнот. и совсем не блокнот – а расширяемый текстовый редактор. расширяемый скриптухой, ассемблером и DLL-ками.

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

есть визуальные IDE на ассемблере (написаные сами на ассемблере и позволяют разрабатывать на ассемблере). например, EasyCode: 7.8 Mb запакованное, 50Мб установленное.

примерно аналогичное дельфи – есть редактор ресурсов, инспектор, настройка событий в инспекторе, даже вроде бы какое-то ООП тоже есть.

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

зато минималистичная среда разработки: ml.exe, link.exe, rc.exe для компилятора ресурсов, что-то типа resedit для редактора ресурсов визуальное или те же IDE типа EasyCode или вот FreshIDE и FreshLIB под Fasm (кроссплатформенное windows/linux, можно сидя под одной осью кросскомпилировать под другую, FreshLIB позволяет разрабатывать кроссплатформные приложения на ассемблере).

это всё ещё винда. ну и да, поскольку на чистом ассемблере удовольствие писать то ещё – хотя в том же masm есть HLL = High Level Language высокоуровневые конструкции (типа if/then/else, invoke для вызова функций, while/for/repeat, исключения, в некоторых ассемблерах и ООП есть). так что код простого Win32/Win64 приложения выглядит очень просто и вполне себе можно его хоть писать руками, хоть в IDE набросать.

далее конечно нужно обчитаться книжек про Win32 API и хелпы например из MSDN или DDK. и далее про calling convention, например Win64 и SEH. например, одним глазом смотреть в примеры на MSDN и в книжке Чарльза Петцольда про Win32 API и другим – переписывать их в уме на эквивалентное на ассемблере.

то есть: программировать под win32/win64 на ассемблере masm довольно просто. хотя всё-таки нужно включать головной моск.

но лениво. хотя те же invoke и HLL макросы всё сильно упрощают.

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

если как следует упороться разогнаться – можно написать на них даже бейсик: MasmBasic

бейсик, реализованый HLL макросами на Masm. который компилируется в ассемблер.

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

есть похожий PureBasic, но оно ЕМНИП закрытое и проприетарное. много батареек, библиотеки, трансляция через fasm в ассемблер, можно писать ASM вставки, кроссплатформное win/lin.

если говорить не про оффтопик, а про онтопик. есть симпатичные потомки JWasm ассемблера из OpenWatcom: asmc, uasm.

uasm: переписанный на Си, кроссплатформный Win/Lin/MacOSX, есть поддержка ООП на ассемблере.

asmc: в комплекте есть dz – файловый менеджер типа нортона, на ассемблере с исходниками, и стандартная библиотека. в духе libc, на которой написан dz.

в итоге с подобной библиотекой вполне себе возможно программировать кроссплатформные Win/Lin приложения на ассемблере.

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

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

хотя это всё ещё ассемблер.

в ту же степь: HLA aka High Level Assembly, HiASM, PureBasic/MasmBasic, LLVM ассемблер и т.п.

меньше всего ресурсов

Ресурсов чего?

далее высокоуровневость и удобство/полезность языков зависят от выражений и first class objects, которые поддерживает этот язык «из коробки», по умолчанию.

например. в форте – стековые выражения и обратная польская нотация. казалось бы, закат солнца вручную. но, и гомоиконность. и «компилирующие слова» CREATE … DOES, и возможность переопределить свой синтаксис. и возможность писать форт-слова на том же ассемблере, или emit C code в том же gforth. и ООП в некоторых реализациях, события, управление памятью.

в итоге, хотя язык форт оченно прост – он позволяет делать composable expressions, из этих самых первокласных объектов уровня языка, форт-выражений. и переопределять свой синтаксис, модели вычисления выражений. например, на taygeta есть ftrans.f – вычисление обычных выражений (не в постфиксной, а в инфиксной форме) через CREATE … DOES слова макросами времени компиляции. в книге Креншоу «Let’s make a compiler» в старой (есть PDF на русском, ссылка была в 8 треде про метапрог ближе к концу треда) приводится пример компилятора паскаля на паскале в ассемблер Motorola 68000. в новой (погугли, и найдёшь сайт) книге Креншоу он переписал это всё на форте, и под x86 ассемблер целевой. получилось очень компактно, просто и наглядно.

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

но, язык форт довольно низкоуровнев. например, в плане управления памятью. поэтому удобнее тот же Factor, который и гомоиконный и конкатенативный, и функциональный с комбинаторами, списками, сборкой мусора, ООП и т.п.

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

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

то есть: разные языки и среды, «системы программирования» (С) Непейвода Н.Н. , книга «Основания программирования»

потребляют разные ресурсы и накладные расходы.

как то, что замерить просто: %CPU cycles, загрузку через time myprogram в рантайме. так и накладные расходы на %RSS size памяти потребляемой, с учётом разделяемых библиотек, аналогов Libc и CRT, C Runtime Library.

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

но которые реально экономят время в долгосрочной разработке.

то есть : макросы, типы высшего порядка, функциональная композиция, composable выражения, pattern matching, сборка мусора, гомоиконность, гигиена, модульность, компонентность, возможность разработки собственных DSL и eDSL под задачу.

реальна в плане используемых абстракций одна метрика, метрика Билла Гейтса: «меня относительно языка и среды программирования интересесует только одна метрика – насколько программирование на этом языке экономит время программиста»

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

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

Вообще какой ПК подойдет в качестве рабочего для программирования и для какого ЯП?

forth, lisp. любой ПК подойдёт. только лисп нужно брать правильный, минималистичный.

Если реально исходить из самого минимального.

picolisp, jonesforth. минималистичнее некуда. при этом всё ещё высокоуровнево и достаточно полезно. первое всё-таки динамическая скриптуха, но хотя бы уже расширяемая dll-ками и асм вставками, поэтому далее нужно вводить типизацию и эту динамичность ограничивать. по результатам замеров, если это всё-таки нужно.

второе – форт на ассемблере, минималистичнее некуда.

потом берём блокнот, только нормальный. типа qeditor.exe из masm32 – расширяемый DLL-ками.

и педалим в таком блокноте код.

очень высокоуровнево. и низкоуровнево. и минималистично.

Форт называли?

Тогда Форт

Я может не столь хорошо знаком с возможностями GCC, но как он поможет с отсутствием биндингов?

сгенерирует их сам. в чём и смысел двухязычного GNAT/GCC.

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

автомагически (из EmbeddedSPARKandAda-web.pdf, также там про портирование Ada runtime на микроконтроллены, Pebble и проч.):

gcc -c  -fdump-ada-spec file.c -o file.ada

здесь gcc из состава gnat, то есть gcc c поддержкой c/c++/ada.

сгенерировать C биндинги автомагически в аду из сишки.

С++: нужно extern C чтобы отключить манглинг.

в книге Ada_for_the_C_or_Java_Developer-cc.pdf более подробно про pragma import для привязок Ada/C/C++/JNI.

здесь привязки к С++ (С++ объектов в Аду, или наоборот) – это специфика GNAT компилятора. обычный pragma import позволяет подключать C, задаются как С так и экспортируемое Ада имя. поскольку GNAT это GCC + C++ + C + Ada, то раскладка класса в памяти и ABI C++ зафиксированы, то есть можно использовать pragma import(Cxx). там есть тонкости, аналогичные calling conventions от Агнера Фога (метод виртуальный/невиртуальный/статический метод класса == разные ABI). но в целом, всё решаемо, есть 1:1 отображения. есть PDF презентация с примерами.

DLL-ки (разделяемые SO-шки) можно естественно писать и на ADA. рантайм Ады должен быть проинициализирован – adainit();....;adafinal(); в main.

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

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

прагмами можно ограничить. не использовать например ООП, ограничиться ada83. убрать выделение памяти и получить контролируемую RTOS систему (в которой уже будет исключения, параллельные процессы, стектрейсы и асинхронность, на каком-нибудь микроконтроллере при кросскомпилировании). см. EmbeddedSPARKandAda-web.pdf про примеры портирования рантайма на новое железо.

есть более компактный рантайм, ограниченный. например, drake.

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

ldd на exe => 0 внешних зависимостей от какой-нибудь libstdc++/libm/libgcc_s_.blablabla.so

gcc -c -fdump-ada-spec file.c -o file.ada

file.ads, а не .adb, конечно же.

TurboPascal 6.0 летал на 8088 и 1 МБ ОЗУ

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

1 Мб это жрал толстый и тяжёлый турбовижн, ещё с оверлеями это веселье было. без него получалось что-то на 300..400 кб уместить. сам рантайм 5.5 весил что-то около 200кб, конкретные программы могли быть ещё меньше (смартлинкер выкидывал неиспользуемое).

на 8088 был третий турбопаскаль, IDE у него выглядело как у пятого, только ещё проще. он кажется и под CP/M был, выглядел аналогично. третий турбопаскаль что-то около 30..50 кб весил, рантайм программы там примерно столько же. под CP/M емнип раза в два меньше – что-то около 16 кб третий турбопаскаль под CP/M весил, 64 кб+ это уже оверлеи, а там точно без оверлеев было.

только полуось, только PL/I и REXX!!! только хардкоркод!! :)

Для эда целый юникс придется тащить.

AT&T UNIX System V Release 4 Version 2.rar 9.47 Mb
AT&T_UNIX_System_V_Release_4_Version_2.1.rar 10.40 Mb

блоатварь, понимаешь.

получить контролируемую RTOS систему (в которой уже будет исключения, параллельные процессы, стектрейсы и асинхронность, на каком-нибудь микроконтроллере

зачем это чтобы ножками дрыгать ? на асме в 1000 раз проще и ресурсов нужно в 10000 раз меньше при разработке

10.40 Mb

блоатварь, понимаешь

Вот если бы на дискетку влазило.

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

Ну и соль Ada в возможности каких-то статических проверок

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

машкод

ибо Ты лепишь идиомы

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

http://www.terse.com/whatis.htm

если же реалистичней то https://www.t3x.org/t3x/index.html

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

турбовижн не обязательно к работе же был
был же turbo pascal и borland pascal, так turbo pascal работал быстро

на 8088 был третий турбопаскаль,

какой с дискетки поставишь, такой и был )

Это...

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

Ну что портов для Ada нет - это закономерно (хоть и обидно). Можно либо пользоваться готовыми для старших моделей STM32, либо портировать вручную. Где-то видел обещания, что это, дескать, не так уж и сложно.

Если не акцентироваться на языке программирования, то проще конечно взять C и закончить на нём проект раньше, чем был бы готов только bare metal для Ada. Опытный писун на C не сильно много ошибок делает в своих работах, я полагаю. Особенно таких, от которых призвана спасать Ada.

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

Язык программирования определяется грамматикой.

В общем случае, конечно же, твой выбор - один из диалектов ассемблера.

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

почитал EmbeddedSPARKandAda-web.pdf – вроде и правда не сложно. там примеры портирования рантайма на новое железо, часть кодогенерируется какой-то утилитой, потом допиливается руками похожий профиль. как допиливать там в примерах расписано.

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

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

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

С чего это? Модульность есть. Интерфейс с ОС есть.

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

Из крупных систем на Форте: система управления аэропорта Эр-Рияда, анализатор крови и система компьютерного зрения.

На Си, Коболе, PL/1, фортране, ассемблерах всех мастей тоже много чего написано. Но вне *узкоспециализированных* областей или легаси не так много смысла в их использовании. Нормальных же высокоуровневых языков для решения сложных задач не так много - и почти все они лиспы или (e)DSL.

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

Возможность писать большие промышленные системы.

На Си, Коболе, PL/1, фортране, ассемблерах всех мастей тоже много чего написано. Но вне узкоспециализированных областей или легаси не так много смысла в их использовании. Нормальных же высокоуровневых языков для решения сложных задач не так много - и почти все они лиспы или (e)DSL.

Как-то почти на ноль поделил. То есть почти все старые сложные системы написаны на Си и Коболе, почти все новые на Си++ и Джаве, но «высокоуровневых языков для решения сложных задач не так много - и почти все они лиспы или (e)DSL.»? Покажи хоть одну сложную задачу, решённую на любом из лиспов.

И какая же узкоспециализированная область у PL/1?

И какая же узкоспециализированная область у PL/1?

язык реализации Multics? :-))) и TMG

но да, оно по определению универсально.

когда взяли фортран с коболом скрестили = язык для инженеров с готовыми батарейками и DSL для отчётогерераторов с денежным типом и BCD, такой одинэс шестидесятых от Грейс Хоппер, ещё более многословный чем бейсик (но для управления каким-нибудь отчётогенератором вполне ОК, см. объектно-ориентированный визуал кобол – код читается как песня, одинэснее чем сам одинэс!)

и получился сабж.

так-то те же OpenGL и прочие DLL-ки туда можно прикрутить: см. реализацию PL/KT с поддержкой DirectX, OpenGL, SDL или IBM-овский PL/I под OS/2, IronSpring, прочие ).

кстати, PL/I как язык реализации DSL. у одного любителя PL/I есть сравнение PL/I и C – не в пользу С (отсюда). он вообще книжку по PL/I написал (книжка). там примеры про PL/I под полуось, IBM-овский компилятор, OpenGL, REXX, XML, веб-сервер, уникод и JNI.

среди примеров есть например реализация PARSE из REXX как DSL, на препроцессоре PL/I (в IBM-овском PL/I всё хорошо с препроцессором): к книжке из примеров к книжке, там смотрим parse.cpy

видно что у PL/I более мощный препроцессор чем у Си – можно сконструировать любую строку как угодно, как нужно и скормить её компилятору.

PL/I-80 под CP/M от Digital Research

по идее, killer app для PL/I должно было бы быть такой High-Level Assembler, полностью well-form defined, но без UB как в сишке на каждом углу.

например, исходники Multics (open sourced, multics pl/i,kednos,OpenVMS PL/I examples) и софта под него (тот же Emacs) – читается более высокоуровнево.

правда, именно Multics как пример плохой – оно by design было не портабельно, не мобильно – сильно завязано на архитектуру конкретного мейнфрейма, и слой типа HAL не выделен как таковой. автор симулятора SIMH в SIMH_Computer_History_Simulation_Project.pdf пишет, что проще оказалось эмулятор запилить, чем в тех исходниках без HAL разобраться. хотя если бы кто-то как следует их отрефакторил и портировал под какой-то слой совместимости, теоретически это возможно. только трудоёмко.

в OS/360 низкоуровневое писали на диалекте PL/S. CP/M была написана на диалекте PL/M (хотя существует и компилятор PL/I под CP/M, Digital_Research_PL/I, здесь есть ссылка на него и на SIMH. рядом с неофициальными исходниками CP/M тоже много вкусного, где-то там есть и ссылка на исходники PL/I-80 и PL/M под CP/M, из которых видно что PL/M как язык зело проще – такой высокоуровневый ассемблер с формульным транслятором и оптимизацией выражений, а типы толком не выражены, препроцессора тоже полноценного как в PL/I нет)

в целом, странно что это вот направление толком не развивалось – PL/I как язык для реализации диалектов, DSL типа того же PARSE из REXX и/или, альтернативной реализации всего REXX-а как DSL под PL/I.

в итоге вместо связки C/C++ + python вполне можно было бы использовать связку PL/I + препроцессор pli + REXX + куча прочих DSL на препроцессоре PL/I, более полноценном чем в сишке.

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

впрочем, долгое время полноценной реализации препроцессора нигде кроме как в компиляторах от IBM не было. по ссылке прочие пишут, что и opensource реализации нужны 3.5 анонимусам.

в книге про PL/I под полуось и где-то там на сайте в презентациях он приводит оценку, что в середине 90х «во всём мире существовало примерно 300 000 активных действующих программистов на PL/I», тогда их даже сертифицировать пытались.

ну то есть, почти никому он не нужен сейчас, несмотря на.

хотя тот же PL/KT вполне себе самодостаточный полноценный компилятор.

компилятор компилирует, сишные библиотеки подключаются, какие-то библиотеки и батарейки появляются – ну что ещё надо? :)))

Visual Age PL/I под оффтопик

Power and Adventure

из сравнения PL/I с С видно, что PL/I как язык потребляет меньше умственных ресурсов программиста, потому что обладает более предсказуемым поведением. там на наглядных примерах. но и более общие принципы организации языка понятны: язык, в котором всё полностью формально определено vs. язык в котором ad-hoc реализация как в референсном компиляторе и куча UB под капотом.

то есть, умственных ресурсов программиста чтобы распарсить написанное, да и написать своё – для освоения PL/I требует меньше. потому что нет неожиданного поведения.

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

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

например, далее атрибутивное развивается в Q-systems, канадский проект по прогнозированию погоды с распознаванием (и, я так понимаю, синтезом) естественного языка. в котором участвовал Colemeau, который потом после этого опыта изобрёл пролог и алгоритм унификации с бектрекингом (тоже известный тормоз по быстродействию, те же linear logic аналогичные прологу работают быстрее).

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

вообще любопытно было бы совместить в препроцессоре алгола 68 на W-грамматиках парсер не только искусственного многоязычного языка программирования, но и естественного. например, какого-нибудь контролируемого типа Gellish English, Simple English, «Упрощённый Технический Русский». и далее в каком-то BDD стиле типа кукумбера писать ТЗ или конечные автоматы на таком естественноязычном конструируемом контролируемом конланге.

эдакий метапрог.

ещё рассадничек

ещё рассадничек

Очень вкусно пишешь. Можешь ещё порасказвать про PL/1 и REXX?

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

Возможность писать большие промышленные системы.

Написаны на чем угодно такие системы, в том числе и на асме. И чо?

Покажи хоть одну сложную задачу, решённую на любом из лиспов.

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

И какая же узкоспециализированная область у PL/1?

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

Для эда целый юникс придется тащить.

Зачем юникс, когда даже под досом и не такое есть.

Написаны на чем угодно такие системы, в том числе и на асме. И чо?

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

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

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

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

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

Жопаскрипт, конечно же. Тем более среда разработки у тебя уже есть — это твой используемый веб-браузер (если только это не lynx какой :).

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

Мир стар, на лиспе такое в продакшене было 10 лет назад. Даже больше, 10 лет назад я туда пришёл. По-сути, ничего готового не было. К нам в бостонский офис делегация из Альтеры приходила смотреть на это (потом выбрали альтернативный путь). Зайлинкс купили контору, делавшую компилятор (примерно то же самое). Коммерческие продукты появились году в 14-м, и были многобажны и слабоваты.

И там вся суть не в том, чтобы из языка X в Y перевести, а в том, чтобы времянки сошлись, и оно физически смогло бы на чипе работать.

А лисповый компилятор один человек написал.

И там вся суть не в том, чтобы из языка X в Y перевести, а в том, чтобы времянки сошлись, и оно физически смогло бы на чипе работать.

Вот именно.

А лисповый компилятор один человек написал.

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