Именно это и моментально включает 'не надо это использовать, если нет очень существенных преимуществ'. Это Тьюринг-полный конфиг и 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, потому что сравнить/сделать слияние изменений в текстовых файла — стандартная задача, которую делать более-менее научились. И которую, если очень прижмет, можно даже руками сделать. А вот сделать это с файлами неизвестного человеко-непонятного формата — это безнадежно.
Плюс прочие внешние утилиты — в этом вашем формате простой текстовый поиск что выдает?
как превратить донат из попрошайничесва в нормальный способ заработка, по-вашему?
Делать "Деньги — вперед".
Не трекере висит список желаний пользователей с ценой разработки. Как нужная сумма набралась — делаем. Если ничего не набралось — пишем "проект приостановлен в связи отсутствием платежеспособного интереса. Вернусь через год и посмотрю, стоит ли вообще закрыть"
Генерируем миллион бессмысленных текстов при помощи современных бредогенераторов и нейросетей. Добавляем к ним еще миллион (да-да, я знаю) осмысленных, написанных человеком. И начинаем учить отличать одно от другого. По дороге как раз придется научиться понимать, есть ли в тексте смысл и какой он.
Наверняка есть какой-нибудь закон, запрещающий принудительно связывать между собой лишние и независимые услуги.
Хочется общий авторизационный сервер в целях оптимизации — пускай будет. Только тогда надо сделать так, чтобы поведение в соцсети не влияло на использование шлемом. И чтобы можно можно было пользоваться шлемом, но не иметь, собственно, страницы фейсбука и всего, что с ней связанно.
Небольшая поправка. В данном случае 'отвечать на вопросы' — это не только лично задающему вопрос ответить, но и внести соответствующие поправки в учебные материалы, задачи итд итп. С идеальной конечной целью — чтобы больше этого вопроса не задавали.
Именно это и моментально включает 'не надо это использовать, если нет очень существенных преимуществ'. Это Тьюринг-полный конфиг и 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-е.
Ведро дегтя №1:
А теперь поместите исходный код программы в Version Control, сравните две ветки и попробуйте разрешить конфликты, если они были.
Т.е. специальный Version Control, который о формате хранения вот всего этого знает?
И получим, что все широко используемые инструменты совместной разработки к такой программе неприменимы?
2 миллиона текстов — в задачнике. По которому потому детей учим отличать результат работы бредогенераторов от осмысленного текста.
Ну как сказать. При известной точке зрения можно считать весь датацентр целиком одним таким большим мейнфреймом.
Придумано на другом форуме, перетащу сюда:
Генерируем миллион бессмысленных текстов при помощи современных бредогенераторов и нейросетей. Добавляем к ним еще миллион (да-да, я знаю) осмысленных, написанных человеком. И начинаем учить отличать одно от другого. По дороге как раз придется научиться понимать, есть ли в тексте смысл и какой он.
Наверняка есть какой-нибудь закон, запрещающий принудительно связывать между собой лишние и независимые услуги.
Хочется общий авторизационный сервер в целях оптимизации — пускай будет. Только тогда надо сделать так, чтобы поведение в соцсети не влияло на использование шлемом. И чтобы можно можно было пользоваться шлемом, но не иметь, собственно, страницы фейсбука и всего, что с ней связанно.
Небольшая поправка. В данном случае 'отвечать на вопросы' — это не только лично задающему вопрос ответить, но и внести соответствующие поправки в учебные материалы, задачи итд итп. С идеальной конечной целью — чтобы больше этого вопроса не задавали.