ЯП, IDE и подходы к программированию в будущем

Фактически эта тема - продолжение моей же темы, созданной ранее: О более новых парадигмах программирования, чем ООП

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

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

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

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

Ещё при разработке модели ПО разработчик должен иметь возможность быстро обнаруживать (видеть) существенные для него элементы, неважные элементы должны скрываться, а важные выделяться. Здесь у меня тоже имеется некоторое понимание (смутное пока представление).

Так вот. Я хочу какое-то накопление идей в этой теме. Есть ли какие-то интересные уже реализованные идеи на этот счет?

0

0

0

Mikhaylo, тебе сюда: https://www.linux.org.ru/forum... t/15785996

0

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

(Среда Bolt для Unity3d)

Миниатюры

 

0

Сообщение от Vourhey Вложение 1173179

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

0

Сообщение от Mikhaylo Весьма распространены

... в узких кругах?)

0

Сообщение от Mikhaylo Это какая среда разработки?

Это Ylands

0

Сообщение от Usaga ... в узких кругах?)

Точно

0

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

В этом направлении прогресс и идёт.

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

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

0

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

https://ru.wikipedia.org/wiki/ColorForth

https://ru.wikipedia.org/wiki/ДРАКОН

Вот этих двух скрестить...

Добавлено через 17 минут
https://habr.com/ru/post/179987/ -- кстати, хороший список для начального ознакомления...

0

ColorForth не видел, но смотрел ИС Дракон, своего рода доморощенный UML.

В связи с этим при создании языка ДРАКОН были выдвинуты необычные для программистов и математиков требования гуманитарного характера: - предложить эффективные средства для описания не только алгоритмов, но и структуры человеческой деятельности в любой отрасли знаний (включая бизнес-процессы); - предоставить человеку такие языковые средства, которые безальтернативно заставляют человека мыслить отчетливо, глубоко и продуктивно, а потому значительно упрощают восприятие сложных процедурных проблем и общение с коллегами. В этих условиях вероятность заблуждений, просчетов и ошибок падает, а производительность растет[6]; - облегчить межотраслевое и междисциплинарное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий; - устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей (врачами и физиками, математиками и конструкторами, биологами и экономистами и т. д.), а также программистами и теми, кто не владеет программированием[6]; - за счет использования когнитивно-эргономического подхода к проектированию (синтаксиса и семантики) языка добиться значительного улучшения качества программного обеспечения по критерию «понятность алгоритмов и программ»[21].

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

0

Да, кстати, APL с его алфавитом тоже веселая штука

0

Сообщение от Mikhaylo смотрел ИС Дракон, своего рода доморощенный UML.

Ошибся, смотрел DRAKON Editor.

Сообщение от Mikhaylo У меня цель аналогичная. Но я смотрел скриншоты и не увидел то, что я хотел бы.

Сейчас после прочитки статьи про ИС Дракон столкнулся с хорошей идеей шампура (царской дороги). Эту идею я давно вынашиваю, но она распространяется не только на императивные блок-схемы.
А ещё поймал какую-то интересную идею про силуэты, силуэтные циклы...

0

https://ru.wikipedia.org/wiki/... анный_язык

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

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

Чуточку о форте - уже одна только возможность в качестве алфавита использовать всю ascii таблицу кружила голову:

Добавлено через 16 минут
Вот еще примерчик, на этот раз Lua, это карта местности для несложной игры:

Здесь maps.interpret -- это и есть интерпретатор предметно-ориентированного представления данных.

Вот кстати еще из прошлого и форта:

И это именно программа, не текстовый подгружаемый файл... Этот дамп включается в исходник. Си-шный препроцессор имхо нервно курит.

2

APL - предшественник MATLAB... Алфавит и синтаксис, конечно, несильная сторона APL. Работа с массивами и матрицами позволит совсем уйти от циклов?

Добавлено через 6 минут

Сообщение от vantfiles Этот дамп включается в исходник.

Да, я планировал реализовать эту фишку. Для boolean, integer, double, string и прочего в языках заложена возможность задавать дефолтное значение, а для массивов - "гуляй, Вася".

Добавлено через 6 минут

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

У с++ есть возможность перегружать операторы +, -, /, *, >, <, = (и другие) под новые классы. То есть фактически это и есть заточка под предметную область?
С точки зрения графического языка эта заточка представляет собой весьма интересный инструмент??....

0

Сообщение от Mikhaylo У с++ есть возможность перегружать операторы +, -, /, *, >, <, = (и другие) под новые классы.

У Haskell и F# есть возможность объявлять свои операторы. Это лучше.
ИМХО синтаксис языка должен быть как можно более простым. В идеале в нём должны быть только функции и операторы (те же функции, но другая запись). Ну и по мелочи - объявление/связывание переменных, инициализаторы списков, префиксы/суффиксы для задания типов коллекций/переменных и т.п.

0

Я говорю совсем о другом...

я сейчас уже очень смутно помню Fortran, но помню, что там был оператор условия на меньше/больше/равно_нулю.

В языке forth такого оператора нет, но добавить в язык конструкцию вида:

не составляет труда.
причем запись будет именно такая, как я ее написал, то есть "if_x<0" и прочее - это новодобавленные конструкции языка

0

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

0

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

Добавлено через 12 минут
Я понял. В графическом языке это будет в основе - реализация паттерна MVC и новый View - это и есть ориентация на новую предметную область. Просто нужно сделать поддержку создания новых View...

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

Другие фишки, которые с трудом проглядываются в других ЯП-IDE:
1. Abstraction (абстракция) - элементы ЯП должны максимально поддерживать частичную неопределенность (незавершённость). Компилятору, конечно, такие элементы синтаксиса нисколько неинтересны, они предназначены для разработчика. Я верю, что можно уйти от некомпилируемого кода к абстрактному коду. В чем суть? В обычном языке можно забыть точку с запятой и от этого код становится некомпилируемым, я же предлагаю позволить разработчику только абстракцию - в принципе то же самое, но компилятор понимает, где эта незавершенность и примерно как ее закрыть...

2. Projection (проекция) - разработчик использует ЯП не только для того, чтобы объяснить компьютеру, какие вычисления он должен выполнить сейчас, но и для того, чтобы набрасывать план дальнейшего развития ПО. Сейчас программисты накидывают этот план (plan projection) в голове или помещают в комментариях кода списки to do и т.д. Проекция тесно связана с абстракцией.

3. Explanation (разъяснение) - благодаря высокоабстрактным конструкциям языка практически отпадет необходимость в комментировании кода (модели). Однако это не всегда верно. Ведь модель ПО не содержит информации об особенностях окружения ПО, аппаратных реализациях и т.п.

4. Task orientation (ориентация на задачу) - разработчику сложно просматривать весь код целиком, со всеми подробностями, нужно что-то скрывать или прятать. Идея шампура (царской дороги) из языка Дракон: основное ветвление программы отображается слева, вспомогательные - правее. То есть разработчик указывает, что первостепенно для задачи, а что нет. При этом задач может быть много. В помощь - уровни абстракции, слои модели ПО и маркировка важности.

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

Добавлено через 1 час 19 минут
Сейчас перечитал статьи в Википедии по DSL (Domain specific language), DDD (Domain driven development), дошел до LOP (Language oriented programming):
https://ru.m.wikipedia.org/wik... 0%B8%D0%B5

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

Противоположное мнение в этой же статье:

ЯОП <...> решает проблему сложности как фундаментальную проблему программирования[2], описанную Фредериком Бруксом в знаменитом эссе «Серебряной пули нет», из-за которой оказывается невозможно простым совершенствованием рабочего инструментария повысить производительность труда программистов даже на порядок.

Добавлено через 18 минут
Моя аргументация против устаревших утверждений Фредерика Брукса:
http://programming-lang.com/ru... 0/j18.html

Графическое программирование. Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование — применение компьютерной графики в разработке программного обеспечения. [9] Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок-схем. Ничего убедительного и удивительного из этих попыток пока не вышло, — и я уверен, не выйдет. Во-первых, как я всюду доказываю, блок-схема является весьма слабой абстракцией структуры программы. [10] Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединенных линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ. Во-вторых, сегодняшние экраны имеют слишком мало пикселов, чтобы показать целиком и с достаточным разрешением сколько-нибудь подробную схему программы. Так называемая «метафора рабочего стола» становится метафорой «сиденья самолета». Всякий, кому приходилось листать пачку бумаг, будучи стиснутым двумя корпулентными соседями, почувствует разницу: одновременно можно увидеть очень немного. Настоящий рабочий стол позволяет обозревать и произвольно выбирать множество бумаг. Более того, в порыве творчества не один программист или писатель предпочитал рабочему столу более вместительный пол. Аппаратным технологиям нужно сделать очень большой наг, чтобы предоставляемый экранами обзор был достаточным для задач проектирования программ. Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрестных ссылок переменных, потоков данных, иерархических структур данных или чего-то еще, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения. Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.

Про пиксели понятно - решаемо! Непонятно, почему решено, что все-таки текст удобнее???)))

0