Почему инструменты сборки используют язык сценариев, отличный от основного языка программирования?

23

Недавно я использовал некоторые инструменты сборки для проекта Nodejs на работе, когда понял, что основной инструмент / система сборки большинства языков использует язык, отличный от основного языка программирования.

Например, make не использует C или C ++ для написания сценариев, а ant (ни Maven) не использует Java в качестве языка для сценариев.

Более новые языки, такие как Ruby, используют один и тот же язык для инструментов сборки, таких как rake , что имеет смысл для меня. Но почему это не всегда так? В чем преимущество наличия инструмента для сборки, который использует язык, отличный от основного языка?

programming-languages history build-system joshin4colours
источник
14
Может быть, язык общего назначения недостаточно хорошо подходит для использования инструмента специалистом? Например, я бы не хотел писать make-файлы на C! Иногда DSL лучше.
Андрес Ф.
13
Посмотрите на это с другой стороны: почему бы не использовать make для написания прикладного программного обеспечения?
Что такое
4
Эта статья в основном о том, что, по мнению автора, делает Lisp великолепным, но содержит некоторую соответствующую информацию о том, почему Ant использует XML вместо Java.
8bittree
6
Если вы хотите написать программу на C, которая автоматизирует создание программ на C, разве вы не захотите написать makeснова (что в любом случае реализовано в C)?
Брандин
6
@ joshin4colours сделать это написано на языке C. язык , которые делают использование, однако, это язык , который запускает оболочку по мере необходимости.

Ответы:

36

Выбор того, какой язык программирования использовать для достижения цели, должен зависеть от конкретных особенностей этой цели, а не от других задач, связанных с этим проектом.

Инструмент сборки выполняет очень специфическую работу, и независимо от того, какой язык вы используете для основного проекта, инструмент сборки сам по себе является программным обеспечением.

Попытка связать основной проект и инструмент для его сборки может быть очень плохим решением. Что вам нужно в инструменте сборки - это в основном быстрый процесс простых правил с быстрым управлением файлами и вводом-выводом.

Если такие языки, как ruby, используют себя для реализации своего инструмента сборки, это больше связано с особенностями этого языка, чем с предполагаемой необходимостью сохранять все написанное на одном языке.

Николас
источник
18

Нет ничего невозможного в написании инструмента для сборки, который использует такие языки, как C или Java, в качестве языков сценариев. Однако инструменты сборки выигрывают от использования более декларативных языков сценариев. Вообразите боль и шаблон написания make-файла (или build.xml, или чего-то еще) на C.

Инструменты сборки выигрывают от использования DSL, для которых C не особенно хорош. C слишком общий для инструмента сборки и слишком озабочен ошибками и низкоуровневыми деталями. Например, вы не хотите заниматься явным управлением памятью в инструменте сборки! Таким образом, даже если вы используете C-подобный синтаксис, вы, вероятно, будете использовать сборщик мусора в своем инструменте сценариев, и в таком случае, почему бы просто не использовать выделенный DSL?

Имеет смысл, что Ruby может использоваться для этого, так как это более высокоуровневый, более декларативный язык, чем C или Java. Также см .: Gradle, сб.

Андрес Ф.
источник
13
Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C.Представьте себе боль и беспорядок попыток выразить нетривиальную условную логику (вы знаете, стандартные императивные вещи) в декларативном XML-скрипте. Ой, подожди, ты не должен представлять; Вам, вероятно, приходилось иметь дело с этим, и это было, вероятно, полторы беспорядка, не так ли? Сборки являются одним из худших вариантов выбора декларативного языка сценариев, потому что серьезные проблемы быстро оказываются за пределами декларативных ограничений, а те, которые не достаточно просты, чтобы не нуждаться в инструменте сборки.
Мейсон Уилер
7
@MasonWheeler Есть случаи, когда существующие инструменты сборки заставляли меня страдать, да. Ни одному из них не помогло бы использование низкоуровневого императивного языка. Я считаю что-то вроде Ruby идеальным: декларативным и достаточно императивным, по мере необходимости. С дала бы мне кошмары для этой задачи. Для меня системы сборки - хороший пример использования (в основном) декларативных DSL: вас интересует, что делать, а не то, как это делать (большую часть времени).
Андрес Ф.
2
Справедливо. Я всегда полагал, что C - одна из тех технологий «если Х - это ответ, который вы задаете неправильный вопрос», чтобы быть совершенно честным; просто работа с «скриптами» XML была кошмаром каждый раз, когда мне приходилось погружаться в них. Я согласен, что императивный язык более высокого уровня с возможностями DSL был бы идеальным.
Мейсон Уилер
@AndresF .: Такие вещи, как make files, требуют сочетания подходов. Желаемое состояние вывода указывается декларативно, но действия, необходимые для достижения этого состояния, указываются обязательно.
суперкат
1
@MasonWheeler Я думаю, что это проблема людей, которые разработали язык конфигурации, чем сам XML. Распространенной ошибкой авторов таких языков является допущение, что если что-то есть в XML, оно автоматически станет читабельным для человека. (Я знаю, что совершал эту ошибку чаще, чем мне бы хотелось. Это очень заманчиво.) Хорошо разработанный и тонкий язык конфигурации может работать с XML так же хорошо, как и в любой другой форме.
Бизиклоп
12

Давайте приведем пример из реальной жизни.

Около 15 лет назад я работал над переносом большой системы, написанной на C, из Unix в Windows, в ней было около 3 миллионов строк кода. Чтобы дать вам некоторое представление о масштабе, для компиляции на некоторых из наших Unix-систем (RS6000) потребовалось более 24 часов, Windows может скомпилировать систему примерно за 4 часа.

(У нас также было 2 миллиона строк кода на нашем собственном интерпретируемом языке, но мы решили не использовать наш язык для систем сборки, поскольку он никогда не был предназначен для обработки файлов. Также нам была нужна система сборки для компиляции кода C, который реализовал наш язык .)

В то время, когда система сборки была написана в виде сценариев оболочки и файлов создания, они не были переносимы на окна - поэтому мы решили написать нашу собственную систему сборки.

Мы могли бы использовать C, но мы решили использовать Python, причин было мало. (В то же время мы также переписали нашу систему управления исходным кодом на python, она была сильно интегрирована с системой сборки, поэтому объектные файлы для проверенных модулей могут быть общими для разработчиков.)

  • Большая часть нашего кода может быть построена с помощью нескольких простых правил (всего несколько тысяч строк Python для всех платформ, Windows, VMS и 6 версий Unix), которые основаны на соглашениях об именах файлов.

  • В то время, когда RegEx не был очень стандартным для систем C на разных платформах, Python встроил RegEx.

  • Несколько модулей требовали пользовательских шагов сборки, Python позволял динамически загружать файлы классов. Мы разрешили использовать собственный класс для сборки модуля (lib), основанный на наличии в папке файла python с волшебным именем. Это была убийственная причина использовать Python.

  • Мы рассматривали Java, но на тот момент она не была доступна на всех платформах.

(Пользовательский интерфейс нашей системы управления исходным кодом использовал веб-браузер, поскольку он был переносимым на всю платформу. Это было за 6 месяцев до того, как у нас было подключение к Интернету. Нам пришлось загружать браузер поверх X25!)

Ян
источник
Проработав несколько крупных систем, я иногда чувствую, что у меня есть представление о том, как масштабируется разработка. Затем я читаю такие истории. Sheesh.
dmckee
@immibis Это было модно делать 15 лет назад. Более того, эта практика была фактически одобрена и поощрена ведущими поставщиками Unix (в частности, SGI и DEC, но также и IBM).
дубад
1
Люди склонны забывать, что Unix имел в виду «дорогой». Windows выиграла войну настольных компьютеров и рабочих станций, поскольку стала дешевле. По той же причине Linux позже выиграл серверную войну.
Slebetman
1
Если я хочу, чтобы на компьютере работало программное обеспечение, которое я написал сам, я хочу, чтобы оно было гибким и имело 101 опцию компиляции ядер и т. Д. Однако, если я продаю программное обеспечение, которое будет установлено на компьютере клиента, я хочу, чтобы клиент был под управлением ОС, которая не является гибкой, так что я знаю, что она будет работать на их компьютере, если она работает на моей. Это было важным фактором, если рассматривать Linux как поставщика программного обеспечения - поддержка выглядела слишком дорого. Linux выиграл размещенное программное обеспечение сервера войны, где сервер , предоставляемый поставщик программного обеспечения - например , большинство вебов - развертывание программного обеспечения.
Ян
3
@slebetman Это справедливо - Unix выиграл предыдущую «войну», поскольку был дешевле (по сравнению с LISPM и подобными машинами). Это было абсолютно ужасно, ужасно спроектировано и постоянно зависало (но загружалось намного быстрее, чем LISPM!: P), используя C в качестве основного языка программирования (довольно большое падение с LISP и аналогичных), но это было намного дешевле. Фактически, многие приняли его, потому что он был бесплатным (было много свободных мутаций задолго до Linux). На самом деле, я встречал много LISPers старой школы, которые предпочитали MS-DOS юниксам того времени. Да, это ужасно.
Луан
3

Краткий ответ на этот вопрос заключается в том, что это и есть инструмент сборки . Инструмент, который автоматизирует использование других инструментов с целью создания конечного продукта из некоторых исходных файлов. Если мы пишем скрипт сборки на том же языке, что и сам продукт, мы попадаем в сферу языковых инструментов, которые не будут рассматриваться как инструменты сборки таким же образом.

Возникает вопрос - почему компиляторы не предоставляют такую ​​автоматизацию сборки, к которой мы привыкли, из таких инструментов, как make? На что ответ просто потому, что существует make . Философия Unix «делай одно и делай хорошо» предполагает, что компилятор не несет ответственности за обеспечение этого *. Тем не менее, я лично прошел через мою головную боль от make, и мне было бы интересно попробовать компилятор, который предоставляет свою собственную "нативную" систему сборки, заключающуюся в кавычки.

Для примера компилятора, спроектированного таким образом, см. Jai (пока еще не выпущенный) Джона Блоу , язык, предназначенный в качестве замены C ++. Ссылки на доклады и демонстрации компилятора собраны здесь . Этот язык компилируется в байт-код, который выполняется внутри компилятора, а компиляция в двоичный код является стандартной функцией библиотеки, доступной из байт-кода. Цель состоит в том, чтобы обеспечить как автоматизацию сборки, так и метапрограммирование в родном синтаксисе языка.

* Взгляд на Microsoft Visual Studio покажет вам пример противоположной философии. :)

Хэддон CD.
источник
2

Инструмент сборки - это, прежде всего, инструмент, такой же, как 'gcc', 'ls', 'awk' или 'git'. Вы вводите инструмент для ввода (имя файла, параметры и т. Д.), И он будет делать некоторые вещи соответственно.

Все эти инструменты позволяют вам вводить данные способами, которые должны быть достаточно простыми для написания и понимания. В конкретном случае инструментов сборки вход представляет собой файл рецепта, файл, который описывает, как ваш проект переходит от исходных файлов к готовому продукту.

Если ваш рецепт так же прост, как передача в папку, содержащую проект и используемый компилятор, тогда достаточно декларативного «языка». Как только рецепт становится все более и более сложным, с большей логикой, становится проблематично обращаться с ним с декларативными языками, и используются языки более общего назначения.

Теперь должно быть очевидно, что нет никакой связи между языком, используемым для написания ваших рецептов сборки, и языками, используемыми для написания кода вашего продукта, просто потому, что они имеют разные цели и требования. Нет никакой связи даже между языком, на котором написан инструмент сборки, и языком, на котором должны быть написаны рецепты сборки. Всегда используйте лучший инструмент для работы!

Tibos
источник