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)
Ответ на: комментарий от metaprog

Да зачем мне? Тут никто в твоей схеме разобраться не смог, которая в одну строчку кода транслируется. Куда уж там более сложные вещи из 2 строк, 10, 100, 10 000, 1 000 000? Ты уже расписался в том, что твоя поделка неработоспособна.

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

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

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

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

Да зачем мне?

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

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

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

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

Ты случайно не его препод? Когда метапрог по телику увидим?)))

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

А если потрачу время на то, чтоб разобраться с Project Euler вместо работы непосредственно над Метапрогом - сколько задонатишь?

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

Твой вопрос некорректен, потому что любой донат доброволен.

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

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

Реальных задач и без того хватает - перенести Метапрог «сам на себя», гуй на Xlib, сетевой функционал, свой аналог Гитхаба с графическими схемами, функционал для одновременного программирования онлайн. Это реальная практика, а не сферическая математика в вакууме.

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

Там расширяемая система регэкспов. Запись немножко громоздкая по сравнению с PCRE, но если всё равно транслируем из графики — это неважно. Вот не знаю, насколько это можно выдернуть в качестве библиотеки для C (для lua — видел), но поинтересуюсь на досуге.

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

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

Ты случайно не его препод?

Да, киевский лабвиевский университет, ты угадал.

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

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

Кстати, я уже пилил рекурсивный парсер Си на своей системе регулярных выражений. Но лагало дико, и забросил, узнав про gcc -e и castxml. На днях откопаю и покажу примеры с регулярныи выражениями.

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

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

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

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

Scratch/Pawn все равно завязаны на текст.

Ну да, он один-в-один траслируется в тот или иной язык программирования или разметки. В как-бы это сказать — иерархическую текстовую структуру. Когда речь идёт об управлении последовательностью команд — старое-доброе структурное программирование. Ну так не зря же в основе любого современного языка программирования лежит именно это изобретение Дийкстры сотоварищи (а не то, что, к примеру, в том же Сноболе). Да, иногда произвольная state-машина удобнее. Но лично мне кажется, язык state-машин не должен быть основным, но вспомогательным. Видим state-машину — ага, значит тут реализована какая-то сложная логика…

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

чем вхренячивать еще и Снобол.

Весь Снобол вхренячивать точно не надо. Я писал

Вот не знаю, насколько это можно выдернуть в качестве библиотеки для C (для lua — видел), но поинтересуюсь на досуге.

Теперь знаю, ссылка со snobol4.org на библиотеку match. На которую, прежде чем начинать делать свой велосипед, стоит как минимум посмотреть.

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

Не работаю с текстом, забываю как называются символы которые «отображаются» но состоять могут из нескольких и «весить» больше int64_t. Мне вот на такое разделить надо к примеру.

Это ж глифы. Из известных мне языков самое низкоуровневое, что по дефолту работает с ними в строках — swift.

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

mp_a - слишком коротко, возможна коллизия с именами из включенных через #include сишных библиотек.

О, ещё немного и ты изобретёшь неймспейсы.

. Это существенно, так как какой-нибудь управляющий символ «\[]{}*^ может повлиять на процесс компиляции

Если больше ничего не сделать — заэскейпи, иначе дебажить нереально же?

Абстракции хороши тогда и только тогда, когда:

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

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

Коллективные текстовые редакторы давно есть, но их не используют вместо контроля версий потому, что CI/CD с ними не сделаешь.

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

Как это будет выглядеть в этой твоей «онлайн-игре»? Тесты спокойно могут идти несколько минут (если не часов), ты собираешься запускать их в реалтайме? Как будет выглядеть merge с диаграммами?

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

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

в человеческом мире оно должно начинаться с async и идти дальше синхронно.

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

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

Кстати, а тебя не смущает, что в ядре Linux полным-полно нелюбимого тобой ООП, только реализованного средствами процедурного языка?

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

Э? Если переменная меняется неизвестно кем в типа-синхронном коде — это практически как мультитредовый софт со всеми прелестями синхронизации shared-состояния. Это не «кишки», а вполне заметное поведение.

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

Так не надо её менять. Даже в старом PHP всё знали, что такое глобальные переменные.

Shadow ★★★★★
()

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

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

Simulink. У нас в конторе так софт пишется

О Вашей работе телепередач не снимали? Пока поискал только вот в этом архиве: https://www.youtube.com/channel/UCFnTHrvjQUKs_05d0nOW0qA Но мне сдаётся, что они не все выпуски на ютьюб выложили.

anonymous
()

Владимир

ИМХНО ваш проект заслуживает внимание.
Скорее всего в нем будет много недочетов /А где их нет?/.
Не прочь бы на github увидеть ваши исходники.
Кстати ради интереса введите https://github.com/search?q=metaprog.

Пора и поумничать.
Если community github заинтересуется вашим проектом, то обязательно будет contributions.

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

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

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

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

Вот ряд вопросов (разного уровня, взяты, можно сказать, с потолка):

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

2) Что ты предлагаешь на замену традиционным системам контроля версий? Когда в основе всего текст, доработки и изменения легко представить в виде патчей. А как будет выглядеть «графический патч»?

3) Очевидно, чтобы диаграммы Метапрога можно было парсить, их надо набирать не в абы каком графическом редакторе. Нужна специально заточенная под Метапрог IDE. Как ты будешь такую IDE писать? Воспользуешься ли какими-то тулкитами (Qt, GObject+GTK+...) или в соответствии со своей тягой к низкому уровню напишешь всё на xlib? :)

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

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

Хорошие вопросы. Побольше б умных людей и поменьше обезьян, кидающихся какашками.

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

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

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

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

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

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

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

Бинарный файл блок-диаграммы. Для этого надо будет не только портировать сишные типы, но и сделать удобный функционал сериализации/десериализации бинарных типизированных объектов в строки (для записи в файл, передачи через сеть итп). Что будет полезно далеко не только для самого Метапрога. Кстати, в самом Лабвью функции тоже хранятся в бинарнике, на картинке лишь отрисовываются. Хранить диаграмму в формате картинки и парсить картинку при каждой загрузке - верх идиотизма.

2) Что ты предлагаешь на замену традиционным системам контроля версий? Когда в основе всего текст, доработки и изменения легко представить в виде патчей. А как будет выглядеть «графический патч»?

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

3) Очевидно, чтобы диаграммы Метапрога можно было парсить, их надо набирать не в абы каком графическом редакторе. Нужна специально заточенная под Метапрог IDE. Как ты будешь такую IDE писать? Воспользуешься ли какими-то тулкитами (Qt, GObject+GTK+...) или в соответствии со своей тягой к низкому уровню напишешь всё на xlib? :)

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

Я просто несколько раз сталкивался с системами, написанными по принципу «пусть программисты не пишут код или пищут его по минимуму». И в лучшем случае продукт был пригоден для чего-то узкоспециального, шаг влево, шаг вправо — расстрел. То есть явно не замена тому же Си, на котором писать можно буквально ВСЁ (вопрос, какой ценой).

Ничего серьезнее Лабвью по части графического программирования нет в природе. Все остальное - либо жалкие надстройки над текстовыми языками (которые заслуженно получают вердикт «ненужно»), либо узкоспециализированные системы. Даже Лабвью компания-разработчик позиционирует как всего лишь «систему для измерений и обработки данных». Они реально идиоты или так решили маркетологи, чтоб увеличить прибыли? Сделав фактически универсальное IDE для программирования, они сами же искусственно ограничивают области его применения! Пускай подавятся баблом, тупые и жадные скоты, я хочу из разорить!

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

Почему проигнорировал мое замечание по поводу мнения Дениса Ритчи?

Потому что не знаком с его мнением о С++.

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

Для чего вообще существует концепция ООП? Для простоты? Тогда какого черта она плодит толстенные талмуды?

Я правильно понял, что на си ты научился писать с молоком матери и ничего читать не пришлось?

Дебильный аргумент, извини

Отбрось пока ООП и ознакомься со средствами, которые предоставляет c++ для процедурного программирования. При разработке c++ был учтен гигантский опыт работы на Си, на основании этого опыта, язык был доработан, но доработан очень умно. Активнейшую роль в этом сыграл Денис Ритчи. Напомню, речь о процедурном программировании.

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

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

С профессиональным праздником тебя, кстати!

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

Владимир

Для этого надо будет не только портировать сишные типы, но и сделать удобный функционал сериализации/десериализации бинарных типизированных объектов в строки (для записи в файл, передачи через сеть итп).

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

У меня бы процесс разработки выглядел так:
- разработка добротной метадата базы;
- разработка объектов, используемых для конкретного проекта;
- разработка GUI /в частности пригодного для отображения диаграмм/;
- реализация какого-либо проекта /в вашем случае визуализация C/ для тестирования, вышеприведенного функционала.

Имеется и другой путь - сделать «на коленке» и быстрее в productions.

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

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

Да озвучивай его уж наконец!

Я правильно понял, что на си ты научился писать с молоком матери и ничего читать не пришлось?

Читать, черт возьми, пришлось. Это по Си. А вот по Labview читать почти не приходилось. Все функции, типы, структуры и так лежат на поверхности в графических меню.

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

Да озвучивай его уж наконец!

А я его не знаю :)

Однако мне известно, что на первых же страницах своей книги товарищ Страуструп выражает ему огромную благодарность за помощь в создании языка (они в одном месте работали), а в первых главах он пишет почему Си++ — улучшенный си даже по отношению к процедурному стилю программирования. Обращаю внимание, Ритчи принимал активное участие в этой работе. Все, что было хорошего в Си сохранилось в плюсах (собсно, плохое тоже сохранилось, ибо плюсы были написаны так, что Си — его (С++) подмножество)

Читать, черт возьми, пришлось. Это по Си

То есть по Си читать нормально, а по плюсам — плохо?

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

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

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

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

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

С праздником!

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

Кроме первоапрельских шуток, читал на хабре интересный пост об ООП-языках:

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

У меня на работе много небольших проектов, и мы используем разные стеки — .net, React.ts, c++, Java. В чем ты хоть немного прошарен, то на тебя и повесят. Я пришел как дотнетчик, но таски на доске есть на все приложения, доступ к репозиториям — тоже.

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

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

Я просто делал одно и то же на разных языках программирования. Этот код был очень похожим, за исключением деталей, которые никак не влияют на решаемую задачу. Ведь бизнес не приходит ко мне со словами: «Эй Фил! Нам нужно использовать абстрактные классы, чтобы отобразить клиенту состояние впн соединения». Бизнес и пользователи хотят, чтобы девайс показал им картинку. Да и я на самом деле тоже просто хочу показать им эту картинку.

...

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

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

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

Они бы не офигели от нашего количества абстракций ради абстракций? Смогли бы принять, что в 2019 все чаще выбирают абстракции чисто эстетически и этим размывают связь с выполнением на машине.

Конец цитаты.

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

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

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

и, черт побери, все придется заново делать

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

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

Они реально идиоты или так решили маркетологи, чтоб увеличить прибыли? Сделав фактически универсальное IDE для программирования, они сами же искусственно ограничивают области его применения!

А вот это — вполне допускаю. IBM именно так просрал OS/2.

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

Еще одну статью нашел о бизнесе (добавьте приставку «нае»):

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

Черт побери, мир был бы намного лучше без макетологов, банкиров и прочих продавцов воздуха!

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

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

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

И как на этом фоне красив Си!

А кто спорит? Я сейчас страшное скажу: я пишу на си, а не на плюсах. Тем не менее я не считаю всех любителей плюсов идиотами, и тебе не советую.

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

Хочу разнести энтерпрайз в пух и прах. Меня и 0,1% от его прибыли устроит:)

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

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

Владимир

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

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

Владимир

Это не вам ни кому другому не удастся сделать.
Почему?
Потому что среди пьяниц, трезвенников нет.

PS: Когда вы заработаете деньги, то забудете, то о чем говорили и более того ...

(Новый Завет, Евангелие от Матфея, гл. 6, ст. 24):
«Никто не может служить двум господам: ибо или одного будет ненавидеть, а другого любить;
или одному станет усердствовать, а о другом нерадеть.
Не можете служить Богу и маммоне».

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

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

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