Вот предположим, я решил принести миру новый язык.
И согласно вашего же сценария — потенциальному разработчику нового языка для этого нужно изучить уйму других технологий чтобы это заработало. А потом объяснять пользователю как это все установить и настроить, чтобы все заработало. Удобство так себе. В случае разработки небольшого DSL будет потрачено больше времени, чем необходимо. В MetaIDE все находиться в одной инфраструктуре — вы пишите свой DSL пользуясь готовыми инструментами IDE. Затраты по времени намного меньше, упрощается деплой для пользователя, за счет виджетов работа с DSL будет намного проще чем набирание незнакомого для пользователя plain текста.
«Если». Вы, действительно, уже несколько раз об этом писали, только пока нигде так и не смогли это аргументировать.
Аргументация присутствует, просто читать нужно внимательнее.
которую ваш инструментарий гарантированно решит на порядок эффективнее, чем мой нынешний инструментарий?
Вы шутите? Мне несколько раз нужно перепечатывать одно и тоже? Впрочем, если вы не видите как вашу работу можно автоматизировать, то здесь никакие инструменты общего назначения не подойдут.
Спасибо, в целом похожий подход. Жаль годиться только для dotnet и никакие DSL не поддерживаться. У меня такая функциональность заложена в основу и позволяет подобным образом обрабатывать любые структурные данные, созданные на системе нод.
Задача стоит не в упрощении некого языка, а в общем упрощении работы с кодом и данными для программиста, что вполне себе реализуется с помощью структурированного подхода в организации информации.
Работа программиста состоит не в том, чтобы набирать код
К чашке чая надо было добавить тег сарказма, ну да ладно. Вопрос набора кода в среде где доступ к клавиатуре ограничен (ВР, планшеты) все также актуален.
Да и читать удобнее, плотность информации на порядок выше.
Можно было просто посмотреть на приведеные скриншоты, где плотность кода такая же, как в обычных текстовых языках. Впрочем, если учитывать что окна с кодом можно размещать в двухмерном пространстве (как в примере на КДПВ) то плотность даже повыше будет.
Все эти визуальные штуки применимы разве что в качестве простых dsl для людей не связанных с программированием
Да, это один из пунктов применения структурированной информации. В этом направлении работают JetBrains с их MPS, но там несколько другой подход.
В итоге Я не соглашусь с топик-кастером — реально не проблема в длине текстов и скорости набора, а читаемость работает немного не так.
Вы дали отзыв на работу с Blueprint-ами и я даже могу с ним согласиться. Вот только предложный мною подход сильно отличается от того с чем вы работали (собственно по моим скриншотам это даже видно).
не надо это использовать, если нет очень существенных преимуществ
У меня есть опыт парсинга готовых текстов ЯП, разработки аддонов для существующих ИДЕ, также писал интерпретаторы для собственных ЯП. Могу с полной уверенностью сказать, что структурное представление исходного кода дает очень существенные преимущества, по сравнению с текстовым. И не только в плане разработки языка/ИДЕ, но и в плане рутинной работы с кодом.
Я считаю, что ваша разработка бесперспективна именно потому, что вам приходится разрабатывать свою СКВ, свой поиск, свое все.
Вы считаете что продукт бесперспективный, потому что его нужно разрабатывать… Не слишком интересное утверждение.
При этом, будем честными, я не вижу, какие же такие гигантские преимущества я получаю от тотальной смены инфраструктуры.
Я уже несколько раз писал — работа со структурными данными сильно упрощает саму работу и время программиста. Если на решение задачи с текстовым форматом у вас уйдет в 10 раз больше времени, чем решение той же задачи со структурированными данными — разве это уже не достаточное преимущество?
… именно поэтому есть поисковые механизмы, которые работают с AST, а не с текстовым представлением. Да, уже сейчас.
Ничего не имею против. Вопрос сложности таких механизмов и аналога для структурных данных. Как вы понимаете, разница будет громадна и не в пользу текстового представления.
В том что стандартные инструменты, не заточенные конкретно под этот тип файла, в случае конфликта покажут
«вот этот (бинарый) кусок в этой ветке изменился так, а вот в этой (тоже бинарный) — так. Какой вариант использовать будем?»
Это банальный вопрос наличия подходящего инструментария. Показать разницу в двух ветках дерева существенно проще чем разницу в двух фрагментах текста (которые по сути просто набор байт с \r\n разделителями). Вы раньше писали про XML — это как раз текстовые данные, с ними для слияния и будут проблемы, по причине сложностей самого текстового слияния.
Вот конкретно я, рандомный программист умею, и знаю людей, которые тоже умеют и делают. Работать с Syntax Tree, который предоставляет Roslyn удобно.
Можете привести конкретный пример что на добыло сделать и как это было сделано с помощю Roslyn. Интересно сравнить подходы.
Парсинг текста быстрый процесс, на крайний случай результат парсинга кешируется.
Даже близко не настолько быстрый, как изначальное хранение в AST. Просто распарсить еще не проблема, а вот связывание узлов дерева по имени узла может потребовать уйму времени.
Что плохого произойдет, если эти ноды на диске так и будут выглядеть, как тот текст, который 'представление'?
Для структурных данных будет возможность сериализации/десериализации в текстовый формат, похожий на тот что на скриншотах — с целю, чтобы фрагментами кода можно было поделиться в чате, на сайте или еще где. Но держать все изначально структурированные данные в текстовом формате, чтобы каждый раз при открытии проекта их парсить и линковать — это очень сильный оверхед по производительности и надежности данных.
Сначала приведите доказательство, что нужные инструменты не возможно реализовать на выбранной концепции (чего вы естественно не можете сделать, кроме утверждений «Мне не удобно», не понимая даже полностю всю концепцию).
С помощью рослина, на минуточку, пишутся рефакторинги в современной VS (под .net).
А конкретно Вы, можете писать крупные рефакторинги и генерировать нужный Вам код с помощью рослина? Я еще раз напомню, что не решаемость какой-либо задачи очень условна. В написание скриптов под структурные данные может и один человек. И это все нативно в MetaIDE, без подключения чужих проектов и изучения их АПИ. В roslyn на гитхабе 456 — контрибуторов. Пускай из них только 30 человек наиболее активные. Но разницу между 30 и 1 увидеть совсем не сложно.
Ну пока у вас претензии не к концепции, а к ограниченном наборе инструментов.
Хочу, и этот инструментарий у меня есть.
Инструмент для компиляции и статического анализа кода? Как он вам поможет в написании кода, или автоматизации рутинных действий с кодом, специфических для вашего проекта?
Казалось бы, это как раз и подтверждает то, что я сказал: текст наиболее человеко-читаем.
При этом не важно из чего он сгенерен.
Это не текст. Это только отображение данных нод в виде текста. Я даже могу скопировать эту функцию как текст, но данные которыми оперирует IDE/программист — это ноды (примерно то что в правом окне). Из чистого текста — там только названия переменных/функций. Текстовка виджетов к данным программы совершенно не относиться.
И? К чему тогда притензии к реализации инструментария MetaIDE, если вам все равно что в инструменте под капотом, и вы просто с этим работаете.
Я хочу
А управлять кодом посредства кода вы не хотите? Чтобы вместо ручного рефакторинга, который не поддерживается вашей IDE, можно было бы написать небольшой скрипт который все сделает, уменьшая тем самым «человеческий фактор» с возможностю пропустить фрагмент кода или опечататся. Выполнять совершенно рутинную и легко автоматизируемую работу с помощью скриптов, а не перекидания буковок, не хотите? Конвертировать даные в любой удобный формат, а не писать парсер с лексером для свободной текстовой граматики тоже не хотите? Ну тогда это все точно не для вас.
Я на экране, тем не менее, вижу просто текст. С какими-то визуальными элементами, которые слабо отличаются от того, что я имею в любой другой тексто-ориентированной IDE.
Проще таки было бы прочитать статью, где указанно, что виджеты сделаны в форме текстовых элементов, так как такое представление лучше подходит для программирования. Вот скриншот как пример:
окно слева — обычные виджеты для отображения кода Delight,
окно справа — теже самые ноды, но отображены виджетами для просмотра AST.
(Я бы мог тоже самое скинуть текстом, а не картинкой, но боюсь, опять возникнет недопонимание)
Разговор ведь про совершенно новую систему, а не про адаптацию существующего кода/конфигов под новую инфраструктуру. Естественно что при переходе с С++ на Rust, ваши «хитроизобретенные эквиваленты eval» ничем не помогут.
И согласно вашего же сценария — потенциальному разработчику нового языка для этого нужно изучить уйму других технологий чтобы это заработало. А потом объяснять пользователю как это все установить и настроить, чтобы все заработало. Удобство так себе. В случае разработки небольшого DSL будет потрачено больше времени, чем необходимо. В MetaIDE все находиться в одной инфраструктуре — вы пишите свой DSL пользуясь готовыми инструментами IDE. Затраты по времени намного меньше, упрощается деплой для пользователя, за счет виджетов работа с DSL будет намного проще чем набирание незнакомого для пользователя plain текста.
Аргументация присутствует, просто читать нужно внимательнее.
Вы шутите? Мне несколько раз нужно перепечатывать одно и тоже? Впрочем, если вы не видите как вашу работу можно автоматизировать, то здесь никакие инструменты общего назначения не подойдут.
К чашке чая надо было добавить тег сарказма, ну да ладно. Вопрос набора кода в среде где доступ к клавиатуре ограничен (ВР, планшеты) все также актуален.
Можно было просто посмотреть на приведеные скриншоты, где плотность кода такая же, как в обычных текстовых языках. Впрочем, если учитывать что окна с кодом можно размещать в двухмерном пространстве (как в примере на КДПВ) то плотность даже повыше будет.
Да, это один из пунктов применения структурированной информации. В этом направлении работают JetBrains с их MPS, но там несколько другой подход.
Вы дали отзыв на работу с Blueprint-ами и я даже могу с ним согласиться. Вот только предложный мною подход сильно отличается от того с чем вы работали (собственно по моим скриншотам это даже видно).
У меня есть опыт парсинга готовых текстов ЯП, разработки аддонов для существующих ИДЕ, также писал интерпретаторы для собственных ЯП. Могу с полной уверенностью сказать, что структурное представление исходного кода дает очень существенные преимущества, по сравнению с текстовым. И не только в плане разработки языка/ИДЕ, но и в плане рутинной работы с кодом.
Вы считаете что продукт бесперспективный, потому что его нужно разрабатывать… Не слишком интересное утверждение.
Я уже несколько раз писал — работа со структурными данными сильно упрощает саму работу и время программиста. Если на решение задачи с текстовым форматом у вас уйдет в 10 раз больше времени, чем решение той же задачи со структурированными данными — разве это уже не достаточное преимущество?
Ничего не имею против. Вопрос сложности таких механизмов и аналога для структурных данных. Как вы понимаете, разница будет громадна и не в пользу текстового представления.
Это банальный вопрос наличия подходящего инструментария. Показать разницу в двух ветках дерева существенно проще чем разницу в двух фрагментах текста (которые по сути просто набор байт с \r\n разделителями). Вы раньше писали про XML — это как раз текстовые данные, с ними для слияния и будут проблемы, по причине сложностей самого текстового слияния.
Можете привести конкретный пример что на добыло сделать и как это было сделано с помощю Roslyn. Интересно сравнить подходы.
Даже близко не настолько быстрый, как изначальное хранение в AST. Просто распарсить еще не проблема, а вот связывание узлов дерева по имени узла может потребовать уйму времени.
Да, много. Но не настолько, чтобы с этим было невозможно справиться.
Думаю вы понимаете что C# в MetaIDE не подерживаеться. С таким же успехом можно спросить про программирование Паскаля на платформе для C++.
Для структурных данных будет возможность сериализации/десериализации в текстовый формат, похожий на тот что на скриншотах — с целю, чтобы фрагментами кода можно было поделиться в чате, на сайте или еще где. Но держать все изначально структурированные данные в текстовом формате, чтобы каждый раз при открытии проекта их парсить и линковать — это очень сильный оверхед по производительности и надежности данных.
Сначала приведите доказательство, что нужные инструменты не возможно реализовать на выбранной концепции (чего вы естественно не можете сделать, кроме утверждений «Мне не удобно», не понимая даже полностю всю концепцию).
А конкретно Вы, можете писать крупные рефакторинги и генерировать нужный Вам код с помощью рослина? Я еще раз напомню, что не решаемость какой-либо задачи очень условна. В написание скриптов под структурные данные может и один человек. И это все нативно в MetaIDE, без подключения чужих проектов и изучения их АПИ. В roslyn на гитхабе 456 — контрибуторов. Пускай из них только 30 человек наиболее активные. Но разницу между 30 и 1 увидеть совсем не сложно.
Ну пока у вас претензии не к концепции, а к ограниченном наборе инструментов.
Инструмент для компиляции и статического анализа кода? Как он вам поможет в написании кода, или автоматизации рутинных действий с кодом, специфических для вашего проекта?
Это не текст. Это только отображение данных нод в виде текста. Я даже могу скопировать эту функцию как текст, но данные которыми оперирует IDE/программист — это ноды (примерно то что в правом окне). Из чистого текста — там только названия переменных/функций. Текстовка виджетов к данным программы совершенно не относиться.
И? К чему тогда притензии к реализации инструментария MetaIDE, если вам все равно что в инструменте под капотом, и вы просто с этим работаете.
А управлять кодом посредства кода вы не хотите? Чтобы вместо ручного рефакторинга, который не поддерживается вашей IDE, можно было бы написать небольшой скрипт который все сделает, уменьшая тем самым «человеческий фактор» с возможностю пропустить фрагмент кода или опечататся. Выполнять совершенно рутинную и легко автоматизируемую работу с помощью скриптов, а не перекидания буковок, не хотите? Конвертировать даные в любой удобный формат, а не писать парсер с лексером для свободной текстовой граматики тоже не хотите? Ну тогда это все точно не для вас.
Проще таки было бы прочитать статью, где указанно, что виджеты сделаны в форме текстовых элементов, так как такое представление лучше подходит для программирования. Вот скриншот как пример:
окно слева — обычные виджеты для отображения кода Delight,
окно справа — теже самые ноды, но отображены виджетами для просмотра AST.
(Я бы мог тоже самое скинуть текстом, а не картинкой, но боюсь, опять возникнет недопонимание)