Вот я и озвучиваю некоторые пункты, которые, на мой взгляд, делают эту разработку бесперспективной.
Будущее наличие системы контроля версий уже заявлено. Скорость поиска не является какой либо проблемной, чтобы считаться бесперспективной. Более того, учитывая структурные данные, поиск может быть намного глубже чем regex. Можно написать скрипт, который найдет какое либо слово, включая множество параметров по типу наличия некой парент или чайлд ноды, что очень сложно провернуть в текстовом представлении информации.
Когда эта ваша «рассчитанная» IDE догонит grep и git log -S, тогда и будет смысл об этом говорить.
Это уже какая-то вариация претензии «вы находитесь здесь». Вас совершенно никто не заставляет использовать MetaIDE для вашей работы. Более того, в статье написано что это пока только прототип. Предполагаться обсуждение уже проделанной работы и перспективности разработки, а пока оно скатываться в обсуждение конкретно ваших предпочтений, и того, что вы пользуетесь инструментарием с десятилетней выдержкой, что совершенно не корректно сравнивать с продуктом на стадии разработки.
Про все вместе — и упрощение работы программиста и упрощение работы IDE. Разработка IDE в статье приводиться как пример упрощения написания кода в целом.
Это обычная IDE должна сильно напрягаться, поскольку для построения AST требуется дополнительный инструментарий. Если данные уже AST — значительная часть IDE сильно упрощается.
Текстовые IDE (в том числе Visual Studio) и без файлов могут открываться долго.
Ваша IDE с проектом такого размера справится?
Предполагаться что должна. Хотя требования к железу будут на порядки выше чем в обычном блокноте, хотя и сопоставимы с текстовой IDE которая смогла полностью распарсить текстовый код.
Хорошо, MetaIDE рассчитываться быть модульной, в том числе запускаться с минимумом функционала, для мгновенного запуска. В этом плане работа с IDE будет мало отличаться от работы с блокнотом, но с возможностью расширения функционала по потребности.
Я же говорю: вырожденный случай «структура из одного элемента, эквивалентного тексту», я не рассматриваю.
эм… В статье же описанно, что любой оператор (или ключевое слово, переменная, функция и т.п.) это отдельная нода. Одна функция это структура из сотни элементов.
Это пример графа.
Тем не менее, в основе того графа лежат такие же ноды, что и при отображении Delight.
Вот в том-то и дело. Текст человекочитаем без виджетов.
Вы можете прочитать биты в памяти без какой либо помощи? Сомневаюсь. Попробуйте сначала проанализировать все необходимые алгоритмы для того чтобы читать и менять код в каком либо самом простом «блокноте», а потом уже говорите про человекоудобность. В общем случае вы даже не замечаете уйму кода, которая используется для вашей работы в «блокноте». Для структурной IDE это мало чем отличается.
… а теперь выясняется, что случая «невозможная» нет. Гм-гм.
Мы вроде бы не бессмертны. Если какая то задача слишком сложная для реализации, то вы либо не возметесь за нее, либо выберете подходящий инструмент, который таки позволит решить эту задачу в приемлемые строки.
Возвращаемся к тезису, что IDE недостаточно. Я не хочу быть привязанным только и исключительно к вашей IDE.
Но привязка к исключительно не вашим блокнотам/IDE/ОС/железу вас совершенно не смущает.
Которого нет. И весь существующий — не подойдет.
Критика так себе. Можно было ограничиться охотой зубами и жильем в пещере, ведь всего остального банально не было, а что создавалось — не совместимо с зубами.
Потому что ход мысли такой.
А в коде (файле) где вы забыли про переименование сущности внезапно возникнет ошибка связывания по не правильному имени. Любой подход имеет свои не удобности, которые можно обходить разными способами.
Тем не менее, если вы действительно работаете с проектом, то проще открыть его в IDE, а не прыгать по файлам через блокнот.
И еще — открытие Visual Studio занимает до минуты потому что большая часть сложности этой IDE в том, что ей приходиться парсить сырые текстовые данные, формируя AST. Это требует кучу инструментария, который на порядки сложнее чем простое редактирование текста. Как вы понимаете для структурных данных, ситуация с этим намнооооого проще.
В статье есть скриншоты с языком Delight. Они полностью эквивалентны обычному текстовому представлению. Также как и представление языка разметки нод. Для mindmaps, как видите, представление намного более удобнее, чем таковое в текстовом формате.
Структурных — не вижу.
Все данные на скриншотах представлены в структурном формате с помощью человекочитаемых виджетов.
Приведите пример невозможной обработки.
Нет такого случая как «невозможная обработка». Сырые текстовые данные (при условии безошибочного синтаксиса) вполне успешно могут быть обработаны программно. Вопрос только в сложности обработки — для структурных данных она может быть элементарной, для текстовой — слишком сложной для реализации. С++ существует почти 40 лет, а для IDE все еще огромные трудности в понимании его кода. Справляются только компиляторы, но про завышенную сложность С++ компилятора, думаю вы и так в курсе.
И чем это отличается от вашего формата, который тоже «не всегда и не везде поддерживается»?
В пределах IDE — он всегда и везде поддерживаться. За пределами — вопрос наличия стороннего инструментария.
… ну то есть я удалил какое-то свойство, потом подумал, создал новое с таким же именем — и все клиенты поломались?
А зачем вам удалять и создавать заново данные, которые вам таки нужны? Логичнее будет модифицировать сущность, а не пересоздавать все заново.
Впрочем для Delight такое можно делать — IDE сделает перевязку нод на основании имени некоторых сущностей.
вы говорите не о человекопонятности, а об обработке.
Структурные данные могут быть не менее человекопонятными чем обычные текстовые. В некоторых случаях даже более читаемые чем текстовый формат (примеры есть в статье). При том, они дают доступ к обработке данных, которая слишком сложная, либо не возможная в текстовом представлении.
А во-вторых, моя IDE успешно осуществляет эту операцию, несмотря на то, что исходники лежат в текстовых файлах.
Такое не всегда и не везде поддерживаться. В структурном формате — это нативная часть самого формата, а не инструментов для его обработки.
ссылка будет по чему? По имени? По какому-то идентификатору?
Ссылка будет по идентификатору, уникальному для каждой ноды.
Попробуйте провернуть такой трюк с С++, особенно при использовании макросов/темплейтов.
во всех остальных местах сразу будет показана ошибка «обращение к неизвестному полю».
Это уже благодаря компилятору, который (внимание) стоит AST чтобы разобраться что там в тексте написано. У программиста нет прямого доступа к этому AST, хотя порой оно очень пригодилось бы.
«не так уж востребовано» — потому что подавляющая часть работы проходит в IDE и даже та часть которая в «блокноте» может проходить в IDE. Без «блокнота» вы можете обойтись, без IDE в крупном проекте — нет (если, конечно, цените свое время).
Уже писал — работа в IDE существенно упрощает работу программиста. Можно конечно весь код в блокноте писать/редактировать, но на это уйдет гораздо больше времени чем в IDE и в результате может получится менее надежный код. Если что, то для редактирования системы нод тоже можно написать минимальный редактор по типу «блокнота».
Самый простой пример. В коде программы у вас описан класс, в котором есть поле Name (член класса, функция или проперти, здесь не важно). Это поле используется в десяти местах. Возникла необходимость разбить это поле на два поля FirstName и SecondName. Вот только текстовый поиск выдаст вам более сотни результатов, так как общее слово Name используется в множестве разный мест. С структурным представлением информации, вам просто нужно взять все ноды которые ссылаются на нужное вам поле и проверить код только в этих местах.
Основное преимущество структурных данных в том, что эти данные изначально максимально понятны для автоматизированной обработки информации. Это позволяет очень гибко работать с данными, без необходимости ручного поиска и исправления (если вам нужно сделать какой либо рефакторинг данных). Хранение низкоуровневых данных в виде текста не просто ломает некоторые преимущества такого подхода, но и не так уж и востребовано при программировании. Да, обычный исходник можно отрыть в каком-то «блокноте», но полноценно работать с исходным кодом все таки на несколько порядков проще и надежнее в конкретной IDE а не в блокноте.
Как и в бинарном формате — простой поиск покажет что в файле есть нужная строка. Для просмотра содержимого необходима подходящая программа. Как-то форматы данных для офисных программ (где поиск работает также) никого не смущают.
Опять же, предлагаться не просто «неизвестный человеко-непонятный формат», а вполне конкретное представление данных в виде нод, что не так уж и сложно. Фактически бинарными форматами (типа Protocol buffers) сейчас много кто пользуется, в MetaIDE все еще больше стандартизировано. Вы ведь текстовый формат тоже не совсем руками битики прямо в памяти машины меняете, а пользуетесь определенными инструментами. Вопрос только в наличии необходимого инструмента.
Большинство технологий начиналось с нуля. Без нужного инструментария и с отрывом от текущей инфраструктуры. Это не повод забрасывать гнилыми овощами все что находится на стадии разработки.
Будущее наличие системы контроля версий уже заявлено. Скорость поиска не является какой либо проблемной, чтобы считаться бесперспективной. Более того, учитывая структурные данные, поиск может быть намного глубже чем regex. Можно написать скрипт, который найдет какое либо слово, включая множество параметров по типу наличия некой парент или чайлд ноды, что очень сложно провернуть в текстовом представлении информации.
Это уже какая-то вариация претензии «вы находитесь здесь». Вас совершенно никто не заставляет использовать MetaIDE для вашей работы. Более того, в статье написано что это пока только прототип. Предполагаться обсуждение уже проделанной работы и перспективности разработки, а пока оно скатываться в обсуждение конкретно ваших предпочтений, и того, что вы пользуетесь инструментарием с десятилетней выдержкой, что совершенно не корректно сравнивать с продуктом на стадии разработки.
Текстовые IDE (в том числе Visual Studio) и без файлов могут открываться долго.
Предполагаться что должна. Хотя требования к железу будут на порядки выше чем в обычном блокноте, хотя и сопоставимы с текстовой IDE которая смогла полностью распарсить текстовый код.
Хорошо, MetaIDE рассчитываться быть модульной, в том числе запускаться с минимумом функционала, для мгновенного запуска. В этом плане работа с IDE будет мало отличаться от работы с блокнотом, но с возможностью расширения функционала по потребности.
эм… В статье же описанно, что любой оператор (или ключевое слово, переменная, функция и т.п.) это отдельная нода. Одна функция это структура из сотни элементов.
Тем не менее, в основе того графа лежат такие же ноды, что и при отображении Delight.
Вы можете прочитать биты в памяти без какой либо помощи? Сомневаюсь. Попробуйте сначала проанализировать все необходимые алгоритмы для того чтобы читать и менять код в каком либо самом простом «блокноте», а потом уже говорите про человекоудобность. В общем случае вы даже не замечаете уйму кода, которая используется для вашей работы в «блокноте». Для структурной IDE это мало чем отличается.
Мы вроде бы не бессмертны. Если какая то задача слишком сложная для реализации, то вы либо не возметесь за нее, либо выберете подходящий инструмент, который таки позволит решить эту задачу в приемлемые строки.
Но привязка к исключительно не вашим блокнотам/IDE/ОС/железу вас совершенно не смущает.
Критика так себе. Можно было ограничиться охотой зубами и жильем в пещере, ведь всего остального банально не было, а что создавалось — не совместимо с зубами.
А в коде (файле) где вы забыли про переименование сущности внезапно возникнет ошибка связывания по не правильному имени. Любой подход имеет свои не удобности, которые можно обходить разными способами.
И еще — открытие Visual Studio занимает до минуты потому что большая часть сложности этой IDE в том, что ей приходиться парсить сырые текстовые данные, формируя AST. Это требует кучу инструментария, который на порядки сложнее чем простое редактирование текста. Как вы понимаете для структурных данных, ситуация с этим намнооооого проще.
В статье есть скриншоты с языком Delight. Они полностью эквивалентны обычному текстовому представлению. Также как и представление языка разметки нод. Для mindmaps, как видите, представление намного более удобнее, чем таковое в текстовом формате.
Все данные на скриншотах представлены в структурном формате с помощью человекочитаемых виджетов.
Нет такого случая как «невозможная обработка». Сырые текстовые данные (при условии безошибочного синтаксиса) вполне успешно могут быть обработаны программно. Вопрос только в сложности обработки — для структурных данных она может быть элементарной, для текстовой — слишком сложной для реализации. С++ существует почти 40 лет, а для IDE все еще огромные трудности в понимании его кода. Справляются только компиляторы, но про завышенную сложность С++ компилятора, думаю вы и так в курсе.
В пределах IDE — он всегда и везде поддерживаться. За пределами — вопрос наличия стороннего инструментария.
А зачем вам удалять и создавать заново данные, которые вам таки нужны? Логичнее будет модифицировать сущность, а не пересоздавать все заново.
Впрочем для Delight такое можно делать — IDE сделает перевязку нод на основании имени некоторых сущностей.
Структурные данные могут быть не менее человекопонятными чем обычные текстовые. В некоторых случаях даже более читаемые чем текстовый формат (примеры есть в статье). При том, они дают доступ к обработке данных, которая слишком сложная, либо не возможная в текстовом представлении.
Такое не всегда и не везде поддерживаться. В структурном формате — это нативная часть самого формата, а не инструментов для его обработки.
Ссылка будет по идентификатору, уникальному для каждой ноды.
Попробуйте провернуть такой трюк с С++, особенно при использовании макросов/темплейтов.
Это уже благодаря компилятору, который (внимание) стоит AST чтобы разобраться что там в тексте написано. У программиста нет прямого доступа к этому AST, хотя порой оно очень пригодилось бы.