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

В Хаскеле типы строгие и сильные (т.е. грань стирается), но указывать их почти никогда не нужно (обычно достаточно для top-level bindings указать, всё остальное выведется само). Вы про такой подход или про duck typing? Если duck typing, то нафиг надо.

Алсо, в Rust статанализ форсится компилятором.

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

Нет, это напрочь убивает CI/CD. Лучше без дополнительных каналов, а просто компилятор выдает ошибки и ворнинги, а программист их исправляет (или возможно компилятор их сам исправляет прямо в коде, как rust)

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

Linux победил винду на серверах именно благодаря настройке через текст

Винда тоже умеет запускаться с голой консолью.

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

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

Сервера серверами. К ним надо тоже прикручивать графический интерфейс, но уже на стороне настройщика (вместо консольного ssh).

Вот как выглядит компилятор в Лабвью

http://www.ni.com/tutorial/11472/en/

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

Стат анализ выявляет реальные ошибки, а раст просто запрещает то, что не было доказано, что оно безопасно. Мне не нравится, когда существуют корректные программы, которые не проходят проверку компилятора. Да, я понимаю, что ограничения могут быть полезны со стилистической точки зрения, вот только проверять стилистику кода следует отдельно, а не в рамках type/lifetime чекинга и дать возможность временно игнорировать проблемы. В текстовых языках в принципе можно потерпеть злобный компилятор, потому что залезший в текст изначально является красноглазым гиком, но если засунуть такой в графический ЯП, то у него просто не останется узеров.

Если duck typing, то нафиг надо.

Дело не в рантайм типе, а в возможности описывать dependent типы, такие как тип функции printf. Можно было бы использовать dependent type язык для этого, но программировать реальные задачи там слишком сложно. Не думаю, что тактики автоматического вывода доказательств как в петухе/идрисе достаточно упростят процесс программирования. Вот и получается пример того, как же неудобно использовать формальные типовые системы. В хаскеле отказались от dependent type и пытаются догнать возможности расширениями. Итого получается дичайший лес из фич тоже наглядно демонстрирующий недостатки формальных типовых систем как таковых. Невозможно найти компромисс между формальностью и удобством

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

Я вот printf вообще не собираюсь использовать в своих диаграммах. Форматированые строки будут формироваться через графику, будут свои функции. Роль управляющих символов (типа %«\'*) будет исключена.

А что за dependent type?

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

Опять же, бинарный формат ломает VCS.

Пока что не увидел доказательств неудобства, увидел «я думаю». А я вот думаю (и убедился на собственном опыте), что формальный анализ удобнее fuzzy.

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

А что за dependent type?

Ну блин, писать ЯП не зная матана... Человечество давно пытается стереть грань между рантаймом и компилтаймом позволяя отложить часть возни с типами на рантайм. Но обычно получается пятая нога у коровы. Посему умные люди решили зайти с другой стороны изначально отказавшись от разделения понятий на значение и тип. Получилось компактное исчисление конструкций, в котором отношение что-то имеет какой-то тип осталось, но множества объектов которые могут иметь тип и объектов которые могут быть для кого-то типом совпадают (ну или почти совпадают, я точно не скажу). Ну вобщем суть в том, что при описании типов можно использовать значения (аля тип вектор длины N), а в переменные можно присваивать типы (например для полиморфного поведения объектов). Все конечно замечательно, но всплывают много нюансов, тонна разной мишуры, которую приходится описывать, чтобы тайпчекер мог быть уверен в корректности программы. Зато выразительные возможности типов позволяют не только убедиться, что она не упадет, а еще убедится, что она не зависнет и выдаст ожидаемый результат. Хотя опять же, вопрос описания ожиданий результата - та еще хрень. Я, например, так и не осилил написать сортировку, которая скомпилится только в том случае, если её код реально сортирует.

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

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

На чем писали сортировку? И что именно у вас не получилось?

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

Здесь точно не тот случай. ОП хочет написать по сути динамически типизированный язык поверх сишечки.

Вот пробовал себя в роли журналиста в мире кодинга https://q0tw4.livejournal.com/20198.html

Сама сортировка получилась без проблем. А вот верификация её правильности так и осталась в планах на будущие статьи

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

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

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

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

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

Ну блин, писать ЯП не зная матана

Я с матаном не очень дружу. На всякие незнакомые заумные формулировочки так и хочется выругаться матом.

Насколько я понял, речь идет о полиморфизме. Например, есть функция «суммировать». Она принимает и знаковые 32-битные, и беззнаковые 8-битные, и флоаты, в общем - все числовые типы. Верно?

В таком виде полиморфизм я уже фактически воплотил в своем прототипе. Типы объединяются в категории. Беззнаковые (8, 16, 32, 64, 128-битные), знаковые (так же), целые (знаковые и беззнаковые), дроби (32, 64, 128-битные с плавающей запятой), числа (целые и дроби).

https://postimg.cc/2q2vK8Jw

На картинке видно, что беззнаковые темно-синие, знаковые - голубые, дроби - оранжевые. Если цвет не задан явно, он наследуется автоматически.

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

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

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

Чем питон лучше Си?

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

Графические (даже не языки, а среды) программирования на первый взгляд сложнее. Но это если их писать в тексте. Вот я сейчас делаю прототип Метапрога на графическом Лабвью, что уже упрощает работу для меня, не владеющего текстовыми языками и нежелающего курить тонны англоязычных мануалов. Теперь начинаю делать Метапрог «сам на себе» (уже есть первые пока простые примеры, корректно компилирующиеся в Си и бинарники).

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

Как показала практика, ваши схемки только вам и понятны. Так что нет, ни разу не проще.

Условный выбор все равно не совсем динамический. Он зависит от «выбирающего» значения. Скорее всего, на уровне Си это будет просто структура из выбирающего значения и юниона из выбираемых типов. Структура и юнион - все в рамках Си. Выбирающий тип будет использоваться в switch+case структурах.

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

Графические (даже не языки, а среды) программирования на первый взгляд сложнее.

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

Условный выбор - вообще отдельная песня. Вот например что, если я хочу, чтоб у меня компилился (и тайпчекался) вот такой код

void f1(int) {}
void f2(int, int) {}

void main() {
  const char c = getch();
  auto f;
  if (c == '1')
  {
    f = &f1;
  }
  else
  {
    f = &f2;
  }

  int x = getInt();
  if (c == '1')
  {
    f(x);
  }
  else
  {
    f(x, 2);
  }
}

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

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

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

Хорошо. Тогда я открываю вашу софтину и сразу (ничего не рисуя и не дописывая) тыкаю: «Скомпилировать». Что спросит у меня компилятор? При правильной реализации (с теорией разума) компилятор спросит «что ты хочешь сделать» и после этого по этому запросу сам сделает всё, что надо. Пока это не так – вопросы компилятора в итоге сведут программирование с его помощью к обычному программированию в IDE, где редактор подчеркивает непонятные места.

Ну так я и хочу получить обычное программирование в ИДЕ. Только в виде схем, которые понятнее, чем текст. Интерактивность - не фича системы, а только способ решения проблем, которые приводят к непопулярности графических сред. Цена, которую приходиться платить за улучшение того, что есть.

Схемы далеко не всегда понятнее, чем текст. Если бы схемы были действительно понятнее, всё человечество сейчас бы писало пиктограммами, причем без абстракций (абстракции над пиктограммами – это и есть текст). Это очевидно не так.

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

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

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

Зависимые типы... Это простые типы + проверки к переменным. К примеру создаешь тип NonZeroInt

typedef int (value > 0) NonZeroInt;

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

Винда хороша именно тем, что ей проще пользоваться.

Враки. ХОРОШИЙ GUI удобнее лишь тем, что разгружает память, освобождая от необходимости помнить наборы ключей к и наборы команд.

Удобный GUI ещё позволяет полноценно управлять с клавиатуры.

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

Последний пример: БД с СУБД на основе ВыжралФоксПро на Винде. Её периодически надо «чистить», но не удаляя записи, а помечая их как «мусор» («не отображать»). Так вот, как я понимаю, sql-запросом легко и быстро по регулярному выражению можно отобрать лишь нужные записи и, если в поле «количество» не нуль, пометить их «мусор».

Но увы, CLI-интерфейса к БД нет, потому приходится РУКАМИ и глазами просматривать БД, вызывать кнопочкой форму редактирования записи, мышкой ставить галочку и мышкой жмакать кнопочку «Записать», т.к. кнопка клавы «Ентер» совсем не завершает редактирование, а в цикле переключает на следующее редактируемое поле.

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

Точно в том же виде можно написать только с Duck typing.

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

f1 :: Int -> IO ()

f2 :: Int -> Int -> IO ()

main = do
  c <- getChar
  let f = if c == '1' then Left f1 else Right f2
  i <- readLn
  case f of 
    Left a -> a i
    Right a -> a i 2

Если не ошибаюсь, должно работать

Ну так я тоже всеми руками за, но тут же предлагается вообще отказ от текста (вернее сказать, полный отрыв от него). Уже человек 5 сказали ОПу, что нужно выбрать нишу, в которой графическое программирование удобно и привычно, и потом (при желании и возможности) пытаться сделать что-то более общее.

Кстати, для раста есть (если не ошибаюсь) LSP, так что можно писать в емаксе с lsp-mode + rust-mode