Исправление hobbit, (текущая версия) :
Ну самое очевидное — таблицы виртуальных методов, ярчайшая ООПшная фишка. А более подробно таки советую ознакомиться с оригиналом.
Вообще, у меня такое ощущение, что твоя категоричность в некоторых вопросах (неприязнь к текстовому представлению программы, неприязнь к ООП) может быть вызвана тем, что ты не разрабатывал достаточно больших проектов.
Ты попробуй выполнить заявленную цель - перенести сам Метапрог на Си, это действительно нетривиальная задача. Заодно уровень твоей аргументации сильно вырастет. Либо ты переубедишь людей (у тебя же есть код), либо какие-то взгляды пересмотришь сам. :)
Вот ряд вопросов (разного уровня, взяты, можно сказать, с потолка):
1) Что физически будет исходником программы на Метапроге? Именно растровая картинка, к примеру в PNG? В Лабвью, насколько я помню, именно так и сделали (могу путать, я ей последний раз интересовался аж в 2011 году), но парсить растровые картинки - нетривиальная вещь, даже когда они скомбинированы из заранее известных шаблонов. По какой логике будет работать парсер? Или всё-таки картинка будет только визуализацией для программиста, а под капотом будет какой-нибудь XML/JSON/etc?
2) Что ты предлагаешь на замену традиционным системам контроля версий? Когда в основе всего текст, доработки и изменения легко представить в виде патчей. А как будет выглядеть «графический патч»?
3) Очевидно, чтобы диаграммы Метапрога можно было парсить, их надо набирать не в абы каком графическом редакторе. Нужна специально заточенная под Метапрог IDE. Как ты будешь такую IDE писать? Воспользуешься ли какими-то тулкитами (Qt, GObject+GTK+...) или в соответствии со своей тягой к низкому уровню напишешь всё на xlib? :)
И на самом деле таких, достаточно простых, но каверзных вопросов, под каждым из которых скрывается целый айсберг, по твоей концепции куда больше. Я просто несколько раз сталкивался с системами, написанными по принципу «пусть программисты не пишут код или пищут его по минимуму». И в лучшем случае продукт был пригоден для чего-то узкоспециального, шаг влево, шаг вправо — расстрел. То есть явно не замена тому же Си, на котором писать можно буквально ВСЁ (вопрос, какой ценой).
Исходная версия hobbit, :
Ну самое очевидное — таблицы виртуальных методов, ярчайшая ООПшная фишка. А более подробно таки советую ознакомиться с оригиналом.
Вообще, у меня такое ощущение, что твоя категоричность в некоторых вопросах (неприязнь к текстовому представлению программы, неприязнь к ООП) может быть вызвана тем, что ты не разрабатывал достаточно больших проектов.
Ты попробуй выполнить заявленную цель - перенести сам Метапрог на Си, это действительно нетривиальная задача. Заодно уровень твоей аргументации сильно вырастет. Либо ты переубедишь людей (у тебя же есть код), либо какие-то взгляды пересмотришь сам. :)
Вот ряд вопросов (разного уровня, взяты, можно сказать, с потолка):
1) Что физически будет исходником программы на Метапроге? Именно растровая картинка, к примеру в PNG? В Лабвью, насколько я помню, именно так и сделали (могу путать, я ей последний раз интересовался аж в 2011 году), но парсить растровые картинки - нетривиальная вещь, даже когда они скомбинированы из заранее известных шаблонов. По какой логике будет работать парсер? Или всё-таки картинка будет только визуализацией для программиста, а под капотом будет какой-нибудь XML/JSON/etc?
2) Что ты предлагаешь на замену традиционным системам контроля версий? Когда в основе всего текст, доработки и изменения легко представить в виде патчей. А как будет выглядеть «графический патч»?
3) Очевидно, чтобы диаграммы Метапрога можно было парсить, их надо набирать не в абы каком графическом редакторе. Нужна специально заточенная под Метапрог IDE. Как ты будешь такую IDE писать? Воспользуешься ли какими-то тулкитами (Qt, GObject+GTK+...) или в соответствии со своей тягой к низкому уровню напишешь всё на xlib? :)
И на самом деле таких, достаточно простых но каверзных вопросов, под каждым из которых скрывается целый айсберг, по твоей концепции куда больше. Я просто несколько раз сталкивался с системами, написанными по принципу «пусть программисты не пишут код или пищут его по минимуму». И в лучшем случае продукт был пригоден для чего-то узкоспециального, шаг влево, шаг вправо — расстрел. То есть явно не замена тому же Си, на котором писать можно буквально ВСЁ (вопрос, какой ценой).