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

Линус попросил стандарты POSIX, кажется, месяца за три до релиза 0.01. Я сейчас, по аналогии, открыл тему на ЛОРе около месяца назад (и уже многого добился с того момента), надеюсь через месяц-другой выкачу альфу. Хотя до этого, скорее всего, будет чатик через тор и, возможно, файловый сервер.

Вы посмотрите как Линус реализовывал системные вызовы вместо того чтобы тупить в талмуд со стандартами:

Похоже, Ари Лемке страдал излишним оптимизмом. Он создал каталог (ftp://ftp.funet.fi) задолго до того, как у меня появилось что туда положить. У меня был пароль, и все было готово для того, чтобы я мог просто войти в систему и закачать свою программу. Но прошло долгих четыре месяца, прежде чем мне захотелось чем-нибудь поделиться с миром или хотя бы с Ари и несколькими другими фанатами операционных систем, с которыми я переписывался.

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

Как создать операционку? Надо выяснить, что должны делать системные вызовы, и написать программы, которые будут это делать. Вообще говоря, системных вызовов около двух сотен. Некоторые из них могут соответствовать целому набору функций. Другие — совсем просты. Наиболее фундаментальные системные вызовы могут быть весьма сложными и в значительной мере зависят от имеющейся инфраструктуры. Возьмем системные вызовы Write (запись) и Read (чтение). Для записи на диск и чтения с диска нужно создать драйвер дисковода. Возьмем вызов Open (открыть). Нужно создать весь уровень файловой системы, который будет анализировать имена и определять, где что лежит на диске. На один этот системный вызов ушло несколько месяцев. Но когда он был уже готов, тот же самый программный код можно было использовать и для других функций.

Так шла разработка на ранних этапах. Я читал стандарты в руководствах к Sun OS и других книжках, брал системные вызовы один за другим и старался написать что-нибудь работающее. Это было довольно изнурительно.

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

В Unix оболочка  — это своего рода мать всех программ. Она всегда наготове, чтобы запустить любой другой бинарник. (Бинарник — это программа, составленная из нулей и единиц — на языке, который понимает машина. Если вы написали программу на каком-то языке программирования, нужно откомпилировать исходный код, чтобы получить бинарник.) Прежде всего оболочка позволяет вам войти в систему. Ну хорошо, в реальной Unix-системе по традиции первая программа, которую вы запускаете, это init, но для работы init необходима большая инфраструктура. Это своего рода контроллер происходящего. Но если у вас нет ничего работающего, то вам и init не нужна.

Поэтому мое ядро запускало не init, а оболочку. К тому времени я реализовал около двадцати пяти системных вызовов и, как я уже писал, это была первая настоящая программа, которую я хотел запустить. Оболочку я сам не писал. Я загрузил к себе на диск клон Bourne Shell, одной из исходных оболочек Unix. Он бесплатно распространялся по Интернету, и его название представляло собой плохой каламбур. Исходную оболочку написал чувак по имени Bourne, поэтому клон назывался Bourne-Again Shell (Bourne-Again произносится как born again -- укрепившаяся в вере. — Прим. пер). Обычно его сокращали до bash.

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

Я дошел до той стадии, когда моя программа загружала оболочку и выдавала на печать сообщение о каждом системном вызове, который содержался в оболочке, но который я еще не реализовал. Я загружался, запускал оболочку, а она выплевывала что-нибудь типа: «Системный вызов 512 не выполнен». День и ночь я вчитывался в распечатки системных вызовов, пытаясь понять, какие я написал неправильно. Но это было намного увлекательнее, чем идти по списку системных вызовов и реализовывать их один за другим. Теперь продвижение было более наглядным.

Наконец, в конце августа или начале сентября, оболочка заработала. После этого все стало намного проще.

Это был важный момент.

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

Кстати, Линукс 0.01 не умел даже компилировать сам себя (чего-то не хватало для полноценной работы gcc), эта возможность добавилась чуть позже. Вот и от альфа-версии Метапрога многого не ждите, возможно это будет только просмотрщик диаграмм, чтоб уже скрины не делать. Потом, через недельку-другую, будет уже и возможность редактировать диаграммы, то есть непосредственно приобщиться к разработке и уже допиливать его совместно, в более быстром темпе.

В моем случае вместо стандартов POSIX мне нужны библиотеки (например для графики) и прочие нюансы Си. Кстати, я взял гтк, хотя и не подумал бы этого делать, если б не подсказали и доступно рассказали чем это лучше чистого Xlib.

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

Нафига?!! Почему бы не транслировать в более высокоуровневый и кроссплатформенный язык, не прибитый гвоздями к конкретным тулкитам?

Мне вот давече попалась на глаза луркостатья «Быдлокодер», дык там в разделе «Поведение быдлокодера» есть хороший пункт:

… 8. Всегда планирует завтра написать Мегапрогу; …

Вот как увидел название - первая ассоциация. А как почитал тему - ещё больше эта ассоциация укрепилась.

веб-сервер с графическим интерфейсом??? вы имеете в виду утилиту настройки?

Инвалид, поинт мессаджа был не в том, что «Линукс 0.01 не умел даже компилировать сам себя», а в том, что а) Линус прочитал дохера и удосужился ознакомится с основами, которых ты не знаешь от слова «совсем», б) ядро 0.01 БЫЛО. Его можно было ВЗЯТЬ и ОТКОМПИЛИРОВАТЬ и даже, о чудо то, ЗАПУСТИТЬ! Можно было посмотреть его код и натыкать носом, где разраб облажался, то есть говорить по существу. У тебя пока только убогие картиночки, которые понятны только тебе и пачка нагенеренного гов-на, которое потенциально не просто не рабочее, но и опасное в плане использования, а еще наполеоновские планы про Мегапрогу и раздутое ЧСВ. В результате черех месяц ты заведешь 10 тему, где будет все то же самое, с картиночками, с кривым кодом и планами. И через 2 месяца и через 2 года.

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

Чесслово, лучше бы чистовый текстовый DSL для Pure Data запилил, и то пользы было бы больше (при условии такой же кроссплатформенности, как и сам движок Pd).

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

Ты всерьёз судишь о чёткости и немыльности графики по скриншоту в __JPG__???

Как по мне так сильно читаемее. https://imgur.com/0H0PhqQ

Автор, какие операции уже реализованы в твоей мегапроге прямо сейчас? Какие алгоритмы уже можно визуально набросать? Есть ли сетевой I/O, буферизация, многопоточность?

И что ты этой цитатой доказал?

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

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

А вот если ты отложишь эту задачу на «потом», то скорее всего, ты этого НИКОГДА не сделаешь. В большом проекте с тысячей предупреждений пытаться от них избавиться — это как плотину пальцем затыкать. Просто поверь мне — как раз наблюдаю у себя программиста, который на это в своё время забил, результат плачевен.

То же и с читаемостью текста. Если ты эту читаемость обеспечишь, ты обеспечишь себе канал обратной связи. Тебе сообщат, в какой функции у тебя ошибка, ты найдёшь это место. В противном случае ты никакого ответа на багрепорты, кроме «УМВР», выдавить не сможешь. Сопровождение написанного продукта (даже хорошо написанного) очень часто оказывается более трудоёмким, чем его написание...

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

Посмотрим как работает мой транслятор. Берется файл incl.h, в котором все нужные инклюды, например:

//gcc ./test.c -o ./test $(pkg-config --cflags --libs gtk+-3.0)

#include <stdlib.h>
#include <stdio.h>
#include <gtk/gtk.h>

Прогоняется через gcc -E, результат сразу в castxml. Все возможные типы и структуры разбиваются до самой элементарщины. Кстати, скорее всего, мне нужно поменять gtk на именно гтк 3.0 в зависимостях, чтоб никаких неоднозначностей (UB) точно не было.

Далее работает транслятор из castxml в бинарный файл с метапроговскими типами и функциями. Все сводится к примитивным типам, которых в Си не так уж и много, а со структурами, юнионами, массивами и указателями Метапрог обращается как с составными типами из примитивных типов. Из них уже стоставляются даграммы, функции итп. И они как раз и превращаются в многоэтажные структуры вместо коротких названий.

Чтоб не было всяких неоднозначностей на бинарном уровне, надо генерировать код именно под нужные версии гтк и других библиотек. Если вдруг надо будет поменять, скажем, гтк 3 на гтк 4, нужно будет поменять incl.h, обновить список типов и поменять измененные типы.

Тут, кстати, весьма актуальным становится вопрос о контроле изменений в зависимостях. Я вот недавно (вместе с версионированием форматов) внедрил управление зависимостями. Данные обо всех объектах диаграммы (подфункции, сишные вставки, контейнеры с данными) хранятся в файле диаграммы. Но при загрузке этого файла идет проверка на зависимости. Если файла зависимости нет - вылетает предупреждение. Если он был как-то изменен, Метапрог спрашивает, заменить ли зависимость новой версией. Примерно так же будет и с типами, в том числе взятыми из сишных инклюдов: если что-то изменилось - изменение будет подсвечиваться и спрашивать заменять ли на новую версию типа.

Молодец!

Все возможные типы и структуры разбиваются до самой элементарщины.

И вот тут ты получаешь тот самый факап, в который тебе уже носом натыкали.

Какие алгоритмы уже можно визуально набросать?

Какие показаны, такие и можно набросать.

А какие показаны? И какие операции реализованы? Словами можно объяснить? Потому как твой postimage.cc грузится целую вечность и содержит туеву хучу баннеров. Нормальные люди пользуются Imgur (как минимум).

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

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

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

Учись читать секцию «примеры».

Учись писать секцию «Примеры», дундель. Ты хоть сам смотрел, на какие посты ведут ссылки в этой секции?

Стыдно за соотечественников. Вот такие и выбирают всяких Педь и Зюзь...

Я, если что, ни за того ни за другого не голосовал. Ладно, хватит, а то за политоту хлопнут.

Всё ещё жду список реализованных на данный момент операций.

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

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

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

То, что за промежуточный этап трансляции был выбран Си, уже красноречиво говорит само за себя. Чел просто не в состоянии объективно оценить объём работ. Да и ставит он совершенно оторванные от реальности цели.

P.S. Был один такой товарищ - Базист, он же RStudio - тоже соотечественник (говорю же, херню творят они, а стыдно почему-то мне) с кучей мегапрожектов, но в памяти народной отложился именно ультракороткий язык программирования RS. Вот советую и топикстартеру тоже ту тему осилить, чтобы понять, как не надо подходить к задачам, дабы не повторить ту же ошибу.

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

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

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

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

RStudio

ого я не один его помню.

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

Я из тех, кто вёл с ним тесный дискурс © в темах FVMas и Стебелька, так что этого персонажа (наряду с Дедалом) мне сложно будет забыть и через 20 лет. А этот кедр - что-то среднее между Дедалом, Базистом и Санёцком (автором Aulix Backup2DVD, если кто-то это УГ ещё помнит здесь…)

прямо по делу и по существу

Тебе уже конкретно на последних 2 страницах сказали аж 3 критические неприятности которые у тебя есть

• Выравнивание структур в памяти, которые ломаются твоим «простым как дверь транслятором»
• выворачивание рекурсивных структур типа struct data {struct data *next; }
• Количество варнингов, которое производит твоя нагенеренная лапша

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

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

Ибо по делу и существу всё уже давно посоветовано:

1. Создать, устаканить и обнародовать чёткую спецификацию визуальных компонентов и уровней абстракции. В идеале это надо было сделать прежде, чем вообще начинать что-то писать.
2. Создать понятную документацию по уже существующим компонентам. Это нужно не столько потенциальным пользователям, сколько тебе самому. Ибо через 3 месяца уже сам запутаешься в этом всём.
3. Транслировать в Java/Red/WxPython вместо Си. На худой конец - в HTML+ JS (ES6) или Gjs. Не привызяваться к конкретным библиотекам.
4. Сделать транслирующий бэкэнд настолько стабильным, насколько это вообще возможно. Потом уже приступать к визуальной части (фронтенду).
5. Меньше клянчить и обещать, но больше делать. Как говорил твой любимый Торвальдс, «talk is cheap, show me some code».

С конкретными тезисами я еще могу работать.

Выравнивание структур в памяти, которые ломаются твоим «простым как дверь транслятором»

Что такое «выравнивание структур в памяти» и почему оно ломается моим транслятором?

выворачивание рекурсивных структур типа struct data {struct data *next; }

С рекурсивными структурами еще есть время подумать что делать. Пока с ними не сталкивался.

Количество варнингов

Об этом я уже ответил. Варнинги - всего лишь рекомендации. О сути этих варнингов есть что сказать?

Мне контекст (С)ПО казался очевидным.

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

Все создается в процессе и диктуется практикой, а не сферической теорией в вакууме.

Создать понятную документацию по уже существующим компонентам. Это нужно не столько потенциальным пользователям, сколько тебе самому. Ибо через 3 месяца уже сам запутаешься в этом всём.

Документацию? Лучше сделаю интерактивную обучалку. Я в Лабвью клепаю прототип Метапрога (и другие проекты) и вообще в них не путаюсь. Лабвьюшные диаграммы - сами по себе документация. Понятная схема вместо тысячи слов.

Транслировать в Java/Red/WxPython вместо Си. На худой конец - в HTML+ JS (ES6) или Gjs. Не привызяваться к конкретным библиотекам.

Зачем мне, черт побери, джаву или питон осваивать вместо Си? В чем их преимущества? Что такое Red я вообще не знаю, и не буду даже пытаться узнать если ты мне не объяснишь доступно по-русски (или українською мовою) что это такое и с чем его едят.

Сделать транслирующий бэкэнд настолько стабильным, насколько это вообще возможно. Потом уже приступать к визуальной части (фронтенду).

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

Меньше клянчить и обещать, но больше делать. Как говорил твой любимый Торвальдс, «talk is cheap, show me some code».

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

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

Там в теме некий Глюк-Казан начал пилить AntiRS. Вот думаю, не начать ли пилить AntiMetaprog (то есть то же самое, но с нормальным подходом к делу и на вменяемых технологиях)… Чисто чтобы посмотреть, каков будет прогресс в сравнении с аффтаром.

Про текстовый сишный уровень можно будет забыть как только будет на 100% надежная трансляция в сишный код

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

Отсутствие предупреждений — один из критериев надёжности. Не единственный и не главный, скорее, самый элементарный из косвенных. Если произошёл фейл ДАЖЕ на этом этапе — дальше вменяемые люди просто не будут ковыряться.

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

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

Ну вот это уже лучше. Элементарные тесты, кстати, должны сохраняться вместе с кодом. Но это — верхний уровень. А низкий тоже должен проверяться.

Варнинги - всего лишь рекомендации.

Формально да. А по факту игнорирование таких «рекомендаций» ведёт к печальным последствиям.

Вот думаю, не начать ли пилить AntiMetaprog (то есть то же самое, но с нормальным подходом к делу и на вменяемых технологиях)… Чисто чтобы посмотреть, каков будет прогресс в сравнении с аффтаром.

Одобряю. Больше метапрогов богу метапрогов! Не посмотреть ли тебе на уже неоднократно склонявшуюся здесь MyOpenLab — вдруг это хорошая основа для старта...

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

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

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

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

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

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

Все создается в процессе и диктуется практикой, а не сферической теорией в вакууме.

Что самое смешное - Базист в той теме высказывался ровно так же.

Документацию? Лучше сделаю интерактивную обучалку.

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

Зачем мне, черт побери, джаву или питон осваивать вместо Си? В чем их преимущества?

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

Что такое Red я вообще не знаю, и не буду даже пытаться узнать если ты мне не объяснишь доступно по-русски (или українською мовою) что это такое и с чем его едят.

Якщо IT-спеціаліст не знає англійської, йому в галузі робити нічого.

Имея графические диаграммы сделать транслятор в Си - дело техники.

Так думают все дилетанты.

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

Это не код.

Ты бы что показал реально полезного для проекта

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

или хоть донат сделал

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

А если нет желания делать ни того ни другого - иди лесом.

Ну пойти-то могу, но то, с чем я вернусь, тебе не понравится.

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

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

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

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

Якщо IT-спеціаліст не знає англійської, йому в галузі робити нічого.

Это, пожалуй, главный миус современного айти. А насчет Red ты меня не убедил. Читать я твой линк не буду - лень. Осваивать Red с нуля без ОЧЕНЬ уважительной на то причины - тем более. Ты мне по-русски давай рассказывай, чем твой Red лучше Си для моего проекта, если хочешь меня убедить.

Это не код.

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

MyOpenLab - не совсем то, что соответствует задумке. Это скорее закос под тот же лабвью. Если я правильно распарсил бред ТС, то он ставит во главу угла визуальное описание не готовых компонентов, а алгоритмов и структур данных. Имхую, что эти вещи можно сделать гораздо проще, но гибче, чем в лабвью и опенлабах. Но я, в отличие от ТС, словами разбрасываться не привык, так что что-либо конкретное скажу уже тогда, когда устаканится сам концепт.

Ждем-с. Неужто я кого-то еще вдохновил на визуализацию программирования?

А Си я, кстати, знаю.

Я аж чаем от смеха поперхнулся

Чисто с целью утереть нос всяким прожектёрам - почему бы и нет? Ударим редом и визуальщиной по базистике и дедаловщине!

Когда будет релиз? Или хоть концепт?

а когда будет твой?

Я уже свои примерные сроки называл. А у тебя что, товарищ анонимус?

Вот как только у тебя что-то запуститься, сгенерит код и соберет без предупреждений и без уб, тогда будет.

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

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

Когда будет релиз? Или хоть концепт?

Концепт будет не позже 3 мая.

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

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

P.S. Залогинился, дабы остальные анонимусы не имперсонировали.