IRL каждый может нарисовать свидетельство о владении, например, Эйфелевой башней. И продать кому то. Но так никто не делает.
Забавно что вы упомянули Эйфелеву башню, так как именно ее пару раз «продавали».
В 1925 году Люстигу удалось на закрытом аукционе продать парижскому бизнесмену Андре Пуассону Эйфелеву башню, уверив того, что башня якобы продается на слом, а он является агентом правительства, осуществляющим эту операцию. Обманутый торговец постеснялся заявить в полицию, и Люстиг проделал этот же трюк ещё раз. Впрочем, новый покупатель отправился в полицию, и афера была раскрыта.
Нам демонстрируют обычное ООП, основанное на классах
В ООП перегрузка функций возможна только на разных уровнях иерархии, в Delight перегрузка функций возможна на одном уровне иерархии — такого поведения невозможно добиться в ООП. Таким образом, финальная класс-сущность в Delight может просто состоять из списка классов-компонентов, что вполне соответствует КОП подходу.
Построенный на композиции Go прекрасно обходится и без классов, и без [shared] с [virtual], и без циклических зависимостей…
Go использует ключевое слово interface — которое обозначает что все функции в этом интерфейсе — виртуальные [virtual]. И да, в Go нет [shared], но попробуйте в Go реализовать примеры из статьи, где это [shared] используется.
Из популярных языков проблема ромбовидного наследования есть только в C++.
Проблема ромбовидного наследования возникает при множественном наследовании (из популярных языков, такую концепцию поддерживают Perl, Python и C++). Большинство современных языков, из-за сложностей отказались от множественного наследования, используя при этом одиночное наследование + наследование интерфейсов. В Delight же используется множественное наследование, но без тех проблем которые за ним стоят.
Использовать nextFn для вызова предшествующего в цепочке наследования метода
Именно следующего. Даже в ООП, первой будет вызвана функция, которая стоит выше по иерархии, а последней — декларация.
Пока что это скриптовый язык, так что про сравнение скорости говорить не приходиться. В будущем будет трансляция в С++, с последующей компиляцией в бинарник, так что скорость ожидается примерно на уровне С++.
Такие комментарии имели бы место, при описании общей теории, я же поделился уже рабочим концептом. Размышления о том, как бы плохо это должно было бы работать, выглядят странными.
Как читаются ваши сообщения — «я вот такой то разработчик, сделайте мне хорошо. То что вы что-то для других делаете, а не персонально под меня — не имеет никакого значения, а значит бесперспективно».
… а вот это еще надо доказать.
Надо доказать что другие люди пишут под вас софт и улучают его со временем, позволяя еще больше автоматизировать вашу работу?
Вам не приходило в голову, что может быть потому, что «для дотнета» функциональность немного шире?
Конечно шире. Но парсинг и обработка кода не должны занимать столько человеко-часов, что я и демонстрирую своими наработками.
Ответ уже был дан — в местах где автоматизация работы может упростить работу программиста. То что вы таких мест не видите, не значит что их нет. Более того — вы уже пользуетесь автоматизацией которую создают тысячи разработчиков вашего ПО. Что позволяет мой подход — использование для тех же целей меньше человеко-часов. Пример с Roslyn вы же и привели. То что у меня сделано просто и нативно, для дотнета потребовало разработки сотен людей.
А все, кто не такие как вы, это уже не программисты? Если я профессиональный программист, и действительно вижу уйму мест, где мой инструмент может быть полезен, то что не так с процитированным вами утверждением?
На ваших скриншотах нет вообще ни того, ни другого — связность есть только в пределах кода одной ноды, остальные ноды представляют собой несвязанные карточки различных представлений
Похоже вы не правильно прочитали скриншоты — окна (карточки) это ноды, но внутри них отображены десятки других нод — каждый оператор языка (или другая его конструкция), это отдельная нода, со своими под-нодами. Естественно, виджеты все это скрывают под более удобным текстовым представлением, хотя по желанию для тех же нод можно использовать другие виджеты. Я уже приводил пример скриншота:
здесь окно справа отображает АСТ ноды функции слева. Выделенная справа зеленой рамкой нода (виджет) также подсвечивается слева, поскольку это одна нода и та же нода, но отображенная двумя разными виджетами.
Еще не совсем понятно, почему текстовое представление сильно усложняет программный анализ.
Не нужно заниматься парсингом текста, наборщику кода не нужно заботиться о сохранении структурной целостности текста с помощью дополнительных знаков/слов. Ошибки на подобии забытой скобки (которые очень сложно выявляются в тексте с помощью алгоритмов) при структурном подходе невозможны. Выравнивание табами/пробелами в код отсутствует как класс. Фактически АСТ избавленно от лишних данных форматирования кода, которые обязательны в текстовом представлении. Для валидации данных достаточно проверить типы нод и их целостность — если какая-либо нода в конкретном месте не ожидается, то можно выдать четкую и локализированую информацию про ошибку. Ну и также кастомизация отображения одних и тех же данных. Например класс можно отобразить как полноценный, или ограничиться только списком полей, или же показывать только функции/перегруженые функции и т.п. И все это будет живой код, а не статический список в каком-то текстовом листе.
программа регулярно будет проводить ровно обратную операцию — интерпретацию ноды в человекопонятное состояние виджета
Виджет крайне простой по своей архитектуре — он просто следит за данными ноды (а это примитивные типы) и отображает нужную информацию на экране (графикой или текстом). Здесь совершенно никакой сложности нет.
С помощью типизированной системы нод. Каждая нода описывает какие типы child нод она может иметь. В результате получается дерево с типизированными нодами. Примерно такое же, если бы вы описывали АСТ на классах.
Тем не менее, они вполне могут использовать MetaIDE в собственных целях. Это лучше чем Ексель, а для интеграции с другими наработками — лучше чем Ацес.
Но надо понимать ограничения «единой и самодостаточной архитектуры».
Если инструмент покрывает все нужные потребности и делает это достаточно удобно, то ограничения в выборе другого инструмента можно проигнорировать.
Я вот знаю людей, которые программированием решают свои задачи. И вполне обходятся без гита, VS Code и консольных систем сборок. Я так понимаю что для вас они вообще не программисты.
Все эти люди — не разработчики.
Нда уж. А если им таки нужно написать пару скриптов, то они должны обязательно изучить весь стек ваших технологий чтобы считаться разработчиками. Очень интересная у вас классификация.
Ну вот вас интересуют простые DSL, но в моем примере был полноценный ЯП, целевая аудитория которого — разработчики.
Ну так пользуйтесь всеми возможными технологиями для его реализации. Если вас единая и самодостаточная архитектура никак не устраивает, это совершенно не значит что это плохо для других.
Ага, так и запишем: подход ускоряет разработку, но только в определенных сценариях. Ок.
Я более чем уверен что в веб разработке есть множество мест, где автоматизация работы с кодом может упростить работу разработчика. Если вы их не видите, это не значит что их нет. Про СКВ вы раньше тоже не знали, сейчас без него никуда.
Из собственного крайне ограниченного опыта, припоминаю что было бы не плохо автоматически синхронизировать данные между кодом на фронте и кодом на беке, а не рассчитывать что сериализованые данные в json через js в точности также будут десериализованы и обработаны на любом языке бекенда.
В некоторых случаях используют отдельные скриптовые языки для генерации целевого исходного кода, что требует установку и интеграцию интерпретаторов этих языков, изучения взаемодействия скриптового языка с вашей средой разработки. Часто такие сложности не оправдывают результаты, поэтому редко используются. У меня с этим все на порядок проще и нативнее для среды разработки.
Delight — язык общего назначения для разработки прикладных кросплатформеных программ (можно и игр). Поскольку итоговая программа может иметь в себе фрагменты MetaIDE — существенно упрощается разработка самой программы.
Вы уверенны? Если надо отдать разработку скрипта геймдизайнеру? Если надо написать скрипт по обработке данных датасайнтесту? Если отдать физические расчеты математику? Все эти люди могут поверхностно разбираться в программировании (по своей специальности) но ничего не слышать про гит, билд машины, а робота с консолью для них это уже хакерство. Не говоря уже про установку всего вашего софта, для простой работы.
Мне не нужен DSL на пару сотен строчек кода. Я говорил о полноценном языке программирования.
Разница между ЯП и DSL может быть размыта. Какой-то простой процедурный скриптовый язык не так уж далеко от DSL отошел. Тем не менее, меня больше интересуют простые DSL, так как с их помощью можно решать повседневные задачи, на них и основной акцент.
Я такое делал на MS Access в конце 90-ых. Да и сейчас для этого конструкторы есть, прямо скажем.
Как же вы без блокнотиков и СКВ тогда обходились… а вот моя разработка видите ли бесперспективная.
Вы же утверждаете, что ваш подход ускоряет разработку.
Да, ускоряет, путем автоматизации работы с кодом. В моем профиле работы таких требований валом, только они либо не решаются, либо обходяться костылями. Если вам никогда и нигде не нужно было автоматизировать работу с кодом, тогда вам явно не ко мне.
Да вы же сами все описали. Редакторы, СКВ, билд-машины, гитхаб. Еще изучать АПИ потенциальной IDE. Совсем разные технологии. Если вам нужен DSL на пару сотен строчек кода, у вас получиться либо сильный оверхед по технологиям, либо недоделаный сырой DSL с удобностю ниже плинтуса.
Вот скажем попросила вас знакомая написать небольшую программу для бухгалтерского учета. Разработка полноценной UI-шной программы слишком накладна, можно сделать веб страничку (уже проще, но с ограниченными возможностями), можно написать DSL но с существующими инструментами это либо сложно для программиста, либо ужасно сыро для пользователя. Типичным решением является таблица в Екселе — простая в разработке, но сомнительная по удобству.
Ну и как альтернатива — MetaIDE. Описать данные в виде дерева, составить для них виджеты, написать скрипты обработки дерева. Автоматом получая сохранение на диск, возможность отмены действий, и даже систему контроля версий с бекапами. Пользователю отдается исполняемый файл, который даже инсталлировать не нужно. Визуально это будет как полноценная программа, средств на разработку — минимум.
Вы ни одной моей задачи пока в примерах не затронули.
Я не занимаюсь вебом, с чего бы мне затрагивать ваши задачи..?
Как обычно — состоятельность языка программирования выражается в возможности компиляции самого себя. В данном случае — IDE описывает сама себя. Дальше эта IDE и ЯП будут для общего назначения.
Поскольку на Delight разрабатывается сама IDE, то и примеры в основном из того же кода. Например для регистрации нового ключевого слова/функции для интерпретируемого языка (в моей паскалевской архитектуре) нужно:
— завести новое значение в енуме для этого языка
— добавить текстовое описание этого значения (для отображения в UI)
— сделать привязку текста из ЯП к новому значению енума
— добавить функцию обработки нового ключевого слова
— связать новую функцию со значением енума
И это все нужно прописать в нескольких разных файлах исходных кодов. Для Delight пришлось несколько сотен таких действий сделать. Банальная и рутинная работа. Если такое разрабатывать на Delight — то создается небольшой DSL который выглядит как таблица (примет таблицы есть в статье) и пишется небольшой скрипт, который по данным таблицы вписывает код куда нужно. Дальше при добавлении нового ключевого слова достаточно заполнить пару полей таблицы и получить весь необходимый код одним нажатием клавиши. Также вместо навигации по исходникам, можно использовать эту же таблицу, чтобы найти нужную функцию.
Зачем набирать код в среде, где доступ к клавиатуре ограничен?
А что плохого, если планшеты (или другие устройства) будут предлагать тоже удобство програмирования, что и ПК, и даже без клавиатуры?
И, собственно говоря, я могу придумать несколько способов ввода обычного текста без клавиатуры, которые поспорят по удобству с предложенным.
Вы уверенны? Быстрее чем нажатие одной/двух кнопок вместо пяти? Быстрее чем выбор пункта меню, который отображен на кране? Интересно послушать.
Я вижу скриншоты с текстовым представлением и скриншоты с графическим.
Текстовое представление на скриншотах это и есть визуальное отображение структуры кода. Слово break — это виджет с отдельной нодой. Как и все остальные языковые конструкции. Практически весь текст на скриншотах можно отнести к визуальному программированию — там нет ни одного много-строчного текста.
Но даже у них не то, чтобы хорошо взлетело, кажется.
Слишком сложный подход. Даже самый простой туториал занимал несколько страниц текста.
Забавно что вы упомянули Эйфелеву башню, так как именно ее пару раз «продавали».
Люстиг, Виктор
В ООП перегрузка функций возможна только на разных уровнях иерархии, в Delight перегрузка функций возможна на одном уровне иерархии — такого поведения невозможно добиться в ООП. Таким образом, финальная класс-сущность в Delight может просто состоять из списка классов-компонентов, что вполне соответствует КОП подходу.
Go использует ключевое слово interface — которое обозначает что все функции в этом интерфейсе — виртуальные [virtual]. И да, в Go нет [shared], но попробуйте в Go реализовать примеры из статьи, где это [shared] используется.
Проблема ромбовидного наследования возникает при множественном наследовании (из популярных языков, такую концепцию поддерживают Perl, Python и C++). Большинство современных языков, из-за сложностей отказались от множественного наследования, используя при этом одиночное наследование + наследование интерфейсов. В Delight же используется множественное наследование, но без тех проблем которые за ним стоят.
Именно следующего. Даже в ООП, первой будет вызвана функция, которая стоит выше по иерархии, а последней — декларация.
Как читаются ваши сообщения — «я вот такой то разработчик, сделайте мне хорошо. То что вы что-то для других делаете, а не персонально под меня — не имеет никакого значения, а значит бесперспективно».
Надо доказать что другие люди пишут под вас софт и улучают его со временем, позволяя еще больше автоматизировать вашу работу?
Конечно шире. Но парсинг и обработка кода не должны занимать столько человеко-часов, что я и демонстрирую своими наработками.
Похоже вы не правильно прочитали скриншоты — окна (карточки) это ноды, но внутри них отображены десятки других нод — каждый оператор языка (или другая его конструкция), это отдельная нода, со своими под-нодами. Естественно, виджеты все это скрывают под более удобным текстовым представлением, хотя по желанию для тех же нод можно использовать другие виджеты. Я уже приводил пример скриншота:
здесь окно справа отображает АСТ ноды функции слева. Выделенная справа зеленой рамкой нода (виджет) также подсвечивается слева, поскольку это одна нода и та же нода, но отображенная двумя разными виджетами.
Не нужно заниматься парсингом текста, наборщику кода не нужно заботиться о сохранении структурной целостности текста с помощью дополнительных знаков/слов. Ошибки на подобии забытой скобки (которые очень сложно выявляются в тексте с помощью алгоритмов) при структурном подходе невозможны. Выравнивание табами/пробелами в код отсутствует как класс. Фактически АСТ избавленно от лишних данных форматирования кода, которые обязательны в текстовом представлении. Для валидации данных достаточно проверить типы нод и их целостность — если какая-либо нода в конкретном месте не ожидается, то можно выдать четкую и локализированую информацию про ошибку. Ну и также кастомизация отображения одних и тех же данных. Например класс можно отобразить как полноценный, или ограничиться только списком полей, или же показывать только функции/перегруженые функции и т.п. И все это будет живой код, а не статический список в каком-то текстовом листе.
Виджет крайне простой по своей архитектуре — он просто следит за данными ноды (а это примитивные типы) и отображает нужную информацию на экране (графикой или текстом). Здесь совершенно никакой сложности нет.
Тем не менее, они вполне могут использовать MetaIDE в собственных целях. Это лучше чем Ексель, а для интеграции с другими наработками — лучше чем Ацес.
Если инструмент покрывает все нужные потребности и делает это достаточно удобно, то ограничения в выборе другого инструмента можно проигнорировать.
Я вот знаю людей, которые программированием решают свои задачи. И вполне обходятся без гита, VS Code и консольных систем сборок. Я так понимаю что для вас они вообще не программисты.
Нда уж. А если им таки нужно написать пару скриптов, то они должны обязательно изучить весь стек ваших технологий чтобы считаться разработчиками. Очень интересная у вас классификация.
Ну так пользуйтесь всеми возможными технологиями для его реализации. Если вас единая и самодостаточная архитектура никак не устраивает, это совершенно не значит что это плохо для других.
Я более чем уверен что в веб разработке есть множество мест, где автоматизация работы с кодом может упростить работу разработчика. Если вы их не видите, это не значит что их нет. Про СКВ вы раньше тоже не знали, сейчас без него никуда.
Из собственного крайне ограниченного опыта, припоминаю что было бы не плохо автоматически синхронизировать данные между кодом на фронте и кодом на беке, а не рассчитывать что сериализованые данные в json через js в точности также будут десериализованы и обработаны на любом языке бекенда.
Вы уверенны? Если надо отдать разработку скрипта геймдизайнеру? Если надо написать скрипт по обработке данных датасайнтесту? Если отдать физические расчеты математику? Все эти люди могут поверхностно разбираться в программировании (по своей специальности) но ничего не слышать про гит, билд машины, а робота с консолью для них это уже хакерство. Не говоря уже про установку всего вашего софта, для простой работы.
Разница между ЯП и DSL может быть размыта. Какой-то простой процедурный скриптовый язык не так уж далеко от DSL отошел. Тем не менее, меня больше интересуют простые DSL, так как с их помощью можно решать повседневные задачи, на них и основной акцент.
Как же вы без блокнотиков и СКВ тогда обходились… а вот моя разработка видите ли бесперспективная.
Да, ускоряет, путем автоматизации работы с кодом. В моем профиле работы таких требований валом, только они либо не решаются, либо обходяться костылями. Если вам никогда и нигде не нужно было автоматизировать работу с кодом, тогда вам явно не ко мне.
Да вы же сами все описали. Редакторы, СКВ, билд-машины, гитхаб. Еще изучать АПИ потенциальной IDE. Совсем разные технологии. Если вам нужен DSL на пару сотен строчек кода, у вас получиться либо сильный оверхед по технологиям, либо недоделаный сырой DSL с удобностю ниже плинтуса.
Вот скажем попросила вас знакомая написать небольшую программу для бухгалтерского учета. Разработка полноценной UI-шной программы слишком накладна, можно сделать веб страничку (уже проще, но с ограниченными возможностями), можно написать DSL но с существующими инструментами это либо сложно для программиста, либо ужасно сыро для пользователя. Типичным решением является таблица в Екселе — простая в разработке, но сомнительная по удобству.
Ну и как альтернатива — MetaIDE. Описать данные в виде дерева, составить для них виджеты, написать скрипты обработки дерева. Автоматом получая сохранение на диск, возможность отмены действий, и даже систему контроля версий с бекапами. Пользователю отдается исполняемый файл, который даже инсталлировать не нужно. Визуально это будет как полноценная программа, средств на разработку — минимум.
Я не занимаюсь вебом, с чего бы мне затрагивать ваши задачи..?
— завести новое значение в енуме для этого языка
— добавить текстовое описание этого значения (для отображения в UI)
— сделать привязку текста из ЯП к новому значению енума
— добавить функцию обработки нового ключевого слова
— связать новую функцию со значением енума
И это все нужно прописать в нескольких разных файлах исходных кодов. Для Delight пришлось несколько сотен таких действий сделать. Банальная и рутинная работа. Если такое разрабатывать на Delight — то создается небольшой DSL который выглядит как таблица (примет таблицы есть в статье) и пишется небольшой скрипт, который по данным таблицы вписывает код куда нужно. Дальше при добавлении нового ключевого слова достаточно заполнить пару полей таблицы и получить весь необходимый код одним нажатием клавиши. Также вместо навигации по исходникам, можно использовать эту же таблицу, чтобы найти нужную функцию.
Все что на моих скриншотах это визуальное программирование.
А что плохого, если планшеты (или другие устройства) будут предлагать тоже удобство програмирования, что и ПК, и даже без клавиатуры?
Вы уверенны? Быстрее чем нажатие одной/двух кнопок вместо пяти? Быстрее чем выбор пункта меню, который отображен на кране? Интересно послушать.
Текстовое представление на скриншотах это и есть визуальное отображение структуры кода. Слово break — это виджет с отдельной нодой. Как и все остальные языковые конструкции. Практически весь текст на скриншотах можно отнести к визуальному программированию — там нет ни одного много-строчного текста.
Слишком сложный подход. Даже самый простой туториал занимал несколько страниц текста.