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

Зачем? Зачем вы продолжаете это?

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

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

т.е. тему можно закрывать. Потому что вероятность что ТС выкатит что-то КРАЙНЕ МАЛА.

Тему уже знаешь сколько раз так «закрывали»? Только растет как на дрожжах, даже без анонимусов.

Растет только благодаря тебе с котечкой. Ну и еще 2-3 человека, которые ради прикола заходят..

Ну и не без твоей помощи, хотя лучше бы без нее.

Так скучно же, да и интересно чем все закончится.

Да мне вот теперь интересно, как аффтар собирается представлять текстовые данные в графическом виде. Если он этого не делает — значит, он, мягко говоря, нас намахивает со своими намерениями. Если делает — значит, пусть покажет, как. Ибо по его же словам, если текст обернули в квадратик, то текстом он от этого быть не перестаёт. Вот мне и интересно, как он этот парадокс решает (с сохранением простоты понимания, естественно)…

Я ещё 4 страницы назад предлагал разойтись всем по своим IDE и сюда показывать либо что-то работающее, либо действительно интересные технические вопросы, а не «нет ты»...

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

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

Есть куча скринов и компилируемого кода для демонстрации. Хотя, конечно, это не сравнить с работающим прототипом. К сожалению, Лабвью платное и среди линуксоидов мало котируется, смысла его выкатывать нет. Придется для полноты ощущений ждать альфы.

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

Ничего нет. Проходи мимо.

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

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

Не трогай дерьмо, и оно вонять не будет. Ему уже 4 треда объясняют, а он прям по методичке «Правила демагога» шпарит. Бесполезно.

интерпретатор C++ -> C транслятор C++ -> C

извиняюсь за опечатку

Иди на три буквы, первая из которых «х». Эх, если б не правила...

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

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

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

Для чего существует ООП? Оно проще? Для чего С++, если есть чистый Си? Он проще? Если да, то освоить его должно быть проще, но в реальности С++ неимоверно сложнее в освоении чем чистый Си. Если даже сам Страуструпп оценивает свое знание С++ на 8 из 10 (из вики), то ООП явно сложнее. И для компиляции и выполнения «железом» ООП-код тоже сложнее. Так зачем учить и осваивать ООП?

Близится 4 мая, а концепт твоей «визуальной среды» был обещан до 3 мая. Успеешь за оставшиеся часы?

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

А для железа он проще?

Осталось меньше 2 часов. Часики тикают.

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

99% С++ разработчиков используют своё подмножество языка, а не все фичи, и им норм. Тот же Qt для С++ - на нём можно писать проект любой сложности (под силу далеко не каждому), и при этом использовать 30% возможностей языка.

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

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

да проще чем другие ООП языки (тот же python) не говоря уже о вебдаунистических технологиях пихаемых ныне повсюду. если ты говоришь о фичах самого языка perfomance hit настолько незначителен что им можно пренебречь на фоне современного железа и современного жирного софта. тем более к примеру методы в C++ по умолчанию даже не virtual что позволяет избежать вставки в объекты класса малюсенькой таблички с pointer'ами, одним словом на perfomance он ориентирован и вряд ли какой то другой ООП язык может сравниться с ним по производительности. если ты говоришь о производительности STL то ты можешь наклепать конечно более эффективный код с pointer'ами и malloc наделав при этом кучу багов.

C прост в изучении и написании hello world. Язык прост и логичен. Python сложен для изучения целиком но прост в написании скриптов из готовых библиотек для чего не нужно знать весь язык а в большинстве случаев только основы. C++ для профессионалов время которых стоит дороже чем полсекунды процессорного времени о чём говорить вообще считаю абсурдным на фоне других современных языков джавы, python'а, javascript'ов от которых загибаются мощнейшие компы под тяжестью тонн оопического говнокода.

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

Зависит от задач.

зачем вы сравниваете python и C++. у них разные области применения.

https://pics.me.me/good-luck-with-that-writing-device-drivers-with-javascript...

Хром и нода jit'ят js в машинный код + нашлись извращенцы, что пихают js в ардуину! даже не в одноплатники а-ля малинка, а схема, что не тянет ОС, где код пишется на js!

С учётом этого драйвера на js вполне возможны. Но слава Богу, что это никому не нужно кроме кучки извращенцев.

Сколько раз писали, что тормозит не js, а DOM и кривой код. Правда, в js и питоне объекты сделаны на основе словарей. В результате сишное и с++ное person->name в жс и питоне person.name де-факто превращается в что-то типа

std::map<std::string, std::variant> person;
name = person["name"];
person["hi"]();

Qt очень сильно понижает порог входа для С++ для разработки полезных программ. Даже в таких областях как быстрый обмен данными между разными потоками без дедлоков.

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

И что же это за мастера С++ и какие проблемы они решают, что им платят такие космические зарплаты?

концепт AMP будет устаканен в течение недели

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

Неделя прошла. «Спецификаций» и чего-либо еще нет. Торжественно объявляю тебя пи брехуном.

Бесспорно С++ лучше питонов, джав и другого говна, даже как пользователь программ замечаю. Но это все же меньшее из зол. Чистый Си лучше http://harmful.cat-v.org/software/c /

Для бекенда для Метапрога лучшего варианта чем Си не знаю.

какие космические зарплаты? труд уборщика дороже в 10 раз того процессорного времени которое затратится на C++ программу в сравнении с тем что на быдлокодит этот школьник pointer'ами на C. с учётом повсеместного засилья вебдаунизма даже джава выглядит performance oriented технологией. да я в курсе что тормозит dom, и ещё css3 и прочие свистопердящие онемацеи в электронах и т.д. говнофреймвёрках. глазам своим не верю что в век засилье жырных фреймвёрков, джав, питонов и прочих многотонных выжирающих память софтовин кто то завёл разговор о производительности C++ который уже во времена начала работы страустрапа был не актуален.

C++ никак не может быть лучше или хуже питонов так же как отвёртка никак не может быть лучше молотка а грузовик лучше мотоцикла.

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

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

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

а всё потому что на C пишется системный софт системными программистами относительно высокой квалификации и тестируется всё это дело очень хорошо потому что используется много где в том числе корпорациями. ты сильно разочаруешься в C если узнаешь что первые версии ядра linux написанные финским студентом падали постоянно в kernel panic?

в то же время если ты делаешь GUI для работы с базой данной хранящей сотни миллионов записей ты можешь убить месяц на клепание этого гуя на C и ещё год на обработку баг репортов о сегфаултах или наляпать на Python за день только узким местом всё равно будет являться база данных которую как раз надо делать на C и желательно ещё со вставками ассемблерного кода местами потому как поиск по таким объёмам информации дело не простое и твой супербыстрый GUI всё равно большую часть времени будет простаивать дожидаясь ответа от базы данных.

а что у тебя на плюсах падает?

а что у тебя на плюсах падает?

Мне вот проще сказать что не падает %)

ты можешь убить месяц на клепание этого гуя на C

Но GUI делается в glade, плюс там еще удобное подключение сигналов чисто для С!

Для чего существует ООП? Оно проще?

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

• ООП — namespace isolation
• Функциональное — работа с массивами, списками
• Реактивное — интерфейсы пользователя, и может ещё что-то
• Императивное — связка между всеми этими вот

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

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

Я сужу языки программирования по программам, на них написанным.

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

Ну и эта... если судить «по программам, на них написанным», то для твоей задачи лучший язык - это Java. Поскольку почему-то всякие моделлеры, диаграммеры и др. народ предпочитает писать именно на ней. (Это если не вспоминать про рантайм, сборку мусора и прочие технические подробности, а именно судить «по программам, на них написанным».)

говорят, после примерно 30,000 LOC в C начинаются реальные проблемы с пространством имён. но это ещё не самое страшное. огромное количество ошибок в C это отсутствие гарантированной инициализации сложных структур (constructor).

ты сильно разочаруешься в C если узнаешь что первые версии ядра linux написанные финским студентом падали постоянно в kernel panic?

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

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

отсутствие гарантированной инициализации сложных структур

удваиваю

начинаются реальные проблемы с пространством имён

А ещё прикол в том, что нельзя сделать

enum x {
   X_ONE
};

struct x {
};

Т.е. блин приходиться

enum x_enum {
    X_ONE
};
struct x_struct {
};

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

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

Сделать разделяемую библиотеку Метапрогом не получиться или будет не тривиальной задачей?

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

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

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

аххаха. идиотские абстракции как раз таки и созданы для удобства допиливания. представь что у тебя есть класс Matrix в котором энкапсулировано низкоуровневое представление матрицы и операций с ней. этот класс может быть протестирован независимо от остального кода и использоваться с тем же удобством как и машинный тип данных учитывая operator overloading в C++. на каком то этапе разработки ты обнаруживаешь более быстрый алгоритм для транспонирования этой матрицы и можешь с лёгкостью поменять этот класс не опасаясь что это приведёт к необходимости изменений в остальном коде программы т.к. характеристикой класса интересующими использующий его код являются исключительно его public методы. если же у тебя нет этой абстракции вполне возможно что новый алгоритм потребует другой структуры данных и тебе придётся менять весь код. почитай книгу Bruce Eckel «Thinking in C++» что бы разобраться а не тупо обсирать. там такие вещи очень хорошо описаны. и довести до ума программу на ООП гораздо проще чем без него.

Я либо открываю код под GPL, либо не открываю. Код лабвью-прототипа не открываю потому что п. 2 FAQ.

Библиотеку типа .so, .ko и .dll? Думаю будет несложно... когда руки дойдут до этого, но это уже будет после раскрутки Метапрога.

т.е. ты предпочитаешь писать в стиле

if (!( dirp = opendir(argv[1]) )) {
  perror("opendir(3)");
  return 2;
}

вместо обработки exceptions в одном месте? или просто игнорируешь проблему, пущай её идёт дальшь dirp == NULL и падает в segfault?

идиотские абстракции как раз таки и созданы для удобства допиливания

Только самая главная моя претензия к ООП - сложность в освоении - никуда не девается. Читай что-то да учись все время, ведь даже сам Страуструпп оценивает свое знание С++ на 8/10. ООП - хороший выбор для любителей вечно учиться да читать, но я не из таких.

представь что у тебя есть класс Matrix в котором энкапсулировано низкоуровневое представление матрицы и операций с ней. этот класс может быть протестирован независимо от остального кода и использоваться с тем же удобством как и машинный тип данных учитывая operator overloading в C++. на каком то этапе разработки ты обнаруживаешь более быстрый алгоритм для транспонирования этой матрицы и можешь с лёгкостью поменять этот класс не опасаясь что это приведёт к необходимости изменений в остальном коде программы т.к. характеристикой класса интересующими использующий его код являются исключительно его public методы. если же у тебя нет этой абстракции вполне возможно что новый алгоритм потребует другой структуры данных и тебе придётся менять весь код.

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

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

Кстати, как насчёт выложить исходники на bitbuket.org? Там есть приватные бесплатные репозитории

Они теперь есть и на гитхабе, после прихода MS.

Насколько я понял, автор не хочет пользоваться существующими хостингами по другой причине — там же везде VCS на ТЕКСТОВЫХ диффах, что по мнению автора, отстой и вчерашний день. Он хочет написать свою VCS, где всё будет в виде диаграмм и в бинарных форматах.

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

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

Да и вообще, исключения для исключительных ситуаций %) Это не про обычную обработку ошибок.

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

Про зависимые типы и теоретическое предсказание значения переменной на проводке мы уже говорили. А проверка ошибок, думаю, будет через простые if+else/switch+case (то есть, их графические аналоги).

Ну я к тому что зависимые типы сразу же отметают кучу ошибок! А остальное можно и с помощью if, switch проверить.

Только самая главная моя претензия к ООП - сложность в освоении - никуда не девается. Читай что-то да учись все время, ведь даже сам Страуструпп оценивает свое знание С++ на 8/10. ООП - хороший выбор для любителей вечно учиться да читать, но я не из таких.

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

Ну так и без ООП можно поменять функцию транспонирования. И структуру можно поменять.

лень расписывать, почитай всё же книжку то. автор её бесплатно выложил https://archive.org/details/TICPP2ndEdVolOne он тебе лучше объяснит чем я. я её классе в 10 когда учился прочитал так что сложностей в освоении особых не думаю что она у тебя вызовет.

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

Можно, но сложно. Зависимые типы спасут от костылей.

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

https://en.wikipedia.org/wiki/Dependent_type

ну и как это поможет? приведи пример кода с обработкой ошибок.

Они теперь есть и на гитхабе, после прихода MS.

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

Ах, ну да, ТС же не хочет с детищем Microsoft иметь дело... Точно, он говорил об этом. А Atalssian — поцаны обычные, они в своё время заняли $10k и принялись за работу. Сейчас их поделие ценят уже в $20M, если не ошибаюсь. Т.е. идеологических причин отказа быть не должно.

Библиотеку типа .so, .ko и .dll? Думаю будет несложно... когда руки дойдут до этого, но это уже будет после раскрутки Метапрога.

Проблема в разрешении имён. В Си же символ зовётся так как он зовётся. Т.е. например использование функции malloc — это использование кода по адресу в .dynsym с именем malloc.

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

Google?

Что ж, не поленюсь заглянуть.

A program is a bunch of objects telling each other what to do by sending messages

Кое-где мы это уже проходили:

The alternative is a microkernel-based system, in which most of the OS runs as separate processes, mostly outside the kernel. They communicate by message passing

https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI[1-25]

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

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

здаётся мне ты просто не писал ничего на C значительно длиннее helloworldа. точно помню мне тоже поначалу C++ показался фигнёй какой то непонятной. ты молодец что начал C изучать а не паскали какие нибудь и прочее говнище. сам или учитель по информатике подсказал?

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

а что за дракон? ещё одна УГСП?

Будет возможность поставить в нужном месте маркер «недопустимого состояния» и функцию-обработчик ошибки

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

Это надо много примеров... Ну вот нашел кое что: https://habr.com/ru/company/piter/blog/432416/

а что за дракон?

https://ru.wikipedia.org/wiki/ДРАКОН

Только что не душевный.

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

Я толком-то ни на чем код не писал, только на Лабвью собирал диагарммы. И Си фактически еще учу (хотя в основном уже знаю).

В графических диаграммах «писанины» будет существенно меньше.

Стоп, как это «писанины будет меньше»? Писанины вообще не будет! И телодвижений в целом надо будет куда меньше, даже без ввода каких-либо новых абстракций.

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

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

проще и понятнее

ну это для тебя ключевые критерии как я посмотрю

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

Совершенно верно. А для тебя какие критерии ключевые? Чем больше книжек по паттернам ООП прочитал - тем больше ЧСВ?))

А, и если книжки на английском, а не русском/украинском - умножаем ЧСВ на 100500.

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

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

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

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

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

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

Ну там в «целевая аудитория» прямо написано, что для макак их дрессировщиков.

даже абсурдная идея автора уже не нова как выясняется

Мде, прочти шапку треда, там про дракон есть, и то почему он провалился.

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

Стоп, как это «писанины будет меньше»? Писанины вообще не будет! И телодвижений в целом надо будет куда меньше, даже без ввода каких-либо новых абстракций.

а вот в будущем когда УГСП метапрог станет повсеместным де факто стандартом во всех областях программирования как будет правильно сказать? не «написал программу» а получается «накликал программу» или «нарисовал программу».

представляю заголовки «финский студент накликал ядро операционной системы linux» или вот ещё «украiнский школьнiк наклiкал революционное УГСП».

Мде, прочти шапку треда, там про дракон есть, и то почему он провалился.

Всхохотамши под лавкою!

не «написал программу» а получается «накликал программу» или «нарисовал программу».

«Начертил». По смыслу близко к работе конструктора, который чертит свою продукцию во всяких автокадах...

Я не «пишу» программы, а собираю.

Что там с циклами?

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

Вот мечта идиота: когда конструктор чертит свою продукцию, а эта продукция уже готова к обработке какими-либо утилитами, в итоге, то, что эти утилиты сделали, попадает к специалисту/программисту. Тогда макак вообще не нужно! Но и опять мы возвращаемся к работе с текстом, а не мышевозюканию.

И лет через ...надцать мы к этому придем. АСУ ТП — это очень консервативная область IT.

Ну и поскольку ответы на свои вопросы от ТСа я не получил, он просто не сумел/не захотел адекватно (а не лозунгами) ответить, получается, что метапрога в нашей отрасли пролетает, как фанера над парижем. А значит, это ни хрена не универсальная среда программирования.

Хороший вопрос.

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

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

Рисовать циклы уже умею, а вот с трансляцией в Си пока мудрую. Однозначно это будет цикл do... while. Кстати, лабвьюшная «While loop» тоже эквивалентна сишному do... while. По схеме ж очевидно какие элементы должны повторяться в цикле, а какие выполняться только один раз?

Какой из ответов тебя не устроил?

А ты разве кроме этого Metaprog: универсальная графическая среда программирования [в разработке] часть 4 (комментарий) ответил хоть на один мой вопрос? Как могут устроить ответы, которых нет?

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

Когда у тебя будет что-то, что можно будет пощупать? Может тогда и будет помощь и в коде и в донатах?

автор, не трать время, учи лучше C++ и Java. у тебя ничего не выйдет полезного.

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

Какое-то месиво из стрелочек, хардкоженых циферок и непонятных символов. Если б «аффтар» не рассказал, что это, якобы, «превращать нуль-терминированную строку в нормальный массив с известным размером.», яб не понял. Ты сам то потом вспомнишь что там происходит?

+1. я даже после того как он рассказал ничего не понял. и это какой то простенький helloworld. я даже не понял что такое «нормальный массив». это что то типа struct { size_t length; char *start; };. афтар выложи лучше Cшный код будет понятнее ей богу даже если он криво сгенерирован твоей утилитушкой.

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

https://www.youtube.com/watch?v=r8uCWl2LliI

не люблю ссылки на видево но на этот раз решился посмотреть и не пожалел. очень точно описывает впечатление от «кода» афтара.

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК. И вообще, хватит приводить Таненбаума в пример, он был прав по большинству вопросов. Если бы вы почитывали иногда lkml, проблемы монолита частенько всплывают там.

А сейчас есть помощь в подсказках по гтк и нюансам Си. Не от тебя, конечно.

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

Данные из строки копируются в массив и сохраняется длинна? В текстовом представлении это выглядит так:

char arr[128], *s = "Hello World!", *p = arr;
int n = 0;
while((*s+1) && (*p++ = *s++)) n++;

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК

Ты про Intel ME? А где еще миникс есть? На ARM?

Если бы вы почитывали иногда mailing lists, проблемы монолита частенько всплывают там.

А в 1991 (когда Линус сделал Линукс) была куча проблем с микорядром Миникса. И винда тоже, кстати, мироядерная, насколько я знаю - разве она лишена проблем?

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

«Правильные строки» есть тут кстати. https://developer.gnome.org/glib/stable/glib-Strings.html

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

Кстати, arr у тебя длиной 128. А если строка больше?

Так правильнее...

char arr[128], *s = "Hello World!", *p = arr;
int n = 0;
while((*p++ = *s++) && *s) n++;

И винда тоже, кстати, мироядерная, насколько я знаю - разве она лишена проблем?

Кек. Чукча не читатель, чукча писатель :) Винда – лютый монолит, но при этом NT вполне себе в ООП-стиле работает – везде передаются объекты, а не текст. Да и Linux на самом деле тоже написан с использованием многих практик ООП, иначе бы на первый год разработки всё схлопнулось бы.

Опять же, ограничение на 128. Лучше не избавляться от *s, вместо этого лучше всего лишь просмотреть какое из его значений «0» и сделать вывод о длине строки.

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

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

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

Ты не стесняйся, создвай темы с непонятными тебе вопросам в Си и гтк, тебе всегда ответят и без стеба.

Там данные вообще не копируются.

Тогда получается это аналог?

char *s = "Hello World!", *p = s;
size_t n = 0;
while(*s++) n++;


// length(Hello World!) == 12
printf("length(%s) == %zu", p, n);

А если строка больше?

segfault.

Си по критерию качества программ бесспорно выигрывет

Если бы это было бы так, то код для космических ракет, банковских систем и военки бы писался на нем. Это не так. Там, где нужна скорость, C оптимален – быстрее писать, чем на ассемблере (и кроссплатформенность получше), и при этом оверхед пропорционален используемым фичам. А для качественных (в смысле более читаемых и безопасных) сишечка уступает вообще почти всем неэзотерическим языкам (ну написанный дебилами от программирования код на C++ или обфусцированные вещи на жс мы не берем в расчет).

код для космических ракет
Это не так.

Вот как? И что там юзают?

Ada

Как ни странно, монолитные линукс и винда захватили мир, а микроядерный миникс только в Intel ME тихонько сидит, Hurd вообще на обочине...

Пруфы?

Ты реально это сам в гугле набрать не можешь? https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html

у нас в клинике тамограф стоит GE, там тоже ада, как инженегры из этого GE рассказали.

Это не пруфы. Вот к примеру марсоход ихний на VxWorks и программы на нем на С.

В 2000х у них спутник был на Commmon Lisp запрограммирован. Используется много чего! А не только Ada.

VxWorks и программы на нем на С.

пруфы?

был на Commmon Lisp запрограммирован. Используется много чего! А не только Ada.

Используется много чего! А не только C, да.

https://en.wikipedia.org/wiki/Comparison_of_embedded_computer_systems_on_boar...

Это не пруфы.

Пруфы. А твоя ссылка не доказывает что все ракеты на Ada.

А твоя ссылка не доказывает что все ракеты на C.

Поехавший что ли? Я это и не доказывал. Прочти комментарии выше.

Поехавший чтоли? Где я доказывал что ВСЕ ракеты на Ада?

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

ты бот чтоль?

Так текстовое программирование тоже захватило мир, и самые популярные представители ГП типа Лабвью не имеют и доли от (небольшого) успеха микроядра. Заставляет задуматься.

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

Текстовое программирование, может быть, по-своему прекрасно, но меня оно не устраивает.

Ого! Прогресс.

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

Например то, что я уже задолбался предлагать — пусть диаграммы будут диаграммами, но внутренний формат их представления оставить текстовым. Это сразу снимет с тебя бремя писать свою VCS и ещё дохрена всего. Да и вообще — если какой-то левый чувак может просто посмотреть потроха твоей диаграммы в виде plain text, это сразу снимет кучу вопросов, понизит порог доверия и создаст предпосылки, чтобы этот чувак стал твоим союзником, а не наоборот.

Уверенно поддерживаю!

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

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

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

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

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

если ошибка в программе просмотра файлов, то будет сегфолт

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

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/flatten_to_string/

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/unflatten_from_string/

Что-то подобное будет и в Метапроге.

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

В ООП, судя по всему, такой же оверхед по передаче данных между объектами. Микроядра - это ООП от операционных систем.

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

Визуальное программирование никак не спасает от невнимательности.

В С++, Java, и, возможно, в Swift и JS, если методы НЕ виртуальные, то никакого оверхеда по сравнению с Си не будет. Если же методы виртуальные, то есть небольшой оверхед на таблицу виртуальных методов. При этом в сишке часто эту фичу велосипедят сами через выбор нужной функции по указателю прямо во время выполнения программы.

А вот питон, php, js с магией, perl5 и прочая скриптота даёт оверхед из-за key-value структур данных.

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

Да, Метапрог не будет давать 100% гарантию от ошибок и невнимательности. Не дает такой гарантии и Лабвью, но в графических диаграммах ошибки и какие-то недоделки гораздо более очевидны, чем в стене текста. Невозможно сделать какую-то глупую и неочевидную синтаксическую ошибку или опечатку, возможно лишь не так соединить проводки, и то только если они того же типа. В Лабвью провдки разных типов подключишь - уже показывает ошибку прямо на диагармме. В Метапроге вообще невозможно будет подключить проводник неправильного типа.

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

ручного проставления всяких скобок

Они нужны для компактности кода, Metaprog: универсальная графическая среда программирования [в разработке] часть 4 (комментарий) насколько компактнее текстовый вариант тех схем! Надо что то с этим придумывать...

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

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

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

Кстати про типы: вы же сами хвастались про (void*) и всё такое – значит ли это, что указателями можно будет жонглировать по полной? Если да, то привет сотням ошибок, которых не будет видно в диаграммах.

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

Да, так же как в чистом Си. Я не хочу каким-либо образом обрезать его возможности в графическом Метапроге. Если же в каких-то ситуациях неопределенные указатели (или вообще указатели) не нужны - можно будет выделить специальное подмножество Метапрога.

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

Почему не видно? Неопределенные указатели можно специально подсвечивать, если надо.

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК

Мертвым грузом в Intel ME? :D

Ага, в качестве прошивки для шпионского зонда. Таненбаум, наверное, бьется в экстазе. xD Кстати, BSD лицензия-то, насколько я понял, не нарушена. Поэтому смело пихайте чужой BSD-код в свой проприетарный зонд. И имя автора указать не забудьте :) А GPL v.3, кстати, тивоизацию не допускает.

В ООП, судя по всему, такой же оверхед по передаче данных между объектами.

В общем случае — ерунда. Точнее, зависит от реализации. В C++ класс как таковой - это всего лишь структура, у которой класс видимости по умолчанию не public, а private. Обычная структура. Если есть виртуальные функции, то как тебе уже объяснили, добавляется таблица виртуальных методов, т.е. прямой вызов функции заменяется косвенными. Это сущие копейки.

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

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

И как тебе уже писали, в том же Linux используется ООП, смоделированное на чистом Си. :)

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

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

Если print('Hello, world!') занимает столько места, то что будет с более-менее сложными вещами?

Подумай об этом.

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

Хорошо, хорошо, ты меня уделал. Ну не буду же я тут юродивым всяким объяснять, что когда человека отправляют во внезапную командировку на другой конец планеты, то остальное какбэ отходит на второй, а то и на десятый план, ага. Хорошо, ты выиграл. ЧТО ДАЛЬШЕ?

За это время от тебя что-то рабочее и жизнеспособное появилось? Нет. Один троллёж да демагогия, ну и попытки, как и было предсказано, развести новоприбывших на донаты.

Молодец, так держать. Вот только скриншот твоего поста у меня тоже имеется. И если ты все эти два месяца будешь только смотреть, как «часики тикают», то продуешь вообще по всем фронтам.

А меня, как и себя, можешь объявлять кем угодно, вон, в любой психушке Наполеонов хватает.

ЧТО ДАЛЬШЕ?

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

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

Знаешь, с тобой шо в шахматы с голубем играть

Зачем играть с голубем в шахматы? Это заведомо глупо.

И если ты все эти два месяца будешь только смотреть, как «часики тикают»

А ТС про те два месяца (из которых один уже прошёл) уже и не говорит:

Надеюсь к середине-концу лета успеть сделать прототип Метапрога «сам на себе».

Может получиться так, что после ещё пары коррекций сроков окажется, что быстрее было (например) таки подучить Java, допилить MyOpenLab и уже после этого спокойно переписывать её «саму по себе», тем более, что к этому процессу других людей подключить куда проще, чем когда прототип прибит гвоздями к огороженному LabVIEW :)

Ну нравится пилить одному — пускай пилит. Вдруг сделает?

саму по себе

Опечатка, «саму на себе», конечно же.

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

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

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

За это время от тебя что-то рабочее и жизнеспособное появилось?

У меня за неполных 2 месяца около 50 скринов диаграмм и несколько компилирущихся примеров. А вот ты ничем кроме одного-двух скринов без компилируемого кода пока похвастаться не можешь - даже консольным хеллоуворлдом.

Хорошо, ты выиграл. ЧТО ДАЛЬШЕ?

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

Кстати, у тебя хватило мужества признать, что я выиграл спор. Однако я хотел бы задать тебе тот же вопрос: что дальше? Ты будешь вообще делать свой «антиметапрог» или пророчество сбылось?

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

Имхо, делать ПО не для себя, не за деньги, а чтобы доказать, что кто-то не умеет делать ПО - слабая мотивация. Если это пишется не за недельку. У ТС есть хотя бы «ЗАЧЕМ» - мотивация пилить месяцами, а ты сделаешь максимум прототип, так как дальше нужна мотивация типа «я верю в визуальное программирование, моё решение на базе RED - то, что нужно». Гениальные навыки и знания * нулевую мотивацию = нулевой результат.

У меня за неполных 2 месяца около 50 скринов диаграмм и несколько компилирущихся примеров.

Д – Достижение. У чувака с MD OS Ice, помнится, тоже «скрины» были…

ты будешь вообще делать свой «антиметапрог»

Почему бы и нет? Как только хоть какая-то публичная версия метапрога твоего появится. Думаю, это произойдёт точно не раньше моего возвращения в середине июня.

Д – Достижение. У чувака с MD OS Ice, помнится, тоже «скрины» были…

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

ты будешь вообще делать свой «антиметапрог»

Почему бы и нет? Как только хоть какая-то публичная версия метапрога твоего появится. Думаю, это произойдёт точно не раньше моего возвращения в середине июня.

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

Но так ты будешь на несколько шагов назад.

Не вопрос, тем интереснее челлендж. Сейчас всё равно не до того.

А ты хвалился, что уделаешь меня. Разочаровываешь.

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

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

реальные успехи (построение диаграмм и трансляцию в компилируемый сишный код),

#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 ./test.c -o ./test $(pkg-config --cflags --libs gtk+-3.0)

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

Ежу понятно, что его можно скомпилировать. Можешь сразу в машинный код переводить. Вопрос - зачем нужны исходники на C, если они все равно в итоге нечитаемые? В чем достижение-то? У LabView, думаю, есть свой компилятор и средства для трансляции в C. Или ты свой собственный компилятор/транслятор написал?

слакобомжей

В слаке еще в день релиза был GCC9.1 в твой Arch его когда завезут? Через год? Два?

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

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