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

@Mikhaylo · Регистрация: 20.09.2014

Author24 — интернет-сервис помощи студентам

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

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

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

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

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

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

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

Vourhey · 18.08.2020, 19:01

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

Vourhey · 18.08.2020, 19:04

@korvin_ · 18.08.2020, 19:34

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

@Mikhaylo · 19.08.2020, 08:09 **[ТС]**

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

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

@Mikhaylo · 19.08.2020, 08:12 **[ТС]**

Сообщение от Vourhey

Вложение 1173179

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

@Usaga · 19.08.2020, 11:26

Сообщение от Mikhaylo

Весьма распространены

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

Vourhey · 19.08.2020, 11:50

Сообщение от Mikhaylo

Это какая среда разработки?

Это Ylands

@Mikhaylo · 19.08.2020, 12:51 **[ТС]**

Сообщение от Usaga

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

Точно

@Shamil1 · 19.08.2020, 14:09

Сообщение от Mikhaylo

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

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

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

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

@vantfiles · 19.08.2020, 15:28

Сообщение от Mikhaylo

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

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

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

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

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

@Mikhaylo · 19.08.2020, 15:33 **[ТС]**

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

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

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

@vantfiles · 19.08.2020, 15:40

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

@Mikhaylo · 19.08.2020, 15:55 **[ТС]**

Сообщение от Mikhaylo

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

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

Сообщение от Mikhaylo

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

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

@vantfiles · 19.08.2020, 16:59

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

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

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

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

Код

: | ; immediate -- здесь я определил знак "|" как незначащий

: факториал -- да-да, можно и по-русски
  1 swap
  0 do
    | i * -- а здесь я его использовал для разметки цикла
    loop
;

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

Lua

require( "maps" )
 
all_maps = {}
 
local map = [[
 
TNW-[w]-[w] [.] [w]-[w]-TNE
 |       |       |       | 
[w] KZN-[w]-[w]-[w] KAZ [w]
 |           |       |   | 
[w]-[w] [d]-[d]-[d] [w]-[w]
     |   |   |   |   |     
[.] [w]-[d]-[K]-[d]-[w] [.]
     |   |   |   |   |     
[w]-[w] [d]-[d]-[d] [w]-[w]
 |   |       |           | 
[w] SKL [w]-[w]-[w]-ARS [w]
 |       |   |   |       | 
TSW-[w]-[w] [M] [w]-[w]-TSE
 
]]
 
maps.add( all_maps, maps.interpret( map ) )

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

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

Код

Dump буква_А
00 00 00 01 00 00 00 00
00 00 01 00 01 00 00 00
00 01 00 00 00 01 00 00
01 00 00 00 00 00 01 00
01 01 01 01 01 01 01 00
01 00 00 00 00 00 01 00
01 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00

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

@Mikhaylo · 19.08.2020, 20:54 **[ТС]**

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

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

Сообщение от vantfiles

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

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

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

Сообщение от vantfiles

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

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

@Shamil1 · 20.08.2020, 00:14

Сообщение от Mikhaylo

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

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

@vantfiles · 20.08.2020, 00:25

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

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

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

Код

if_x<0
...
if_x>0
...
else
...
end

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

@Shamil1 · 20.08.2020, 00:47

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

Вот это и есть DSL.

@Mikhaylo · 20.08.2020, 09:26 **[ТС]**

Как же будет выглядеть организация 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] Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединенных линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ.

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

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

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

@vantfiles 1003 / 1858 / 176 Регистрация: 07.05.2013 Сообщений: 3,894 Записей в блоге: 12
	19.08.2020, 15:40	13
	Да, кстати, APL с его алфавитом тоже веселая штука 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
		1
	ЯП, IDE и подходы к программированию в будущем 18.08.2020, 18:47. Показов 6696. Ответов 69 Метки нет (Все метки) Фактически эта тема - продолжение моей же темы, созданной ранее: О более новых парадигмах программирования, чем ООП В общем я с момента создания той темы освоил еще несколько новых для себя ЯП, немного прокачался в алгебре, компьютерной науке, машинном обучении, системной инженерии и т.п. Мое видение программирования будущего становится все более отчётливым. Итак, что я хочу придумать? По сути, новый ЯП, но тут надо сразу оговориться, что ЯП следует понимать не в узком смысле (привычные правила текстового синтаксиса языка), а в более широком смысле. То есть это должен быть программный продукт, в котором ЯП и IDE сплетаются воедино. Более близко мою идею выражают UML-редакторы. Итак, фактически я хочу, чтобы разработчик создавал модель ПО, а не программу (исходный код). Имея готовую модель ПО, легко можно автоматизировать формирование исходного кода и бинарного кода. Модель ПО - это представление кода, наиболее приспособленное к восприятию человеком. То есть фактически я предлагаю, наконец-то, при разработке ЯП не искать баланс между простотой понимания кода человеком и простотой перевода кода в машинный код, понятный компьютеру. Я считаю, что следует бросить все силы на простоту работы разработчика с кодом. Итак, первая идея - вместо кода разработчик создает модель ПО. Модель ПО должна достаточно точно выражать поведение программы. Но тут надо оговориться, что это не всегда правда. Иногда можно поступиться с этим, и это должно решаться разработчиком. Тут есть несколько хороших идей у меня. Частный случай представления модели ПО - набор последовательно выполняемых инструкций, записанных сверху вниз текстовым языком, не лишён смысла! Обозначать переменные, функции с помощью набора букв латинского алфавита без использования пробелов - это тоже допускается. Но всегда следует думать о более привычных человеку представлениях! Я хочу использовать в качестве элементов синтаксиса языка гораздо более широкий диапазон способов передачи данных (текст и графические примитивы - прямоугольники, окружности, стрелки и т.п., а также положение, размер, цвет, форма, толщина текста и графических примитивов). Ещё при разработке модели ПО разработчик должен иметь возможность быстро обнаруживать (видеть) существенные для него элементы, неважные элементы должны скрываться, а важные выделяться. Здесь у меня тоже имеется некоторое понимание (смутное пока представление). Так вот. Я хочу какое-то накопление идей в этой теме. Есть ли какие-то интересные уже реализованные идеи на этот счет? 0

Vourhey Почетный модератор 7393 / 2639 / 281 Регистрация: 29.07.2006 Сообщений: 13,696
	18.08.2020, 19:01	2
	0

Vourhey Почетный модератор 7393 / 2639 / 281 Регистрация: 29.07.2006 Сообщений: 13,696
	18.08.2020, 19:04	3
	0

@korvin_ 4485 / 2720 / 485 Регистрация: 28.04.2012 Сообщений: 8,585
	18.08.2020, 19:34	4
	Mikhaylo, тебе сюда: https://www.linux.org.ru/forum... t/15785996 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	19.08.2020, 08:09 [ТС]	5
	Весьма распространены и широко известны графические языки функциональной парадигмы: (Среда Bolt для Unity3d) Миниатюры 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	19.08.2020, 08:12 [ТС]	6
	Сообщение от Vourhey Вложение 1173179 Попытка улучшить императивную парадигму. Ужасно, конечно выглядит. Проще не стало. Это какая среда разработки? 0

@Usaga 12061 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,559
	19.08.2020, 11:26	7
	Сообщение от Mikhaylo Весьма распространены ... в узких кругах?) 0

Vourhey Почетный модератор 7393 / 2639 / 281 Регистрация: 29.07.2006 Сообщений: 13,696
	19.08.2020, 11:50	8
	Сообщение от Mikhaylo Это какая среда разработки? Это Ylands 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	19.08.2020, 12:51 [ТС]	9
	Сообщение от Usaga ... в узких кругах?) Точно 0

@Shamil1 Модератор 3051 / 2193 / 459 Регистрация: 26.03.2015 Сообщений: 8,469
	19.08.2020, 14:09	10
	Сообщение от Mikhaylo То есть фактически я предлагаю, наконец-то, при разработке ЯП не искать баланс между простотой понимания кода человеком и простотой перевода кода в машинный код, понятный компьютеру. Я считаю, что следует бросить все силы на простоту работы разработчика с кодом. В этом направлении прогресс и идёт. Что касается графического представления, это зависит от типа и структуры программы. Желательно выделять "чистую" часть (детерминированные функции без побочных эффектов). Остальную часть можно, например, представить в виде состояния и событий, которые меняют это состояние. Не факт, что графическое представление ускоряет работу. Скорее всего, ускоряет для новичков и замедляет для опытных пользователей. 0

	20.08.2020, 09:26

Опции темы

@vantfiles 1003 / 1858 / 176 Регистрация: 07.05.2013 Сообщений: 3,894 Записей в блоге: 12
	19.08.2020, 15:28	11
	Сообщение от Mikhaylo Я хочу использовать в качестве элементов синтаксиса языка гораздо более широкий диапазон способов передачи данных https://ru.wikipedia.org/wiki/ColorForth https://ru.wikipedia.org/wiki/ДРАКОН Вот этих двух скрестить... Добавлено через 17 минут https://habr.com/ru/post/179987/ -- кстати, хороший список для начального ознакомления... 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	19.08.2020, 15:33 [ТС]	12
	ColorForth не видел, но смотрел ИС Дракон, своего рода доморощенный UML. В связи с этим при создании языка ДРАКОН были выдвинуты необычные для программистов и математиков требования гуманитарного характера: - предложить эффективные средства для описания не только алгоритмов, но и структуры человеческой деятельности в любой отрасли знаний (включая бизнес-процессы); - предоставить человеку такие языковые средства, которые безальтернативно заставляют человека мыслить отчетливо, глубоко и продуктивно, а потому значительно упрощают восприятие сложных процедурных проблем и общение с коллегами. В этих условиях вероятность заблуждений, просчетов и ошибок падает, а производительность растет[6]; - облегчить межотраслевое и междисциплинарное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий; - устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей (врачами и физиками, математиками и конструкторами, биологами и экономистами и т. д.), а также программистами и теми, кто не владеет программированием[6]; - за счет использования когнитивно-эргономического подхода к проектированию (синтаксиса и семантики) языка добиться значительного улучшения качества программного обеспечения по критерию «понятность алгоритмов и программ»[21]. У меня цель аналогичная. Но я смотрел скриншоты и не увидел то, что я хотел бы. 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	19.08.2020, 15:55 [ТС]	14
	Сообщение от Mikhaylo смотрел ИС Дракон, своего рода доморощенный UML. Ошибся, смотрел DRAKON Editor. Сообщение от Mikhaylo У меня цель аналогичная. Но я смотрел скриншоты и не увидел то, что я хотел бы. Сейчас после прочитки статьи про ИС Дракон столкнулся с хорошей идеей шампура (царской дороги). Эту идею я давно вынашиваю, но она распространяется не только на императивные блок-схемы. А ещё поймал какую-то интересную идею про силуэты, силуэтные циклы... 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	19.08.2020, 20:54 [ТС]	16
	APL - предшественник MATLAB... Алфавит и синтаксис, конечно, несильная сторона APL. Работа с массивами и матрицами позволит совсем уйти от циклов? Добавлено через 6 минут Сообщение от vantfiles Этот дамп включается в исходник. Да, я планировал реализовать эту фишку. Для boolean, integer, double, string и прочего в языках заложена возможность задавать дефолтное значение, а для массивов - "гуляй, Вася". Добавлено через 6 минут Сообщение от vantfiles Вот этот подход мне кажется перспективным. То есть - язык, позволяющий затачиваться под предметную область. У с++ есть возможность перегружать операторы +, -, /, *, >, <, = (и другие) под новые классы. То есть фактически это и есть заточка под предметную область? С точки зрения графического языка эта заточка представляет собой весьма интересный инструмент??.... 0

@Shamil1 Модератор 3051 / 2193 / 459 Регистрация: 26.03.2015 Сообщений: 8,469
	20.08.2020, 00:14	17
	Сообщение от Mikhaylo У с++ есть возможность перегружать операторы +, -, /, *, >, <, = (и другие) под новые классы. У Haskell и F# есть возможность объявлять свои операторы. Это лучше. ИМХО синтаксис языка должен быть как можно более простым. В идеале в нём должны быть только функции и операторы (те же функции, но другая запись). Ну и по мелочи - объявление/связывание переменных, инициализаторы списков, префиксы/суффиксы для задания типов коллекций/переменных и т.п. 0

@vantfiles 1003 / 1858 / 176 Регистрация: 07.05.2013 Сообщений: 3,894 Записей в блоге: 12
	20.08.2020, 00:25	18
	Я говорю совсем о другом... я сейчас уже очень смутно помню Fortran, но помню, что там был оператор условия на меньше/больше/равно_нулю. В языке forth такого оператора нет, но добавить в язык конструкцию вида: Код if_x<0 ... if_x>0 ... else ... end не составляет труда. причем запись будет именно такая, как я ее написал, то есть "if_x<0" и прочее - это новодобавленные конструкции языка 0

@Shamil1 Модератор 3051 / 2193 / 459 Регистрация: 26.03.2015 Сообщений: 8,469
	20.08.2020, 00:47	19
	Любой текст может оказаться кодом на Forth, который делает именно то, что написано в тексте. Вот это и есть DSL. 0

@Mikhaylo 645 / 521 / 72 Регистрация: 20.09.2014 Сообщений: 3,353
	20.08.2020, 09:26 [ТС]	20
	Как же будет выглядеть организация 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