Оно все-таки для писателей. Это им не надо. Может, какой-нибудь плагин и есть. Но зато, например, в Quoll Writer, можно вставит здоровый кусок, который анализируешь, в качестве главы.
Прямо там же по тексту выделить мышкой нужные куски и термины ('персонаж'), сделать про них 'заметки на полях' ('Plot Outline'). Потом накидать рядом ('информация о мире') кусочки мыслей и и прочих записей и все это слинковать друг с другом. Причем про 'персонажи' программа сразу строит ссылки, в какой главе он встречался. Простым совпадением по подстроке, но тоже сильно помогает.
Приложения 'для писателей'. Они позиционируются иначе, но, как ни странно, неплохо подходят и для заметок. Потому что все эти 'сюжет', 'персонажи', 'объекты мира', древовидная структура глав — применимы и для реального мира.
Мне почему-то казалось, что когда нужно все это сделать, просто пользуются генераторами парсеров, а не прописывают руками все эти энумы и привязки где-то в коде. Не очень убедительно.
Вас оценивают на двойку как создателя «инфраструктуры»
Именно так. Сама концепция визуального программирования тоже большие сомнения вызывает, но как раз его тут не очень много. Только пару непонятно как применимых деревьев на несколько экранов, которые с тем же успехом рядом в виде текстового дерева с отступами показаны.
А так — да, самое главное возражение, что то, как описывается — оно с существующими инструментами почти не совместимо. Было бы хранение, как я выше написал, в том же текстовом представлении, что человек видит — все было бы вполне адекватно.
Судя по всему, "работа с кодом" в данном случае понимается большей частью "автоматическая трансформация при помощи какого-то тут же написанного скрипта".
А можно все-таки накидать побольше примеров, где и как оно полезно и нужно? Ну, кроме переименования.
А то складывается впечатление, что упрощается работа программиста, что IDE пишет, а не работа того, кто этой IDE пользуется.
Речь идет не о тех данных и не о том коде, с которыми идет работа (не человеком, причем — он как раз с текстовым представлением работает).
А о тех, что на диске лежат и которые другие инструменты, которые не IDE, видят.
Что плохого произойдет, если эти ноды на диске так и будут выглядеть, как тот текст, который 'представление'?
Именно это и моментально включает 'не надо это использовать, если нет очень существенных преимуществ'. Это Тьюринг-полный конфиг и IDE к нему тоже рекламировался как "новый способ ....". А потом как-то сдулось, оставив после себя плохо поддерживаемое нечто, с чем в современных инструментах работать нельзя.
<вздыхая> И опять все про написание. Есть еще такая часть работы, которая про "что тут 10 лет назад такого понаписали, что хотели написать, можно ли это выкинуть, не сломав всего остального"
А потому выясняется, что оно таки ломается, потому что функционал ухитрились вызвать через какой-нибудь хитроизобретенный эквивалент eval(functionNamePrefix[i]+ functionNameSuffix[j] + "()").
Написав и встроив в систему полный по Тьюрингу интерпретатор конфиг-файлов, например.
И вот тут эта вот самая спец-IDE, для редактирования этих конфигов, про которую производитель уже лет 5 делает вид, что ее никогда не было — совершенно не радует.
Может я недопонял, в чем сложность мержа нетекстовых кодов, но я сталкивался с компараторами графических ЯП (Сименс).
В том что стандартные инструменты, не заточенные конкретно под этот тип файла, в случае конфликта покажут
"вот этот (бинарый) кусок в этой ветке изменился так, а вот в этой (тоже бинарный) — так. Какой вариант использовать будем?"
И если человек не способе понять, что эти бинарные куски означают, то как он конфликт решить должен?
Пример — взять екселевский файл, сделать три копии, в каждой изменить какое-то места, которые взаимно перекрываются. Попытаться слить все вместе. Повторить то же самое, когда файлы лежат в разных ветках в github-е.
Это обычная IDE должна сильно напрягаться, поскольку для построения AST требуется дополнительный инструментарий. Если данные уже AST — значительная часть IDE сильно упрощается.
Мы все-таки про упращение работы и написание IDE (такое ощущение, что именно эта задача решается) или про упрощение работы человеком?
И еще — открытие Visual Studio занимает до минуты потому что большая часть сложности этой IDE в том, что ей приходиться парсить сырые текстовые данные, формируя AST.
Тут раньше было утверждение, что описываемое представление легче и удобнее для человека, а аргумент приводится вида 'IDE слишком сильно напрягается'. Кроме того, если Visual Studio открывается долго — то, я подозреваю, это означает, что там в коде классов сотни тысяч или даже миллионы.
Возможно, C++ в этом отношении плох. Но для чего новый язык изобретать-то? Только для решения этой проблемы. Берем Java, скажем — там с этим сильно легче. Не говоря про пачку других статических языков, к которым визуальный редактор можно прикрутить.
Я тут под руками имею проект, в котором логика вот в таких XML файлах хранится, с названиями тегов и атрибутов, значения которых знает только фирма производитель IDE. В результате если два человека поменяли одну и ту же схему (даже если случайно элемент на пару пикселей сдвинут), которая этим файлом описана — то изменения из двух веток слить нельзя. Приходится буквально руками открывать три окошка и руками изменения искать и в новую ветку вносить.
Как бы смущает. То что вордовский файл нельзя залить в git, работать с ним толпой человек и сливать неконфликтующие изменения простым нажатием кнопки — это всегда огорчает.
Прошу прощения, но если уж так хочется визуального программирования, технология должна выглядеть так:
Исходный, человекопонятный код лежит в простых текстовых файлах. Ваша IDE
его компилирует в бинарное представление нодами и хранит, показывает, обрабатывает, заменяет, трансформирует, итд итп где-то внутри себя. Соответствующим образом меняя исходный текстовый код. И отдельно — то же самое, но без IDE, а command line (де)компилятором
И да, "текстовый исходник" в виде зубодробительного XML или текста, который нельзя понять — тоже считается за бинарный файл.
Т.е. вся визуальное программирование — это один из вариантов работы (возможно, удобный) с текстом, а что-то отдельное и ни с чем не совместимое.
'свой git' — очень большая проблема. Потому что он — один. И только ваша среда им пользоваться умеет. И удобный интерфейс к нему — неизвестно когда сделать сумеете.
А тот, который с текстовыми файлами работает — его кто только не умеет. И, причем, работать с простыми текстами не только git может, но и прочие Version Control, потому что сравнить/сделать слияние изменений в текстовых файла — стандартная задача, которую делать более-менее научились. И которую, если очень прижмет, можно даже руками сделать. А вот сделать это с файлами неизвестного человеко-непонятного формата — это безнадежно.
Плюс прочие внешние утилиты — в этом вашем формате простой текстовый поиск что выдает?
как превратить донат из попрошайничесва в нормальный способ заработка, по-вашему?
Делать "Деньги — вперед".
Не трекере висит список желаний пользователей с ценой разработки. Как нужная сумма набралась — делаем. Если ничего не набралось — пишем "проект приостановлен в связи отсутствием платежеспособного интереса. Вернусь через год и посмотрю, стоит ли вообще закрыть"
Оно все-таки для писателей. Это им не надо. Может, какой-нибудь плагин и есть. Но зато, например, в Quoll Writer, можно вставит здоровый кусок, который анализируешь, в качестве главы.
Прямо там же по тексту выделить мышкой нужные куски и термины ('персонаж'), сделать про них 'заметки на полях' ('Plot Outline'). Потом накидать рядом ('информация о мире') кусочки мыслей и и прочих записей и все это слинковать друг с другом. Причем про 'персонажи' программа сразу строит ссылки, в какой главе он встречался. Простым совпадением по подстроке, но тоже сильно помогает.
Приложения 'для писателей'. Они позиционируются иначе, но, как ни странно, неплохо подходят и для заметок. Потому что все эти 'сюжет', 'персонажи', 'объекты мира', древовидная структура глав — применимы и для реального мира.
Примеры — Manuskript, Quoll Writer
Мне почему-то казалось, что когда нужно все это сделать, просто пользуются генераторами парсеров, а не прописывают руками все эти энумы и привязки где-то в коде. Не очень убедительно.
Именно так. Сама концепция визуального программирования тоже большие сомнения вызывает, но как раз его тут не очень много. Только пару непонятно как применимых деревьев на несколько экранов, которые с тем же успехом рядом в виде текстового дерева с отступами показаны.
А так — да, самое главное возражение, что то, как описывается — оно с существующими инструментами почти не совместимо. Было бы хранение, как я выше написал, в том же текстовом представлении, что человек видит — все было бы вполне адекватно.
Судя по всему, "работа с кодом" в данном случае понимается большей частью "автоматическая трансформация при помощи какого-то тут же написанного скрипта".
А можно все-таки накидать побольше примеров, где и как оно полезно и нужно? Ну, кроме переименования.
А то складывается впечатление, что упрощается работа программиста, что IDE пишет, а не работа того, кто этой IDE пользуется.
Речь идет не о тех данных и не о том коде, с которыми идет работа (не человеком, причем — он как раз с текстовым представлением работает).
А о тех, что на диске лежат и которые другие инструменты, которые не IDE, видят.
Что плохого произойдет, если эти ноды на диске так и будут выглядеть, как тот текст, который 'представление'?
Именно это и моментально включает 'не надо это использовать, если нет очень существенных преимуществ'. Это Тьюринг-полный конфиг и IDE к нему тоже рекламировался как "новый способ ....". А потом как-то сдулось, оставив после себя плохо поддерживаемое нечто, с чем в современных инструментах работать нельзя.
<вздыхая> И опять все про написание. Есть еще такая часть работы, которая про "что тут 10 лет назад такого понаписали, что хотели написать, можно ли это выкинуть, не сломав всего остального"
А потому выясняется, что оно таки ломается, потому что функционал ухитрились вызвать через какой-нибудь хитроизобретенный эквивалент eval(functionNamePrefix[i]+ functionNameSuffix[j] + "()").
Написав и встроив в систему полный по Тьюрингу интерпретатор конфиг-файлов, например.
И вот тут эта вот самая спец-IDE, для редактирования этих конфигов, про которую производитель уже лет 5 делает вид, что ее никогда не было — совершенно не радует.
В том что стандартные инструменты, не заточенные конкретно под этот тип файла, в случае конфликта покажут
"вот этот (бинарый) кусок в этой ветке изменился так, а вот в этой (тоже бинарный) — так. Какой вариант использовать будем?"
И если человек не способе понять, что эти бинарные куски означают, то как он конфликт решить должен?
Пример — взять екселевский файл, сделать три копии, в каждой изменить какое-то места, которые взаимно перекрываются. Попытаться слить все вместе. Повторить то же самое, когда файлы лежат в разных ветках в github-е.
Мы все-таки про упращение работы и написание IDE (такое ощущение, что именно эта задача решается) или про упрощение работы человеком?
Тут раньше было утверждение, что описываемое представление легче и удобнее для человека, а аргумент приводится вида 'IDE слишком сильно напрягается'. Кроме того, если Visual Studio открывается долго — то, я подозреваю, это означает, что там в коде классов сотни тысяч или даже миллионы.
Ваша IDE с проектом такого размера справится?
Возможно, C++ в этом отношении плох. Но для чего новый язык изобретать-то? Только для решения этой проблемы. Берем Java, скажем — там с этим сильно легче. Не говоря про пачку других статических языков, к которым визуальный редактор можно прикрутить.
Моя IDE вполне успешно показывает все места, где конкретное поле используется, заглядывая в обычные текстовые исходники.
Более того, я могу просто сразу разбить его на два, и во всех остальных местах сразу будет показана ошибка "обращение к неизвестному полю".
Я тут под руками имею проект, в котором логика вот в таких XML файлах хранится, с названиями тегов и атрибутов, значения которых знает только фирма производитель IDE. В результате если два человека поменяли одну и ту же схему (даже если случайно элемент на пару пикселей сдвинут), которая этим файлом описана — то изменения из двух веток слить нельзя. Приходится буквально руками открывать три окошка и руками изменения искать и в новую ветку вносить.
Как бы смущает. То что вордовский файл нельзя залить в git, работать с ним толпой человек и сливать неконфликтующие изменения простым нажатием кнопки — это всегда огорчает.
Прошу прощения, но если уж так хочется визуального программирования, технология должна выглядеть так:
Исходный, человекопонятный код лежит в простых текстовых файлах. Ваша IDE
его компилирует в бинарное представление нодами и хранит, показывает, обрабатывает, заменяет, трансформирует, итд итп где-то внутри себя. Соответствующим образом меняя исходный текстовый код. И отдельно — то же самое, но без IDE, а command line (де)компилятором
И да, "текстовый исходник" в виде зубодробительного XML или текста, который нельзя понять — тоже считается за бинарный файл.
Т.е. вся визуальное программирование — это один из вариантов работы (возможно, удобный) с текстом, а что-то отдельное и ни с чем не совместимое.
Это настолько оптимистично, что даже не знаю, как это назвать можно.
'свой git' — очень большая проблема. Потому что он — один. И только ваша среда им пользоваться умеет. И удобный интерфейс к нему — неизвестно когда сделать сумеете.
А тот, который с текстовыми файлами работает — его кто только не умеет. И, причем, работать с простыми текстами не только git может, но и прочие Version Control, потому что сравнить/сделать слияние изменений в текстовых файла — стандартная задача, которую делать более-менее научились. И которую, если очень прижмет, можно даже руками сделать. А вот сделать это с файлами неизвестного человеко-непонятного формата — это безнадежно.
Плюс прочие внешние утилиты — в этом вашем формате простой текстовый поиск что выдает?
как превратить донат из попрошайничесва в нормальный способ заработка, по-вашему?
Делать "Деньги — вперед".
Не трекере висит список желаний пользователей с ценой разработки. Как нужная сумма набралась — делаем. Если ничего не набралось — пишем "проект приостановлен в связи отсутствием платежеспособного интереса. Вернусь через год и посмотрю, стоит ли вообще закрыть"
Вот только кто-то будет смотреть diff-ы, merge-request-ы и делать code review в условном github-е.