645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
1 | |
ЯП, IDE и подходы к программированию в будущем18.08.2020, 18:47. Показов 6696. Ответов 69
Метки нет (Все метки)
Фактически эта тема - продолжение моей же темы, созданной ранее: О более новых парадигмах программирования, чем ООП
В общем я с момента создания той темы освоил еще несколько новых для себя ЯП, немного прокачался в алгебре, компьютерной науке, машинном обучении, системной инженерии и т.п. Мое видение программирования будущего становится все более отчётливым. Итак, что я хочу придумать? По сути, новый ЯП, но тут надо сразу оговориться, что ЯП следует понимать не в узком смысле (привычные правила текстового синтаксиса языка), а в более широком смысле. То есть это должен быть программный продукт, в котором ЯП и IDE сплетаются воедино. Более близко мою идею выражают UML-редакторы. Итак, фактически я хочу, чтобы разработчик создавал модель ПО, а не программу (исходный код). Имея готовую модель ПО, легко можно автоматизировать формирование исходного кода и бинарного кода. Модель ПО - это представление кода, наиболее приспособленное к восприятию человеком. То есть фактически я предлагаю, наконец-то, при разработке ЯП не искать баланс между простотой понимания кода человеком и простотой перевода кода в машинный код, понятный компьютеру. Я считаю, что следует бросить все силы на простоту работы разработчика с кодом. Итак, первая идея - вместо кода разработчик создает модель ПО. Модель ПО должна достаточно точно выражать поведение программы. Но тут надо оговориться, что это не всегда правда. Иногда можно поступиться с этим, и это должно решаться разработчиком. Тут есть несколько хороших идей у меня. Частный случай представления модели ПО - набор последовательно выполняемых инструкций, записанных сверху вниз текстовым языком, не лишён смысла! Обозначать переменные, функции с помощью набора букв латинского алфавита без использования пробелов - это тоже допускается. Но всегда следует думать о более привычных человеку представлениях! Я хочу использовать в качестве элементов синтаксиса языка гораздо более широкий диапазон способов передачи данных (текст и графические примитивы - прямоугольники, окружности, стрелки и т.п., а также положение, размер, цвет, форма, толщина текста и графических примитивов). Ещё при разработке модели ПО разработчик должен иметь возможность быстро обнаруживать (видеть) существенные для него элементы, неважные элементы должны скрываться, а важные выделяться. Здесь у меня тоже имеется некоторое понимание (смутное пока представление). Так вот. Я хочу какое-то накопление идей в этой теме. Есть ли какие-то интересные уже реализованные идеи на этот счет?
0
|
18.08.2020, 18:47 | |
Ответы с готовыми решениями:
69
obj\Debug\IDE.o||In function `Z11OpenProjectv':| C:\tsserver\Projects\cpp\codeblocks\MyComp\IDE\IDE\IDE.cpp|2 36|undefined reference to `GetOpenFileNam каким образом пожна подключить на мать с 2 IDE выходами и 2 SATA 3 жестких диска IDE и 2 CD-ROM IDE? Новая мать не видит ide ЖД и ide привод, проблема в Sata - Ide контроллере? C:\tsserver\Projects\cpp\codeblocks\MyComp\IDE\IDE\IDE.cpp|1 5|error: 'InitApplication' was not declared in this scope| |
4485 / 2720 / 485
Регистрация: 28.04.2012
Сообщений: 8,585
|
|
18.08.2020, 19:34 | 4 |
Mikhaylo, тебе сюда: https://www.linux.org.ru/forum... t/15785996
0
|
645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
19.08.2020, 08:09 [ТС] | 5 |
Весьма распространены и широко известны графические языки функциональной парадигмы:
(Среда Bolt для Unity3d)
0
|
645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
19.08.2020, 08:12 [ТС] | 6 |
Попытка улучшить императивную парадигму. Ужасно, конечно выглядит. Проще не стало. Это какая среда разработки?
0
|
12061 / 8369 / 1280
Регистрация: 21.01.2016
Сообщений: 31,559
|
|
19.08.2020, 11:26 | 7 |
0
|
645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
19.08.2020, 12:51 [ТС] | 9 |
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
19.08.2020, 14:09 | 10 |
В этом направлении прогресс и идёт.
Что касается графического представления, это зависит от типа и структуры программы. Желательно выделять "чистую" часть (детерминированные функции без побочных эффектов). Остальную часть можно, например, представить в виде состояния и событий, которые меняют это состояние. Не факт, что графическое представление ускоряет работу. Скорее всего, ускоряет для новичков и замедляет для опытных пользователей.
0
|
19.08.2020, 15:28 | 11 |
https://ru.wikipedia.org/wiki/ColorForth
https://ru.wikipedia.org/wiki/ДРАКОН Вот этих двух скрестить... Добавлено через 17 минут https://habr.com/ru/post/179987/ -- кстати, хороший список для начального ознакомления...
0
|
645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
19.08.2020, 15:33 [ТС] | 12 |
ColorForth не видел, но смотрел ИС Дракон, своего рода доморощенный UML.
0
|
645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
19.08.2020, 15:55 [ТС] | 14 |
Ошибся, смотрел DRAKON Editor.
Сейчас после прочитки статьи про ИС Дракон столкнулся с хорошей идеей шампура (царской дороги). Эту идею я давно вынашиваю, но она распространяется не только на императивные блок-схемы. А ещё поймал какую-то интересную идею про силуэты, силуэтные циклы...
0
|
19.08.2020, 16:59 | 15 | |||||
https://ru.wikipedia.org/wiki/... анный_язык
"Функциональные и логические языки программирования выглядят неестественно в визуальном окружении, так как функциональное программирование и логическое программирование в чистом виде запрещают побочные эффекты, и для взаимодействия с GUI их концептуальную целостность приходится нарушать." Вот этот подход мне кажется перспективным. То есть - язык, позволяющий затачиваться под предметную область. В свое время у меня в этой роли выступал Forth, он позволял затачивать синтаксис программы под задачу. Сейчас у меня в этой роли выступает встраиваемый язык Lua. Чуточку о форте - уже одна только возможность в качестве алфавита использовать всю ascii таблицу кружила голову: Код
: | ; immediate -- здесь я определил знак "|" как незначащий : факториал -- да-да, можно и по-русски 1 swap 0 do | i * -- а здесь я его использовал для разметки цикла loop ; Вот еще примерчик, на этот раз Lua, это карта местности для несложной игры:
Вот кстати еще из прошлого и форта: Код
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
2
|
645 / 521 / 72
Регистрация: 20.09.2014
Сообщений: 3,353
|
|
19.08.2020, 20:54 [ТС] | 16 |
APL - предшественник MATLAB... Алфавит и синтаксис, конечно, несильная сторона APL. Работа с массивами и матрицами позволит совсем уйти от циклов?
Добавлено через 6 минут Да, я планировал реализовать эту фишку. Для boolean, integer, double, string и прочего в языках заложена возможность задавать дефолтное значение, а для массивов - "гуляй, Вася". Добавлено через 6 минут У с++ есть возможность перегружать операторы +, -, /, *, >, <, = (и другие) под новые классы. То есть фактически это и есть заточка под предметную область? С точки зрения графического языка эта заточка представляет собой весьма интересный инструмент??....
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
20.08.2020, 00:14 | 17 |
У Haskell и F# есть возможность объявлять свои операторы. Это лучше.
ИМХО синтаксис языка должен быть как можно более простым. В идеале в нём должны быть только функции и операторы (те же функции, но другая запись). Ну и по мелочи - объявление/связывание переменных, инициализаторы списков, префиксы/суффиксы для задания типов коллекций/переменных и т.п.
0
|
20.08.2020, 00:25 | 18 |
Я говорю совсем о другом...
я сейчас уже очень смутно помню Fortran, но помню, что там был оператор условия на меньше/больше/равно_нулю. В языке forth такого оператора нет, но добавить в язык конструкцию вида: Код
if_x<0 ... if_x>0 ... else ... end причем запись будет именно такая, как я ее написал, то есть "if_x<0" и прочее - это новодобавленные конструкции языка
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
20.08.2020, 00:47 | 19 |
Любой текст может оказаться кодом на Forth, который делает именно то, что написано в тексте. Вот это и есть DSL.
0
|
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 Моя аргументация против устаревших утверждений Фредерика Брукса: http://programming-lang.com/ru... 0/j18.html
0
|
20.08.2020, 09:26 | |
20.08.2020, 09:26 | |
Помогаю со студенческими работами здесь
20
C:\tsserver\Projects\cpp\codeblocks\MyComp\IDE\IDE\IDE.cpp|3 9|undefined reference to `GetStockObject@4'| Подскажите пожалуйста IDE для линукса (например, для кали-линукса) для новичка для обучения программированию на си++ Версионность: подходы, решения. 2-ух, 3-ёх уровневый подходы к проектировнаию БД Подходы к разработке ПО и их связь с ООП Посоветуйте модульные подходы создания класса Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |