Здравствуйте, Alekzander, Вы писали:
A>Весьма недружелюбные инструменты, и слава богу, что когда я учился и начинал работать, в студии настройки были через GUI.
Да, когда только начинаешь — мышкой может и комфортнее. Но когда начинаешь, обычно нет задачи выстроить специфический процесс сборки.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, rosencrantz, Вы писали:
R>>Всякие там ключи компиляции настроить в студии — мышкой
M>И как же это я всё ручками пишу?
Ну расскажи как ты ручками пишешь. Мне действительно интересно — может с тех пор действительно что-то поменялось.
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, rosencrantz, Вы писали:
R>>Всякие там ключи компиляции настроить в студии — мышкой. Пакет из нугета поставить — мышкой. IIS настроить — мышкой.
K>По-моему кто-то просто не разобрался, т.к. всё это делается без мышки при желании.
Насколько велико должно быть желание?
K>У того же nuget есть CLI, но я не понимаю в чём прикол делать это вручную. K>Хочешь — добавь вручную в csproj строку типа: K>
Я смотрю на проект ~2015 года — зависимости из нугета лежат в packages.config, а в *.csproj — ссылки на конкретные assemblies. Я припоминаю, что одно время когда в студии открываешь солюшн, там надо было руками что-то нажать, чтобы пакеты скачались. Потом вроде появилась какая-то галочка "скачивать автоматически".
R>>Будь добр скачать и поставить отдельный тул (WebDeploy) — и потом дёргать его из MSBuild как обычную внешнюю программу.
K>Какие-то ограничения на число инструментов?
Не ограничения, а профессиональные предпочтения. Чем меньше инструментов — тем лучше.
K>В случае с maven или gradle внезапно тоже чудес нет. Либо есть нужный плагин, который скачается сам, потом подтянет нужный тул, либо так же будешь дёргать как обычную внешнюю программу.
Разница в культуре. В Gradle/Maven есть плагины — их много, они сами скачиваются и работают. В MSBuild, как ты сам сейчас продемонстрировал, "этого нет, но ведь оно и не надо".
K>В Microsoft мире просто этим меньше загоняются, большинство задач решается в 2 клика и не так много народа вникает во все эти xml.
А почему в Microsoft мире на это меньше загоняются? Было бы интересно разобраться, почему большинство задач решается в 2 клика — то ли потому что у Микрософт инструменты сборки такие мощные, то ли потому что инструменты плохие, но об этом все знают — и поэтому никому даже в голову не приходит решить более-менее сложную задачу (которая в том же Gradle будет просто "обычной")
K>И с тем же nuget отдельным нормально. Отдельно сборки, отдельно репозиторий пакетов.
Ну нормально, так нормально.
K>А в чём удобство, когда вроде используешь gradle, а пакеты берёшь из mavenCentral?
А что именно смущает? Слово "Maven" в названии репозитория?
Здравствуйте, vsb, Вы писали:
vsb>Я за качественный DSL. XML или JSON это приемлемо в какой-то мелкой программе, где парсер был бы больше её самой.
vsb>В принципе можно DSL на основе другого ЯП. К примеру в Gradle можно использовать DSL на основе Groovy или Kotlin. Если этот другой ЯП позволяет такое использование.
Отказ от XML в пользу DSL решает здесь какую-то проблему, или просто вкусовщина?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>В общем, я понял, ты не стал разбираться с MSBuild и вместо этого начал писать дополнительные скрипты поверх. ЭФ>Хотя мог бы просто сделать или найти нужные задачи и вставить их в имеющиеся файлы сборки.
"There are some significant differences between when projects build in Visual Studio vs. when you invoke MSBuild directly" и дальше по тексту — примерно об этом я говорил. В Gradle ничего подобного нет: там запуск билда из IDE — это просто тот же самый вызов Gradle, который программист сделал бы из командной строки.
Здравствуйте, rosencrantz, Вы писали:
A>>Весьма недружелюбные инструменты, и слава богу, что когда я учился и начинал работать, в студии настройки были через GUI.
R>Да, когда только начинаешь — мышкой может и комфортнее. Но когда начинаешь, обычно нет задачи выстроить специфический процесс сборки.
А те, кто выстраивают специфический процесс сборки — они, конечно же, не люди, и комфорт не любят, ага.
Тут обе стороны говно, ИМХО. То, что студия билдит не через свой же msbuild, это, конечно, косячина. Но и то, что конкуренты не мыслят категориями "формат документа", "программа-редактор" и т.п., а следуют концепции "кто настроит файлов пачку, тот и сбилдит водокачку", это хорошим словом тоже никак не назовёшь. Обожаю мир Java, с кучей запутанных конфигов, без документации, без тулзов, без генерации значений по умолчанию. Они изобрели девопсов, когда те ещё не были мейнстримом.
Здравствуйте, IT, Вы писали:
IT>Не знаю. Хотя бы как в Razor, а лучше было сделать свой язык описания GUI. А так получилась полнейшая хрень, многословная, плохо читаемая, с кучей тупых ограничений. К тому же смешит попытка декларативного описания UI, в котором ввели сеттеры специально для декларативного описания императивных операций
"Свой язык" это значит "не на базе XML"? (Потому, что в остальных смыслах XAML это очень даже их язык). Да какая разница. HTML объективно (технически) силён своими стилями, селекторным DSL и скриптами с динамическим тайпингом, а не языком разметки как таковым. А коммерчески он силён тем, что он, типа, ничейный (хотя его и делает в основном гугл, но FF может взять и не поддержать самые одиозные новинки). MS не смогла предложить ни чисто технические преимущества, ни доминацию, а какой там синтаксис был — дело десятое.
Здравствуйте, Alekzander, Вы писали:
A>"Свой язык" это значит "не на базе XML"? (Потому, что в остальных смыслах XAML это очень даже их язык). Да какая разница. HTML объективно
Мы же вроде как про XAML. При чём тут HTML?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alekzander, Вы писали:
R>>Да, когда только начинаешь — мышкой может и комфортнее. Но когда начинаешь, обычно нет задачи выстроить специфический процесс сборки.
A>А те, кто выстраивают специфический процесс сборки — они, конечно же, не люди, и комфорт не любят, ага.
Абсолютное большинство инструментов для сборки оформлены как "конфиг + тул для его исполнения". Хоть мы говорим про всякие "локальные" инструменты сборки — Gradle, Maven, MSBuild, Make, хоть мы говорим про CI-решения типа GitHub Actions, GitLab CI, Concourse CI, AWS CodeBuild/CodePipeline. Везде пишется конфиг руками. UI там конечно есть, но он чаще для целей посмотреть билд логи, а не для того, чтобы дизайнить процедуру сборки.
Мышко-ориентированные решения это вымирающее меньшинство. Студия — была отличным примером 10-20 лет назад, сейчас вот меня в топике сливают, говорят, что уже всё, можно писать руками и нормально работает. Есть билдсервер TeamCity — там тоже 10 лет назад не было конфигов, была мышка, но за прошедшие 10 лет конфиги появились (с Jenkins аналогичная история).
Слово "комфорт" здесь наверно не приведёт к конструктивному разговору, потому что, в зависимости от степени погружения в вопрос, комфорт будет от "слава богу всё свелось к одной галочке" до "слава богу тут внятно видно как устроен процесс и я могу просто написать 10 очевидных строчек XML, чтобы решить свою задачу".
A>Тут обе стороны говно, ИМХО. То, что студия билдит не через свой же msbuild, это, конечно, косячина. Но и то, что конкуренты не мыслят категориями "формат документа", "программа-редактор" и т.п., а следуют концепции "кто настроит файлов пачку, тот и сбилдит водокачку", это хорошим словом тоже никак не назовёшь. Обожаю мир Java, с кучей запутанных конфигов, без документации, без тулзов, без генерации значений по умолчанию. Они изобрели девопсов, когда те ещё не были мейнстримом.
В Java конечно есть инструменты, которые даже с ридми не понятно как настраивать, но они не так чтобы мейнстрим.
Здравствуйте, karbofos42, Вы писали:
K>Для того же maven приходится на сайт лезть и делать там то же самое, а потом копипастить кусок конфига.
Это не правда. Мавен репы индексируются. IDEA индексы умеет скачивать и потом тупо в коде пишешь какой-то SomeClass — оно тебе предложит найти класс по имени/маске _во всех доступных библиотеках_ и автоматически добавит <dependency> с выбранной версией (по умолчанию предлагает последнюю) в pom.xml. И это всё с клавиатуры делается, мышой возить необязательно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, rosencrantz, Вы писали: R>>>Всякие там ключи компиляции настроить в студии — мышкой M>>И как же это я всё ручками пишу? R>Ну расскажи как ты ручками пишешь. Мне действительно интересно — может с тех пор действительно что-то поменялось.
Здравствуйте, rosencrantz, Вы писали:
R>Насколько велико должно быть желание?
Примерно такое же, как в случае с Maven. Только там заставят и придётся этим заниматься, а в .NET велика вероятность, что и не понадобится никуда руками лазить, всё из коробки работать будет.
R>Я смотрю на проект ~2015 года — зависимости из нугета лежат в packages.config, а в *.csproj — ссылки на конкретные assemblies. Я припоминаю, что одно время когда в студии открываешь солюшн, там надо было руками что-то нажать, чтобы пакеты скачались. Потом вроде появилась какая-то галочка "скачивать автоматически".
Можно было в csproj прописать Target, который это автоматом перед сборкой делал.
R>Разница в культуре. В Gradle/Maven есть плагины — их много, они сами скачиваются и работают. В MSBuild, как ты сам сейчас продемонстрировал, "этого нет, но ведь оно и не надо".
У .NET нормальные шаблоны и та же Visual Studio успешно делает грязную работу по редактированию csproj.
Большинство проектов собирается на этом шаблонном проекте и ничего хитрого им не нужно.
maven и gradle с самого начала в это всё окунают и барахтайся как хочешь.
Мне тут больше нравится подход .NET и всего смежного. Начинающий разработчик и ничего хитрого не мудришь — тыкай кнопки в GUI и всё будет работать.
Понадобилось что-то эдакое изобразить — погружайся в xml и изучай всё это добро.
R>А почему в Microsoft мире на это меньше загоняются? Было бы интересно разобраться, почему большинство задач решается в 2 клика — то ли потому что у Микрософт инструменты сборки такие мощные, то ли потому что инструменты плохие, но об этом все знают — и поэтому никому даже в голову не приходит решить более-менее сложную задачу (которая в том же Gradle будет просто "обычной")
Берём C# и Visual Studio. Просто создаёшь Solution, в нём нужные проекты, между проектам проставляешь взаимосвязи. Нажимаешь F5, всё собралось и запустилось (сборка основного проекта вызовет сборку тех проектов, от которых он зависит, артефакты скопируются в выходную папку и т.д.).
Ноль телодвижений и изучения xml или ещё чего, в два клика в GUI настроилось и работает интуитивно понятно.
То же самое изобразить в maven — придётся статью-другую прочитать и разобраться как сделать корневой pom.xml и
прикрутить к нему pom.xml от проектов и как-то связи между проектами проставить.
Даже hello world вынудит лезть в xml и разбираться что там и как работает.
Опять же, вопрос в выбранном использовании инструментов. Можно в MSBuild всю сборку и деплой засунуть.
Можно оставить только базовую сборку, а разные варианты развёртывания уже в CI реализовать в виде скриптов каких-нибудь.
С maven и другими вопрос такой же. Ну, есть для него плагин для flyway, можно через mvn миграцию БД сделать.
Только куча людей скажет, что это идиотизм, так не надо делать и плагин этот не нужен.
R>А что именно смущает? Слово "Maven" в названии репозитория?
что сборка привязана к репозиторию и транспорту по сути.
На локальной машине у меня могут быть одни настройки, может у меня локальный репозиторий или какой-нибудь собственный, но доступный по адресу 192.168.0.1.
В CI тот же самый репозиторий мне может доступен по адресу 10.0.0.1.
Вместо того, чтобы настроить транспорт для пакетов, мне нужно городить конфиг сборки, где всё это учитывать, заводить разные профили и т.д.
Здравствуйте, ·, Вы писали:
·>Это не правда. Мавен репы индексируются. IDEA индексы умеет скачивать и потом тупо в коде пишешь какой-то SomeClass — оно тебе предложит найти класс по имени/маске _во всех доступных библиотеках_ и автоматически добавит <dependency> с выбранной версией (по умолчанию предлагает последнюю) в pom.xml. И это всё с клавиатуры делается, мышой возить необязательно.
Не помню такого в Netbeans и что там я ещё пробовал...
В Visual Studio для Nuget тоже подобная фича есть. Ни разу не пользовался.
Как-то предпочитаю смотреть что за библиотеку подключаю, какие у неё зависимости, лицензия и т.д.
И не помню ни одного мануала по Java, где были такие рекомендации.
Везде пишут какой кусок xml нужно в pom прописать, чтобы что-то там добавить.
Здравствуйте, karbofos42, Вы писали:
K>·>Это не правда. Мавен репы индексируются. IDEA индексы умеет скачивать и потом тупо в коде пишешь какой-то SomeClass — оно тебе предложит найти класс по имени/маске _во всех доступных библиотеках_ и автоматически добавит <dependency> с выбранной версией (по умолчанию предлагает последнюю) в pom.xml. И это всё с клавиатуры делается, мышой возить необязательно. K>Не помню такого в Netbeans и что там я ещё пробовал...
Вот уже в 2009 году было https://blog.mrhaki.com/2009/07/add-maven-dependency-in-netbeans.html
Для справки: nuget появился в 2010м.
K>В Visual Studio для Nuget тоже подобная фича есть. Ни разу не пользовался. K>Как-то предпочитаю смотреть что за библиотеку подключаю, какие у неё зависимости, лицензия и т.д.
Это всё есть в pom файле, в том числе и тулзы в IDEA для визуализации и навигации по зависимостям.
А для лицензий есть даже license-maven-plugin, чтобы всё само проверялось.
K>И не помню ни одного мануала по Java, где были такие рекомендации.
Ну займись самообразованием, изучи используемые инструменты, а не тупо копипасть код со стаковерфлоу.
K>Везде пишут какой кусок xml нужно в pom прописать, чтобы что-то там добавить.
Потому что в мануалах надо кусок кода показывать, а не скриншоты какие кнопки нажимать, чтобы такой код набрать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, rosencrantz, Вы писали:
R>>>Да, когда только начинаешь — мышкой может и комфортнее. Но когда начинаешь, обычно нет задачи выстроить специфический процесс сборки.
A>>А те, кто выстраивают специфический процесс сборки — они, конечно же, не люди, и комфорт не любят, ага.
R>Абсолютное большинство инструментов для сборки оформлены как "конфиг + тул для его исполнения". Хоть мы говорим про всякие "локальные" инструменты сборки — Gradle, Maven, MSBuild, Make, хоть мы говорим про CI-решения типа GitHub Actions, GitLab CI, Concourse CI, AWS CodeBuild/CodePipeline. Везде пишется конфиг руками. UI там конечно есть, но он чаще для целей посмотреть билд логи, а не для того, чтобы дизайнить процедуру сборки.
R>Мышко-ориентированные решения это вымирающее меньшинство. Студия — была отличным примером 10-20 лет назад, сейчас вот меня в топике сливают, говорят, что уже всё, можно писать руками и нормально работает. Есть билдсервер TeamCity — там тоже 10 лет назад не было конфигов, была мышка, но за прошедшие 10 лет конфиги появились (с Jenkins аналогичная история).
R>Слово "комфорт" здесь наверно не приведёт к конструктивному разговору, потому что, в зависимости от степени погружения в вопрос, комфорт будет от "слава богу всё свелось к одной галочке" до "слава богу тут внятно видно как устроен процесс и я могу просто написать 10 очевидных строчек XML, чтобы решить свою задачу".
Ещё как приведёт к конструктивному разговору. Было бы желание.
Только для начала надо понять, что мышка тут ни при чём. Это же не Фотошоп, чтобы тыкать в пиксели. В студии можно и с клавы работать. Это не "мышка", это, как я уже написал, "формат документа" + "программа-редактор". То есть, концепт, типичный для классического Майкрософта. У них всюду были документы и редакторы для их обработки. Конечно, студия не совсем обычный редактор, он не похож на Блокнот, но на уровне Save Project / Save Project As... это, всё-таки, редактор.
А что такое редактор? Это, в первую очередь, генерация минимального готового документа. То есть, в данном случае, генерация набора значений по умолчанию для полного работоспособного сценария. То есть, ты создаёшь новый проект, заходишь в свойства — а там всё прописано от и до. Во-первых, ты видишь, какие свойства вообще бывают. Во-вторых, можешь поменять одно, связанное, скажем, с оптимизацией. Классический способ в чём-то разобраться — взять большое заведомо работоспособное нечто и менять по кусочку.
Я, например, специализируюсь в узкой области, и изучать этот ваш Maven мне хочется меньше всего. Студия позволяла мне сосредоточиться на моих задачах, при этом оставляла возможность что-то выборочно поменять в самой сложной схеме сборки, не вникая во все детали. Разделение труда.
Напротив, Java тебя заставит разобраться во всех хитросплетениях, прежде чем ты добьёшься хоть какого-то полезного эффекта. Я говорю сейчас не только о системах сборки, а вообще об их культуре. Два дня эксепшены из логов курить, чтобы только понять, что в таком-то XML-конфиге надо было дописать то-то и то-то, это для них типично. И стоит за этим самая пошлая мотивация в виде борьбы за сохранение ненужных рабочих мест.
Ты, конечно, прав про направление тренда. "Вымирающее меньшинство" это слишком сильно сказано, но всё определённо катится в ту сторону. И это деградация.
А студия это мутант, которого при лысом разодрали во все стороны люди с разной идеологией и разным уровнем интеллекта (Гейтс-то лично во все программистские тонкости вникал, при нём такой каши не было). По уму если, надо было сделать сборку студией в командной строке из "документа", так же, как печать из Ворда в командной строке.
A>>Тут обе стороны говно, ИМХО. То, что студия билдит не через свой же msbuild, это, конечно, косячина. Но и то, что конкуренты не мыслят категориями "формат документа", "программа-редактор" и т.п., а следуют концепции "кто настроит файлов пачку, тот и сбилдит водокачку", это хорошим словом тоже никак не назовёшь. Обожаю мир Java, с кучей запутанных конфигов, без документации, без тулзов, без генерации значений по умолчанию. Они изобрели девопсов, когда те ещё не были мейнстримом.
R>В Java конечно есть инструменты, которые даже с ридми не понятно как настраивать, но они не так чтобы мейнстрим.
Здравствуйте, IT, Вы писали:
A>>"Свой язык" это значит "не на базе XML"? (Потому, что в остальных смыслах XAML это очень даже их язык). Да какая разница. HTML объективно
IT>Мы же вроде как про XAML. При чём тут HTML?
Так HTML это давно уже маркап для UI, а не какой-то там гипертекст
А XAML — это HTML, из которого убрали Фатальный Недостаток
Про все эти маркапы (XAML, QML и т.п.) давно говорят, что не хочешь закончить с проприетарной версией HTML, технически отставшей на несколько поколений, ни с чем несовместимой, и которую знает меньшинство разработчиков — пиши на оригинальном HTML.
Здравствуйте, rosencrantz, Вы писали:
R>Я смотрю на проект ~2015 года — зависимости из нугета лежат в packages.config, а в *.csproj — ссылки на конкретные assemblies. Я припоминаю, что одно время когда в студии открываешь солюшн, там надо было руками что-то нажать, чтобы пакеты скачались. Потом вроде появилась какая-то галочка "скачивать автоматически".
Да, так действительно всё было с .NET Framework. Ограниченные возможности автоматизации, всё завязано на студию. Позже в .NET Core (который сейчас просто .NET) начали движение в противоположную сторону, так как теперь всё должно быть кросс платформенно, и делать всё через магию студии уже не прокатит. Так что все эти нугеты, msbuild и т.д. теперь самостоятельны и кросс платформенны и в общемт-то в духе типичного open source
Здравствуйте, rosencrantz, Вы писали:
R>Ну расскажи как ты ручками пишешь. Мне действительно интересно — может с тех пор действительно что-то поменялось.
Да, сильно поменялось. Сделали так называемый SDK-style project format для файлов csproj. В нём наконец-то больше не надо явно указывать все файлы с кодом. Нугеты работают интуитивно через <PackageReference> (никакой больше магии с отдельным файлом packages.config). При этом создавать и манипулировать csproj можно через командную строку
Здравствуйте, Alekzander, Вы писали:
A>Только для начала надо понять, что мышка тут ни при чём. Это же не Фотошоп, чтобы тыкать в пиксели. В студии можно и с клавы работать. Это не "мышка", это, как я уже написал, "формат документа" + "программа-редактор".
Я надеялся получить от вас кредит хотя бы в объёме "понимает разницу между мышкой и моделью" Слишком жирно?
A>А что такое редактор? Это, в первую очередь, генерация минимального готового документа.
Я вижу набор чуждых мне концепций. Дело в том, что дизайн процесса сборки — это в первую очередь "что и как надо сделать". Знание о том, что нужно команде ("проекту" — в организационном смысле) для того, чтобы "всё было как надо", о том как скомпилировать проект, как получить какой-то там финальный дистрибутив-пакет, куда потом его положить, как проверить что он туда положился. Это бОльшая часть сложности автоматизации билдов — и она требует не ковыряния конфигов, а широкого понимания потребностей команды ("проекта"). Оставшаяся часть, битва между страшными текстовыми конфигами и "удобными" GUI редакторами (что мы сейчас обсуждаем) — это настолько мало и несущественно, что меня удивляет само желание спорить на эту тему.
Если вы знаете что и как нужно сделать, вы это сделаете и на уродливом XML. Если не знаете, визуальный редактор вам никак не поможет. Если здесь и есть какое-то противостояние, оно не по поводу "GUI вместо текста", а по поводу "сделать без подготовки против уууу, надо читать документацию".
A>Я, например, специализируюсь в узкой области, и изучать этот ваш Maven мне хочется меньше всего. Студия позволяла мне сосредоточиться на моих задачах, при этом оставляла возможность что-то выборочно поменять в самой сложной схеме сборки, не вникая во все детали. Разделение труда.
Т.е. вы контролируете некоторые нюансы сборки и для вашей работы этого достаточно. А о чём тогда мы спорим? Я не специализируюсь в узкой области. Мне надо чтобы когда джуниор Вася закоммитил код в репозиторий, через 3 минуты можно было посмотреть на обновлённую версию программы, доступную по известному адресу. Я ни разу не видел, чтобы можно было такое заполучить ограничиваясь галочками в студии. Какие-то мелочи можно настроить галочками в студии, но это именно мелочи.
A>Напротив, Java тебя заставит разобраться во всех хитросплетениях, прежде чем ты добьёшься хоть какого-то полезного эффекта. Я говорю сейчас не только о системах сборки, а вообще об их культуре.
Вы описываете очень болезненный экспириенс, который для меня выглядит как участие в легаси проекте. У меня есть аналогичный опыт в компаниях где всё закрыто, где Maven это стандарт, потому что комитет 10 лет назад так решил. А конкретно у вас Maven не может качать пакеты из репозитория, потому что вашего юзера ещё не добавили в нужную группу. Это не Java, это компании такие. В современной Java таких проблем нет. Ещё бывают "винтажные инструменты", которые почему-то ругаются непонятными ошибками и ридми у них нет.
В современной Java (вру, это уже лет 10 назад было) в конфиге Gradle пишешь 3 строчки — и сразу всё билдится и работает.
A>Два дня эксепшены из логов курить, чтобы только понять, что в таком-то XML-конфиге надо было дописать то-то и то-то, это для них типично. И стоит за этим самая пошлая мотивация в виде борьбы за сохранение ненужных рабочих мест.
Современное Java сообщество негативно относится к XML и избавляется от него везде, где только возможно. Если не делать какой-то кровавый интерпрайз с интеграциями с хрен пойми чем, можно пилить проекты на Java (веб-сервисы, ходящие в БД), где XML вообще ни в каком виде не попадается.
A>Ты, конечно, прав про направление тренда. "Вымирающее меньшинство" это слишком сильно сказано, но всё определённо катится в ту сторону. И это деградация.
Вымирающее меньшинство — это объективная оценка тренда. У вас наоборот более сильно сказано: "деградация". Я не думаю, что это деградация — это де-факто стандарт индустрии. Вы уже объяснили, что не занимаетесь этим, поэтому ваш дискомфорт понятен.
A>А студия это мутант, которого при лысом разодрали во все стороны люди с разной идеологией и разным уровнем интеллекта (Гейтс-то лично во все программистские тонкости вникал, при нём такой каши не было). По уму если, надо было сделать сборку студией в командной строке из "документа", так же, как печать из Ворда в командной строке.
Здравствуйте, rosencrantz, Вы писали:
vsb>>Я за качественный DSL. XML или JSON это приемлемо в какой-то мелкой программе, где парсер был бы больше её самой.
vsb>>В принципе можно DSL на основе другого ЯП. К примеру в Gradle можно использовать DSL на основе Groovy или Kotlin. Если этот другой ЯП позволяет такое использование.
R>Отказ от XML в пользу DSL решает здесь какую-то проблему, или просто вкусовщина?
Меньше синтаксического шума, больше возможностей. Как пример крайности — XSLT, язык программирования на XML. Пользоваться им решительно невозможно. И это они ещё всё-таки ввели туда DSL (XPath).
Если нам не помогут, то мы тоже никого не пощадим.
