LINUX.ORG.RU

Metaprog: универсальная графическая среда программирования [в разработке]

 , , ,


7

7

Почему, несмотря на обилие «чудесных» ООП-языков, Си, разработанный в 1973 году, до сих пор не умер? Потому что не выхдящие за рамки текстового программирования попытки «улучшить» или заменить Си давали и дают проблем больше, чем решали.

Какой из ныне существующих языков программирования позволяет программировать мышкой, а не клавиатурой? На чем можно программировать графически, а не в тексте? Пока что это позволяет на приличном уровне только пропиетарное LabVIEW. Трудно поверить, но это единственная полностью графическая среда программирования серьезного уровня в 2019 году! Но даже в LabVIEW есть куча недостатков (которые невозможно самостоятельно устранить из-за пропиетарности).

Графическое программирование намного проще и понятнее. Если в качестве бэкенда брать Си и манипулировать функциями из сишной стандартной библиотеки, это не будет создавать никаких лишних абстракций, зато серьезно упростит жизнь программистам и особенно людям, имеющим дело с чужим кодом. Код любого уровня и любой сложности, представленный в виде графических блоков, станет открытым не только для узких специалистов, но и вообще любому продвинутому пользователю. Простота программирования и эффективность, не меньшая, чем у Си, убьет C++, Python, Java, Javascript и прочую ерунду с раздутыми и полными багов абстракциями (которые Линус не раз крыл матом).

Я уже делаю некое подобие LabVIEW на самом LabVIEW, назовем его Metaprog. Так же, как в 1991 Линус Торвальдс делал линукс, пользуясь пропиетарным Minix. И так же жаловался на кучу недостатков в Minix, желая устранить их в своей системе.

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

Примеры

Примеры с кодом на Си генерируются автоматически. Они тут же скармливаются компилятору и не предназначены для чтения эстетами, не любящими «абракадабру». Здесь они приведены лишь как пример работы транслятора и для возможности самостоятельно скомпилировать графические диаграммы со скринов. Так сказать, приобщиться к прекрасному.

Самое простое - Hello World. Скомпилируйте (gcc -o ./test ./code.c).

https://i.postimg.cc/YCywWbSh/fwrite.png

#include <stdio.h>

int main(){
char metaprog_array_pointer_10156130170823954432[] = {72,101,108,108,111,32,87,111,114,108,100};
unsigned long int metaprog_variable_13830126042312755200 = 1;
unsigned long int metaprog_array_size_10156130170823954432 = 11;
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,stdout);

}

Я подписываю терминалы на украинском (сам оттуда), с таким же успехом их можно подписывать на русском, а не только на английском. Можно будет перевести все, кроме, разве что, вызываемых сишных функций, а gcc этого и не заметит (посмотрите код). При работе международной командой можно к каждой подписи/надписи прилагать словарь с нужными языками. Игры ж локализируют, чем визуальное программирование хуже?

Массив декларируется не как строка в кавычках, а как последовательность байтов, а байт - это цифра. Строки редактируются отдельным редактором (пока что средствами LabVIEW, но это временно). Больше никаких проблем и глюков с управляющими символами, кавычками итп (очень серьезная проблема при программировании на Си, Shell scripting и вообще всех текстовых языках).

Константа-массив имеет отдельные терминалы для указателя на массив и длины массива (известной редактору кода). Если терминал длины подключен - декларируется отдельная переменная. Не подключен - незачем и декларировать.

Пример посложнее: запись и в stdout, и в файл ./fwrite-test.txt

https://i.postimg.cc/v8KvKKmQ/fwrite2.png

#include <stdio.h>

int main(){
char metaprog_array_pointer_10156130170823954432[] = {72,101,108,108,111,32,87,111,114,108,100};
unsigned long int metaprog_variable_13830126042312755200 = 1;
unsigned long int metaprog_array_size_10156130170823954432 = 11;
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,stdout);
char metaprog_array_pointer_12385851444566411264[] = {46,47,102,119,114,105,116,101,45,116,101,115,116,46,116,120,116,0};
char metaprog_array_pointer_16510743873862514688[] = {119,43,0};
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,fopen(metaprog_array_pointer_12385851444566411264,metaprog_array_pointer_16510743873862514688));

}

В данном примере используется функция fwrite, а не printf. То есть, символ «0» не влияет на запись массива в файл или stdout. Сколько символов писать функция и так знает из длины массива.

Заявки

Принимаю заявки на новые фичи. Пишите в комментариях. Уже приняты заявки:

1. Пример с простым HTTP-сервером.

2. Пример с сортировкой Хоара (quicksort).

3. Простой в пользовании функционал работы со строками (больная тема для Си и С++).

4. Полностью графический функционал работы с регулярными выражениями, без вовлечения PCRE.

Сейчас нужно научить Metaprog «компилировать» блок-схемы прямо в Си и скармливать этот код gcc, получая бинарники. После чего перенести сам Metaprog на Си, чтоб перестать нуждаться в пропиетарном LabVIEW и выложить результаты в опенсорс. И получить за это донат, хотя желательно уже сейчас (для ускорения работы). Bitcoin:1AYoK2TScSpD5bhf67mv9AxHDJ2RidRvjD

Ответ на: комментарий от metaprog

Какие то цифры, какие то проводки куда то идут... Я С знаю, но еле понимаю что на схемах... Еще шрифты неоче)) В UE/BluePrint понятнее имхо https://i.ytimg.com/vi/EFXMW_UEDco/maxresdefault.jpg еще подписать вверху на блоке мелко «Условие», «Си-Функция», в заголовке, что бы за него можно было таскать, и подпись не будет занимать важное место.

vladimir_vist ()
Ответ на: комментарий от vladimir_vist

еще подписать вверху на блоке мелко «Условие», «Си-Функция», в заголовке, что бы за него можно было таскать, и подпись не будет занимать важное место

Или немножко приложить дизайна, как в приведенном вами примере, но в целом пожелание понятно.

metaprog ()
Ответ на: комментарий от tz4678

за нейросетями нет будущго

Ты сам, случаем, не нейросеть? За ними неизбежно будущее

pihter ★★ ()
Ответ на: комментарий от vladimir-vg

А зачем писать такой код? Я десять секунд посмотрел и ниче не понял.

pihter ★★ ()
Ответ на: комментарий от metaprog

В общем, моя деменция малость всё напутала: mkizub на рсдн-е гнал про свою SymADE, а здесь была статья MPS от JetBrains, где оная упоминалась. Судя по всему и MPS и SymADE почили в бозе. Откуда возникла связь с тобой - mkizub свои «лексические деревья» тоже представлял исключительно в графике.

yyk ★★★★★ ()
Ответ на: комментарий от yyk

Вы сравнили лошадь со свиньей.

MPS предназначена для разработки... в среде JVM

Это при моем крайнем неприятии Джавы. И вообще всех текстовых языков кроме Си, Ассемблера и машинного кода, на которые будет опираться мой Метапрог.

metaprog ()
Ответ на: комментарий от metaprog

Скажите, а если сделать все то, что Вы предлагаете, но с ассемблерами?! Асм мышкой. М? Это открыло бы грандиознейшие перспективы, в том числе для Вас лично.

anonymous ()
Ответ на: комментарий от anonymous

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

metaprog ()
Ответ на: комментарий от vladimir_vist

В итоге «высокоуровневый» PL/1 был выброшен на свалку истории, а Си используется уже больше 40 лет.

Сишники опустились с «высокоуровневых» небес на землю. Отбросили все лишние абстракции кроме самых необходимых. Сегодня это надо повторить, только в куда больших масштабах.

metaprog ()
Ответ на: комментарий от metaprog

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

anonymous ()
Ответ на: комментарий от metaprog

Нет, просто Unix, C это были хипстерские поделки по типу Gnome3, где все выкинули, только Gnome3 неплохо так работает, а Unix... это был ужос.

vladimir_vist ()
Ответ на: комментарий от metaprog

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

Абстракции это приобретённое. Никто не рождается со знанием C|C++|Java|Rust|<любой ЯП> — обучение потребуется безусловно.
Сама концепция ООП проста: объект содержит в себе данные и методы, работающие с этими данными. На основе объекта можно создать объект-потомок, который унаследует все свойства (данные) и методы предка. Вот здесь (дальше) начинается усложнение.

Код в реальных проектах на ЯП с ООП может быть очень-очень сложным. Cи прост*, но на и нём создают очень-очень сложное ПО.

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

Не, ну мысль «правильная»... Но что есть «утяжеление программ»?
Производительность... Заказчик/работадатель/программист желает быстро получить работающий код. Никто не хочет ждать «идеального кода» — или я ошибаюсь?.
В современном программировании оптимизация выполнения кода (быстро == выше производительность — оно?) в основном возложена на компиляторы.

3. В случае надобности легко и просто разбираются до элементарных «винтиков».

Для чего? Для расширения кругозора и утоления любопытсва? Если код «свой», то что там разбирать до «винтиков»? «Чужие» исходники? Возможно... На «знакомом» ЯП их можно прочесть. Если нет исходников, то скажем есть отладчики — сразу в процессорных инструкциях можно увидеть. Но тут приходится наоборот «сворачивать» инструкции в функции и т.д.

Метапроге это - системные вызовы и функции из стандартной библиотеки Си, но в идеале - возможность «раскрутки» вплоть до отдельных инструкций процессора.

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

Функции стандартной библиотеки C самая " простая" часть Вашей задумки. НО: стандартная библиотека C тоже внешний независимый компонент от Вашего ПО. В машинных кодах (операциях процессора) каждая реализация библиотеки C «уникальна» т.е привязана к процессору (архитектуре процессора и т.д.), ОС...

Раскрутка до инструкций процессора исходного кода не выполнима. Исходные тексты блоксхемы только «сырьё» для «производства» машинных кодов. Исключением может быть ассемблер.

anymouze ()
Ответ на: комментарий от metaprog

и будет список типов, структур, юнионов и функций

Констант? Дефайнов?

pihter ★★ ()
Ответ на: комментарий от metaprog

Политические дискуссии запрещены в правилах

Без танцпола на ЛОРе была б скукота

Админы, не спать!

Фу так далать )

pihter ★★ ()
Ответ на: комментарий от metaprog

Слона то ты и не заметил... Речь была не про MPS, а про SymADE и про его графическое представление «синтаксических деревьев», и про то, что оно сдохло...

То что твой проект уйдёт в страну ОСРВ СМ ЭВМ очень скоро сомнений не вызывает. А вот соберешь ли ты приемлемую сумму донатов - в современном мире меня это уже не удивит...

yyk ★★★★★ ()
Ответ на: комментарий от metaprog

«Учиться, учиться и учиться» - это про них.

Это плохо что-ли? Ленин имел в виду, что только тот и человек, кто никогда не перестает саморазвиваться. И что главная проблема — неграмотность, которую нужно решать в первую очередь.

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

pihter ★★ ()
Ответ на: комментарий от metaprog

Не только я, а сам Линус Торвальдс считает, что все говно кроме Си.

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

Хочешь быть хорошим программистом на си? В таком случае, изучи на пятерку си, а затем изучи как следует плюсы. Изучи почему люди лешили такое построить, какие проблемы решали. Попробуй попользовать в работе. Не понравится — вернешся к сям, твои знания и опыт по ним только увеличатся от опыта работы с плюсами. А если понравится (а тебе понравится) — то будешь владеть обоими-двумя инструментами, и использовать каждый к месту (отвертка и шуруповерт — оба нужны, каждый к своему месту) как и положено толковому программисту.

Вот это вот твое отрицание — это юношеский максимализм. Это нормально. Это пройдет. Все там были )

pihter ★★ ()
Ответ на: комментарий от metaprog

Почему, несмотря на обилие «чудесных» ООП-языков, Си, разработанный в 1973 году, до сих пор не умер? Потому что не выхдящие за рамки текстового программирования попытки «улучшить» или заменить Си давали и дают проблем больше, чем решали.

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

pihter ★★ ()
Ответ на: комментарий от vq156

Зачем менять то, что хорошо работает уже больше века?

Так себе аргумент. ) Рабовладение вон и поболе века хорошо работало. Или феодализм. Или любая технология, у которой есть более прогрессивный аналог

pihter ★★ ()
Ответ на: комментарий от metaprog

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

Да все в этом мире, что сложнее, чем насрать себе в штаны, требует обучения! Акстись. Почему это должно быть что-то плохое? Давай теперь программистов не будем по пять лет в ВУЗе учить? Пусть они в школе берут мышку и начинают «программировать». Нафиг они такие нужны

pihter ★★ ()
Ответ на: комментарий от metaprog

Си, плохо тем, что невозможно или очень трудно разложить блоки кода на элементарные «кирпичики».

main() {
  read_config();
  do_job();
  say_goodbye();
}

read_config() {
  open_file();
  remove_comments();

  read_first_param();
  read_second_param();
  ...
  read_Nth_param();

  close_file();
}

open_file() {
  ...
}

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

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

pihter ★★ ()
Ответ на: комментарий от yyk

Слона то ты и не заметил...

Подростковый моск так не работает. В любом контраргументе (иногда даже не контр-) он будет замечать только триггеры «java, js, python, ...» и выдавать стандартную реакцию «говно! я знаю си, си форевер!». Точно так же как у девочек, сохнущих по очередной поп-звезде.

ТС, ничего личного, сам такой был :(

anonymous ()
Ответ на: комментарий от hobbit

Дракон? Нет, не слышали.

По состоянию на 2019 год оно опенсорсно и кроссплатформеннно.

есть веб-версия, в браузере именно этой программы: DrakonHub блог

в блоге — как обучалка по ДРАКОНу и его возможностям на примерах, так и разбор полезных юзкейсов, например про управление требованиями и спецификации требований (или диаграмм прецедентов, или бизнес-процессов), про приёмочные тесты, проконечные автоматы

про конечные автоматы либо там, либо на гитхабе где исходники Drakon-editor на tcl был пример парсера грамматики через ДРАКОН-диаграммы конечных автоматов.

вот это вот всё — полезные примеры применения.

далее напрашивается скрестить с каким-то не чисто графическим, и не чисто текстовым, а совмещённым, текстово-графическим подходом.

например, есть (был) такой libero, генератор конечных автоматов FSM из наследия iMatix, которые в конце 90х разрабатывали кроссплатформенный веб-сервер Xitami (даже додумались до своего протокола с транзакциями на замену HTTP без состояний с куками-костылями, rtfm в доках про TWP, тоже мысль здравая). сам Xitami, кстати, написан как конечный автомат конечных автоматов, на основе кроссплатформенных С библиотек, тоже занятно. но речь не об этом.

среди примеров старого сайта есть любопытный такой lrdot.tgz, содержащий lrdot.nw — в NoWeb разметке literate programming, грамотного программирования, из которого генерируется .tex, и затем .ps .pdf. это пример парсинга и генерации graphviz графов чего-то там интересного, например протокола взаимодействия smtp ещё чего-то там.

вот, собственно пример того как можно совместить «коня и трепетную лань» — через грамотное, литературное программирование. то есть пишем книжку, рассказывающую пояснительную записку к программе, кул юзер стори (а концептуально, прорабатывая диаграммы прецедетнов ещё из требований). получаем make tangle — код на си(или чего угодно, см. настраиваемый lrschema.*) + кодогенератор из конечных автоматов. или make weave — TeX и далее везде, нормальный файл с индексами и глоссарием, ссылками на «литературные» кусочки кода с определениями.

далее, можно взять более другие инструменты для LitProg. например классический noweb2 уже толком не соберётся у среднестатистического школолохипстера из-за отсутствия icon интерпретатора, особенно под шинду, например. можно взять реликтовый бинарник icon или unicon и им пересобрать, ну или взять другой инструмент: noweb3 на Lua, noweb.py или аналоги, или вот например, нормальный самодостаточный litprog инструмент нового поколения.

таковых на гитхабе гуглится два: Slit2 написанный итальянцем на Free Pascal и Literate, написанный на D. оба годные.

Slit2 — минималистичный, годный, использующий весьма годный lout вместо tex/latex. собирается fpc в полпинка.

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

всё это генерирует lout разметку, которая + примеры стилей на lout собирается в нормальный litprog компендиум, с индексами, глоссарием, списком чанков — «блоков кода», и т.п.

Literate на D выглядит похоже, разметка проще.

anonymous ()
Ответ на: комментарий от anonymous

приёмочные тесты, про конечные автоматы

Lout в целом неплохой вариант для LitProg написания компендиума. всяко проще, нагляднее и изкоробочнее чем tex + latex + кучка рецептов стилей, расширений и примочек к tex-у.

есть правда и недостаток — фронтэнд генерации pdf в lout недопилен, ибо завязано на display model PostScript (сам lout это набор скриптов-расширений в стиле функционального программирования к PostScript, который сам по себе ООП расширение форта со сборкой мусора и объектами).

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

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

в целом, нерабочие русские фонты из коробки — самый большой (и чуть ли не единственный) недостаток lout.

lout интересен нам тут тем, что позволяет делать функциональную композицию блоков — есть в tex разметка императивная, в lout это функциональное программирование.

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

в Literate D вроде генерируется PDF, и markdown, и в целом, pdf вместо постскрипта с дефолтными уникодными фонтами вроде бы всё упрощает.

anonymous ()
Ответ на: комментарий от anonymous

далее двигаться нужно в направлении повышении декларативности разметки: например в GNU Skribilo на основе GNU Guile схемы возможны AST макросы, различные reader/writer бекенды, есть что-то типа DOM — это фактически структурированный документ есть макрос с макросами, пишущими макрос на Схеме. есть нормальные разные синтаксисы, например org-mode или xml.

собственно, далее «литературный документ» типа того lrdot.nw из lrdot.tgz должен быть не потоком текста, а потоком структурированных выражений.

либо лисповых S-выражений, либо REBOL-выражений и бекенда на каком-нибудь REBOL или лучше, RED. на REBOL есть makedoc в несколько сотен строк, более полноценный makedoc3 и навороченный wetan на конечных автоматах, с промежуточным представлением. RED имеет в составе самодостаточный тулчейн подо всё с 0 зависимостями, сам RED написан на RED/System, который по сути эквивалентен Си.

далее графический GUI редактор диаграмм такого вот, ДРАКОНоподобного визуального моделирования нужно писать на всём этом.

в духе Libero и Xitami, в духе lrdot.tgz как Literate Programming редактор.

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

например, взяв Pharo и Morphic где уже есть этот MVC. и наколбасив в духе PlantUML простую рисовалку картинок по инструкциям, только теперь она будет MVC и в DOM-подобном представлении.

а GUI потом к этому сверху прикрутить, как альтернативный способ для мышевозюконья. но основным оставить Literate Programming интерфейс, генеря сначала литературные .tex .dvi .ps .pdf, потом картинки растром в morphic, потом картинки вектором, потом картинки как структурированные выражения, сиречь объекты.

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

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

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

далее постепенно двигаться в направлении semantic web и заменять эти text-only чанки в LitProg сначала в S-exprs, REBOL-exprs структурированные выражения, затем в полноценные модели базы данных, только не SQL, а нормальной, многомерной типа MUMPS-а.

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

далее заменять чанки как текст в полноценные модели.

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

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

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

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

к примеру, adventure.pdf из примеров CWEB,TeX, Кнута. взяли программу на Фортране, откомментировали развесисто, затем перевели по развесистым концепциям в Cи реализацию.

Slit2 написан на итальянском и Free Pascal. можно переписать на кириллический и Ada2011, например. сделать параллельно Slit2.s копии Slit2_FPC.s, Slit2_ADA.s. затем как-то расширить язык Slit2 чтобы умел дефолтные переменные по умолчанию.

далее из этого сделать например benchmark с тестами для двух параллельных реализаций, на FPC и на Ada.

то же самое относится к графическому языку моделирования, представленному структурированными выражениями. переводить его автомагически на Си, лисп, форт, или лучше и проще — REBOL, RED, RED/System.

anonymous ()
Ответ на: комментарий от anonymous

под форт кстати, тоже есть примеры автоматизированной кодогенерации. парсер и транслятор формул в форт из инфиксной записи ftran, конечные автоматы, jonesforth, META, «FROM PASCAL TO FORTH Leonard Morgenstern» или «A User Definable Language Interface for Forth» by T.A.Ivanco and G.Hunter, см. журнал, статьи, книга Креншоу «Давайте напишем компилятор» адаптированная для форта

то есть: код на форте можно генерировать парсером из какого-нибудь обероноподобного паскаля. метакомпилятором форта раскрутится под любую систему. макросами, то есть CREATE..DOES можно будет прикрутить свой синтаксис.

или взять не форт, а постскрипт. который ООП, со сборкой мусора, ну а далее всё то же самое. например, автор xpost, второй нормальной кроме GhostScript реализации PostScript интерпретатора пытается реанимировать Display Postscript, целясь на в PS level 3, а в PS lv 2, DPS, Sun NeWS, PSIBER оконную систему на Display PostScript с ООП отладчиком.

прикрутить их в lout, Slit2, далее везде. генерировать диаграммы не картинки как растр, не картинки как вектор, а картинки как объекты, модели MVC, структурированные лисповые S-выражения или RED/System REBOL-выражения (чистый PostScript, форт вроде как будет слишком хардкорно).

далее такой вот GUI для Blueprint и user story в духе BDD Gherkin рисовать из таких вот Display PostScript, Literate programming наглядных диаграмм, с моделями, структурированных выражений гарантированно корректных, а не как простой текст.

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от metaprog

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

нужна не столько читабельность, сколько машиночитаемость и наглядность.

ну почему бы не взять тот же лисп, REBOL, RED/System?

погляди, например внимательно, как сделан RED. тулчейн на себе самом: есть низкоуровневый RED/System, эквивалентный Си. там есть все те же типы, примитивы, вызов функций, FFI к Cи прозрачный. потом на этом написан высокоуровневый RED с объектами и богатыми типами. почитай блог разработчиков RED — занятный прогресс у них происходит.

при этом например GC написан на себе самом, линкер и компилятор написан на себе самом, в гуйне тоже пока всё довольно компактно: Rich Text Edit занимает несколько строк, Livecoding реактивные объекты, например Эксель  — десяток строк. пилят нормальный кроссплатформный реактивный GUI.

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

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

1. кроссплатформную

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

3. в такие представления, текстовые синтаксисы, которые были бы не просто низкоуровневые, а концептуально полезные: те же S-выражения лиспа или REBOL-выражения для RED/System.

4. потенциально расширяемые, то есть макрос лиспа тоже лисп, а REBOL, RED, RED/System — это всё ребол-выражения, только уровень разный, от сверхвысокого до высокого до низкоуровневого.

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

а раскрутив такую среду, ну назовём её «метаязык графического программирования» из LabVIEW на себе самом, это конечно будет наглядно. но не так полезно — графический язык всё тот же старый, ограниченный, не расширяемый.

при этом можно в общем-то брать не LabVIEW, а какие-то более другие языки, инструментарии и технологии. например, те же конечные автоматы, или тот же самый ДРАКОН (см. блог ДраконХаба). кстати, «текстовые блоки», про которые ты говоришь — это по сути метаязык. не ясно, зачем от него избавляться, ИМХО, лучше наоборот сделать максимально гибким, перенастраиваемым, расширяемым.

anonymous ()
Ответ на: комментарий от anonymous

конечные автоматы на ДРАКОНе, на примере парсера.

акторы, агенты, объекты и передача сообщений. я бы взял для этого PonyLang, ну или для любителей синтаксического сахара --- SObjectizer.

anonymous ()
Ответ на: комментарий от WitcherGeralt

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

где-то на форуме любителей ДРАКОНа и оберона приводят пример школьника, написавшего дракон-обвязку на Visio. он настроил диаграммы как в книжках, затем добавил произвольные атрибуты и GUID (мега фича Visio), связавшие их с БД, затем написал на VBA под Visio транслятор из диаграмм в текстовое представление. примерно то, что в Drakon-Editor на tcl написано.

и выступал там про «программирование в Visio, картинками без программистов».

вроде бы велосипед, а людям нравиццо. ты будешь смеяться, но в каком-нибудь БизнесИнженере или БизнесСтудии всё то же самое: хранят визио как блобы в MS SQL, привязывают произвольные аналитики и классификаторы, пилят свой велосипедный графический редактор диаграмм на основе Visio. и далее на этом велосипедят редакторы IDEF0, UML, EPC, BPML и прочее.

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

имхо, на каком-нибудь picolisp, tcl или RED более компактно получилось бы, и всё то же самое по сути.

anonymous ()
Ответ на: комментарий от hobbit

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

кстати, про бейсик. BaCon, бейсик транслируемый в си (написан на шелле). раскручен из M4basic, который, сюрприз, на M4, как ./autogen && ./configure автотулзы.

оно транслируется в си, собирается си компилятором.

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

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

anonymous ()
Ответ на: комментарий от hobbit

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

если позанудствовать, то в C++ методы принадлежат классам, отсюда хрупкость базового класса. а в какой-нибудь Julia мультиметоды и нет такой проблемы. а в смоллтоке метаклассы. поэтому ООП там разное.

и тот тупик, к которому сейчас пришли в браузерах, жручих память и дорогой, сложный, тяжёлый DOM, и костыли на JS чтобы хоть как-то работало — вовсе не обязательны, а родовые травмы С++. в более другом ООП и в более другой компонентной модели на эти костыли можно было бы и не натыкаться.

anonymous ()
Ответ на: комментарий от metaprog

Кстати, планирую встроить в Метапрог интерактивную обучалку - как в играх.

векторную и гипертекстовую?

anonymous ()
Ответ на: комментарий от metaprog

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

anonymous ()
Ответ на: комментарий от vladimir_vist

До Unix его создатели с нерусскими сложнозапоминающимися ФИО до этого Unix'а работали над Multics который был написан на очень высокоуровневом PL/1,

как по мне, так в исторических реализациях emacs что изначальный Emacs под Multics на PL/1, что Zwei на Common Lisp под Genera и лисп-машины --- всяко понятнее и нагляднее той лапши, что мы наблюдаем сейчас в GNU Emacs на няшной сишечке.

и кстати, был ещё и PL/M на котором была CP/M написана, кроссплатформенно. вполне могла бы взлететь кроссплатформная инфраструктура на алгольном тяжеловесном PL/1, PL/M, REXX заместо C++, C, Bash с конфигурой на перевес. и выглядело бы всё это гораздо нагляднее.

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

anonymous ()
Ответ на: комментарий от metaprog

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

да запросто. запускай gcc с нужными ключами, чтобы он 1) не удалял временные файлы 2) оставлял все эти промежуточные стадии компиляции. потом откопай там лисп в GIMPLE и удивись.

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

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

что значит «прячет»? это не означает что нельзя сделать просто, обозримо и наглядно. к примеру, взгляни на jonesforth на ассемблере или на тот же RED тулчейн.

в первом — хорошо откомментированный *.S gas с макросами, которыми сделан next шитый код, и далее, минималистичная реализация форта на ассемблере. далее какая-то простая запускалка ко всему этому, примерно как M4basic.

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

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

какую именно проблему? что прячет? и GUI MetaCASE будет прятать ещё лучше, ещё загадочнее?

или дело всё-таки не в средствах реализации (графически и интерактивно), а в выразительной силе, настраиваемости такой CASE в полноценную MetaCASE и прочее, настраиваемости под конкретный язык, будь то хоть асм хоть PL/M хоть BaCon бейсик, хоть RED/System, хоть в С++?

это всё эффективно языки одного и того же уровня — низкоуровневого. потому что «язык низкоуровневый, когда требует внимания к несущественному». вот например RED и RED/System — языки разного уровня. языки с макросами, однородного и гомоиконного вида, в которых можно сделать макрос, пишущий макрос, слова времени компиляции, пишущие слова времени интерпретации CREATE..DOES — это расширяемые языки, в которых одинаков только синтаксис, а уровни по сути могут быть разные.

В отдаленной перспективе - собственный компилятор с возможностью «раскрутки» кода вплоть до инструкций процессора.

скорее, метакомпилятор. посмотри как сделан тот же метакомпилятор форта, например lbForth в LitProg стиле, и forthmacs поверх него (и/или, сравни с тем forthmacs, что есть в составе OpenFirmware).

далее, допустим берём тот же язык с алгольным синтаксисом типа паскаля или оберона. например, читаем article2.pdf T.A. Ivanco and G.Hunter «A User Definable Language Interface for Forth».

взяли BNF алгола/паскаля/оберона, написали транслятор этого всего в форт. из паскаль-выражений в форт-выражения. затем получили Forth Meta-83 Compiler языка SmallAlgol с тестами.

8 страниц транслятор, на форте. из которых половина это грамматика с тестами.

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

не в ассемблер, а в тот же форт проще будет.

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

В отдаленной перспективе - собственный компилятор с возможностью «раскрутки» кода вплоть до инструкций процессора

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

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

anonymous ()
Ответ на: комментарий от metaprog

Вызовы сишных функций и декларация переменных для этого. Что там непонятного?

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

вот на эту тему рекомендую посмотреть высокоуровневый ассемблер HLA или даже тот же jonesforth + gas из gcc

anonymous ()
Ответ на: комментарий от anymouze

Сама концепция ООП проста:

какого именно ООП?

объект содержит в себе данные и методы, работающие с этими данными.

не содержит он методы. не обязан. отношение один к многим, да, имеется. или даже многие к многим.

Вот здесь (дальше) начинается усложнение.

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

на С++-ном ООП свет клином не сошёлся же. некий ООП на сишке, кстати, мог бы быть гораздо гибче чем single dispatch, virtual/non virtual и прочее всякое.

anonymous ()
Ответ на: комментарий от anymouze

Раскрутка до инструкций процессора исходного кода не выполнима. Исходные тексты блоксхемы только «сырьё» для «производства» машинных кодов.

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

впрочем, META был пример на JS. значит и на labview это в общем можно повторить же, только громоздче выглядеть будет.

раз два

anonymous ()
Ответ на: комментарий от anonymous

у автора xpost, кстати, на гитхабе есть ещё два любопытных проекта: ibis.ps и парсер комбинаторы на си и постскрипте

только постскрипт, только форт, только хардкор!!!

лисп интерпретатор здесь зело примитивный. разве что для раскрутки mc_tutorial выше и пригодится. а ссылка оттудова на scheme from scratch годная.

vision у него интересный, у автора xpost, ibis.ps и прочее.

«написать парсер+транслятор+litprog средство типа skribe на постскрипте, на себе самом».

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

не всё же вебсерверы на постскрипте писать.

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

anonymous ()
Ответ на: комментарий от anonymous

на академичность изложения я не претендую. описанное только моё понимание/восприятие ООП.

anymouze ()
Ответ на: комментарий от anonymous

Вы про метаассемблер, а я про бинарный код. Это java компилируется раз и выполняется везде в ВМ. А бинарный код даже на одной аппаратной платформе (например, на x86-64) зависит от операционной системы.

К примеру в какой машинный код развернётся стандартная функция printf()? Или Метапрог будет работать на одном процессоре и одной ОС? Тогда: да, легко.

anymouze ()
Ответ на: комментарий от anymouze

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

metaprog ()

новость дня: autodesk на грани банкротства

новость дня: autodesk на грани банкротства

а ведь когда-то они родили такое: ATLAST atlast-1.0.tgz (сейчас на эту тему стоит смотреть FICL там же или на sf.net)

читаю ATLAST.ps/.rtf и рыдаю навзрыд:

Open, programmable products are superior to and displace even the best designed closed applications. A threaded language, implemented in a single portable C file, allows virtually any program, existing or newly developed, to be made programmable, extensible, and open to user enhancement.

by John Walker

March 9th, 1990

основатель этого AutoDesk, между прочим (он вроде бы ещё Xanadu спонсировал и пытался допилить до ума, да так и ниасилили).

простой встраиваемый форт с возможностью переписать примитивы на Си функции.

какие-то бенчмарки есть (сорцы в приложении):

	C	ATLAST	AutoLISP 
CSQRT	1.00	7.41	67.08 
SSQRT	1.00	1.00	1.52  

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

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

в итоге вот она, технология 1990 года, блин:

1. писать приложение на Си с встраиваемым фортом (лиспом)

2. заменять форт-примитивы или лисп-примитивы переписыванием на си.

3. повторять пока не взлетит ... ???

4. PROFIT !!!

блин, уже тогда это всё было. ещё один всё понял.

даже жалко его, автодеска проприетарного. целая эпоха ведь.

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

anonymous ()
Ответ на: комментарий от metaprog

Например, операция сложения, и в x86 и в ARM есть соответствующая инструкция, но там разные коды операции.

ну так и я про это. Это в бинарнике всё определено*. В исходном коде программы это никак не определить*. Нет можно, конечно, захоркодить — но зачем?

anymouze ()
Ответ на: комментарий от anymouze

Производительность... Заказчик/работадатель/программист желает быстро получить работающий код. Никто не хочет ждать «идеального кода» — или я ошибаюсь?

Для чего? Для расширения кругозора и утоления любопытсва? Если код «свой», то что там разбирать до «винтиков»? «Чужие» исходники? Возможно... На «знакомом» ЯП их можно прочесть. Если нет исходников, то скажем есть отладчики — сразу в процессорных инструкциях можно увидеть. Но тут приходится наоборот «сворачивать» инструкции в функции и т.д.

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

Функции стандартной библиотеки C самая " простая" часть Вашей задумки. НО: стандартная библиотека C тоже внешний независимый компонент от Вашего ПО. В машинных кодах (операциях процессора) каждая реализация библиотеки C «уникальна» т.е привязана к процессору (архитектуре процессора и т.д.), ОС...

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

metaprog ()
Ответ на: комментарий от metaprog

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

ну какая тебе разница, транслировать сложение в add eax, ebx; (add eax bx) или аналог в GIMPLE, \ ebx eax add на фортассемблере, или как в ATLAS си примитивы, или SSA для LLVM например?

получается, что конкретный +, конкретно синтаксичный — слишком уровневый. а более AST-подобный + уже нормально транслируется. и не важно на этом уровне будет ли это ARM, x86, x86-64 или ещё что.

вот смотрю я твой пример в заголовке темы:

#include <stdio.h>

int main(){
char metaprog_array_pointer_10156130170823954432[] = {72,101,108,108,111,32,87,111,114,108,100};
unsigned long int metaprog_variable_13830126042312755200 = 1;
unsigned long int metaprog_array_size_10156130170823954432 = 11;
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,stdout);
char metaprog_array_pointer_12385851444566411264[] = {46,47,102,119,114,105,116,101,45,116,101,115,116,46,116,120,116,0};
char metaprog_array_pointer_16510743873862514688[] = {119,43,0};
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,fopen(metaprog_array_pointer_12385851444566411264,metaprog_array_pointer_16510743873862514688));

}

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

теперь если добавляем метауровень — можно char[] писать буквами а не байтами, чтобы читать лучше было. можно идентификаторы в стиле SSA GUID переименовать, чтобы лилалось лучше.

можно и API более читабельный сделать, или примитивы этой виртуальной машины. где есть операции такого метаинтерпретатора: fwrite, fopen, ещё что-то, в них транслирующееся.

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

если теперь язык сам нормально расширяемый, является собственным метаязыком в духе макросов лиспа или «слов, пишущих слова» CREATE..DOES форта, с возможностью переписать затем такие форт-слова на фортассемблер слова на ассемблере, или в духе ATLAS заменить си реализацией.

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

если физически оно может транслироваться во всё тоже самое.

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

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

то получится у нас Litprog описание метакомпилятора какого-то метаязыка, который последовательно специализируется и уточняется. и получаются проекции Футамуры-Турчина «специализация компилятора есть интерпретатор», хочется надеяться и на синтез «суперкомпиляция интерпретатора есть компилятор».

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

anonymous ()
Ответ на: комментарий от metaprog

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

а теперь в качестве упражнения, поразмяться попробуй реализовать бекендом бейсик (в варианте BaCon, транслятора на шелле бейсика, компилируемого в си с 0 накладными расходами на рантайм и прозрачной си интеграцией) или в RED/System (вроде бы пишут что медленнее чем си, но во сколько конкретно — мерять надо) и высокоуровневый RED.

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

anonymous ()
Ответ на: комментарий от metaprog

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

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

Раскрутка до элементов машинного кода - план весьма отдаленный

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

anymouze ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)