Мир в принципе отказывается от XML дублируя все его стандарты в комплекте технологий Json.
Какие идеи лежали в основе решения использовать XML?
1) не надо писать парсер под специфичный язык, можно использовать единый код XML-парсера.
(то же самое соображение действует и для Json)
2) использовать "декларативный подход", что бы это ни значило.
(то же самое соображение действует и для Json)
Одной из проблем XML-файлов является их "монолитность",
например, когда надо подключать классы из другой .dll-ки нельзя просто взять и положить рядом второй файл,
надо вписывать строки в уже существующий: https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.tasks#L105-L107
это мешает интеграции с пакетными менеджерами.
(теоретически это решаемо, но не средствами XML, надо смотреть что там в коде msbuild)
Если они такие умные и предусмотрительные, что же они не сделали вывод процесса сборки и вывод списка ошибок в виде XML, чтобы их было легче парсить для последующих интеграций?
В принципе непонятно, что мешало сделать любой произвольный 25-ый стандарт DSL для сборки.
Вот, например, в пакетном менеджере для Ruby прямо используют язык Ruby и не стесняются,
а в NixOS отдельный язык Nix, и ничего, нормально.
Или в powershell на C# пишут. И в msbuild могли бы так же, как в powershell.
Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
слишком крутая фича, чтобы вот так просто взять и переписать.
Некогда объяснять, лучше спою (не мое).
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мир в принципе отказывается от XML дублируя все его стандарты в комплекте технологий Json.
Плохая идея была делать MSBuild отдельным от механизмов сборки проекта через студию. Плохая идея была делать в студии все настройки «мышкой». А использовать XML — где-то между «мало на что влияет» и «хорошо».
R> Плохая идея была делать в студии все настройки «мышкой».
Я точно не знаю, но думаю, что внутри есть API, который даёт программный доступ ко всему тому же, что делается мышкой
R> Плохая идея была делать MSBuild отдельным от механизмов сборки проекта через студию.
Насколько я знаю, студия компилирует именно используя MSBuild, нет там никаких "отдельных механизмов".
Здравствуйте, Эйнсток Файр, Вы писали:
R>> Плохая идея была делать в студии все настройки «мышкой».
ЭФ>Я точно не знаю, но думаю, что внутри есть API, который даёт программный доступ ко всему тому же, что делается мышкой
Например в мире Java есть 2 распространенных инструмента сборки — Maven и Gradle. В обоих все пишется руками. Один и тот же билд скрипт используется и для локальной работы, и для билдсервера. Maven кстати тоже на XML сделан.
R>> Плохая идея была делать MSBuild отдельным от механизмов сборки проекта через студию.
ЭФ>Насколько я знаю, студия компилирует именно используя MSBuild, нет там никаких "отдельных механизмов".
Когда я последний раз делал автобилды для дотнетного проекта, там нужно было писать отдельный скрипт в отдельном файле, чтобы взять вон тот вон *.sln, собрать его как надо, задеплоить куда надо, и т.д. Это было лет 10+ назад правда. А всякие там нугеты уже тоже без мышки работают?
В общем, я понял, ты не стал разбираться с MSBuild и вместо этого начал писать дополнительные скрипты поверх.
Хотя мог бы просто сделать или найти нужные задачи и вставить их в имеющиеся файлы сборки.
Здравствуйте, Эйнсток Файр, Вы писали:
R>> Maven кстати тоже на XML сделан.
ЭФ>Ты бы ещё Ant вспомнил...
Ещё когда я только начал в Java лет 15 назад, Ant уже был мёртвый. А Maven пощас в живых проектах нередко можно увидеть.
ЭФ>В общем, я понял, ты не стал разбираться с MSBuild и вместо этого начал писать дополнительные скрипты поверх. ЭФ>Хотя мог бы просто сделать или найти нужные задачи и вставить их в имеющиеся файлы сборки.
, где ты признаешься в том, что только что открыл для себя MSBuild. В 2017 году MSBuild уже 10+ лет как существовал, а я уже 2+ года как сбежал из этого дурдома
Я достаточно много времени потратил на изучение MSBuild — поднимал билд-серверы в нескольких проектах, настраивал автобилды, и веб, и десктоп. Опыт, который я описываю, это ни в коем случае не "всё достало, сделаю чтоб работало через задницу", а наименее плохое найденное мной решение после кучи экспериментов и граблей. Я перестал заниматься дотнетом и микрософтовской экосистемой как раз после того, как в нескольких проектах потрахался с микрософтовской же культурой дизайна инструментов. Всякие там ключи компиляции настроить в студии — мышкой. Пакет из нугета поставить — мышкой. IIS настроить — мышкой. Деплоймент в IIS? Будь добр скачать и поставить отдельный тул (WebDeploy) — и потом дёргать его из MSBuild как обычную внешнюю программу. Открываешь все эти *.sln, *.csproj — там зачем-то все файлы исходников упомянуты, гуиды какие-то. Я думаю не предполагалось, что кто-то будет это читать и править руками — слишком не по-человечески, поэтому взять и сделать отдельный build.xml под цели автобилда и деплоймента — вполне была здравая идея.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мир в принципе отказывается от XML дублируя все его стандарты в комплекте технологий Json.
Когда MSBuild появился 20 лет назад, слова "JSON" ещё не было — на его месте как раз был XML. Если ты посмотришь в Google Trends сравнение XML и JSON, то обнаружишь, что популярность XML долгое время падает, популярность JSON долгое время растёт, и JSON начинает обгонять XML только где-то в районе декабря 2014.
Здравствуйте, Эйнсток Файр, Вы писали:
R>> ты признаешься в том, что только что открыл для себя MSBuild
ЭФ>Это твоя гипотеза (на которой ты основываешь клевету на меня). ЭФ>Поэтому просто иди лесом.
Здравствуйте, Эйнсток Файр, Вы писали:
R>> Когда MSBuild появился 20 лет назад
ЭФ>Раньше он (msbuild) появился, думаю сразу после Java, т.е. году в 1997
Если верить википедии, MSBuild появился в 2003.
ЭФ>
Douglas Crockford originally specified the JSON format
ЭФ>in the early 2000s. He and Chip Morningstar sent the first JSON message in
ЭФ>April 2001
Имеется в виду не адекватный стандарт, а кривое описание на коленке с кучей неточностей и неизвестностей. Это привело к тому, что разные парсеры вели себя по-разному в одних и тех ситуациях. Стандарт появился может лет 10 назад.
ЭФ>Но это всё неважно. Вопрос-то в том, имеет ли смысл делать по-другому сейчас?
Ну как вы определите слово "смысл", такой и ответ будет. Экономическая целесообразность для микрософта? Привлечь побольше хипстеров? Из моего опыта — MSBuild вполне решает те задачи, которые на него возлагаются. Просто может некоторые из этих задач решать на нём противно. Вещи, которые я вижу как проблему:
1. Управление зависимостями делается через отдельный тул (нугет) — не понятно нафига. Надо 2 инструмента, чтобы сделать билд, а не 1.
2. Взаимодействие с внешним миром (по крайней мерез 15 лет назад) было сделано убого — дёргай внешние программы на свой страх и риск. И да, их ещё нужно скачать и поставить.
3. Вроде как человекочитаемые студийные *.sln, *.csproj, которые при этом не предназначены для человека. Их можно скормить msbuild'у, но это только 1 из этапов сборки/деплоймента.
А то что он XML — я, честно говоря, не вижу большой проблемы. Язык, да язык.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
MSBuild постоянно допиливается и расширяется.
Вряд ли MS его вдруг похоронит и на что-то поменяет.
Даже если появится какой-то DSL от Microsoft, то в процессе всё равно будет использоваться этот XML, т.к. не будут они с нуля MSBuild переписывать ради этого и непонятно зачем это делать.
Кому надо: может хоть сейчас взять себе Cake или Nuke и писать скрипты на C#
Здравствуйте, rosencrantz, Вы писали:
R>Всякие там ключи компиляции настроить в студии — мышкой. Пакет из нугета поставить — мышкой. IIS настроить — мышкой.
По-моему кто-то просто не разобрался, т.к. всё это делается без мышки при желании.
У того же nuget есть CLI, но я не понимаю в чём прикол делать это вручную.
Хочешь — добавь вручную в csproj строку типа:
и радуйся.
Как по мне, так удобно в студии зайти в менеджер Nuget, найти нужные пакеты, посмотреть версии, зависимости и т.п.
Для того же maven приходится на сайт лезть и делать там то же самое, а потом копипастить кусок конфига.
Не понимаю я как-то этого удобства.
R>Будь добр скачать и поставить отдельный тул (WebDeploy) — и потом дёргать его из MSBuild как обычную внешнюю программу.
Какие-то ограничения на число инструментов?
В случае с maven или gradle внезапно тоже чудес нет. Либо есть нужный плагин, который скачается сам, потом подтянет нужный тул, либо так же будешь дёргать как обычную внешнюю программу.
В Microsoft мире просто этим меньше загоняются, большинство задач решается в 2 клика и не так много народа вникает во все эти xml.
И с тем же nuget отдельным нормально. Отдельно сборки, отдельно репозиторий пакетов.
А в чём удобство, когда вроде используешь gradle, а пакеты берёшь из mavenCentral?
R>Открываешь все эти *.sln, *.csproj — там зачем-то все файлы исходников упомянуты, гуиды какие-то.
*.csproj давно уже очеловечили и они стали несколько приятнее.
Я за качественный DSL. XML или JSON это приемлемо в какой-то мелкой программе, где парсер был бы больше её самой.
В принципе можно DSL на основе другого ЯП. К примеру в Gradle можно использовать DSL на основе Groovy или Kotlin. Если этот другой ЯП позволяет такое использование.
Здравствуйте, rosencrantz, Вы писали:
R>>> Плохая идея была делать в студии все настройки «мышкой».
R>Например в мире Java есть 2 распространенных инструмента сборки — Maven и Gradle. В обоих все пишется руками. Один и тот же билд скрипт используется и для локальной работы, и для билдсервера. Maven кстати тоже на XML сделан.
Весьма недружелюбные инструменты, и слава богу, что когда я учился и начинал работать, в студии настройки были через GUI.
Здравствуйте, Alekzander, Вы писали:
IT>>Ещё более худшей идеей было XAML поверх XML. A>А как надо было? Разметку на джейсоне? Или уже смириться, не переизобретать HTML и уйти в монастырь?
Не знаю. Хотя бы как в Razor, а лучше было сделать свой язык описания GUI. А так получилась полнейшая хрень, многословная, плохо читаемая, с кучей тупых ограничений. К тому же смешит попытка декларативного описания UI, в котором ввели сеттеры специально для декларативного описания императивных операций
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
