Метапрог-прототип, версия 7 + графические диалоги на Метапроге

а руст так и в этих задачах почти ни чем не уступает С

Уступает по скорости, библиотекам, переносимости…

там есть слово «почти», ну в любом случае наверное это пока самая близкая альтернатива С.

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

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

Важно же, во первых rust делают анскильные лалки, которые не могут даже -ffast-math поддержать, во вторых rust строится на llvm, а значит шагнуть дальше C/C++ просто не может, ну нету такой возможности, тем более он состоит из ограничений (возможностей).

Повеяло монархическим душком :)

vcpkg

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

Возвращаясь к теме треда, можно еще рассказать ТС что в паскале не нультерминированные строки с длинной внутри строки

А какой там тип для длинны?

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

то есть фактически уже в 70х прошлого века какая-то часть тусовочки считала что нультерминированные строки это возможно не то, что нужно всем.

Из Lazarus Wiki.

ShortString имеет фиксированную максимальную длину, определяемую программистом (например name : String[25];), но при этом ограниченную 255 символами. Если длина переменной типа ShortString не указана явно, то длина устанавливается равной 255. В этом типе нет счетчика ссылок.

AnsiString имеет переменную длину, ограниченную значением High(SizeInt) (которое зависит от платформы) и доступной памятью. В этом типе есть счетчик ссылок.

WideString имеет переменную длину, как и тип AnsiString, но состоит из символов WideChar вместо символов Char. Данный тип совместим со строковым типом BWSTR и в нем нет счетчика ссылок.

UnicodeString похож на тип WideString, но тип UnicodeString является управляемым типом и содержит счетчик ссылок, в то время как WideString является совместимым с типом BWSTR, который совместим с COM и не содержит счетчик ссылок.

В итоге есть строка на с лимитом на 256 байтов, и строки со счетчиками ссылок всякими...

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

Почему костыль?

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

Ну волшебства не бывает, тут либо так, либо эдак.

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

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

Сейчас полезно именно описание языка. (Чуть попозже разверну мысль, сейчас надо уйти от компа).

вот если бы вы вообще ничего не делали но знания волшебным образом появлялись

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

И отсутствие этих знаний не мешает мне программировать на Лабвью и прототипе Метапрога. Для этого надо знать сравнительно немного: систему типов (деление числовых типов по видам и разрядностям), структуры, юнионы, указатели, массивы и дополнителньые удобные плюшки как СУВТ и версионированные форматы. Это все несложно и при должной простоте интерактивных гайдов осваивается так же легко как игра-стратегия даже 10-летними детьми, никогда в жизни ранее не программировашими. Лабвью я освоил, не прочитав ни одной книги по нему. В этом мне очень помогает контекстная справка, однако нормальных обучалок для новичков там все же нет - копирастам из NI все же надо зарабатывать на фирменных курсах (хоть я и обошелся без них) и сертификациях знаний по Лабвью (я и без того царь Лабвью).

а так в любом случае что-то то читаете хотя бы тут в попытках понять почему что-то не работает

В Лабвью это делать почти не приходится.

один черт лезете гуглить или в исходник, даже если не читаете мануалы и книги

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

сейчас вообще сложно что-то писать без гугла так-то, потому что технологий уже жопой жуй, действительно нельзя все это знать

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

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

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

иначе и будете дальше метапроги писать на циклах массивах и если то иначе, это не код это барахло

А как лучше? Таненбаум Линусу предлагал микроядра вместо монолита, а что же предложишь из своих Сакральных Знаний ты, о Высшая Мудрость?

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

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

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

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

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

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

Повторюсь ещё раз для читающих Невнимательно - если делать от баллы то не спасёт Никакой Инструмент. А вы в первых темах свой проект позиционировала вроде как для всех. А теперь получается что нужно уметь управлять памятью. Те кто это умеют - как правило умеют и в си

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

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

Он рассуждает как большой ребёнок (а может, даже и совсем не большой, но это нюансы).

Я не укушен текстовой скриптухой и могу как ребёнок сказать что-то вроде: «а король-то голый».

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

Этому научиться проще, чем всякого рода абстракциям ради абстракций. И в Метапроге «на самом себе» планирую добавить еще и возможность автопростановки блоков с free в концах веток, оперирущих массивами.

Те кто это умеют - как правило умеют и в си

Да, но в Метапроге это будет проще.

Никаких сборщиков мусора и прочего подобного бреда в рантайме.

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

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

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

В самом Метапроге система управления зависимостями пока очень простая: при экспорте меню в систему контроля версий пакуются все элементы меню (могут быть любые файлы), если это диаграмма - пакуются дополнительно еще и все ее метапроговские зависимости (диаграммы и типы).

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

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

У вас теперь уже просто «текстовая скриптуха». Сильный ход

И отсутствие этих знаний не мешает мне программировать на Лабвью и прототипе Метапрога

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

Знания помогают не просто писать программы, а писать программы которые элегантные и эффективные.

То же GUI:

можно ничего не знать и рисовать в Builder,

а можно знать MVC паттерн, или MVP, или MVVM, или MVU.

Программа нарисованная в Builder и программа котороя корректно реализует паттерн Model View Update просто несравнимы по надёжности и эллегантности. Model View Update можно легко юнит тестить, это просто божественно, узнать методику которая позволяет тебе делать GUI приложение к которому можно писать юнит тесты. Которая позволяет сохранять состояние и легко сделать кнопку которая по желанию пользователя отправит например последние 100 состояний разработчику. Так что если пользователь найдёт баг, больше никаких мучений с воспроизведением бага, это автоматически.

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

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

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

А зачем учиться абстракция ради абстракций? Один раз понять что это и не более того

Ага, и постоянно учиться и переучиваться, разве не так устроено современная индустрия ИТ?

вы сами на данный момент создаете именно абстракцию причём с отнюдь не очевидным поведением

Очевидным. Все транслируется «в лоб» на Си. В этом меня упрекали, но я считаю это именно достоинством Метапрога.

Ибо стрелки это одно а их реализация совсем другое

Какие еще стрелки?

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

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

Вот еще немножко Ваших цитат, из них получается великолепный диалог:

– ты можешь построить простейшую паровую машину без матана, но атомоход без него уже не построить
– Атомный реактор - это почти как паровой котел, только вместо дров - таблетки с ураном/плутонием (с)@metaprog
– Если бы не заслуги Тьюринга, Шокли и прочих «прохвессоров»…
– Если б мне довелось придумывать с нуля компьютер вместо них, то я сам бы за них все что надо придумал! (с)@metaprog
– Так что там с легированием переходов в транзисторе?
– по переходам формулы, насколько я знаю, нехитрые (с)@metaprog
– Тебя попросили решение квадратного уравнения..
– Императивная логика, конечно, не айс для МАТАНА. (с)@metaprog

Занавес. А вот это

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

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

Ага, и постоянно учиться и переучиваться, разве не так устроено современная индустрия ИТ?

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

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

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

«Выносил я как-то мусорный бак. Замёрз. Опрокинул его метра за три до помойки. Минут через пятнадцать к нам явился дворник. Устроил скандал. Выяснилось, что он по мусору легко устанавливает жильца и номер квартиры.

В любой работе есть место творчеству».

С. Довлатов

Хе, щас было видео - в мск дворник на сегвее снег чистил.

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

А как лучше? Таненбаум Линусу предлагал микроядра вместо монолита, а что же предложишь из своих Сакральных Знаний ты, о Высшая Мудрость?

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

Относительно паттернов тоже сто раз говорили, но еще разок выше сказал fsb4000 тут

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

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

В продолжение предыдущего комментария

Как я вижу описание языка?

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

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

Третья глава — стандартная библиотека. Что у нас есть для ввода, вывода, работы с файлами, возможно GUI (когда устаканится), сетью (тоже когда устаканится) и др.

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

Вот, где-то так…

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

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

Профессор написал очень годную книгу по операционным системам

Листал я эту книгу. Водянистая обзорная мудня из под коня это, как и все его книги. Советую всем начинающим(не полным нулям) читать Олега Цилюрика.

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

Но да, для начала бы вообще определиться ТС что он делает, «язык» ли это, если да, то где грамматика языка?

Если это не «язык», то тогда в любом случае необходимо хотя бы четко ограничить то, что пишет hobbit и желательно это сделать с четким пониманием синтаксиса и семантики С, потому что сейчас оно генерируется в условную глобальную мусорную лапшу с кучей лишних бессмысленных переменных и семантически бессмысленных выражениях подобно пустой ветке else например. Под «четко ограничить» это обосновать и расписать во что взаимооднозначно будет транслироваться тот или иной блок при всех возможных вариантах его использования. Ну и да неплохо было бы формально описать что из себя представляет блок, а что жгутик, и как они работают.

вы хотите техническое описания

Нет конечно, до технического описания еще далече. Речь идет именно о концепции, без которой вообще то стандарт ЯП (которого хочет hobbit) создать невозможно.

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

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

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

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

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

Листал я эту книгу. Водянистая обзорная мудня из под коня это, как и все его книги

Читать не пробовал?

могу как ребёнок сказать что-то вроде: «а король-то голый».

Вот именно, что как ребенок. На аргументацию твоих знаний не хватает.

Будет ли metaprog подерживать wasm?

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

Зачем читать если картинки неинтересные?;-)

Грамматика это формальное описание языка и того что в нем есть и что из себя что представляет.

Синтаксис это уже «физическое» представление формы записи этого языка

Семантика что эта форма записи значит и делает. Это если прямо кратко и грубо.

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

Вот тсу надо какое-нибудь BNF или EBNF (любой другой попсовый сейчас аналог) показать нам если это «язык». Или признать что это все же не язык и вообще он не знает что делает.

Или признать что это все же не язык и вообще он не знает что делает.

Ну вот авторы LabVIEW, например, говорят, что у них таки язык, называется G.

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

Я сходу могу предложить несколько концепций:

1. Пытаемся задать AST какого нить ЯП, возможно кастрированного. Что то рисуем, что то текстом, что то заметаем под ковер (если это возможно). Из бонусов - все уже придумано в общем, но это скучно.

2. Просто рисуем блок-схему. Опять таки все бол-мен придумано, но это ОЧЕНЬ скучно.

3. ФП/декларативщина-стайл (я их все время путаю;-(), направленный ациклический граф (зависимостей). Есть блоки (действия) со входами и выходами, есть стрелочки, из одного выхода может идти несколько стрелочек, в один вход может приходить только одна стрелочка. По стрелочкам могут «ходить сигналы». Если у блока все зависимости разрешены (пришли сигналы на все входы) блок атомарно выполняется и отправляет сигналы по всем стрелочкам из выходов. Блок может содержать фрагмент диаграммы или текст на каком то ЯП, при этом входы/выходы проименованы (ау, ТС - мультиязычность это возможность использовать РАЗНЫЕ ЯП в разных блоках на одной диаграмме а не то что у Вас). Данные от пользователя скрыты (это детали реализации), есть только данные на входе/выходе из диаграммы (то что с-но делает сама программа).

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

Вот тсу надо … признать что это все же не язык и вообще он не знает что делает.

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

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

Прочел, и сразу вспомнился великий физик программист, поучающий необразованных дворников, хы. Вот кто реально боится хоть что то признать. Метапрог-прототип, версия 7 + графические диалоги на Метапроге (комментарий)

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

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

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

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

Это как раз самая маленькая из проблем, после распаривания текста уже не остаётся а есть какая то структура данных, в общем пофик как ее задавать…

Я в аспирантуре тоже свой ЯП для задания параметров расчетов сделал, коллеги даже пользовались… А потом мы узнали про питон.

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

Вот из-за этого тебя и называют необучаемым. Из-за воинствующего невежества.

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

Вот например, как ты собираешься без ООП писать драйвера устройств, к примеру? Драйвер в любой современной ОС — это по сути дела класс, который предоставляет методы открытия, закрытия, позиционирования, чтения, записи… И есть внутренние структуры, в которых за пределами драйвера никто лазить не должен, вот тебе и инкапсуляция. И неважно, на каком языке это написано. Хоть на ассемблере. По сути это ООП.

Но у тебя подход «я не понял, зачем это надо, значит, надо обосрать».

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