Comments 186
Ведро дегтя №1:
А теперь поместите исходный код программы в Version Control, сравните две ветки и попробуйте разрешить конфликты, если они были.
В будущем планируется добавить систему контроля версий для нод (такой себе git)
Т.е. специальный Version Control, который о формате хранения вот всего этого знает?
И получим, что все широко используемые инструменты совместной разработки к такой программе неприменимы?
Также возможна сериализация (и десериализация) данных в текстовый формат, хотя при таком подходе теряются некоторые возможности структурной обработки информации.
С этим нет проблем.
Ну то есть потеря совместимости со подавляющей частью нынешнего массового инструментария — это для вас не проблема?
Если некая технология полностью покрывает все потребности и добавляет новые, более удобные инструменты работы
"Если". Для меня то, что это условие выполнено, пока не очевидно.
то проблема только в изучении этой технологии.
На самом деле — нет. Еще проблема в миграции. Миграции кода, миграции инфраструктуры, миграции тулинга.
полностью покрывает все потребности
Это настолько оптимистично, что даже не знаю, как это назвать можно.
Прошу прощения, но если уж так хочется визуального программирования, технология должна выглядеть так:
Исходный, человекопонятный код лежит в простых текстовых файлах. Ваша IDE
его компилирует в бинарное представление нодами и хранит, показывает, обрабатывает, заменяет, трансформирует, итд итп где-то внутри себя. Соответствующим образом меняя исходный текстовый код. И отдельно — то же самое, но без IDE, а command line (де)компилятором
И да, "текстовый исходник" в виде зубодробительного XML или текста, который нельзя понять — тоже считается за бинарный файл.
Т.е. вся визуальное программирование — это один из вариантов работы (возможно, удобный) с текстом, а что-то отдельное и ни с чем не совместимое.
Исходный, человекопонятный код лежит в простых текстовых файлах.
Текстовые файлы не являются оптимальными носителями чего-то человеко-понятного. Думаю мое утверждение особо не требуется доказывать. Тогда едем дальше: непонятно, зачем хранить человеко-понятные тексты, пусть там компилятор разбирается. Если эти тексты будут XML-стандартизированы, тогда IDE смогут быть совместимыми друг с другом.
Текстовые файлы не являются оптимальными носителями чего-то человеко-понятного. Думаю мое утверждение особо не требуется доказывать.
На самом деле, требуется. Для меня оно совершенно не очевидно.
Моя IDE вполне успешно показывает все места, где конкретное поле используется, заглядывая в обычные текстовые исходники.
Более того, я могу просто сразу разбить его на два, и во всех остальных местах сразу будет показана ошибка "обращение к неизвестному полю".
Моя IDE вполне успешно показывает все места
Попробуйте провернуть такой трюк с С++, особенно при использовании макросов/темплейтов.
во всех остальных местах сразу будет показана ошибка «обращение к неизвестному полю».
Это уже благодаря компилятору, который (внимание) стоит AST чтобы разобраться что там в тексте написано. У программиста нет прямого доступа к этому AST, хотя порой оно очень пригодилось бы.
Попробуйте смёржить ветку, где было произведено переименовывание и ветку, где добавилось использование старого апи. Без структурного представления, где каждая идиома имеет свой уникальный суррогатный идентификатор, это невозможно. А когда добавляете такие идентификаторы в текстовый файл — получается такое месиво, что читать невозможно. То есть редактор должен под капотом следить за этими идентификаторами, сохраняя вместе с исходниками, но не показывая пользователю. Это принцип работы всех rich редакторов пригодных для коллаборативного использования.
Во-первых (и в самых важных), это не пример к утверждению "текстовые файлы не являются оптимальными носителями чего-то человеко-понятного", потому что вы говорите не о человекопонятности, а об обработке.
А во-вторых, моя IDE успешно осуществляет эту операцию, несмотря на то, что исходники лежат в текстовых файлах.
Кстати, о "ссылаются на". А как в вашем подходе решается простой, в общем-то, случай с библиотеками общего использования? Вот добавили мы в новый проект ссылку на библиотеку, используем из нее какой-то объект — ссылка будет по чему? По имени? По какому-то идентификатору?
вы говорите не о человекопонятности, а об обработке.
Структурные данные могут быть не менее человекопонятными чем обычные текстовые. В некоторых случаях даже более читаемые чем текстовый формат (примеры есть в статье). При том, они дают доступ к обработке данных, которая слишком сложная, либо не возможная в текстовом представлении.
А во-вторых, моя IDE успешно осуществляет эту операцию, несмотря на то, что исходники лежат в текстовых файлах.
Такое не всегда и не везде поддерживаться. В структурном формате — это нативная часть самого формата, а не инструментов для его обработки.
ссылка будет по чему? По имени? По какому-то идентификатору?
Ссылка будет по идентификатору, уникальному для каждой ноды.
Структурные данные могут быть не менее человекопонятными чем обычные текстовые.
Не всегда.
(вырожденный случай "структура из одного элемента, эквивалентного тексту", я не рассматриваю)
В некоторых случаях даже более читаемые чем текстовый формат (примеры есть в статье).
Структурных — не вижу. Вижу диаграммы и графы, да, они иногда, для определенных данных более читаемы. Но не для всех и не всегда.
Зато они дают доступ к обработке данных, которая слишком сложная, либо не возможная в текстовом представлении.
Приведите пример невозможной обработки.
Такое не всегда и не везде поддерживаться.
И чем это отличается от вашего формата, который тоже "не всегда и не везде поддерживается"?
Ссылка будет по идентификатору, уникальному для каждой ноды.
… ну то есть я удалил какое-то свойство, потом подумал, создал новое с таким же именем — и все клиенты поломались?
Как мило.
Не всегда.
В статье есть скриншоты с языком Delight. Они полностью эквивалентны обычному текстовому представлению. Также как и представление языка разметки нод. Для mindmaps, как видите, представление намного более удобнее, чем таковое в текстовом формате.
Структурных — не вижу.
Все данные на скриншотах представлены в структурном формате с помощью человекочитаемых виджетов.
Приведите пример невозможной обработки.
Нет такого случая как «невозможная обработка». Сырые текстовые данные (при условии безошибочного синтаксиса) вполне успешно могут быть обработаны программно. Вопрос только в сложности обработки — для структурных данных она может быть элементарной, для текстовой — слишком сложной для реализации. С++ существует почти 40 лет, а для IDE все еще огромные трудности в понимании его кода. Справляются только компиляторы, но про завышенную сложность С++ компилятора, думаю вы и так в курсе.
И чем это отличается от вашего формата, который тоже «не всегда и не везде поддерживается»?
В пределах IDE — он всегда и везде поддерживаться. За пределами — вопрос наличия стороннего инструментария.
… ну то есть я удалил какое-то свойство, потом подумал, создал новое с таким же именем — и все клиенты поломались?
А зачем вам удалять и создавать заново данные, которые вам таки нужны? Логичнее будет модифицировать сущность, а не пересоздавать все заново.
Впрочем для Delight такое можно делать — IDE сделает перевязку нод на основании имени некоторых сущностей.
В статье есть скриншоты с языком Delight. Они полностью эквивалентны обычному текстовому представлению.
Я же говорю: вырожденный случай "структура из одного элемента, эквивалентного тексту", я не рассматриваю.
Для mindmaps, как видите, представление намного более удобнее, чем таковое в текстовом формате.
Это пример графа.
Все данные на скриншотах представлены в структурном формате с помощью человекочитаемых виджетов.
Вот в том-то и дело. Текст человекочитаем без виджетов.
Нет такого случая как «невозможная обработка».
Ээээ. Вы вот только что писали:
Зато они дают доступ к обработке данных, которая слишком сложная, либо не возможная в текстовом представлении.
… а теперь выясняется, что случая "невозможная" нет. Гм-гм.
С++ существует почти 40 лет, а для IDE все еще огромные трудности в понимании его кода.
Возможно, это повод не писать на С++. Я вот не пишу, и у меня все хорошо.
В пределах IDE — он всегда и везде поддерживаться.
Возвращаемся к тезису, что IDE недостаточно. Я не хочу быть привязанным только и исключительно к вашей IDE.
За пределами — вопрос наличия стороннего инструментария.
Которого нет. И весь существующий — не подойдет.
А зачем вам удалять и создавать заново данные которые вам таки нужны?
Потому что ход мысли такой.
Я же говорю: вырожденный случай «структура из одного элемента, эквивалентного тексту», я не рассматриваю.
эм… В статье же описанно, что любой оператор (или ключевое слово, переменная, функция и т.п.) это отдельная нода. Одна функция это структура из сотни элементов.
Это пример графа.
Тем не менее, в основе того графа лежат такие же ноды, что и при отображении Delight.
Вот в том-то и дело. Текст человекочитаем без виджетов.
Вы можете прочитать биты в памяти без какой либо помощи? Сомневаюсь. Попробуйте сначала проанализировать все необходимые алгоритмы для того чтобы читать и менять код в каком либо самом простом «блокноте», а потом уже говорите про человекоудобность. В общем случае вы даже не замечаете уйму кода, которая используется для вашей работы в «блокноте». Для структурной IDE это мало чем отличается.
… а теперь выясняется, что случая «невозможная» нет. Гм-гм.
Мы вроде бы не бессмертны. Если какая то задача слишком сложная для реализации, то вы либо не возметесь за нее, либо выберете подходящий инструмент, который таки позволит решить эту задачу в приемлемые строки.
Возвращаемся к тезису, что IDE недостаточно. Я не хочу быть привязанным только и исключительно к вашей IDE.
Но привязка к исключительно не вашим блокнотам/IDE/ОС/железу вас совершенно не смущает.
Которого нет. И весь существующий — не подойдет.
Критика так себе. Можно было ограничиться охотой зубами и жильем в пещере, ведь всего остального банально не было, а что создавалось — не совместимо с зубами.
Потому что ход мысли такой.
А в коде (файле) где вы забыли про переименование сущности внезапно возникнет ошибка связывания по не правильному имени. Любой подход имеет свои не удобности, которые можно обходить разными способами.
эм… В статье же описанно, что любой оператор (или ключевое слово, переменная, функция и т.п.) это отдельная нода. Одна функция это структура из сотни элементов.
Я на экране, тем не менее, вижу просто текст. С какими-то визуальными элементами, которые слабо отличаются от того, что я имею в любой другой тексто-ориентированной IDE.
В общем случае вы даже не замечаете уйму кода, которая используется для вашей работы в «блокноте».
А зачем мне ее замечать, если оно работает?
(пока, конечно, оно не ломается)
Для структурной IDE это мало чем отличается.
Вот только я не хочу "структурную IDE", понимаете? Я хочу версионник. Я хочу легкий просмотрщик. Я хочу веб-морду. Я хочу диффы в анализаторе билдов. Я хочу поиск из командной строки. Я хочу хуки на удобном мне языке.
Короче говоря, я хочу инфраструктуру, которая уже есть, и в отношении которой у вас пока нет даже оценок, сколько ресурсов вам понадобится на замену.
Но привязка к исключительно не вашим блокнотам/IDE/ОС/железу вас совершенно не смущает.
Она меня не смущает именно потому, что у меня есть выбор.
А в коде (файле) где вы забыли про переименование сущности внезапно возникнет ошибка связывания по не правильному имени.
Ну да, возникнет. Но это, по крайней мере, понятное поведение.
Я на экране, тем не менее, вижу просто текст. С какими-то визуальными элементами, которые слабо отличаются от того, что я имею в любой другой тексто-ориентированной IDE.
Проще таки было бы прочитать статью, где указанно, что виджеты сделаны в форме текстовых элементов, так как такое представление лучше подходит для программирования. Вот скриншот как пример:
окно слева — обычные виджеты для отображения кода Delight,
окно справа — теже самые ноды, но отображены виджетами для просмотра AST.
(Я бы мог тоже самое скинуть текстом, а не картинкой, но боюсь, опять возникнет недопонимание)
Проще таки было бы прочитать статью, где указанно, что виджеты сделаны в форме текстовых элементов, так как такое представление лучше подходит для программирования.
Стоп.
Смотрите. Вы только что написали: "такое [текстовое] представление лучше подходит для программирования".
Казалось бы, это как раз и подтверждает то, что я сказал: текст наиболее человеко-читаем.
При этом не важно из чего он сгенерен.
Казалось бы, это как раз и подтверждает то, что я сказал: текст наиболее человеко-читаем.
При этом не важно из чего он сгенерен.
Это не текст. Это только отображение данных нод в виде текста. Я даже могу скопировать эту функцию как текст, но данные которыми оперирует IDE/программист — это ноды (примерно то что в правом окне). Из чистого текста — там только названия переменных/функций. Текстовка виджетов к данным программы совершенно не относиться.
Это не текст. Это только отображение данных нод в виде текста.
… но то, что вы выбрали такое отображение, намекает нам: это наиболее удобное отображение. А это ровно то, о чем я говорю.
Я просто напомню, что все это началось с вопроса, какое же представление более читаемое.
Речь идет не о тех данных и не о том коде, с которыми идет работа (не человеком, причем — он как раз с текстовым представлением работает).
А о тех, что на диске лежат и которые другие инструменты, которые не IDE, видят.
Что плохого произойдет, если эти ноды на диске так и будут выглядеть, как тот текст, который 'представление'?
Что плохого произойдет, если эти ноды на диске так и будут выглядеть, как тот текст, который 'представление'?
Для структурных данных будет возможность сериализации/десериализации в текстовый формат, похожий на тот что на скриншотах — с целю, чтобы фрагментами кода можно было поделиться в чате, на сайте или еще где. Но держать все изначально структурированные данные в текстовом формате, чтобы каждый раз при открытии проекта их парсить и линковать — это очень сильный оверхед по производительности и надежности данных.
А зачем мне ее замечать, если оно работает?
И? К чему тогда притензии к реализации инструментария MetaIDE, если вам все равно что в инструменте под капотом, и вы просто с этим работаете.
Я хочу
А управлять кодом посредства кода вы не хотите? Чтобы вместо ручного рефакторинга, который не поддерживается вашей IDE, можно было бы написать небольшой скрипт который все сделает, уменьшая тем самым «человеческий фактор» с возможностю пропустить фрагмент кода или опечататся. Выполнять совершенно рутинную и легко автоматизируемую работу с помощью скриптов, а не перекидания буковок, не хотите? Конвертировать даные в любой удобный формат, а не писать парсер с лексером для свободной текстовой граматики тоже не хотите? Ну тогда это все точно не для вас.
К чему тогда притензии к реализации инструментария MetaIDE
А у меня нет претензий к реализации, я ее даже не видел. У меня есть претензии к концепции.
А управлять кодом посредства кода вы не хотите?
Хочу, и этот инструментарий у меня есть.
У меня есть претензии к концепции.
Ну пока у вас претензии не к концепции, а к ограниченном наборе инструментов.
Хочу, и этот инструментарий у меня есть.
Инструмент для компиляции и статического анализа кода? Как он вам поможет в написании кода, или автоматизации рутинных действий с кодом, специфических для вашего проекта?
Ну пока у вас претензии не к концепции, а к ограниченном наборе инструментов.
… который набор напрямую вытекает из концепции.
Инструмент для компиляции и статического анализа кода? Как он вам поможет в написании кода, или автоматизации рутинных действий с кодом, специфических для вашего проекта?
С помощью рослина, на минуточку, пишутся рефакторинги в современной VS (под .net). Когда у нас есть разобранный код, мы можем (менее или более эффективно) сгенерить новый код.
… который набор напрямую вытекает из концепции.
Сначала приведите доказательство, что нужные инструменты не возможно реализовать на выбранной концепции (чего вы естественно не можете сделать, кроме утверждений «Мне не удобно», не понимая даже полностю всю концепцию).
С помощью рослина, на минуточку, пишутся рефакторинги в современной VS (под .net).
А конкретно Вы, можете писать крупные рефакторинги и генерировать нужный Вам код с помощью рослина? Я еще раз напомню, что не решаемость какой-либо задачи очень условна. В написание скриптов под структурные данные может и один человек. И это все нативно в MetaIDE, без подключения чужих проектов и изучения их АПИ. В roslyn на гитхабе 456 — контрибуторов. Пускай из них только 30 человек наиболее активные. Но разницу между 30 и 1 увидеть совсем не сложно.
Сначала приведите доказательство, что нужные инструменты не возможно реализовать на выбранной концепции
Я и не говорю, что невозможно. Я просто считаю, что это потребует слишком много ресурсов. А существующие инструменты вы не поддерживаете.
А конкретно Вы, можете писать крупные рефакторинги и генерировать нужный Вам код с помощью рослина?
Конкретно я — не могу, потому что никогда это не изучал специально. Подозреваю, что если понадобится, разберусь где-нибудь в пределах недели.
И это все нативно в MetaIDE, без подключения чужих проектов и изучения их АПИ.
А программист на MetaIDE может нативно писать на C# компоненты, которые будут работать в существующей экосистеме? Ну там, лежать в общем с другими программистами git-репозитории, собираться общим с другими программистами билд-сервером, работать в общей платформе?
Я просто считаю, что это потребует слишком много ресурсов.
Да, много. Но не настолько, чтобы с этим было невозможно справиться.
А программист на MetaIDE может нативно писать на C# компоненты, которые будут работать в существующей экосистеме?
Думаю вы понимаете что C# в MetaIDE не подерживаеться. С таким же успехом можно спросить про программирование Паскаля на платформе для C++.
Но не настолько, чтобы с этим было невозможно справиться.
… вот и работа с кодом в виде текста требует не настолько много ресурсов, чтобы с этим было невозможно справиться.
Думаю вы понимаете что C# в MetaIDE не подерживаеться. С таким же успехом можно спросить про программирование Паскаля на платформе для C++.
Ну во-первых, бывают IDE, которые поддерживают несколько языков.
А во-вторых, теперь я базируюсь не на своих предположениях, а на вашем утверждении — и вы, получается, говорите, что придется бросить вообще все, и завязаться на один инструмент, который вы предлагаете. Один язык, одна IDE, одна СКВ…
Я в повседневной работе использую не меньше трех языков.
А конкретно Вы, можете писать крупные рефакторинги и генерировать нужный Вам код с помощью рослина?
Вот конкретно я, рандомный программист умею, и знаю людей, которые тоже умеют и делают. Работать с Syntax Tree, который предоставляет Roslyn удобно.
Вообще не вижу проблем храниния синтаксических деревьев в виде текста (исходного кода). Все плюсы работы с тектом есть — поиск, мерж, поддержка существующих инструментов, кросс-платформность. И никаких минусов бинарных форматов — порядок байтов, выравнивания, схема и версии схем и зависимость от инструментов.
Парсинг текста быстрый процесс, на крайний случай результат парсинга кешируется.
Вот конкретно я, рандомный программист умею, и знаю людей, которые тоже умеют и делают. Работать с Syntax Tree, который предоставляет Roslyn удобно.
Можете привести конкретный пример что на добыло сделать и как это было сделано с помощю Roslyn. Интересно сравнить подходы.
Парсинг текста быстрый процесс, на крайний случай результат парсинга кешируется.
Даже близко не настолько быстрый, как изначальное хранение в AST. Просто распарсить еще не проблема, а вот связывание узлов дерева по имени узла может потребовать уйму времени.
github.com/deniszykov/code-contracts-remover
удаление декларативных Code Contracts из кода и замена на их императивный эквивалент. Там даже пара контрибуторов есть т.е. это доступная не только единицам технология.
Из приватного: нахождение и дописывание атрибутов, кодогенерация, ну и конечно царица полей — инспекция.
Даже близко не настолько быстрый, как изначальное хранение в AST.
Результат парсинга кеширует, кеш выбрасывается когда меняется исходный код. В итоге плюсы от обоих миров скорость обработки+понятность людям. Это подход где исходный код это основа, у вас основа это распаршеный AST, и вы получаете только скорость. Про минусы AST-first уже было рассказано выше lair.
… ну то есть я удалил какое-то свойство, потом подумал, создал новое с таким же именем — и все клиенты поломались?
Лучше, поменял сигнатуру функции:
а) все отвалилось т.к. сигнатура поменялась
б) всё отвалилось т.к. айди поменялся в связи со сменой сигнатуры
в) костылики с overload'ом и поздним связыванием
Я тут под руками имею проект, в котором логика вот в таких XML файлах хранится, с названиями тегов и атрибутов, значения которых знает только фирма производитель IDE. В результате если два человека поменяли одну и ту же схему (даже если случайно элемент на пару пикселей сдвинут), которая этим файлом описана — то изменения из двух веток слить нельзя. Приходится буквально руками открывать три окошка и руками изменения искать и в новую ветку вносить.
Может я недопонял, в чем сложность мержа нетекстовых кодов, но я сталкивался с компараторами графических ЯП (Сименс).
lair, у меня часовой лимит между сообщениями на Хабре, поэтому отвечаю вам в соседней ветке.
Для меня оно совершенно не очевидно.
Позиционирование внимания у человека натренировано на 3D-пространство, монитор нам предоставляет 2D, третье измерение ослабленное — в виде закладок или дерева проекта. Текст кода — это навигационный объект 1D, схема кода — 2D. По тексту наша навигация осуществляется вверх-вниз, по схеме — вверх-вниз, влево-вправо. Это означает, что навигация по текстовому коду не использует всех способностей человеческого мышления. Это один из аргументов… Аргументов много, будьте уверены. Это же достаточно очевидно, граница в виде {} менее наглядна, чем помещение в квадратик. В прочем эту проблему начинают потихоньку так или иначе решать в текстовых IDE, не одними же четырехпробельными отступами жить.)))
И когда вы говорите: «Моя текстовая IDE может также», то я уже понимаю, что она нетекстовая (неБлокнот). Почему всё движется в сторону неБлокнота? И где там предел развития неБлокнотов, не задумывались?
Позиционирование внимания у человека натренировано на 3D-пространство
Это утверждение нуждается в доказательстве.
Текст кода — это навигационный объект 1D, схема кода — 2D.
Это произвольным образом выбранная система обозначений.
Это же достаточно очевидно, граница в виде {} менее наглядна, чем помещение в квадратик
А вы уверены, что мне зачем-то нужна более наглядная граница? Есть такая вещь, как "визуальный шум".
Это означает, что навигация по текстовому коду не использует всех способностей человеческого мышления.
Но вообще, я хочу вам сказать, что вы незаметно подменили текстовые файлы на текстовый код. Это зря.
И когда вы говорите: «Моя текстовая IDE может также», то я уже понимаю, что она нетекстовая (неБлокнот).
Проблема в том, что вы не понимаете главного: текстовый файл можно прочитать без IDE. Не важно, что там может или не может IDE. Важно, что человек может без нее.
Это утверждение нуждается в доказательстве.
Нее, пожалуй я пас. Не хочу доказывать.
Это произвольным образом выбранная система обозначений.
Могли бы сказать проще: это все хня!) Именно поэтому сложное бремя доказательств я сбрасываю.) Интереснее было бы, если бы вы впитывали знания как губка, а не как горох об стенку.
А вы уверены, что мне зачем-то нужна более наглядная граница? Есть такая вещь, как «визуальный шум».
вы не понимаете главного: текстовый файл можно прочитать без IDE
Я понимаю, где главное, а где нет: границы объектов — это существенная информация, зрительный якорь. Но вы-то должны понимать, что если вы открываете код без IDE по разу в течение 5-7 лет, то это не главное.
inkelyad
В том что стандартные инструменты, не заточенные конкретно под этот тип файла
Тут два варианта: либо у тебя инструмент точеный, либо ты сам точишься. Вы же понимаете, что код многократно усложняется, надо что-то делать… Да, вместо напильника обрабатывающий фрезерный центр надо поставить. А что делать? Посчитали: выгода есть. Или нет выгоды…
Думаю мое утверждение особо не требуется доказывать.
[...]
Не хочу доказывать.
… и вот так всегда.
Интереснее было бы, если бы вы впитывали знания как губка, а не как горох об стенку.
Мне интереснее вписывать знания, а не чьи-то бездоказательные утверждения.
Я понимаю, где главное, а где нет: границы объектов — это существенная информация, зрительный якорь.
Существенная, да. Обязательная? Нет. И да, отступ — прекрасная "граница объекта".
Но вы-то должны понимать, что если вы открываете код без IDE по разу в течение 5-7 лет, то это не главное.
… а в этой фразе я не понял почти ничего.
Посчитали: выгода есть.
Вот эти расчеты-то и хочется увидеть. Только я еще ни разу не видел адекватной методики расчета производительности программиста, безотносительно того, какой IDE он пользуется.
Может я недопонял, в чем сложность мержа нетекстовых кодов, но я сталкивался с компараторами графических ЯП (Сименс).
В том что стандартные инструменты, не заточенные конкретно под этот тип файла, в случае конфликта покажут
"вот этот (бинарый) кусок в этой ветке изменился так, а вот в этой (тоже бинарный) — так. Какой вариант использовать будем?"
И если человек не способе понять, что эти бинарные куски означают, то как он конфликт решить должен?
Пример — взять екселевский файл, сделать три копии, в каждой изменить какое-то места, которые взаимно перекрываются. Попытаться слить все вместе. Повторить то же самое, когда файлы лежат в разных ветках в github-е.
В том что стандартные инструменты, не заточенные конкретно под этот тип файла, в случае конфликта покажут
«вот этот (бинарый) кусок в этой ветке изменился так, а вот в этой (тоже бинарный) — так. Какой вариант использовать будем?»
Это банальный вопрос наличия подходящего инструментария. Показать разницу в двух ветках дерева существенно проще чем разницу в двух фрагментах текста (которые по сути просто набор байт с \r\n разделителями). Вы раньше писали про XML — это как раз текстовые данные, с ними для слияния и будут проблемы, по причине сложностей самого текстового слияния.
Хранение низкоуровневых данных в виде текста не просто ломает некоторые преимущества такого подхода, но и не так уж и востребовано при программировании.
Хотелось бы услышать какие-то объективные основания для утверждения "не так уж востребовано". А то лично мной вот очень востребовано (я за день могу открыть один и тот же исходник как минимум четырьмя разными программами).
Уже писал — работа в IDE существенно упрощает работу программиста.
Да, я тоже предпочитаю пользоваться IDE. Это никак не отменяет того, что иногда мне приходится пользоваться чем-то другим.
Так что я не понимаю, откуда вы берете утверждение "не так уж востребовано", кроме как из какого-то ограниченного опыта.
даже та часть которая в «блокноте» может проходить в IDE
Это только тогда, когда IDE сравнится по скорости поиска в большом репозитории с обычным grep. А до тех пор — нет.
Я про это и говорю: вы уверены, из какого-то собственного ограниченного опыта, что ваша IDE всем подойдет и все их задачи закроет. Но нет, это не так.
Тем, что открытие Visual Studio занимает до минуты.
И еще — открытие Visual Studio занимает до минуты потому что большая часть сложности этой IDE в том, что ей приходиться парсить сырые текстовые данные, формируя AST. Это требует кучу инструментария, который на порядки сложнее чем простое редактирование текста. Как вы понимаете для структурных данных, ситуация с этим намнооооого проще.
Тем не менее, если вы действительно работаете с проектом, то проще открыть его в IDE, а не прыгать по файлам через блокнот.
А я не работаю, мне быстренько посмотреть надо. Работаю я с соседним проектом.
И нет, это не надуманный случай. Я иногда сравниваю один и тот же кусок между несколькими мажорными версиями ПО, на интервале лет в пять-семь. Если я все это потащу в IDE — она немножко умрет.
А я не работаю, мне быстренько посмотреть надо.
Хорошо, MetaIDE рассчитываться быть модульной, в том числе запускаться с минимумом функционала, для мгновенного запуска. В этом плане работа с IDE будет мало отличаться от работы с блокнотом, но с возможностью расширения функционала по потребности.
Хорошо, MetaIDE рассчитываться быть модульной, в том числе запускаться с минимумом функционала, для мгновенного запуска.
"Рассчитывается". Угу.
Когда эта ваша "рассчитанная" IDE догонит grep и git log -S, тогда и будет смысл об этом говорить.
Когда эта ваша «рассчитанная» IDE догонит grep и git log -S, тогда и будет смысл об этом говорить.
Это уже какая-то вариация претензии «вы находитесь здесь». Вас совершенно никто не заставляет использовать MetaIDE для вашей работы. Более того, в статье написано что это пока только прототип. Предполагаться обсуждение уже проделанной работы и перспективности разработки, а пока оно скатываться в обсуждение конкретно ваших предпочтений, и того, что вы пользуетесь инструментарием с десятилетней выдержкой, что совершенно не корректно сравнивать с продуктом на стадии разработки.
Предполагаться обсуждение уже проделанной работы и перспективности разработки
Вот я и озвучиваю некоторые пункты, которые, на мой взгляд, делают эту разработку бесперспективной.
Вот я и озвучиваю некоторые пункты, которые, на мой взгляд, делают эту разработку бесперспективной.
Будущее наличие системы контроля версий уже заявлено. Скорость поиска не является какой либо проблемной, чтобы считаться бесперспективной. Более того, учитывая структурные данные, поиск может быть намного глубже чем regex. Можно написать скрипт, который найдет какое либо слово, включая множество параметров по типу наличия некой парент или чайлд ноды, что очень сложно провернуть в текстовом представлении информации.
Будущее наличие системы контроля версий уже заявлено.
Эх. Вы продолжаете меня не слышать. Я считаю, что ваша разработка бесперспективна именно потому, что вам приходится разрабатывать свою СКВ, свой поиск, свое все. При этом, будем честными, я не вижу, какие же такие гигантские преимущества я получаю от тотальной смены инфраструктуры.
Можно написать скрипт, который найдет какое либо слово, включая множество параметров по типу наличия некой парент или чайлд ноды, что очень сложно провернуть в текстовом представлении информации.
… именно поэтому есть поисковые механизмы, которые работают с AST, а не с текстовым представлением. Да, уже сейчас.
Я считаю, что ваша разработка бесперспективна именно потому, что вам приходится разрабатывать свою СКВ, свой поиск, свое все.
Вы считаете что продукт бесперспективный, потому что его нужно разрабатывать… Не слишком интересное утверждение.
При этом, будем честными, я не вижу, какие же такие гигантские преимущества я получаю от тотальной смены инфраструктуры.
Я уже несколько раз писал — работа со структурными данными сильно упрощает саму работу и время программиста. Если на решение задачи с текстовым форматом у вас уйдет в 10 раз больше времени, чем решение той же задачи со структурированными данными — разве это уже не достаточное преимущество?
… именно поэтому есть поисковые механизмы, которые работают с AST, а не с текстовым представлением. Да, уже сейчас.
Ничего не имею против. Вопрос сложности таких механизмов и аналога для структурных данных. Как вы понимаете, разница будет громадна и не в пользу текстового представления.
Вы считаете что продукт бесперспективный, потому что его нужно разрабатывать…
Нет, я считаю, что концепция бесперспективна, потому что для нее нужно разрабатывать слишком много всего.
Вот предположим, я решил принести миру новый язык. Если он текстовый, то все, что нужно, чтобы люди начали с ним работать — это компилятор, запускающийся из командной строки. Редакторы есть, СКВ есть, билд-машины заработают через консольку. Хочу выложить код на гитхаб? Пожалуйста. Хочу его собрать на аппвейоре — пожалуйста. Я выпустил один инструмент, и уже можно работать чуть ли не в проде.
Я хочу улучшить опыт людей в IDE? Можно пойти и написать language server + extension, и люди с VS Code получат опыт не сильно хуже работы с питоном. (Честно признаюсь, не знаю других настолько же легко расширяемых IDE, но думаю, что они все же существуют)
И чтобы попробовать, людям не надо отказываться от существующих инструментов или привычек, им не надо идти и разворачивать кучу нового тулинга с нуля: они просто создают новый репозиторий в СКВ, или даже просто кладут код в соседнюю папочку с уже существующим и продолжают работать.
А у вас так не выйдет, вам нужно будет выкатить все компоненты, прежде чем будет возможна разумная работа в проде.
Я уже несколько раз писал — работа со структурными данными сильно упрощает саму работу и время программиста. Если на решение задачи с текстовым форматом у вас уйдет в 10 раз больше времени, чем решение той же задачи со структурированными данными — разве это уже не достаточное преимущество?
"Если". Вы, действительно, уже несколько раз об этом писали, только пока нигде так и не смогли это аргументировать.
Вот я обычный такой разработчик line-of-business (если быть точным, ERP-системы). Веб, преимущественно бэкенд, плюс сервисная платформа в облаке. Можете привести пример регулярно встречающейся у меня задачи, которую ваш инструментарий гарантированно решит на порядок эффективнее, чем мой нынешний инструментарий? Понятное дело, что эта задача должна иметь ощутимый вклад в мою производительность, а то если я раз в день (это регулярно) трачу на что-то секунду вместо минуты (это на порядок), это не "сильно упрощает мою работу".
Ничего не имею против. Вопрос сложности таких механизмов и аналога для структурных данных. Как вы понимаете, разница будет громадна и не в пользу текстового представления.
Как я понимаю, написать свою СКВ будет сложнее, чем взять уже существующие средства метапрограммирования и анализа кода.
Вот предположим, я решил принести миру новый язык.
И согласно вашего же сценария — потенциальному разработчику нового языка для этого нужно изучить уйму других технологий чтобы это заработало. А потом объяснять пользователю как это все установить и настроить, чтобы все заработало. Удобство так себе. В случае разработки небольшого DSL будет потрачено больше времени, чем необходимо. В MetaIDE все находиться в одной инфраструктуре — вы пишите свой DSL пользуясь готовыми инструментами IDE. Затраты по времени намного меньше, упрощается деплой для пользователя, за счет виджетов работа с DSL будет намного проще чем набирание незнакомого для пользователя plain текста.
«Если». Вы, действительно, уже несколько раз об этом писали, только пока нигде так и не смогли это аргументировать.
Аргументация присутствует, просто читать нужно внимательнее.
которую ваш инструментарий гарантированно решит на порядок эффективнее, чем мой нынешний инструментарий?
Вы шутите? Мне несколько раз нужно перепечатывать одно и тоже? Впрочем, если вы не видите как вашу работу можно автоматизировать, то здесь никакие инструменты общего назначения не подойдут.
И согласно вашего же сценария — потенциальному разработчику нового языка для этого нужно изучить уйму других технологий чтобы это заработало.
Это каких? Зачем?
В случае разработки небольшого DSL будет потрачено больше времени, чем необходимо.
"Небольшой DSL" обычно пишется для конкретного применения, когда инфраструктура заранее известна.
Вот только я не про DSL говорю. Я говорю про полный язык программирования.
Вы шутите?
Нет, я совершенно серьезно.
Вы ни одной моей задачи пока в примерах не затронули.
Впрочем, если вы не видите как вашу работу можно автоматизировать
Знаете, я вот сегодня весь день занимаюсь тем, что аккуратно собираю сложный писпарковский скрипт для анализа данных в AWS. Там автоматизировать нельзя более-менее ничего. Этот скрипт — это и есть автоматизация.
Это каких? Зачем?
Да вы же сами все описали. Редакторы, СКВ, билд-машины, гитхаб. Еще изучать АПИ потенциальной IDE. Совсем разные технологии. Если вам нужен DSL на пару сотен строчек кода, у вас получиться либо сильный оверхед по технологиям, либо недоделаный сырой DSL с удобностю ниже плинтуса.
Вот скажем попросила вас знакомая написать небольшую программу для бухгалтерского учета. Разработка полноценной UI-шной программы слишком накладна, можно сделать веб страничку (уже проще, но с ограниченными возможностями), можно написать DSL но с существующими инструментами это либо сложно для программиста, либо ужасно сыро для пользователя. Типичным решением является таблица в Екселе — простая в разработке, но сомнительная по удобству.
Ну и как альтернатива — MetaIDE. Описать данные в виде дерева, составить для них виджеты, написать скрипты обработки дерева. Автоматом получая сохранение на диск, возможность отмены действий, и даже систему контроля версий с бекапами. Пользователю отдается исполняемый файл, который даже инсталлировать не нужно. Визуально это будет как полноценная программа, средств на разработку — минимум.
Вы ни одной моей задачи пока в примерах не затронули.
Я не занимаюсь вебом, с чего бы мне затрагивать ваши задачи..?
Да вы же сами все описали. Редакторы, СКВ, билд-машины, гитхаб.
Эээ… это набор базовых навыков разработчика.
Если вам нужен DSL на пару сотен строчек кода
Мне не нужен DSL на пару сотен строчек кода. Я говорил о полноценном языке программирования.
Ну и как альтернатива — MetaIDE. Описать данные в виде дерева, составить для них виджеты, написать скрипты обработки дерева. Автоматом получая сохранение на диск, возможность отмены действий, и даже систему контроля версий с бекапами. Пользователю отдается исполняемый файл, который даже инсталлировать не нужно. Визуально это будет как полноценная программа, средств на разработку — минимум.
Вы сейчас RAD описали. Я такое делал на MS Access в конце 90-ых. Да и сейчас для этого конструкторы есть, прямо скажем.
Я не занимаюсь вебом, с чего бы мне затрагивать ваши задачи..?
Вы же утверждаете, что ваш подход ускоряет разработку.
Эээ… это набор базовых навыков разработчика.
Вы уверенны? Если надо отдать разработку скрипта геймдизайнеру? Если надо написать скрипт по обработке данных датасайнтесту? Если отдать физические расчеты математику? Все эти люди могут поверхностно разбираться в программировании (по своей специальности) но ничего не слышать про гит, билд машины, а робота с консолью для них это уже хакерство. Не говоря уже про установку всего вашего софта, для простой работы.
Мне не нужен DSL на пару сотен строчек кода. Я говорил о полноценном языке программирования.
Разница между ЯП и DSL может быть размыта. Какой-то простой процедурный скриптовый язык не так уж далеко от DSL отошел. Тем не менее, меня больше интересуют простые DSL, так как с их помощью можно решать повседневные задачи, на них и основной акцент.
Я такое делал на MS Access в конце 90-ых. Да и сейчас для этого конструкторы есть, прямо скажем.
Как же вы без блокнотиков и СКВ тогда обходились… а вот моя разработка видите ли бесперспективная.
Вы же утверждаете, что ваш подход ускоряет разработку.
Да, ускоряет, путем автоматизации работы с кодом. В моем профиле работы таких требований валом, только они либо не решаются, либо обходяться костылями. Если вам никогда и нигде не нужно было автоматизировать работу с кодом, тогда вам явно не ко мне.
Вы уверенны?
Ага, полностью.
Если надо отдать разработку скрипта геймдизайнеру? Если надо написать скрипт по обработке данных датасайнтесту? Если отдать физические расчеты математику?
Я же написал выше: разработчика. Все эти люди — не разработчики.
Хотя, для справки, у меня в отделе два датасаентиста, и оба знают git и понимают, что такое билд, CI и CD.
Не говоря уже про установку всего вашего софта, для простой работы.
… какого "моего софта для простой работы"? Мне кажется, вы немножко не понимаете сценарий.
Тем не менее, меня больше интересуют простые DSL, так как с их помощью можно решать повседневные задачи, на них и основной акцент.
Ну вот вас интересуют простые DSL, но в моем примере был полноценный ЯП, целевая аудитория которого — разработчики.
Как же вы без блокнотиков и СКВ тогда обходились…
Хреново. Точнее, без блокнотика я так и не обходился, а про СКВ по молодости и глупости не знал.
Но СКВ — это одна из основных причин, почему я впоследствии слез с конструкторов, хотя сам их и разрабатывал.
вот моя разработка видите ли бесперспективная.
Не, если ваша разработка целится в нишу RAD — то пожалуйста, сколько угодно. Только не надо это путать с общим назначением.
Если вам никогда и нигде не нужно было автоматизировать работу с кодом, тогда вам явно не ко мне.
Ага, так и запишем: подход ускоряет разработку, но только в определенных сценариях. Ок.
Это, собственно, и ответ на ваш вопрос выше:
Я уже несколько раз писал — работа со структурными данными сильно упрощает саму работу и время программиста. Если на решение задачи с текстовым форматом у вас уйдет в 10 раз больше времени, чем решение той же задачи со структурированными данными — разве это уже не достаточное преимущество?
Так вот, не "программиста", а "программиста в определенных сценариях". И, поскольку у меня не уйдет, благодаря вашей парадигме, в десять раз меньше времени, то и преимуществ она для меня не несет.
Ага, полностью.
Я вот знаю людей, которые программированием решают свои задачи. И вполне обходятся без гита, VS Code и консольных систем сборок. Я так понимаю что для вас они вообще не программисты.
Все эти люди — не разработчики.
Нда уж. А если им таки нужно написать пару скриптов, то они должны обязательно изучить весь стек ваших технологий чтобы считаться разработчиками. Очень интересная у вас классификация.
Ну вот вас интересуют простые DSL, но в моем примере был полноценный ЯП, целевая аудитория которого — разработчики.
Ну так пользуйтесь всеми возможными технологиями для его реализации. Если вас единая и самодостаточная архитектура никак не устраивает, это совершенно не значит что это плохо для других.
Ага, так и запишем: подход ускоряет разработку, но только в определенных сценариях. Ок.
Я более чем уверен что в веб разработке есть множество мест, где автоматизация работы с кодом может упростить работу разработчика. Если вы их не видите, это не значит что их нет. Про СКВ вы раньше тоже не знали, сейчас без него никуда.
Из собственного крайне ограниченного опыта, припоминаю что было бы не плохо автоматически синхронизировать данные между кодом на фронте и кодом на беке, а не рассчитывать что сериализованые данные в json через js в точности также будут десериализованы и обработаны на любом языке бекенда.
Я так понимаю что для вас они вообще не программисты.
Они — не профессиональные разработчики.
А если им таки нужно написать пару скриптов, то они должны обязательно изучить весь стек ваших технологий чтобы считаться разработчиками.
Чтобы считаться разработчиками — да, должны.
Очень интересная у вас классификация.
Ну да, обычная такая классификация. Для того, чтобы считаться профессиональным Х, надо удовлетворять набору требований.
Если вас единая и самодостаточная архитектура никак не устраивает, это совершенно не значит что это плохо для других.
Нет, не значит. Но надо понимать ограничения "единой и самодостаточной архитектуры".
Из собственного крайне ограниченного опыта, припоминаю что было бы не плохо автоматически синхронизировать данные между кодом на фронте и кодом на беке, а не рассчитывать что сериализованые данные в json через js в точности также будут десериализованы и обработаны на любом языке бекенда.
Эта задача давно решена с помощью OpenAPI и прочих описаний схемы. А в рамках одного проекта — иногда прямо на уровне билда: поменяли бэк, собрали, поменялось описание интерфейса для фронта (если они вообще на разных языках, конечно), там даже схема не нужна, API бэка сама выступает схемой.
Они — не профессиональные разработчики.
Тем не менее, они вполне могут использовать MetaIDE в собственных целях. Это лучше чем Ексель, а для интеграции с другими наработками — лучше чем Ацес.
Но надо понимать ограничения «единой и самодостаточной архитектуры».
Если инструмент покрывает все нужные потребности и делает это достаточно удобно, то ограничения в выборе другого инструмента можно проигнорировать.
Тем не менее, они вполне могут использовать MetaIDE в собственных целях.
Могут. Мой пример от этого никак не изменится.
Если инструмент покрывает все нужные потребности и делает это достаточно удобно, то ограничения в выборе другого инструмента можно проигнорировать.
Можно, конечно. Все можно проигнорировать, пока это игнорирование не превратится в проблему, как превратилось оно в одном крупном ведомстве, которое долго пользовалось конструктором под лозунгом "мы тут все сами легко можем поправить", а потом выяснило, что любое изменение потенциально ломает систему, а откатить его уже невозможно.
Я не против применения инструментов по назначению. Я против утверждений вида "совершенно новый подход к написанию программ, открыва[ющий] для программиста новые горизонты в организации всего рабочего процесса".
Потому что я на ваш продукт смотрю с точки зрения профессионального разработчика, а внезапно выясняется, что на таких как я он вовсе и не ориентируется.
Я уже несколько раз спрашивал, какие же это места, чтобы переход — не добавление, а именно переход — на ваш инструмент принес столько пользы, чтобы оправдать полную смену инфраструктуры, но ответа пока так и не получил.
Вот ровно это и "не так".
Ответ уже был дан — в местах где автоматизация работы может упростить работу программиста. То что вы таких мест не видите, не значит что их нет.
Ну так продемонстрируйте.
Более того — вы уже пользуетесь автоматизацией которую создают тысячи разработчиков вашего ПО. Что позволяет мой подход — использование для тех же целей меньше человеко-часов.
… а вот это еще надо доказать.
То что у меня сделано просто и нативно, для дотнета потребовало разработки сотен людей.
Вам не приходило в голову, что может быть потому, что "для дотнета" функциональность немного шире?
Ну так продемонстрируйте.
Как читаются ваши сообщения — «я вот такой то разработчик, сделайте мне хорошо. То что вы что-то для других делаете, а не персонально под меня — не имеет никакого значения, а значит бесперспективно».
… а вот это еще надо доказать.
Надо доказать что другие люди пишут под вас софт и улучают его со временем, позволяя еще больше автоматизировать вашу работу?
Вам не приходило в голову, что может быть потому, что «для дотнета» функциональность немного шире?
Конечно шире. Но парсинг и обработка кода не должны занимать столько человеко-часов, что я и демонстрирую своими наработками.
Как читаются ваши сообщения — «я вот такой то разработчик, сделайте мне хорошо. То что вы что-то для других делаете, а не персонально под меня — не имеет никакого значения, а значит бесперспективно».
… хотя я всего лишь прошу продемонстрировать вашу пользу для других разработчиков.
Надо доказать что другие люди пишут под вас софт и улучают его со временем, позволяя еще больше автоматизировать вашу работу?
Нет, надо доказать, что ваш подход позволяет делать то же самое лучше, не жертвуя остальным.
Но парсинг и обработка кода не должны занимать столько человеко-часов
А вы уверены, что там именно парсинг занимает "столько человеко-часов", а не, скажем, оптимизирующий компилятор или генерация стейт-машин для асинков?
предположим, я решил принести миру новый язык. Если он текстовый, то все, что нужно, чтобы люди начали с ним работать — это компилятор, запускающийся из командной строки.
Если бы всё было так просто. Я, как человек, реально, а не предположительно, разработавший свой язык, могу сказать, что:
- Без подсветки синтаксиса никто на ваш язык даже не посмотрит.
- Без автодополнений никто на вашем языке писать не будет.
- Без подсветки ошибок по мере ввода ваш язык выбросят после первого же падения.
- Ну и, наконец, вам придётся ещё пол жизни потратить а то, чтобы убедить таких вот "не видящих перспектив" людей в том, что достоинства языка перевешивают необходимость его изучать.
Без подсветки синтаксиса никто на ваш язык даже не посмотрит.
Без автодополнений никто на вашем языке писать не будет.
Без подсветки ошибок по мере ввода ваш язык выбросят после первого же падения.
… и как же я пишу для CloudFormation в инструменте, где всего этого нет?
К предыдущему оратору добавлю еще и language server под VS Code, иначе другую IDE даже скачивать не буду. Если разработчик языка не пошевелился сделать LS, то язык для решения рабочих зачал не интересен. Демы/концепции посмотреть можно, но использовать я бы не стал.
О да. Но не выбрасываю же.
К предыдущему оратору добавлю еще и language server под VS Code, иначе другую IDE даже скачивать не буду. Если разработчик языка не пошевелился сделать LS, то язык для решения рабочих зачал не интересен. Демы/концепции посмотреть можно, но использовать я бы не стал.
Так про это было в исходном комментарии, сразу после "напишем компилятор":
Я хочу улучшить опыт людей в IDE? Можно пойти и написать language server + extension, и люди с VS Code получат опыт не сильно хуже работы с питоном. (Честно признаюсь, не знаю других настолько же легко расширяемых IDE, но думаю, что они все же существуют)
С такими уровнем аргументации вам сюда: https://fallacy.hyoo.ru/#search/selected=induction/filter=selected
Дмитрий, вам сюда. https://www.youtube.com/watch?v=SbgqR79nPd0
А то, что вы написали не проблема для решения описанного статье, в смысле, это реализуемо также как и в привычных IDE.
И еще — открытие Visual Studio занимает до минуты потому что большая часть сложности этой IDE в том, что ей приходиться парсить сырые текстовые данные, формируя AST.
Тут раньше было утверждение, что описываемое представление легче и удобнее для человека, а аргумент приводится вида 'IDE слишком сильно напрягается'. Кроме того, если Visual Studio открывается долго — то, я подозреваю, это означает, что там в коде классов сотни тысяч или даже миллионы.
Ваша IDE с проектом такого размера справится?
Текстовые IDE (в том числе Visual Studio) и без файлов могут открываться долго.
Ваша IDE с проектом такого размера справится?
Предполагаться что должна. Хотя требования к железу будут на порядки выше чем в обычном блокноте, хотя и сопоставимы с текстовой IDE которая смогла полностью распарсить текстовый код.
Это обычная IDE должна сильно напрягаться, поскольку для построения AST требуется дополнительный инструментарий. Если данные уже AST — значительная часть IDE сильно упрощается.
Мы все-таки про упращение работы и написание IDE (такое ощущение, что именно эта задача решается) или про упрощение работы человеком?
<вздыхая> И опять все про написание. Есть еще такая часть работы, которая про "что тут 10 лет назад такого понаписали, что хотели написать, можно ли это выкинуть, не сломав всего остального"
А потому выясняется, что оно таки ломается, потому что функционал ухитрились вызвать через какой-нибудь хитроизобретенный эквивалент eval(functionNamePrefix[i]+ functionNameSuffix[j] + "()").
Написав и встроив в систему полный по Тьюрингу интерпретатор конфиг-файлов, например.
И вот тут эта вот самая спец-IDE, для редактирования этих конфигов, про которую производитель уже лет 5 делает вид, что ее никогда не было — совершенно не радует.
Именно это и моментально включает 'не надо это использовать, если нет очень существенных преимуществ'. Это Тьюринг-полный конфиг и IDE к нему тоже рекламировался как "новый способ ....". А потом как-то сдулось, оставив после себя плохо поддерживаемое нечто, с чем в современных инструментах работать нельзя.
не надо это использовать, если нет очень существенных преимуществ
У меня есть опыт парсинга готовых текстов ЯП, разработки аддонов для существующих ИДЕ, также писал интерпретаторы для собственных ЯП. Могу с полной уверенностью сказать, что структурное представление исходного кода дает очень существенные преимущества, по сравнению с текстовым. И не только в плане разработки языка/ИДЕ, но и в плане рутинной работы с кодом.
привет. напишите в телеграм, пообщаемся (похожее делаю) @naliferov
'свой git' — очень большая проблема. Потому что он — один. И только ваша среда им пользоваться умеет. И удобный интерфейс к нему — неизвестно когда сделать сумеете.
А тот, который с текстовыми файлами работает — его кто только не умеет. И, причем, работать с простыми текстами не только git может, но и прочие Version Control, потому что сравнить/сделать слияние изменений в текстовых файла — стандартная задача, которую делать более-менее научились. И которую, если очень прижмет, можно даже руками сделать. А вот сделать это с файлами неизвестного человеко-непонятного формата — это безнадежно.
Плюс прочие внешние утилиты — в этом вашем формате простой текстовый поиск что выдает?
слияние изменений в текстовых файла — стандартная задача, которую делать более-менее научились.
Я перемёржил уже кучу веток и могу с определённостью сказать, что текущие инструменты слияния — полное дерьмо. То, что мы свыклись с их недостатками, когда они не понимают перемещения кода даже в рамках одного файла (что уж говорить про разные), — это ещё не "научились". Даже не близко. И пока мы мёржим текстовые файлики, а не AST, качественно проблема решена не будет.
Это всё не работает, ибо информация уже потеряна. Такие системы пытаются угадать по изменениям, что произошло в каждой ветке и что имел ввиду программист. Это не идёт ни в какое сравнение с системами, которые точно знают, что делал программист в каждой ветке.
Таких систем не существует. С остальным хорошо справляются текущие инструменты.
Я так понимаю, имеется в виду приблизительно такой сценарий:
Есть некий кусок кода. В одной ветке его вынесли в отдельную функцию, в другой — продолжают править как есть. И хочется, что при слиянии все изменения из второй ветки в эту новую функцию попали.
Существующий инструмент, действительно, такого обычно не сделает. И я не очень уверен, что это стоит делать автоматически, без генерации конфликта.
Потому что если вынесли в функцию — то скорее всего стали вызывать в двух местах. Совсем не очевидно, что влитые в эту функцию изменения для обоих мест смысл иметь будут.
Это не идёт ни в какое сравнение с системами, которые точно знают, что делал программист в каждой ветке.
… а это значит, что вам надо трекать именно каждое изменение, каждое действие программиста. Нет?
Именно.
Возникает разумный вопрос "с какой гранулярностью", а вслед за ним — "где столько ресурсов взять".
Программист не просто так делает изменения и корректность мержа не от механических повторений действий двух параллельно работающих программистов, а от слияния их намерений. Пример. первый программист делал исправления бага в фиче отправка «email по STMP», второй делал фичу «замена отправки по SMTP на отправку email через REST API». При мерже надо выбросить весь код первого программиста, даже если он нормально мержится, хотя если он что-то попутно чинил в других частях проекта, то это надо смержить. Оба решения «выкинуть» и «частично забрать» не лежат в плоскости изменений т.к. по изменениям не понятно что взять, а что оставить, они лежат в проскости намерений.
Попытки создания визуальных языков програмирования начались еще в 60-70х годах и до сих пор ни один из них не взлетел. По крайней мере среди языков общего назначения.
По причинам того что програмировать на них на самом деле тяжелее и дольше, читать и сравнивать код — просто боль.
Распостранение получили только визуальные языки которые позволяют «декларативно» собирать что то из «керпичиков». Например LabVIEW, язики описания материялов/шейдеров, визуальных эффктов для фильмов (compositing), и прочие.
Но все эти языки — очень специализированные и декларативные.
В мире разработки игр, визуальные языки получили больше распостранения. На них часто часто кодируется логика игры (не движок).
Но причиной этого является то, что нанимать много десятков програмистов для кодирования логики уровней и взаимодействия персонажей слишком дорого и легче нанять «креативных» людей и дать им визуальный язык программирования.
У меня есть движок диалогов с переменными и тьюринг-полной логикой (можно делать узлы без текста с условиями, циклы и т.д.), пробовал чужие проекты с похожей функциональностью. Регулярно пользуюсь нодовыми редакторами для написания шейдеров эффектов. Пробовал аналог Blueprint для Unity (Bolt)
Отзывы такие — механизмы ограниченно применимы, но, кажется, решают не ту проблему.
Проблема сложности остается почти в том же виде, но инструменты к ее решению еще меньше.
Преимущество целиком видимого дерева ограничивается только небольшим объемом плоскости — в этом смысле эффективно написать можно только простую логику.
При развитии логики те же шейдеры становятся не читаемыми.
Можно оформлять визуальные скрипты в блоки логики, уделять внимание красоте, но это имеет ограниченное применение. В текстовом виде хорошо отработаны механизмы работы со сложностью — ты можешь увидеть и функциональное представление, и данные, у тебя есть стандартизированные блоки, подсказки и т.д)
Возможно, для визуального представления такие механизмы тоже можно придумать, но пока, видимо, они не изобретены, либо похожи на механизмы текстовых редакторов.
Единственный на самом деле мощный инструмент — собрать ветвь в функцию и вызывать по имени. По сути очень быстро переходишь на символические ссылки и точно так же, как с текстовым представлением. Начинаешь держать граф зависимостей больше в голове, потому что на экране он целиком не помещается, а перекрестных ссылок довольно много.
Проблемы со слиянием тоже имеются — но тут да, можно доточить инструменты, либо подобрать форматы хранения данных под слияние.
Еще важный момент — текст на самом деле плотнее, чем визуалы блоков и переходов между ними.
Как итого явное преимущество видно в специфических ситуациях:
— Если нужно визуальное представление (в шейдерах можно рисовать промежуточные фазы переходов, в диалогах — портреты говорящих персонажей, очень удобно) — пока это самый важный кейс
— Контекст ограничен
— Много ветвящихся переходов (но не слишком много, иначе проще использовать абстрагирование и символические ссылки)
Минусы соответственно
— Слабые смежные инструменты — инфраструктура лучше подходит под текст, с этим сталкиваешься как раз в смежных ситуациях типа git
— Не масштабируется — большие блоксхемы плохо читаемы, нужны все равно инструменты абстрагирования (например, делить при создании схему на блоки с одним входом и выходом и на большой блок схеме рисовать уже эти блоки — те же функции)
— Обычно блок схемы так или иначе используют собственно текст — названия функций, аргументы. При масштабировании это тоже не очень видно, и тоже часто выраждается просто в список инструкций.
В итоге Я не соглашусь с топик-кастером — реально не проблема в длине текстов и скорости набора, а читаемость работает немного не так.
Еще интересное замечание — редактор диалогов для голосовых ботов от Just AI имеет упрощенную и про версию
Упрощенная выглядит как редактор нод, а про версия — IDE со специальным языком.
Хотя описывается на этом языке тоже граф по факту.
В итоге Я не соглашусь с топик-кастером — реально не проблема в длине текстов и скорости набора, а читаемость работает немного не так.
Вы дали отзыв на работу с Blueprint-ами и я даже могу с ним согласиться. Вот только предложный мною подход сильно отличается от того с чем вы работали (собственно по моим скриншотам это даже видно).
К вашему редактору развернутый комментарий будет такой:
Ваши тезисы:
«Программисту приходится не просто раз за разом набирать одни и те же сочетания клавиш, но и следить за правильностью форматирования кода, иначе компьютер просто откажется понимать, что в коде написано. Один забытый символ »;" может выдать совершенно невнятные ошибки компиляции/интерпретации. Более того — использование текстового представления программы не просто ставит дополнительные требования к программированию, но и сильно ограничивает возможности программиста для эффективного написания и использования кода. Также текстовое представление информации сильно усложняет анализ этой информации программным способом."
Я вообще не вижу обозначения и решения этих проблем. Скорее важных вещи в вашей системе 2:
— это виртуальная машина с единым контекстом, время жизни которого больше времени компиляции
— это необычный редактор, демонстрирующий различные представления AST этой машины
Первая идея не нова — к ней восходит оригинальные работы по ООП, архитектура микросервисов, горячая перезагрузка во многих движках (та же unity) и диалоговые режимы работы интерпретаторов типа js или python. Это не самая плохая идея, она во многом удобна, но содержит и минусы — неопределенный стейт, проблемы с порчей данных, необходимость дополнительных валидаций либо проблемы, связанные с их отсутствием, и т.д. Эта функциональность не связана с программированием через текст.
Вторая идея — это необычное IDE для этой виртуальной машины со множественными представлениями и гибкой кастомизацией. Эта идея тоже так или иначе имеет отражение в виде расширений редактора для обычных IDE (типа экранов верстки), кастомных компонентов в той же Unity. Тут сложно сказать, насколько она удобна, не попробовав — что то может быть удобно, что-то нет, благо тут очень большой простор для кастомизаций. Пожалуй самое основное, что можно выделить, это расположение блоков отдельно в пространстве — в текстовых редакторах по сути есть один тип представления — вертикальный список. Он же согласуется с самой простой идеей выполнения кода — поочередное выполнение операций. Все остальные связи (нелинейное выполнение операций) все равно сделано через «виртуальные» связи — имена ссылок, переменных, функций, классов и т.д. Опять же — современные IDE содержат и вкладки, и деревья и другие представляния. В нодовых редакторах возможны множественные визуальные связи — соединительные линии. Это позволяет описывать более сложные flow
На ваших скриншотах нет вообще ни того, ни другого — связность есть только в пределах кода одной ноды, остальные ноды представляют собой несвязанные карточки различных представлений (то честь чисто символические виртуальные ссылки по именам)
В принципе, возможно, ваши ноды поддерживают другие полезности — например, динамическую группировку представлений — к примеру представление объекта как данных, как операций, как flow, как связей тех, кто его использует и т.д
Тут не видно.
Но главное, есть куча других утверждений, и не понятно, почему они верны и как предложенная система их решает.
Например про компактность — конечно, наверное не зря люди пишут более компактные языки с минималистичным синтаксисом и без точек с запятой — это может чуть сэкономить, хотя и очень минорно. Ваши сокращения тоже решают эту проблему для ключевых слов, как и подсказки для текстов в современных IDE.
Но основная проблема — это ошибки логики, именах переменных и функций и их быстрый поиск в широком контексте. Проблема в том, что программы пишутся не на условных функциях и нодах, они пишутся на специальном языке, который изобретается вместе с программой. И подсказки действий над нодами — это подсказки базовых операторов, в то время как у программиста проблемы с операторами этого языка.
Список допустимых команд сделает язык немного удобнее для непрограммиста, это как есть. Но собрав допустимые функции в список или дерево их не сделать проще в доступе — их слишком много. По сути команды на клавиатуре — это и есть дерево на 26+10 ветвей вложенности, в различных ветках которого есть все потенциальные команды мира, которые к тому же контекстно связаны с естественной речью. Это очень мощный механизм, который можно сделать проще, но врятли можно сделать быстрее/удобнее, чем печать + контекстные подсказки.
Ваша среда, ее конкретные реализации нод, может успешно решать (или не решать эти проблемы), но за счет конкретной реализации ноды, а не как часть системы. По сути каждая нода будет такой же мини-IDE
Непонятно, как ваша система решает другие проблемы из мира программирования — контракты, допустимые инварианты данных, ошибочные ситуации.
В общем выглядит любопытно, но нет понимания, чем это решит мои каждодневные проблемы.
На ваших скриншотах нет вообще ни того, ни другого — связность есть только в пределах кода одной ноды, остальные ноды представляют собой несвязанные карточки различных представлений
Похоже вы не правильно прочитали скриншоты — окна (карточки) это ноды, но внутри них отображены десятки других нод — каждый оператор языка (или другая его конструкция), это отдельная нода, со своими под-нодами. Естественно, виджеты все это скрывают под более удобным текстовым представлением, хотя по желанию для тех же нод можно использовать другие виджеты. Я уже приводил пример скриншота:
здесь окно справа отображает АСТ ноды функции слева. Выделенная справа зеленой рамкой нода (виджет) также подсвечивается слева, поскольку это одна нода и та же нода, но отображенная двумя разными виджетами.
В смысле конечно не придется заниматься парсингом в смысле интерпретации, но вместо него программа регулярно будет проводить ровно обратную операцию — интерпретацию ноды в человекопонятное состояние виджета и применение изменений виджета на ноду. Все остальные правила — проверка допустимых команд и переменных, валидация данных, останется +- такими же. Просто правила будут проверяться не на коде, а в рантайме на компонентах виджета. Либо не будут проверяться, и тогда их нужно либо проверять рантайм либо это грозит плохой выразительностью языка или UB
Как по мне простой парсинг текста проще, а сложность такой системы сопоставима с современными статистическими анализаторами кода, подсказками и прочим.
Еще не совсем понятно, почему текстовое представление сильно усложняет программный анализ.
Не нужно заниматься парсингом текста, наборщику кода не нужно заботиться о сохранении структурной целостности текста с помощью дополнительных знаков/слов. Ошибки на подобии забытой скобки (которые очень сложно выявляются в тексте с помощью алгоритмов) при структурном подходе невозможны. Выравнивание табами/пробелами в код отсутствует как класс. Фактически АСТ избавленно от лишних данных форматирования кода, которые обязательны в текстовом представлении. Для валидации данных достаточно проверить типы нод и их целостность — если какая-либо нода в конкретном месте не ожидается, то можно выдать четкую и локализированую информацию про ошибку. Ну и также кастомизация отображения одних и тех же данных. Например класс можно отобразить как полноценный, или ограничиться только списком полей, или же показывать только функции/перегруженые функции и т.п. И все это будет живой код, а не статический список в каком-то текстовом листе.
программа регулярно будет проводить ровно обратную операцию — интерпретацию ноды в человекопонятное состояние виджета
Виджет крайне простой по своей архитектуре — он просто следит за данными ноды (а это примитивные типы) и отображает нужную информацию на экране (графикой или текстом). Здесь совершенно никакой сложности нет.
Собственно в нодовых редакторах действительно можно проверять валидность всех входов выходов и сразу говорить, что что-то не так подключено или не имеет правильных вариантов.
Текстовый ввод полагается на широкий контекст слов (в которых возможны ошибки) все время, поэтому каждая операция его пересчитывает.
Но ноды сами по себе не решают эту проблему — они могут решать ее ограничением вариантов, тогда система не будет такой гибкой, как текст. Например, можно выбирать доступные команды из списка — невозможно ошибиться, но сам выбор команд будет довольно неудобным деревом с разной размерностью ветвей либо длинным списком.
Либо это будет текст — и с ним возможны те же проблемы в миниатюре, что и с текстом кода.
В целом, для компиляторов тоже можно делать AST для всех ранних строк и перестраивать его только для измененных. Обычно, конечно так не делают, а делают целиком для юнитов/классов/файлов/типов, но тоже, соответственно не перестраивают AST каждый раз целиком.
И в целом идея не бесполезна — даже современные текстовые языки можно тащить в эту сторону.
Второй аспект — некорректный AST
Можно ошибиться в тексте программы + программа будет невалидной во время непосредственно написания.
Но точно так же и ноды должны следить за своей корректностью и валидировать свои изменения (например, можно сделать ноду, но не добавить в нее связи — она тоже может быть в некорректном состоянии)
Получается аналог «компиляции» переносится на уровень нод — микрокомпиляции, микровалидации. Но они остаются.
Например, мы видим в современных IDE механизм сворачивания части текста кода (фолдинг). В графических языках это пока не я нигде не видел. Они немного отстали в развитии.
И вообще, сокрытие ненужной части кода при выполнении программистом задач — это должно быть тенденцией всех IDE. Нужно автоматизировать сокрытие, вот это я еще нигде не видел.
Самое глупое — думать, что:
1. программист должен видеть максимум кода в каждый момент времени своей работы
2. автоматизация оптимального фолдинга — это что-то невозможное
Дело в том, что масштабирование в обычных текстовых языках — это не уменьшение и увеличение текста, это масштабирование в пространстве абстракций — когда твоя программа состоит из 10 функций, каждая функция может быть открыта — внутри нее тоже 10 функций, внутри каждой — свои подфункции.
В каждый момент времени ты видишь ограниченный контекст и потому можешь его понять — и по кусочкам понять весь проект.
Но это не бесплатное свойство текста, ты прилагаешь усилия для получения возможности такого концептуального масштабирования — огранизуешь код в абстракции, функции, классы, подписываешь их, описываешь интерфейсы и контракты.
Типичные графические редакторы (Я не работал с редактором автора, очевидно) содержат очень куцые инструменты для такого абстрагирования, поэтому с ростом проекта становятся нечитаемыми, как легаси скрипты сборки.
Можно добавить инструменты — блоки для сокрытия, но представляю, как можно автоматизировать их определение. Собственно в фолде текстового кода есть четкие границы абстракций, которые прописываются явно.
Если же в результате этого мы приходим к тому, что у тебя все равно на экране с десяток элементов, а остальные долны быть схлопнуты — в чем преимущество?
Можно придумать неплохие инструменты, который выковыривают автоматически определенную область связанного графа — типа все кейсы использования класса
Но, опять же, ничего не мешает сделать так же для текста.
Я не то чтобы радикальный скептик, но проблемы видны, их нужно пытаться концептуально решать.
Легко говорить сейчас, что люди скептически относились к реактивной авиации во времена ее зарождения и были не правы. Винтовые самолеты реально летали быстрее. Это видно ретроспективно, а в той точке скепсис оправдан. Возможно эти проблемы решаемы, а возможно — просто никто не вспомнит, что это была перспективная технология.
Все просто — фолдинг скрывает ненужные детали. Вопрос — вы представляете, как определить нужные и ненужные элементы программы в контексте ТЕКУЩЕЙ задачи программиста? Как понять, что сейчас программисту ненужно? Хм, вроде кажется проблематично, но решаемо!
Хм, вроде кажется проблематично, но решаемо!
Вы изобрели телепатию?
Но это не будет универсальным решением.
Даже среди двух программистов может быть 5 разных мнений, как декомпозировать 20 строчек кода, что уж говорить про универсальное решение.
Какие то случаи, например декомпозиция по линии model/view общепринятые, но всегда можно написать код, где это не очевидно.
Это занятие непосредственно связано с созданием контексного языка предметной области и решаемой задачей, соответственно типичные примеры можно найти только для хорошо проработанных областей. Для большинства новых областей создание языка предметной области — это и есть одна из основных задач программиста.
lair вам тоже
Ну да, задача автофолдинга не сводится к "присел и запрограммировал". Требуются исследования. Но и телепатия тут не при чем. Все банальненько: во-первых, программист обычно лазит в нескольких конкретных местах кода — запомнить, во-вторых, можно ненапряжненько спросить "какую задачу ты решаешь?", в третьих, если программист открыл функцию func1() и его задача касаема только этой функции, то все несвязанное можно скрыть, в четвертых, у программиста оперативная память 200 байт, поэтому показывать на экране 400 байт информации единовременно, не более.
Требуются исследования
А пока они не проведены, утверждать, что это решаемо, не стоит.
программист обычно лазит в нескольких конкретных местах кода — запомнить
SRSLY? У меня открытые вкладки на экран не помещаются.
можно ненапряжненько спросить "какую задачу ты решаешь?"
… и в каких терминах вы ответ ожидаете?
в третьих, если программист открыл функцию func1() и его задача касаема только этой функции
Но откуда узнать, чего касается его задача?
в четвертых, у программиста оперативная память 200 байт, поэтому показывать на экране 400 байт информации единовременно, не более.
Это, прямо скажем, вообще нелогично. Экран — это как раз то, что не поместилось в мою "оперативную" память, там должно быть то, что мне сейчас понадобится прочитать.
2. Например, есть мысль, в терминах «up» (абстрактнее), «down» (конкретнее), «left» (к причинам), «right» (к следствиям). Ну это такой навигатор получается хитрый ;-)
3. Чего касается задача — надо просто сформулировать все виды задач, которые решает программист с кодом. Вы этим каждый день (наверное) занимаетесь — что-то делаете с кодом. Можете сформулировать свои задачи и описать, как вы для этого перемещаетесь по тексту кода (возможно бестолково — туда-сюда, в силу отсутствия «автофолдинга»)?
4. Экран — да, это то, что вы хотите там увидеть, это очень правильная формулировка. Но вы же не хотите увидеть нечто сложное и непонятное, условно в 400 байт (или 4000 байт, хз). Нужно правильно разбить переваривание информации в несколько уровней-этапов. В этом заключается моя мысль.
Требуются исследования" — это для формализации задачки.
Нет, еще и для того, чтобы понять, решаема ли она.
Например, есть мысль, в терминах «up» (абстрактнее), «down» (конкретнее), «left» (к причинам), «right» (к следствиям). Ну это такой навигатор получается хитрый
Это не "какую задачу ты решаешь". Вот так легко взяли и подменили.
Можете сформулировать свои задачи и описать, как вы для этого перемещаетесь по тексту кода
Мне это зачем? На это понадобится несколько дней, в то время как вы уже сказали, что эта задача решаема.
Попробуйте вот решить одну простую задачу: я иду по коду, читая его, и натыкаюсь на неизвестный мне элемент (модуль, класс, метод — не важно). Я перехожу (в одно нажатие клавиши, конечно же) к этому элементу и что-то о нем нужное мне узнаю. В следующий раз, когда я читаю этот код, надо ли мне показывать дополнительную информацию об этом элементе, или нет?
Нужно правильно разбить переваривание информации в несколько уровней-этапов. В этом заключается моя мысль.
… ну да, нужно. Только никто пока не придумал, как это сделать автоматически для любого кода и любого программиста.
Это не «какую задачу ты решаешь». Вот так легко взяли и подменили.
Не подменил. Up/down/left/right — это указание новой задачи, отталкиваясь от текущей задачи (считаем, что она как-то определена). Относительное определение задачи. Как сделать абсолютное определение задачи — ну допустим ткнуть мышкой куда-то в код и выбрать один из десяти пунктов меню, я честно признаюсь, не знаю, как это бы выглядело… Но совершенно точно знаю, что мы выполняем с кодом буквально 5-10 типов задач. Примерный список: изучение особенности работы кода, локализация ошибки, внесение изменений в код, написание кода с нуля. Все, мой список пока кончился.)
Кстати говоря, семантическая навигация up/down/left/right неправда ли гениальна?) Повседневные вопросы: up — «а в целом как?», down — «ну-ка поподробнее...», left — «почему так?», right — «и что из этого?».
Семантическая навигация уже давно реализована в том или ином виде, но очень сыро, сырее моей идеи.
Только никто пока не придумал, как это сделать автоматически для любого кода и любого программиста.
Да, пока это инновационные вещи.) Но выше я уже говорил, задач-то всего 5-10 типов, помножить это на 100-1000-10000 объектов в коде. Получаем 1000, 10000, 100000 байт информации о задаче, которую надо выдернуть из программиста. Во-первых надо индексировать как-то дерево задач, чтобы сократить количество информации, итого 10-13-16 бит, если я не ошибся с методикой оценки...)
Даже вполне просто реализуемой семантической навигации вам хватит выше крыши. Я ее придумал в ходе дискуссии с вами.) Недооценивайте меня, пожелайте лучше побольше мотивации для исследований. И Corwal (автора статьи) не обижайте. Ок?
p.s. Моя хабракарма упала до -21.)))))
Up/down/left/right — это указание новой задачи, отталкиваясь от текущей задачи (считаем, что она как-то определена).
Но она не определена.
Кстати говоря, семантическая навигация up/down/left/right неправда ли гениальна?
Нет, не правда.
Даже вполне просто реализуемой семантической навигации вам хватит выше крыши. Я ее придумал в ходе дискуссии с вами.
Придумать легко. Сделать сложно.
Что такое "структурное программирование"? У вас в статье нет определения.
Структу́рное программи́рование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков.
ru.wikipedia.org/wiki/%D0%A1%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Да и вообще — кто бы не хотел писать программу попивая чай одной рукой, а второй — спокойно и эффективно набирать код.
Работа программиста состоит не в том, чтобы набирать код. Так что сомневаюсь, чтобы многим хотелось бы. И да, набрать код гораздо быстрее и удобнее, чем прокликать мышкой несколько кнопок. Да и читать удобнее, плотность информации на порядок выше. Все эти визуальные штуки применимы разве что в качестве простых dsl для людей не связанных с программированием. Ну и более менее сложные абстракции ими врядли можно выразить, а если можно, то читаемость скорее всего будет никакая.
Работа программиста состоит не в том, чтобы набирать код
К чашке чая надо было добавить тег сарказма, ну да ладно. Вопрос набора кода в среде где доступ к клавиатуре ограничен (ВР, планшеты) все также актуален.
Да и читать удобнее, плотность информации на порядок выше.
Можно было просто посмотреть на приведеные скриншоты, где плотность кода такая же, как в обычных текстовых языках. Впрочем, если учитывать что окна с кодом можно размещать в двухмерном пространстве (как в примере на КДПВ) то плотность даже повыше будет.
Все эти визуальные штуки применимы разве что в качестве простых dsl для людей не связанных с программированием
Да, это один из пунктов применения структурированной информации. В этом направлении работают JetBrains с их MPS, но там несколько другой подход.
Вопрос набора кода в среде где доступ к клавиатуре ограничен (ВР, планшеты) все также актуален.
Зачем набирать код в среде, где доступ к клавиатуре ограничен? Кто мешает использовать планшеты и VR с клавиатурой? И, собственно говоря, я могу придумать несколько способов ввода обычного текста без клавиатуры, которые поспорят по удобству с предложенным.
Можно было просто посмотреть на приведеные скриншоты, где плотность кода такая же, как в обычных текстовых языках.
Я вижу скриншоты с текстовым представлением и скриншоты с графическим. С графическим плотность ниже. С текстовым ничем не отличается от любой IDE. Открыть в IDE несколько окон — не велика задача, вот вам и двухмерное представление.
JetBrains с их MPS, но там несколько другой подход
Но даже у них не то, чтобы хорошо взлетело, кажется.
Вообще подход абсолютно не нов — в начале 2000-ых еще было модно рисовать UML диаграммы в какой-нибудь Rational Rose и схемы базы данных в ErWin и генерировать из этого код. Но что-то отмерло ведь за ненадобностью.
Зачем набирать код в среде, где доступ к клавиатуре ограничен?
А что плохого, если планшеты (или другие устройства) будут предлагать тоже удобство програмирования, что и ПК, и даже без клавиатуры?
И, собственно говоря, я могу придумать несколько способов ввода обычного текста без клавиатуры, которые поспорят по удобству с предложенным.
Вы уверенны? Быстрее чем нажатие одной/двух кнопок вместо пяти? Быстрее чем выбор пункта меню, который отображен на кране? Интересно послушать.
Я вижу скриншоты с текстовым представлением и скриншоты с графическим.
Текстовое представление на скриншотах это и есть визуальное отображение структуры кода. Слово break — это виджет с отдельной нодой. Как и все остальные языковые конструкции. Практически весь текст на скриншотах можно отнести к визуальному программированию — там нет ни одного много-строчного текста.
Но даже у них не то, чтобы хорошо взлетело, кажется.
Слишком сложный подход. Даже самый простой туториал занимал несколько страниц текста.
А что плохого, если планшеты (или другие устройства) будут предлагать тоже удобство програмирования, что и ПК, и даже без клавиатуры?
А в чем то же удобство? С планшетами вообще не удобно работать — экран маленький и тыкая в виджеты вы заслоняете часть его руками. И скорость ввода в любом случае будет ниже. Плюс нормальная разработка на планшете — ну это фантазии какие-то. Там же нет нормального доступа к файловое системе, никаких утилит нормальных, никакого vcs etc. Макисмум игрушка или тонкий клиент, чтобы быстро что-то поправить.
Вы уверенны? Быстрее чем нажатие одной/двух кнопок вместо пяти? Быстрее чем выбор пункта меню, который отображен на кране? Интересно послушать.
Если нужно делать быстрый ввод на планшете надо ориентироваться на что-то похожее на свайпы и предиктивный анализ. В VR можно еще перчатки какие-нибудь с обратной связью, например. Думаю можно вполне клавиатуру заменить.
Текстовое представление на скриншотах это и есть визуальное отображение структуры кода.
Ну тогда любая IDE это визуальное программирование. Даже VIM за средство визуального программирования сойдет.
Мне не нужен виджет, на который нужно нажимать. Плюс виджеты есть в любой современной IDE. Только там мышкой не нужно кликать и пункты меню выбирать, все можно с клавиатуры сделать. В чем преимущества вашего виджета то?
Вас оценивают на двойку как создателя «инфраструктуры». Да, действительно инфраструктура хреновенькая у вас.))) Зато IDE заслуживает похвал.
Многопользовательскую IDE запилить — это та ещё задача. Но можно найти нишу, где не требуется это, стартануть в ней, а потом замахнуться на более высокий уровень.
Лично я вижу смысл в разработке и продвижении стандарта некоего XML-языка, который, с одной стороны, будет поддерживаться компиляторами, git-инструментами, а с другой стороны, будет давать все необходимое для продвинутого GUI разработчиков.
Спорить с консерваторами о том, возможен ли продвинутый GUI или нет, бессмысленно. Они же не видят, что их IDE сплошь и рядом — это давно уже не Блокнот. Я бы им посоветовал на работе неделю поработать в Блокноте, а потом сказать что-то про преимущество чисто текстовых редакторов, а потом предложил бы проанализировать, являются ли инновации IDE сугубо текстовыми фишками или там все как-то сложно? А потом им следовало бы сделать реальные выводы, а не «фи, мне это не надо!».
Вас оценивают на двойку как создателя «инфраструктуры»
Именно так. Сама концепция визуального программирования тоже большие сомнения вызывает, но как раз его тут не очень много. Только пару непонятно как применимых деревьев на несколько экранов, которые с тем же успехом рядом в виде текстового дерева с отступами показаны.
А так — да, самое главное возражение, что то, как описывается — оно с существующими инструментами почти не совместимо. Было бы хранение, как я выше написал, в том же текстовом представлении, что человек видит — все было бы вполне адекватно.
Приделайте структурный редактор к популярному языку, проще оценить будет. Не заставляйте отказываться от ценного опыта. Структурированная информация безусловно удобней/проще в обработке. Хотя текст — это тоже структура, более изящная для передачи информации. Не задумывался, сложно ли писать логику текстом, хм. Наоборот вместо блок-схем и прочих визуальных штуковен проще выразить мысль на языке программирования или на естественном языке.
Задумался… кажется вы столкнулись с неким сложным языком, например с++, в котором много всяких мелких деталей, хитросплетений. И для решения сложностей программирования вы упростили сам язык. Структурный редактор всего лишь иной способ ввода, довольно спорный в удобстве.
Судя по всему, "работа с кодом" в данном случае понимается большей частью "автоматическая трансформация при помощи какого-то тут же написанного скрипта".
А можно все-таки накидать побольше примеров, где и как оно полезно и нужно? Ну, кроме переименования.
А то складывается впечатление, что упрощается работа программиста, что IDE пишет, а не работа того, кто этой IDE пользуется.
— завести новое значение в енуме для этого языка
— добавить текстовое описание этого значения (для отображения в UI)
— сделать привязку текста из ЯП к новому значению енума
— добавить функцию обработки нового ключевого слова
— связать новую функцию со значением енума
И это все нужно прописать в нескольких разных файлах исходных кодов. Для Delight пришлось несколько сотен таких действий сделать. Банальная и рутинная работа. Если такое разрабатывать на Delight — то создается небольшой DSL который выглядит как таблица (примет таблицы есть в статье) и пишется небольшой скрипт, который по данным таблицы вписывает код куда нужно. Дальше при добавлении нового ключевого слова достаточно заполнить пару полей таблицы и получить весь необходимый код одним нажатием клавиши. Также вместо навигации по исходникам, можно использовать эту же таблицу, чтобы найти нужную функцию.
Мне почему-то казалось, что когда нужно все это сделать, просто пользуются генераторами парсеров, а не прописывают руками все эти энумы и привязки где-то в коде. Не очень убедительно.
а как описывается грамматика?
Частенько сталкиваюсь с ситуацией, когда прекрасное решение не вписывается в контекст. Необходимо учитывать множество жестких условий. Автор планирует изменить условия (свой язык, git и прочая инфраструктура). Утопично. Шанс остается в узкой области, где сами условия способствуют выбору структурного редактора. Например, макрос для exsel описать, квесты на телефоне программировать без клавиатуры…
Кстати, а где этот редактор сейчас планировалось использовать? Для каждой области у нас свои особые языки программирования. Незаменимые=)
ИМХО — не взлетит. Слишком специфично. Может, как обучающая платформа займёт свою нишу.
Хороший вектор развития. Давно уже витает в воздухе, но пока не было хорошей реализации.
Не хотите Tree попробовать для AST представления? https://github.com/nin-jin/slides/tree/master/tree
И как в meta-ide добавить поддержку своего языка?
Структурное/визуальное программирование