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

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

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

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

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

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

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

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

0

Сообщение от Mikhaylo текст удобнее

Возьмем три языка - С, Lisp, Prolog - и попробуем представить их в виде "прямоугольничков со стрелочками".

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

PS:

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

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

0

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

На все можно придумать квадратики со стрелками.) Lisp - это функциональная парадигма, скриншоты этой парадигмы приводили... Пролог, у него там логические отношения - вот тебе стрелка, осталось только понять, что там представляет квадратик - предикат?..

0

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

ИМХО графические языки программирования бесперспективны. Проще читать код, чем картинки разглядывать. Даже для GUI удобнее редактировать разметку, чем пользоваться графическими редакторами (дизайнерами форм).

0

Сообщение от Shamil1 Даже для GUI удобнее редактировать разметку

Вы координаты элементов интерфейса на форме в голове рассчитываете?

0

Сообщение от vantfiles Вы координаты элементов интерфейса на форме в голове рассчитываете?

Обычно плохо использовать фиксированные координаты элементов. Ведь размер окна и разрешение экрана обычно неизвестны. Позиция элементов обычно задётся с помощью margin, padding, floating, docking и т.п.

0

Сообщение от Shamil1 Даже для GUI удобнее редактировать разметку, чем пользоваться графическими редакторами (дизайнерами форм).

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

0

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

Даже когда положение (и даже наличие) элементов на форме зависит от размера экрана?

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

з.ы. Можно сделать голосовалку "пользуетесь ли Вы графическими редакторами для редактирования html/xaml экранных форм?"

0

Сообщение от Shamil1 как Ваш графический редактор догадается, Вы хотите переместить его на конкретное место (с конкретными координатами) или просто хотите, чтобы он отображался после некого другого элемента

Через опции, разумеется. Причем можно накидать элементов, потом выделить все - и указать к примеру привязку к левому краю.

Добавлено через 3 минуты
Особенно весело будет менять в исходнике выравнивание части элементам формы, если вдруг окажется, что надо.

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

0

В визио работал как в графической чертилке. Может проще карандашом на бумаге?

0

Сообщение от vantfiles Особенно весело будет менять в исходнике выравнивание части элементам формы, если вдруг окажется, что надо.

Это легко сделать. Либо в стиле поменять, либо новый стиль добавить (не трогая разметку). В крайнем случае, поменять/добавить класс контекстной заменой.

0

Сообщение от Shamil1 Даже когда положение (и даже наличие) элементов на форме зависит от размера экрана?

Да.

Если под разные размеры нужна разная разметка, то создаются разные разметки (например, приложения для iPhone/iPad в XCode). Это лучше и удобней, чем раскиданные по одному файлу разметки условные конструкции, а ля каша из #ifdef в Сишном коде, вместо которой гораздо лучше был бы вынос платформозависимого кода в отдельные файлы, как это сделано, например, в Plan 9 C и Go.



Если речь резиновость, то layout-менеджеры прекрасно и удобно раскидываются и в визуальном дизайнере (например Swing UI designer в IDEA, да и, думаю в любом другом дизайнере всё с этим ОК), не нужно мудохаться с разными CSS-параметрами, подбирая нужную их комбинацию, чтобы div был расположен как тебе нужно. Это отдельная боль.

Сообщение от Shamil1 Посмотрите, например, разметку этого форума.

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

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

Сообщение от Shamil1 Когда Вы перемещаете некий элемент в дизайнере, как Ваш графический редактор догадается, Вы хотите переместить его на конкретное место (с конкретными координатами) или просто хотите, чтобы он отображался после некого другого элемента?

Ну попробуй Swing UI Designer в IDEA.

Сообщение от Shamil1 Можно сделать голосовалку "пользуетесь ли Вы графическими редакторами для редактирования html/xaml экранных форм?"

Не надо HTML сюда подмешивать, HTML создан для разметки документов, для него нет нормальных визуальных редакторов (были попытки, но провалилсь), потому что он совершенно не подходит для UI: одни сплошные div, да span, о смысле которых визуальному редактору пришлось бы только гадать, в отличие от специализированных разметок для UI.

0

Сообщение от Mikhaylo В визио работал как в графической чертилке. Может проще карандашом на бумаге?

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

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

0

Понятно, что текстовое представление универсально.
Однако есть как минимум три примера, где графическое выигрывает у текстового:

Функциональные схемы САУ (системы автоматического управления)
Диаграммы состояний конечных автоматов
SCADA-системы

0

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

0

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

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

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

Графические языки пытаются внедрить с момента появления дисплеев. Безрезультатно.
Слишком рыхлое представление программы получается. Текстовое представление компактнее.
А увеличение кол-ва пикселей что бы дало? Если увеличить их плотность на мм, то программист глаза посадит. А если превратить экран в сферу что бы программист висел внутри и крутил башкой как сова ... что то меня такое программирование не впечатляет.

1

имхо Даже просто (детальная) схема связей между классами бесполезна. У меня у некоторых свойств/методов 100+ использований по проекту. Если их все отобразить графически, то это не будет наглядно (лес стрелок).

Добавлено через 5 минут
Да и несколько тысяч классов на одной диаграмме тоже бессмысленно отображать.

0

Вы разве не испытываете лес текста?

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

0

Сообщение от Shamil1 схема связей между классами

не прослеживаю связь с GPL, да, это пример неудачного использования визуализации.

Добавлено через 2 минуты
GPL -- Graphical Progrgamming Language или VPL -- Visual Progrgamming Language, а то еще возникнет путаница...

Добавлено через 20 минут
Есть другой пример, фирма, в которой я работал, разрабатывала БД для крупной корпорации. Количество таблиц в какой-то момент перевалило за 1000 и несмотря на попытки декомпозиции, в какой-то момент группа разработчиков перестала контролировать всю эту массу.

Поступили просто - не поленились, отрисовали полную схему, арендовали плоттер A0 - и распечатали ее.

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

Добавлено через 32 минуты
PS: из известных мне примеров VPL рекомендую посмотреть HiAsm.

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

"HiAsm является практическим примером реализации подхода модель-ориентированной архитектуры, также называемого «разработкой от модели». Значимость данного подхода состоит в абстрагировании от платформ и архитектур поставщиков аппаратного и системного программного (математического) обеспечения."

Home, sweet home:

https://hiasm.com/

1

Сообщение от Mikhaylo А я уверен, что текст выигрывает лишь в популярности, но нисколько в удобстве.

А популярности без каких-то серьёзных преимуществ не бывает.

1

Сообщение от Shamil1 Да и несколько тысяч классов на одной диаграмме тоже бессмысленно отображать.

На одной и не нужно, нужны разноуровневые отображения. =/

Сообщение от Mikhaylo Вы разве не испытываете лес текста?

Нет.

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

Попытайся лучше сформулировать как выглядел бы diff двух коммитов.

0