LINUX.ORG.RU

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

 , , ,


10

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



Последнее исправление: CYB3R (всего исправлений: 9)
Ответ на: комментарий от hobbit

1) Что физически будет исходником программы на Метапроге? Именно растровая картинка, к примеру в PNG? В Лабвью, насколько я помню, именно так и сделали (могу путать, я ей последний раз интересовался аж в 2011 году), но парсить растровые картинки - нетривиальная вещь, даже когда они скомбинированы из заранее известных шаблонов. По какой логике будет работать парсер? Или всё-таки картинка будет только визуализацией для программиста, а под капотом будет какой-нибудь XML/JSON/etc?

я ж говорю, в обратную сторону, из текста в картинки зело проще.

берём тот же slit2 например и получаем PS. и рисуем что угодно.

или берём вот сиксель и внимательно изучаем примеры с GhostScript и фортом.

латех формулы в терминале — это внушаить!!!

сиксель — это картинки. которые текст. то есть, Esc-коды к терминалу DEC. ещё ЕМНИП был Tektronix которым векторное можно было отрисовывать, через Esc-коды.

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

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

или прям растр композитить: взять какой-нибудь МУМПС и глобал с отдельными слоями, и в отдельный слой показывать Z-координаты максимальные, вид сверху (самое верхнее непрозрачное, если все эти слои прозрачные).

в общем, текстовый интерфейс — это сила!!!

например, в plan9 в acme прямо текстом и обмениваются. Plumbing общесистемный движок правил, который по регекспам определяет, куда, в какое приложение snarf копипащенным плеваться.

или вот SNAP BYOB: «first class objects, continuations, lists, procedures»

я тут посмотрел, практически TruЪ Unix GUI получается.

самое смешное, что на каком-нибудь поверщеле GUI + такой вот текстовый XML прикрутить — раз плюнуть.

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

векторный фидонет, трёхмерный и текстовый

сиксель через opengl

гипертекстовой ссылочной целостности на них не хватает!

сайт фидокада исходники FidoCadJ примеры фидонета, векторного и многослойного

библиотеки элементов, например flowchart для блоксхем

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

или эту чертилку взять, из примеров сикселя.

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

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

ещё ЕМНИП был Tektronix которым векторное можно было отрисовывать, через Esc-коды.

нечто вроде такого или такого

ещё есть plan9port для acme и devdraw : такое

вся эта «картинка» - сиксель, или «вектор» Tektronix --- по сути простой ASCII текст с Escape кодами.

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

... иксы, которые можно задампить cat-ом и отослать фидопочтой --- вот она, благодатность и лепота Мицголова!

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

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

просто тебе нужен не текстовый, а гипертекстовый код.

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

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

например, SNAP:

" first class objects (sprites, costumes); continuations; procedures; lists"

RED, REBOL-выражения

лисповые S-выражения

некая функциональщина в духе elm и Literate Visualisation (в этом же направлении движется lout3, nonpareil)

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

Автоматический превращатель сишарпа в джаву и плюсы!!!

жесть. вот из веб-сервера Xitami приводят примеры про Model-based подход, с конкретными цифрами MOP ICL

и про X5 сервер, новое поколение этого Xitami. что-то типа «из 10,000 строк модели генерится 100,000 строк другой модели, из которой 1,000,000 строк на С. или на любом другом языке — шаблоны полностью настраиваемы же».

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

ну я ж говорю, возьми какой-то простой язык, который прозрачно транслируется в си: тот же RED/system, BaCon «как бы бейсик», ooc который «гомоиконный си, с синтаксисом типа Io» или вот COS модель от Laurent Deniau.

например, программы на лиспе, RED, ooc проще генерировать другими программами. из-за гомоиконности и регулярности синтаксиса. кстати, есть какой-то «лисп» который по сути выглядит только как лисп, а на самом деле — транслируется в си 1:1. ещё можно lush взять (и почитать про то, как этот лисп, транслирующийся в си использовали для разработки DjVU).

обновил тебе список для чтения про ООП.

посмотри там про язык ooc, объектные модели COS (более гибкая), oopc (более простая и понятная). ещё погуглив ooc гуглится кучу всякого «OOP in ANSI C», например такое

в общем, суть этого довольно проста. вот реализация сути — сложная :))

но есть и некоторые правильные вещи: принципы и механизмы реализации объектных моделей (естественно, это не с++, а некая более разумная ООП модель).

Я выбрал Си как самый оптимальный общий знаменатель для почти всех известных платформ.

ещё раз: это может быть в принципе и не одностадийный компилятор 1:1 в «сложный си», а многостадийный в «простой язык», который прозрачно транслируется в си (те же RED/System, ooc, lush lisp).

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

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

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

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

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

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

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

весь этот текст может быть невидимый, где-то под капотом у такого вот редактора

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

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

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

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

ещё раз: это может быть в принципе и не одностадийный компилятор 1:1 в «сложный си», а многостадийный в «простой язык», который прозрачно транслируется в си (те же RED/System, ooc, lush lisp)... не обязательно это должен быть С со всеми его сложностями. это может быть и нечто простое, также просто и прозрачно, без всяких накладных расходов в си транслирующееся.

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

2. Как в лиспе и прочих перечисленных вами системах обстоят дела с вызовом сишных функций, указателями и прочими чисто сишными плюшками? И вообще что там «проще»?!

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

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

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

Как написал анонимус выше — практика решает. Ждём что-нибудь с исходниками (не на гитхабе так на гитлабе или SF), работающее и не требующее для своей работы LabVIEW.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Верно. А пока что - обмениваемся идеями.

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

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

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

Встроенный в Метапрог функционал работы с репозиторием с графическими схемами. Похожий на The Powder Toy:

https://powdertoy.co.uk/

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

https://powdertoy.co.uk/Themes/Next/Design/Images/Screen1.png

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

Они бранчуются, неделю говнокодят на своём бранче, потом делают pull request и после ревью + автоматических проверок он сливается в мастер. Эти автопроверки упали из-за небольшого изменения в мастере в стиле Stable Api Nonsense: какая-нибудь функция сменила сигнатуру. На починку ушло минут 10... Тесты спокойно могут идти несколько минут (если не часов), ты собираешься запускать их в реалтайме?

Что вообще за тесты и зачем они? И с чего им идти часами? Ядро линукса на современном процике компилируется меньше минуты. Хотя «расчудесные» объектные модели творят чудеса - говорят, либре офис и фаерфокс (С++) компилируются часами.

Метапрог опирается на Си и компилироваться будет быстро.

Как будет выглядеть merge с диаграммами?

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

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

Владимир

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

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

Ядро линукса

https://kernelci.org/

Что вообще за тесты и зачем они?

Чтобы реже ломать. Когда проект живёт больше месяца и его пилит >1 человека — незаменимы.

И с чего им идти часами?

https://kernelci.org/build/linusw/branch/devel/kernel/v5.1-rc1-11-g851f66daeab9/

10+ минут на архитектуру. Тут — параллелится, но это всего лишь линукс. Кровавый тырпрайз бывает страшнее.

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

Тесты - всего лишь на компиляцию на разных платформах? Или что-то еще?

10+ минут на архитектуру. Тут — параллелится, но это всего лишь линукс. Кровавый тырпрайз бывает страшнее.

Страшен он ООП-языками, которые использует, а методами работы - еще страшнее.

https://habr.com/ru/post/443466/

Если Либре Офис компилируется ЧАСАМИ (правда?) из-за С++ и объектных моделей, то чего ожидать от энтерпрайзного говнокода?

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

Тесты - всего лишь на компиляцию на разных платформах?

Конечно, нет! У ядра есть selftest. У каждого более-менее серьёзного проекта подобного размера есть тесты, без них вообще печально. И вообще, это ж C со всеми прелестями сегфолт-ориентированного кодинга, в нём скомпилилось != работает.

компилируется ЧАСАМИ

Не вижу ничего плохого для продакшн-билда.

и объектных моделей

Сами по себе не добавляют времени компиляции. Плюсы — добавляют, но это ж возможность заплатить за абстракции в compile time вместо runtime.

x3al ★★★★★
()

Хотел бы я посмотреть как автор будет рисовать наскальное полотно для большой программы))) В своё время долго плевался от LabView. Он, действительно, оказывает большое впечатление на начальников, которые вдруг сами могут нарисовать кнопочку и соединить её с лампочкой. Но...когда программа большая, рисование превращается в ад. Все таки алфавит - великое изобретение вместе с копи-пастой)

anonymous
()

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

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

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

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

Рука не отваливается все рисовать ? ))) То, что можно сказать парой слов придется долго отрисовывать

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

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

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

То, что можно четко и ясно выразить в графике...

https://i.postimg.cc/RCgfWmRd/image.png

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

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

Особенно бесит когда где-то в текстовом коде сделаешь опечатку. И можно такое не заметить и потом долго радоваться жизни)))

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

то есть вместо того, чтоб просто написать x *= 2, что занимет меньше секунды, мне нужно поеложзить мышкой секунд 5 чтоб найти нужные стрелочки и соединить нужными линями? Выглядит неплохо, быстро, продуктивно, менеджеры под это даже новый аджайл запилят.

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

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

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

Сами по себе не добавляют времени компиляции. Плюсы — добавляют, но это ж возможность заплатить за абстракции в compile time вместо runtime.

За «абстракции» в стиле ООП платить приходится и временем компиляции, и временем выполнения, и временем дебаггинга, и временем потраченным на чтение книг и мануалов по ООП.

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

Ага...особый смак будет промахнуться где нибудь и потом все эти черточки редактировать. Это как эту формулу в паинте по пикселям рисовать - такой же мазохизм ))) Делал уже один раз большой проект на LabView, потом зарекся связываться с рисованием. Текст рулит

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

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

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

Кому-то и консоль рулит.

В 2019 году. Консоль. В 2100 тоже будете программировать в тексте и пользоваться интерфейсом консоли?

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

Не скажу про 2100, но в 2019 году пока что системы рисования программ как то не особо прижились. И это факт. И тексты пока по буквам читаем, а не в виде картинок, хотя для одноклеточных иконки уже придумали. Но только вот изобразить ими что то сложное и точно это передать пока как то не особо получается. Все равно текстовая расшифровка нужна. Проще запомнить 33 буквы, чем миллион иероглифов

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

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

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

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

А помните ли вы все функции стандартной библиотеки Си? Кстати, Метапрог уже умеет их показывать в виде меню!

https://i.postimg.cc/vBjg3Dn4/menu2.png

Скоро я знать стандартную библиотеку буду знать (если вы не сишник - то уже знаю) лучше вас.

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

Представляю ужас в виде стандартной библиотеки С в виде пиктограмм))) Это какой рулон обоев потребуется ))) Упаси господь от такого счастья. ))) Проще все таки запомнить слова, чем искать рисунки и особенно различия в картинках. Найди 10 отличий в иконках, прямо как в детстве ))). fprintf от sprintf отличить легко, а вот как на картинках они будут отличаться, какими видами закорючек ? )))

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

Лабвью избавило меня от необходимости мучиться с ООП и текстовым Си. Метапрог избавит меня и от ограничений самого Лабвью.

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.