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

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

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

Где скачать?

люто-бешенно плюсую этот коммент от собрата anonymous!

В разработке. Пока только обсуждение плюс консультации по разработке.

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

Лучше бы строки в стандартной сишной библиотеке были представлены как структуры из указателя на начало массива байтов и длину массива. Функции типа fwrite, например, позволяют работать со строкой (массивом байтов), содержащей любые байты, в том числе 0, только надо указывать длину массива. Кстати, есть пример в первой теме.

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

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

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

Примерно так же будет и с Метапрогом.

А с «тупой» программой (компилятором/IDE) пиши только то, что она поймет и ни на буковку не ошибайся

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

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

Есть вещи, которые действительно лучше представимы в графике: сетевые и большие иерархические структуры. Например, диаграммы классов и компонентов в том же UML. Да и отступы в тексте программы — это графический элемент. А тащить графику туда, где текст гораздо короче и однозначнее — это перебор.

Я за дополнение текста графикой, а не за вытеснение текста там, где он работает.

Кстати, как со строками в Расте? Строка - фундаментальный тип или структура из указателя на массив и числа-длины массива?

«Умных» компиляторов нет.

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

Общение с людьми тем и отличается от общения с машиной — человеку дозволено тебя неверно понимать (что, кстати, очень часто и случается, и ведёт к бедам, как несущественным, так и весьма серьёзным). Если бы человек по природе своей, не поняв, что имеется в виду на 100% переспрашивал, как это делает «тупой» компилятор, и переспрашивал до тех пор, пока не будет на 100% понимать, что имел в виду собеседник, мир был бы лучше, а не хуже.

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

Не совсем соглашусь с тем, что люди самостоятельны. Большинство, к сожалению, так или иначе рабы. Эволюционируют лишь формы рабства, сегодня многие рабы уже считают себя свободными людьми:)

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

когда компилятор ругается, он по сути говорит: «Хозяин, я не понял тебя вот здесь и вот здесь!» Он сам тебя подталкивает к правильному решению. Ошибки компилятора — это великое благо, это шаг на пути к уверенности, что ты сказал именно то, что хотел.

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

Кстати, сам программируешь на Си?

«Умных» компиляторов нет.

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

Общение с людьми тем и отличается от общения с машиной — человеку дозволено тебя неверно понимать (что, кстати, очень часто и случается, и ведёт к бедам, как несущественным, так и весьма серьёзным). Если бы человек по природе своей, не поняв, что имеется в виду на 100% переспрашивал, как это делает «тупой» компилятор, и переспрашивал до тех пор, пока не будет на 100% понимать, что имел в виду собеседник, мир был бы лучше, а не хуже.

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

Why OO was popular?

Reason 1 - It was thought to be easy to learn. Reason 2 - It was thought to make code reuse easier. Reason 3 - It was hyped. Reason 4 - It created a new software industry.

I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

This is is the real driving force behind OOPs.

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

Общение с людьми тем и отличается от общения с машиной — человеку дозволено тебя неверно понимать (что, кстати, очень часто и случается, и ведет к срачам на ЛОРе).

FTFY

FTFY

JAFA

В основном, на C++. На чистом си писал мало, в основном патчил. Много писал на Дельфях и вообще на объектном паскале. Было некоторое количество ассемблера и даже форта, но это уже совсем давно.

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

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

Жалко только несколько непрактичен он. Так что я ухожу на раст.

%)

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

Ну так реально проще ж чем на С писать %) Но там надо было сразу wasm делать.

А с «тупой» программой (компилятором/IDE) пиши только то, что она поймет и ни на буковку не ошибайся, и большие буквы с маленькими спутать не смей, а то будут баги (редкое исключение - файловая система Windows).

И это же очень хорошо – позволяет избежать ошибок. Каждая ошибка в compile-time – это отсутствие потенциальной ошибки при КАЖДОМ запуске программы. Графика не изменит этого принципа.

Ну как там чатик?

Графика уберет это:

и ни на буковку не ошибайся, и большие буквы с маленькими спутать не смей

На этой неделе занимался инлайн-функциями и управлением зависимостями (словом, допиливал сам прототип метапрога на Лабвью). Чатиком, думаю, уже на этой неделе займусь.

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

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

Кстати, интересная вещь:

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

Клиент для телефонии через тор. Сделан на чистом Си!

насколько я знаю раст - единственный язык, позволяющий выразить понятие владения объектом и время его жизни непосредственно на уровне языка с гарантией соблюдения правил обращения к памяти

В C++ экспериментируют с лайфтаймами на аннотациях, у майкрософта есть уже прототип чекера. Вероятно, допилят, это многим нужно.

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

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

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

Графика упрощает и разбиение, и чтение кода.

Кстати, как со строками в Расте?

Подобно C++ есть 2 вида строк, примитивная строка и класс с изменяемым размером и прочими плюшками. Вот только в отличии от си примитивная строка - это та самая пара из указателя и длины (она используется в основном для статических строковых литералов и указания на подстроку другой строки без копирования). Ну и еще там навязывается соблюдение валидности utf8 (для набора байт есть отдельные типы), хотя есть возможность обойти проверку и собрать невалидную строку (если есть лицензия на огнестрел, стрелять в свою ногу не возбраняется)

лайфтаймы опциональны и реализуются внешним чекером

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

бороться с чекером постоянно.

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

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

Примерно так же будет и с Метапрогом.

Так зачем было брать в основу си, если ты всеравно надергаешь фишек из других языков? Знаем мы моду писать усовершенствованные си. Если самый лучший представитель таковых С++, то каковы тогда остальные лучше и не вспоминать. Я считаю, что надо либо брать за основу нечто, более близкое к тому, что хочешь получить, либо разрабатывать с 0, но не стесняясь копировать отдельные фишки. Единственный смысл делать улучшенный си - забота об интеграции с другим си кодом, но как показала практика, интегрироваться с си можно и не заморачиваясь похожестью на него, а с плюсами интегрироваться как было неудобно, так и осталось...

Мне IDE тоже очень наглядно показывает, где ошибка. Прям сразу, когда печатаешь и ошибаешься – ошибка видна. К тому же та же самая IDE чаще всего подсказывает название нужного символа сама, и достаточно просто нажать TAB.

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

Си тут в роли простого «ассемблера». При этом с указателями и мощной системой типов.

Вот, кстати, пример дебага. Не подключил один ввод - обводит функцию красным.

https://i.postimg.cc/1XGPqGtc/image.png

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

Мне IDE тоже очень наглядно показывает, где ошибка.

А в таком?

char str_arr[] = {
  "hello",
  "world",
  "apple"
  "microsoft",
  "linux"
};

мощной системой типов.

Ха-ха, ха-ха-ха.

указателями

Они и в ассемблере есть.

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

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

Не так написал) Замени там.

const char *str_arr[] = { ... };

Ха-ха, ха-ха-ха.

Аналогов нет! На самом деле реально мощно, можно обойтись без рунтайма!

Они и в ассемблере есть.

Не крошплатформенно.

Аналогов нет! На самом деле реально мощно, можно обойтись без рунтайма!

Что именно вы понимаете под «обойтись без рантайма»? И чему там «аналогов нет»? Раст тоже умеет в типы и тоже почти «без рантайма».

У раста даже ffast-math не работает! Без std:: он ничто!

Так что с твоим ИДЕ и этим?

const char *str_arr[] = {
  "hello",
  "world",
  "apple"
  "microsoft",
  "linux"
};

Ничего %) А ведь там будут элементы:

"hello"
"world"
"applemicrosoft"
"linux"

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

Статанализ находит.

Ну это уже дополнительная тулза, нужны ли вообще текстовые языки если они позволяют такое допустить?

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

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

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

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

https://pastebin.com/SWJJwvvC

Скрины подфункций делать пока лень (автоскринер тоже скорее всего сделаем уже в «настоящем» метапроге, а не прототипе).