Высокоуровневые абстракции, еще и на английском... Котечка, выручай!

Я уже показывал пример с замыканиями!

Альфы, беты, греческий алфавит, формулы... словом, полный φαλλοσ

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

Лямбда-исчисление - это формальная логическая система, на которой по сути основано современное программирование (не всё и не всегда, но все популярные «молодые» языки умеют в лямбды и ФП)

Аксиомы:

1. Существуют некоторые переменные (лямбда-исчисление не уточняет, что это за переменные, какой смысл они несут и т.д.)
2. Существует конструкция, обычно называемая «лямбда-функцией», которая позволяет взять одно выражение и получить из него функцию, в которой каждое вхождение некоторой переменной заменено аргументом этой функции
3. Существует аппликация, т.е. применение функции к переменным.
4. Каждое выражение состоит из переменных, лямбд и аппликаций.

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

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

Если очень упрощённо, то да. Лямбда-исчисление позволяет выполнить любой алгоритм над входными данными, с помощью лямбд и применений этих лямбд, и получить результат этого алгоритма.

Ну так черт побери, так бы и сказали сразу:)

В Метапроге будет что-то подобное через структуру условного выбора типа (структура из селектора и юнион из выбираемых типов).

Точнее будет легко реализовать.

Вообще я очень страдаю в Лабвью от отсутствия юнионов. Есть, конечно, каст в строки и variant, но кастовать всегда надо вручную.

а в текст оно умеет конвертироваться? xml либо json

Кстати, в CDE (Common Desktop Environment) было что то типа IDE, там точно можно было делать интерфейсы без программирования, тоже на схемах, и редактор формочек был. Мне было намного проще что то делать там, а не писать руками...

Блок-диаграммы? Только в Си. Планирую хранение файлов диаграмм в собственных версионированных бинарных форматах, как основной способ. Выше в комментариях уже говорилось об этом.

Однако никто и ничто не помешает сделать вам и конвертер в xml/json. Только сомневаюсь что оно надо.

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

Только сомневаюсь что оно надо.

В качестве сконвертированного результата — действительно не надо. Если бы изначально заложить текст как внутреннее представление диаграммы - другое дело...

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

Мне вот вчера наконец доступно объяснили что такое лямбда-исчисления. Теперь хотелось бы получше понять что понимают под «архитектурой». Вроде бы понятно, но все же хочется лучше понимать тех, кто о ней говорит.

Ну мышкой интерфейсы делать можно везде) Там можно было еще программировать этот интерфейс.

Программировать графически конечно же!

Это уже толсто, чувак. Здесь любят тонкий троллинг.

что такое лямбда-исчисление для третьеклассника

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

мне кажется, можно ещё проще объяснить.

вот смотри, есть nile + gezira

что такое Nile? понятно из презентации

вот например, мы хотим отрисовывать мультимедию. например, 2D графику или 3D. нужен какой-то pipeline и dataflow архитектура поверх него (например, LabVIEW это один из таких dataflow языков — фактически в диаграмме на нём блоки выполняются асинхронно, параллельно, конкурентно и одновременно, вычисление блока запускается по готовности наборов данных)

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

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

далее в PS для отрисовки текста или картинок растром или вектором в этой модели берут форт, добавляют туда тип строка и словарь, сборщик мусора, и на полученном форте (PostScript) отрисовывают физическую глобальную модель Page Description Language. с некоторыми тонкостями вроде обработки шрифтов, векторизации их кривыми и прочее.

в PDF происходит примерно тоже самое, только есть оптимизации невидимого дерева (то есть, можно отрисовывать часть страницы до /showpage в PS, где надо было интерпретировать всю страницу), + в новых версиях стандарта PDF гиперссылки, аннотации, формы + JavaScript для заполнения и валидации форм, и анимации. ещё есть цифровые подписи и запрет копирования и редактирования, опционально. ещё формат бинарный, а не текстовый. но в целом это расширение всё той же PDL из PostScript'а.

если мы возьмём библиотеку для отрисовки векторного гипертекстового, например, AGG, Cairo или Skia. то там всё тоже самое. и это подозрительно напоминает какой-то OpenGL pipeline с матрицами трансформаций и прочим.

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

именно это и сделано в Nile: отдельный язык для представления потоков данных, параллельных процессов (см. в презентации PDF стр 6 про Dup, Zip в графическом конвейере pipeline, или стр. 9 подробнее про DupZip в текстураторе. ещё проникнуться примерами с математикой GUI в стр 4)

что там происходит, на стр 4? формализована математика преобразования системы координат. вводятся типы для цветов, точек, матриц транформации, кривых, полилиний, текстур, растра и прочего.

описывается общий графический конвейер этого всего как поток преобразований в лямбда-исчислении (см примеры стр 11,12,17).

потом делается интерпретатор этого языка, Nile. при этом оттранслировав программу на Nile в OpenGL или OpenCL получим автоматически распараллеленый рендерер. всё это прекрасно распараллеливается — практически линейно, см. стр. 20.

потому что модель вычислений это позволяет — функциональщина вообще и какой-нибудь FRP в частности распараллеливается получше лапши из неудобного ООП в стиле C++ (а не CLOS в CLIM, например).

как всё это реализовано? см. исходники на гитхабе, проект FONC/STEP и про франкенштейна, слайды стр. 13, 14, 17..19..22)

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

-- внутри Nile: пишем язык с нормально составимой (composable) семантикой вычислений (лямбда-исчисление параллельных процессов), пишем его интерпретатор (внутри Nile на «лиспе» схеме COLA от Ian Piumatra, прозрачно транслируемым в си; пишем транслятор такого языка на PEG внутри этой схемы COLA),

-- внутри Gezira, слайд стр 14: пишем компилятор такого языка Nile в C API и далее делаем библиотеку, libgezira

-- в самом приложении с векторным и гипертекстовым, стр 14: просто собираем все библиотеки на си вместе.

это си, но этот си оттранслирован из Nile языка с лямбда-исчислением параллельных процессов-функций-блоков диаграмм графического конвейера через язык COLA, лисп типа схемы, на котором написан PEG транслятор Nile и транслятор в такую схему COLA, и далее в си, в язык си, а по сути — интерпретатор и компилятор этого Nile.

РЕЗУЛЬТАТ? см. про проект FONC/STEP и OMeta. для ноутбуков OLPC был создан стек технологий, («система программирования» (с) Непейвода, «Основания программирования»), который фактически написан на себе самом. есть технология парсера OMeta, объектно-ориентированное расширение Meta метакомпилятора, гуглите mc_tutorial.pdf. есть AST макросы к этому объектному представлению, поверх макросами реализованы несколько DSL.

например, таких как стек TCP/IP начиная из ASCII графики, приведённых в RFC. например, таких, как Nile, язык для описания графического конвейера (или по сути любого dataflow в лямбда-исчислении параллельных процессов, см. слайды стр. 22,23, 26-28)

например, таких как компилятор языка программирования с расширяемой грамматикой, на основе PEG парсера и OMeta.

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

в общем, смотрите отчёты по проекту FONC/STEP и про Франка (франкенштейна).

Мне бы ту красоту, которую вы описали, но сразу в графике. Почему люди еще делают текстовые языки?! 2019 год на дворе!!!

Потому что они удобнее, глупенький.

А эта схема для вас читаемая или не очень?

https://www.gdevagon.ru/scripts/info/map.php

Советую посматривать на досуге, полезно для ума:)

Мне вот вчера наконец доступно объяснили что такое лямбда-исчисления. Теперь хотелось бы получше понять что понимают под «архитектурой». Вроде бы понятно, но все же хочется лучше понимать тех, кто о ней говорит.

объясню на примере Dylan. вот был такой язык Common Lisp, который вроде бы хороший: гибкий и удобный, расширяемый. но, сука, медленный и странный (скобочки же). ещё сложный как стимпанковский дирижабль, и тяжёлый.

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

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

проведём эксперимент: пишем хелловорд на языках: си, с++, Vala, лисп common lisp, лисп cхема, ..., dylan.

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

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

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

упражнение со звёздочкой: а) пишем хелловорд на дельфи на VCL, 400 кб б) пишем хелловорд на дельфи, KOL 20 кб в)тоже самое с лазарусом.

почему например программа собранная статически на С++ занимает килобайт 600, а на C — 5-10, на том же Vala — 5-10 + .dll .so отдельно (собрать GTK статически это особое извращение и как бы не невозможно).

строим .map файл и начинаем разбираться. потому что что делает с программа до запуска main? инициализирует си рантайм (environment, _atexit, сигналы, файловые дескрипторы и прочее). что делает с++ программа (до main)? инициализирует объектную модель С++ (ради cout и прочего).

в итоге, если ты пишеш на с++ си программу с puts, ты получаешь хелловорд в 5-10 кб. стоит тебе прицепить туда std::cout<< , как подтянется cout и зависимости, объектная модель, инициализаторы конструкторов, запускалки деструкторов. в итоге хелловорд растолстеет на 600 кб из libstdc++.

«не платите за то, что не используете», ога. ну как же.

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

хрен там. да,быстро: у С++ virtual методы это один из наиболее быстрых способов вызова диспетчеризации методов (для реализации полиморфизмов: наследования и перекрытия). нет, негибко: ты какого-то хрена должен заранее прозревать, делать тебе метод виртуальным или нет. и прозревать ты должен в библиотеке, а не в клиенте этой библиотеки. то есть, делать не универсализированное ООП в библиотеке, которое уточняется «наиболее специфичным методов» (как например в CLOS и мультиметодах). а средне специализированное, например (виртуальное или невиртуальное) в библиотеке, которе станет сильно специализированным (наследник виртуального) в клиенте библиотеки.

есть объектные системы, свободные от этих недостатков. например, CLOS в Common Lisp на основе мультиметодов и метаобъектного протокола (протокол здесь это интерфейс, подмножество родовых функций, мультиметодов. как категория в Objective C)

ну ок, будем писать всё на лиспе. только ведь он тяжёлый и медленный? и накладные расходы на рантайм составят 40..60 или сколько там у последнего SBCL мегабайтов?

ах, если бы построить хрустальный мост через реку, от москвы до самого спб губы Антонины Петровны приставить к сиськам Ларисы Петровны и жопе Евлампии Потаповной, это ж просто ужос какая страхолюдина получится? (с) женитьба Бальзаминова

ну, то есть, сделаем хитрый план. будем писать на трёх языках. на одном: спецификацию понятных юскейсов, на другом — наговнякаем прототип, на третьем > Мне вот вчера наконец доступно объяснили что такое лямбда-исчисления. Теперь хотелось бы получше понять что понимают под «архитектурой». Вроде бы понятно, но все же хочется лучше понимать тех, кто о ней говорит.

объясню на примере Dylan. вот был такой язык Common Lisp, который вроде бы хороший: гибкий и удобный, расширяемый. но, сука, медленный и странный (скобочки же). ещё сложный как стимпанковский дирижабль, и тяжёлый.

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

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

проведём эксперимент: пишем хелловорд на языках: си, с++, Vala, лисп common lisp, лисп cхема, ..., dylan.

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

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

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

упражнение со звёздочкой: а) пишем хелловорд на дельфи на VCL, 400 кб б) пишем хелловорд на дельфи, KOL 20 кб в)тоже самое с лазарусом.

почему например программа собранная статически на С++ занимает килобайт 600, а на C — 5-10, на том же Vala — 5-10 + .dll .so отдельно (собрать GTK статически это особое извращение и как бы не невозможно).

строим .map файл и начинаем разбираться. потому что что делает с программа до запуска main? инициализирует си рантайм (environment, _atexit, сигналы, файловые дескрипторы и прочее). что делает с++ программа (до main)? инициализирует объектную модель С++ (ради cout и прочего).

в итоге, если ты пишеш на с++ си программу с puts, ты получаешь хелловорд в 5-10 кб. стоит тебе прицепить туда std::cout<< , как подтянется cout и зависимости, объектная модель, инициализаторы конструкторов, запускалки деструкторов. в итоге хелловорд растолстеет на 600 кб из libstdc++.

«не платите за то, что не используете», ога. ну как же.

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

хрен там. да,быстро: у С++ virtual методы это один из наиболее быстрых способов вызова диспетчеризации методов (для реализации полиморфизмов: наследования и перекрытия). нет, негибко: ты какого-то хрена должен заранее прозревать, делать тебе метод виртуальным или нет. и прозревать ты должен в библиотеке, а не в клиенте этой библиотеки. то есть, делать не универсализированное ООП в библиотеке, которое уточняется «наиболее специфичным методов» (как например в CLOS и мультиметодах). а средне специализированное, например (виртуальное или невиртуальное) в библиотеке, которе станет сильно специализированным (наследник виртуального) в клиенте библиотеки.

например, напишем в каком-нибудь plantUML или вот MoonMarkDown (там есть диаграммы последовательностей), ну или BDD и Gherkin, Cucumber (Given STUFF When WTF Then act1 and Then act2 ...) — в качестве первого языка спецификаций, описывающего юзкейзы взаимодействия юзеров с программой

АНОНИИМУС! если ты читаешь эти строки, скажи честно, вот среди этих трёх реализаций MMD, что такое MMD.lunar? где взять компилятор этого расчудесного языка? язык вроде бы похож на PLOT, такой расчудесный лисп внутри, который выглядит как питон снаружи от David A. Moon, CTO Symbolics и автора компилятора Dylan.

Анон, подскажи: ГДЕ ВЗЯТЬ КОМПИЛЯТОР языка PLOT????

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

в качестве третьего — няшную сишечку. и не платить за то, что не используешь.

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

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

технически, берём STELLA из состава PowerLoom (гитхаб)

обмазываемся несвежим лиспом, и пишем на таком недолиспе STELLA, который зато прозрачно транслируется в C++ или Java. или CL.

колбасим протототипы (второй язык) на STELLA оттранслировав в целевой CL. когда убедились, что идея рабочая, этот STELLA транслируем в С++ или Java. и получаем автомагически (третий язык) скодогенерированное оптимальное, «не платишь за то, что не используешь»

во-вторых, подход номер два: возьмём единый язык, кольцо всевластья. которое всех унифицирует. например, PL/1. или алгол.

или вот, Dylan. даже Брюс Шнайер про него написал году эдак в 1992. жаль, не взлетело: акционеры уволили Джона Скалли и зарезали кучу R&D проектов Apple Computer Cambridge Research (а также Copland, Taligent и проч.) потом пришла новая метла со своим NeXT и наступило всем полное Objective C и MacOSX.

но, наш пациент не сдох, по крайней мере не сдох окончательно. хотя реализация Apple Dylan была похоронена, в это время развивалось две параллельных реализации в алгольном синтаксисе, Harlequin Dylan — LispWorks и Gwydion Dylan — CMU CL (не считая prefix dylan со скобками)

первая спецификация Dylan от Apple Research была написана в префиксном скобочном лиспосинтаксисе (про неё пишет Б.Шнайер). её и сейчас можно где-то нагуглить. из альтернативных реализаций скобочного prefix Dylan появились реализации: на схеме, Thomas от DEC, и от самого LispWorks/Harlequin, на Common Lisp LW Dylan translator to CL

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

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

только это всё-таки лисп по сути: есть блоки, tagbody, return, go. есть сигнальный протокол ошибок, signal/condition/restart для реализации исключений. есть своя версия CLOS, объектная система. на ней написан GUI, аналог CLIM — DUIM.

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

по поводу реализации Gwydion Dylan, вот оно, эльдорадо-то. и философия с архитектурой подхода, про гиперкод и SHEETS.

сначала про реализации: Gwydion Dylan был написан командой разработчиков CMU CL которые до этого cl-python наваяли. был написан модельный «правильный» референсный интерпретатор dylan под названием Mindy (гитхаб), Marlais. затем на нём написан компилятор (на dylan) d2c, который транслировал из Dylan в си. потом прилинковывали Boehm gc, сишные библиотеки (например, tk для GUI), и вперёд. потом писались биндинги к библиотекам на Dylan (например, dylan-tk). ну или писалась «нативная библиотека» на Dylan — например, в misc прочитайте про DUIM — GUI библиотеку, отмоделированную по образцу и подобию CLIM.

это при том, что были написаны инструменты: Melange для автоматической кодогенерации биндингов на Dylan к си библиотекам; lisp2dylan - для автоматической трансляции из Common Lisp в Dylan.

АНОНИМУС! если будешь таки тыкать Gwydion Dylan, тыкай сюда: gd-2.5, и частично сюда gd-2.4 за примерами (в частности, приснопамятный DUIM или Dylan-tk; ODBC) или сюда gd-2.4-cleanup или сюда gd-experiments. сюда тыкать можно а вот сюда точно не стоит, оно совсем сдохло уже. )

в 2.5 вроде бы допилили 64-битность под все основные платформы. ну и среду сборки с велосипедов на перле, впрочем, довольно прозрачных переписали на CMake.

сайт же самого проекта gwydion впрочем, почитать стоит. чем сейчас и займёмся.

оказывается, идея с реализацией Gwydion Dylan в CMU была лишь подпроектом более серьёзного проекта — Gwydion

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

предлагается ввести единый язык, на основе которого делать среду. например, взять за основу гибкий в рантайме язык Dylan. и получить код частично сгенерированный из lisp2dylan, частично написанный на Dylan вручную. частично написанный на си батарейках, с обёртками сгенерированными Melange. частично написанный прямо на си.

все эти трансляции спрятать под капот и не отсвечивать. погрузить это всё в некую среду, ну назовём её LitProg MetaCASE (по сути). такая среда и правда была написана — см. проект SHEETS и реализацию на Java (JDK 1.1.7, откопайте на антерсоли)

в изначальном видении архитектуры проекта Gwydion (а не то, что получилось на Java) я так понимаю, SHEETS означало собой понятие из GUI библиотеки на Dylan DUIM — портированной Common Lisp Interface Manager, CLIM (про её архитектуру, ищем в misc файл DUIM-1_1.txt и читаем вдумчиво про sheets panes frames и прочие протоколы и менеджеры — фактически, предлагался compound document на основе CLOS и метаобъектного протокола, МОP; также в примерах Dylan либо OpenDylan есть MVC простенький)

такая архитектура условной LitProg MetaCASE IDE была бы на пользу: представьте себе всё то, что описано про проект SHEETS, только реализованное не на Java, а на Common Lisp или Dylan, и так или иначе, объектной модели CLOS, с MOP метаобъектным протоколом и рефлексией. хотя вот Пол Грэм отметился статьёй про graphics objects, с более простой объектной моделью.

в итоге, такая архитектура позволила бы сделать composable GUI. как объекты CLOS. на CL или на Dylan.

положим, из этих объектов потом отрисовываем диаграммы в каком-то графическом языке моделирования.

запиливаем GUI для поведения такого редактора диаграмм.

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

текстовое представление объектов-компонентов-диаграмм можно откомпилировать, не сложнее чем можно откомпилировать лисп куда угодно собственно (ну или как с тем же Диланом, в схему Thomas, лисп CL LW Dylan translator, сишечку, LLVM SSA биткод и прочее)

то есть, оно сразу становится исполняемым. в лисп-среде, и обвязкой из каких-то макросов. благодая чему его можно инлайнить сразу в DSL, см. PEG парсеры из проектов COLA, Nile, OMeta, FONC/STEP.

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

ну или практически:

1)попытаться собрать SHEETS современной явой

2)попытаться в этом написать нечто текстовое, какой-то литературный хелловорд

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

4)подумать, как выглядело бы описание 3) на каком-нибудь LaTeX: Tiks, pslatex, asymptote, metafont :)

5)подумать, как допилить исходники 1) чтобы было несколько типов FRAGMENTS. не только текстовые, но и графические. которые будут выглядеть как 4), а транслироваться должны в 3). здесь нужно додумать поведение такого редактора диаграмм графических фрагментов

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

и нужно это самое — векторный гипертекстовый фидонетъ! гиперкод, вот.

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

при этом значительная часть вещей (ООБД, язык запросов, какой-то UI) — в проекте SHEETS * уже реализованы *

это всё напоминает «литературное» грамотное программирование, только в удобной IDE среде.

возьмём Emacs org-mode, например. там эти «блоки кода» могут быть на любом языке, а «блоки данных» — разных типов: переменные, таблицы, прочие. ну почему «прочее» не «графическая диаграмма», например? как объект?

для Dylan, есть следующее средство для LitProg грамотного программирования: Monday Project, применение. изучать его стоит, потыкав для примеры.

например, simple compiler. это пример реализации на Gwydion Dylan компилятора простого языка типа паскаля в SSA представление (привет, LLVM: сейчас проще адаптировать этот пример к LLVM биткоду и его ассемблеру, чем пилить свой оптимизатор вручную).

читаем PDF, смотрим «грамотный мануал» (созданный через weave): НОРМАЛЬНАЯ пояснительная записка по реализации, структура программы, хорошо откомментированные «блоки кода» с продолжениями, индексы «блоков кода» в оглавлении.

как это работает? ну, подход в Monday спорный: используется XML.

то есть, мы физически пишем руками XML (в DTD TEI) и «блоки кода» как XML в тегах <mod id=«chunk-name»> <sf> .... </sf> </mod> (при этом надо думать например про escape <CLASSNAME> что совсем уже печально выглядит для Dylan)

какие-то примеры по автоматизации набора этого XML-я есть в monday/literate/tools/{monday-psgml.el,noweb2monday.pl} — можно сначала написать в нормальной noweb разметке, потом в XML сгенерировать.

далее weave делается через xslt с нужным xsl и далее через Apache FOP в HTML/PDF/...

а tangle делается через xsltproc xtangle.xsl LITWEB.xml

далее для этого пишется обвязка к libxml и xslt на lua и свой make.

вообще, на первый взгляд, подход кажется стрёмным и не очень-то и наглядным: XML какой-то зачем-то вместо наглядного и очевидного NoWeb, Emacs org-mode babel либо MMD от David A. Moon синтаксиса.

но на второй взгляд, если задуматься. вот берём например TeXmacs, который позволяет наглядно редактировать и красиво отрисовывать LaTeX. он расширяется плагинами на Guile, при этом LaTeX — это лишь одно из возможных текстовых представлений. ещё может быть xml, scm и даже С++. или PDF.

там есть какой-то FANGLE для TeXmacs для LitProg, кстати.

scm представление полезно например чтобы рисовалку чертилку прикрутить. там уже есть в примерах какая-то рисовалка плагином на Guile. полноценного редактора диаграмм как типизированных «графических объектов» нетути.

xml представление на первый взгляд, не очень-то нужно.

НО! если взять вот это из Monday LITWEB.xml. и его уже генерировать из TeXmacs.

и адаптировать DTD.

то можно на этом написать графический редактор диаграмм как объектов CLOS, с MVC и двумя альтернативными представлениями: графический синтаксис редактора диаграмм, и текстовый синтаксис ООП модели какой-то архитектуры «графических объектов» в духе CLOS.

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

алсо, как бы не в том же Monday лежит dia.xml. который на самом деле XML, ну стало быть весь этот подход с TANGLE тоже работает, только надо распозноваться не по <sf>УГО</sf> тегам, а как-то их в комментарии завернуть, что ли. интересно, если в dia.xml засунуть свой лишний тег <sf> — проигнорирует или ругаться будет на неправильный DTD?

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

например, можно подумать как выглядела бы структура редактора диаграмм «графических объектов» в разных объектных моделях — иерархической типа DOM, навязанной С++ и его ограниченным пониманием ООП. или CLOS, MOP, и архитектура библиотек CLIM, McCLIM на Common Lisp, DUIM на Dylan, ?....? - ILOS на ISLISP.

без всех этих ограничений типа DOM.

а потом на таких вот «графических объектах» выстроить персистентную ООБД и грамотное программирование графических fragments, sheets, прочее.

в духе идеологии проекта SHEETS и ГИПЕРКОДА, векторного и многомерного: текстового, графического, структурного и любого.

только литературного.

Что такое архитектура?

архитектура, упрощённо — это структура программной системы.

есть описание структуры как «чёрный ящик», эскизное описывающее контекст, взаимодействие (пользователей внутри, диаграммы прецедентов, sequence diagram в UML) и интерфейсы с внешним миром (системы снаружи).

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

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

например, если ты сделаешь функцию с 20 параметрами и 40 стрелочек с самопересечениями. работать это будет, а читать это — ниасилят.

поэтому нужно диаграмму преобразовать в эквивалентное, но наглядное и более простое, более понятное. например, в ДРАКОНе говорят про «выполнение по шампуру» и эквивалентные преобразования, которые а) минимизируют самопересечения стрелок б) минимизируют сами стрелки в) задают успешную ветку выполнения по дефолту — самую левую. всякие обработки ошибок, исключения и оговорки — идём по ветке вправо. либо не идём, если и так понятно, и так понимания достаточно.

далее, в том же UML выделяют пакеты и подсистемы. как-то группируют подсистемы со сходным назначением. в LabVIEW кстати тоже — можно квадратиками выделить понятную подсистему.

в общем, Владимир, который интересуется архитектурой Metaprog. говорит что непонятен «белый ящик», конструкционное описание, детальное.

а я б сказал, что не совсем понятен и «чёрный ящик», опорное описание, эскизное.

что это за система и каково её назначение?

что система позволяет делать? какие сценарии она автоматизирует?

кому нужна эта система? для кого нужна, почему не аналоги или конкуренты?

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

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

хотя бы для сам для себя самого, но ответил бы.

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

Для этого существуют модули в большинстве ЯП, превращающие текст в гипертекст со ссылками, по которым умеют ходить специальные «браузеры» - IDE.

Стоп, забыл написать!

ТРИ ЧАЯ ЭТОМУ АНОНИМУСУ! Правда, очень интересное чтиво, хотя это по сути просто поток мыслей.

это не то совсем. это одномерный текст, поток текста, код.

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

либо о гиперкоде, многомерном.

и о том, что гипертекст и гиперкод — это не про текстовое представление.

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

полный OLAP, пацаны. всяческих объектов. временно представимых линейными и иерархическими текстами — но не обязательно.

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

именно это и есть истинное Xanadu Теда нашего Нельсона. об этом он говорил, всю дорогу.

а не об ограниченном недопонимании: WWW реализация с навязанной одномерной линейно-упорядоченной онтологией, классификацией а не фолксономией, DOM а не CLOS, множествами частично упорядоченными — а не категориями с морфизмами монад-объектов и монад-трансформеров-интерфейсов (скорее, метаобъектных протоколов в духе МОП).

А, я понял вас. На самом деле, неплохая идея - в емакс можно было бы легко сделать вставку изображений (при сильном желании и видео можно накостылить), но я не могу себе представить, где это было бы удобно. Как по мне, гипертекстовость в коде сейчас уже достаточная - по одному C-RET емакс может открыть мне картинку, текст, функцию в другом файле, который сейчас под курсором - этого хватает.

картинки я и сейчас в org-mode могу вставлять.

но не могу вставлять например, виджеты-контейнеры. по которым можно было бы кликнуть и отредактировать редактором, типа приснопамятного OLE embedding, только всё имеет два ортогональных представления, текст и картинку.

вот например BlackBox Component Framework позволяет делать такие документы: виджет-вьюшка view в MVC (его специальном понимании с Carriers Riders) паттерне, или контейнер вьюшек.

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

это всё потому что org-mode хотя и имеет структуру, но она недостаточно расширяема.

недостаточно объектна и многомерна. гипертекстовости там всё-таки хватает.

а вот Morphic и MVC в смоллтоке — правильные компоненты-объекты-гаджеты-текстовый DSL для гаджетов.

Владимир

что это за система и каково её назначение?

ТС сказал, что хочет сделать а-ля designer LabVIEW, но
приспособленный для хранения метаданных на основе которых
будет возможность получения C кода.

ИМХНО меня не интересует этот проект ни в чем.
В первой части вел диалог с ТС, а затем понял, что это - пустая трата времени.

... Владимир, который интересуется архитектурой Metaprog

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

Результат - «как об стенку горохом».

PS: Это мой последний message в этом топике.
Время тратить попусту - не хочу.

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

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

кому нужна эта система? для кого нужна, почему не аналоги или конкуренты?

Лично мне Лабвью наиболее удобно для программирования. Ему вообще нет достойных аналогов, их недостатки я уже обсуждал в комментариях выше. Кратко - в основном все «графические языки программирования» кроме Лабвью - убогие системы прототипирования, жалкие надстройки над текстовыми языками или вообще что-то для детей. Особенно меня неприятно удивила реализация цикла while в unreal urinal engine, к которой в официальной документации нарисовали дополнительную блок-схемку, чтоб, видите ли, было понятнее!

https://dnnrz1gqa.blob.core.windows.net/portals/Images/Engine/Blueprints/User...

www.linux.org.ru/forum/development/14918675?cid=14920968

Но на Лабвью тяжело делать многие вещи. Мало библиотек, нет и невозможно добавить (из-за закрытости и пропиетарности) такие вещи как структура выбора типа (в Си это union) или структура условного выбора типа (в Си и других известных мне языках этого нет, будет фишкой Метапрога), даже построитель графических схем делать тяжело (я не увидел там библиотек для ускорения графики, отрисовка больших блоков лагает жутко). В общем, насколько восхитительный интерфейс программирования, настолько же убогий бэкенд, и ничего я с этим из-за закрытости и пропиетарности не поделаю, могу лишь сделать свой аналог, как говорится, «с рандомными числами и программистками».

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

На данный момент реализовано:

Сишные типы, в том числе указатели, массивы, структуры и юнионы

Вызов сишных функций, их взаимосвязи

Импорт типов и функций из #include, их наглядные списки и поиск типа/функции по названию

Трансляция блок-диаграмм в Си

Осталось реализовать:

Указатели на функции

Условия (if, switch+case)

Структуры условного выбора типа

Циклы

Перенести Метапрог с Лабвью «сам на себя»

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

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

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

структура условного выбора типа

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

глючных и корявых текстовых языков

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

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

Ну чо это. Раст например. Я правда свой полугодичный проект открыл и потерялся во всех этих a' b' c'...Даже не понял что там делал :D. Прикольный язык, по местами даже перл понятнее.

Раст - очень хороший язык, за ним будущее. Но даже он не является «серебряной пулей» – на нём недостаточно высокий уровень абстракций для написания, например, игр или целиковых браузеров. Даже firefox пока что на расте очень частично. Ядро на расте (redox) пока вызывает только горькие слёзы, и там уже столкнулись с тем, что безопасность раста идёт по бороде - код по большей части unsafe, и собирать его приходится с максимальными оптимизациями (в ущерб безопасности и стектрейсам), чтобы получить разумную скорость работы. Ну и читаемость, да, в связи с иногда запутанным синтаксисом и странными правилами владения и таймлайнами там тоже проблемы.

(Я на расте только хелло ворлды писал, если чо :D)

Причем тут Раст? ТС все на Сишке собирался написать.

Предлагаю сначала читать ветку, потом писать комментарии :) Анонимус написал про Раст, я ответил.

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

Мне достаточно этого:

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

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

Языки я сужу не по теории, а по практике. Я много лет активно пользуюсь ПК плюс телефон на андроиде. 0xBULLSHIT Fatal error in govnocode.cpp, Java exception или ужасные веб-приложения на Javascript - показатель лучше любых книг.

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

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

Языки я сужу не по теории, а по практике. Я много лет активно пользуюсь ПК плюс телефон на андроиде. 0xBULLSHIT Fatal error in govnocode.cpp, Java exception или ужасные веб-приложения на Javascript - показатель лучше любых книг.

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

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

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

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

Примеры и я могу в гимпе нарисовать. Говоря вашими (на самом деле Линуса) цитатами «Show me the code!»