Чому інструменти побудови використовують мову сценаріїв, відмінну від основної мови програмування?

23

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

Наприклад, make не використовує C або C ++ для написання сценаріїв, а мураха (ні Maven) не використовує Java як свою мову для сценаріїв.

Новіші мови, такі як Ruby, використовують таку ж мову для створення інструментів, як граблі , що для мене є сенсом. Але чому це не завжди було так? Яка перевага у тому, щоб створити інструмент побудови, який використовує іншу мову від основної мови?

programming-languages history build-system

— joshin4colours
джерело

14

Можливо, мова загального призначення недостатньо підходить для використання інструментом спеціаліста? Наприклад, я не хотів би писати створення файлів на C! Іноді DSL краще.

— Андрес Ф.

13

Подивіться на це з іншого кута: Чому б не використовувати make для написання прикладного програмного забезпечення?

— whatsisname

4

Ця стаття в першу чергу стосується того, що, як вважає автор, робить Lisp чудовим, але має деяку релевантну інформацію про те, чому Ant використовує XML замість Java.

— 8bittree

6

Якби ви хотіли написати програму на C, яка автоматизує побудову C-програм, чи не просто ви закінчите писати makeзнову (що все-таки реалізовано в C)?

— Брандін

6

@ Joshin4colours зробити це написано на мові C. мову , які роблять використання, проте, це мова , яка запускає оболонку по мірі необхідності.

36

Вибір мови програмування, щоб зробити що-небудь, повинен залежати від конкретних особливостей цієї мети, а не від інших завдань, пов'язаних із цим проектом.

Інструмент збирання виконує дуже конкретну роботу, і незалежно від того, якою мовою ви користуєтесь для головного проекту, інструмент збирання - це програмне забезпечення саме по собі.

Спроба зв’язати основний проект та його інструмент побудови може бути дуже поганим рішенням. Що вам потрібно з інструментом збирання - це, головним чином, швидкий процес простих правил із швидким управлінням файлами та IO.

Якщо такі мови, як рубін, використовують самі для реалізації свого інструменту побудови, це пов'язано більше з особливостями цієї мови, ніж з передбачуваною потребою зберегти все написане тією самою мовою.

— Ніколас
джерело

18

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

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

Має сенс, що Ruby можна використовувати для цього, оскільки це більш декларативна мова вищого рівня, ніж C або Java. Також див .: Gradle, sbt.

— Андрес Ф.
джерело

13

Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C.Уявіть біль і безлад у спробі висловити нетривіальну умовну логіку (знаєте, стандартні обов'язкові речі) у декларативному сценарії XML. О, зачекайте, не треба уявляти; ви, мабуть, мали справу з цим, і це було, мабуть, півтора безладу, чи не так? Склади - це один з найгірших можливих варіантів для мови декларативного сценарію, оскільки серйозні проблеми швидко закінчуються, але стикаються з межами декларативності, і ті, які не є простими, не потребують інструменту побудови.

— Мейсон Уілер

7

@MasonWheeler Є випадки, коли існуючі інструменти збирання змусили мене страждати, так. Жодному з них не допомогло б використання імперативної мови, що нагадує С на низькому рівні. Я бачу щось на зразок Рубі як певно ідеальне: декларативне та імперативне, як потрібно. C дав би мені кошмари на це завдання. Для мене системи побудови - це гарний випадок для використання (переважно) декларативних DSL: ви дбаєте про те, що робити, а не про те, як це робити (більшість часу).

— Андрес Ф.

2

Досить справедливо. Я завжди вважав, що C - це одна з тих технологій, "якщо X - це відповідь, на яку ти задаєш неправильне запитання", щоб бути абсолютно чесним; це просто те, що робота з «скриптами» XML була кошмаром кожного разу, коли мені доводилося занурюватися в один. Я згоден, що імперативна мова вищого рівня з можливостями DSL була б ідеальною.

— Мейсон Уілер

@AndresF. Такі речі, як файли, вимагають суміші підходів. Бажаний вихідний стан задається декларативно, але дії, необхідні для досягнення цього стану, задаються обов'язково.

— supercat

1

@MasonWheeler Я думаю, що це стільки проблема людей, які розробили мову конфігурації, ніж сам XML. Поширена помилка авторів таких мов - припустити, що лише тому, що щось є в XML, це автоматично буде читабельним для людини. (Я знаю, що я робив цю помилку частіше, ніж мені подобається. Це так спокусливо.) Добре розроблена і худорлява мова конфігурації може працювати так само добре над XML, як і в будь-якій іншій формі.

— biziclop

12

Наведемо вам приклад із реального світу.

Близько 15 років тому я працював над перенесенням великої системи, написаної на С від Unix до Windows, це було близько 3 мільйонів рядків коду. Щоб дати вам уявлення про масштаб, для збирання на деяких наших системах Unix (RS6000) знадобилося 24 години, Windows міг зібрати систему приблизно за 4 години.

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

У той час, коли система збирання була написана в поєднанні скриптів оболонки та файлів, вони не переносилися для Windows - тому ми вирішили написати власну систему складання.

Ми могли використовувати C, однак ми вирішили використовувати python, причин було мало. (Одночасно ми також переписали нашу систему керування вихідним кодом у python. Це було дуже зрушено із системою збирання, тому об’єктні файли для перевірених модулів можуть бути спільними розробниками.)

Більшість нашого коду може бути побудована за допомогою декількох простих правил (лише кілька тисяч рядків python для всіх платформ, Windows, VMS та 6 версій Unix), які були виведені з конвенцій іменування файлів.
У той час, коли RegEx був не дуже стандартним між системами C на різних платформах, Python будував RegEx.
Кілька модулів потребували спеціальних кроків побудови, Python дозволяв динамічно завантажувати файли класів. Ми дозволили використовувати спеціальний клас для побудови модуля (lib), заснований на тому, щоб у папці був файл python з магічним іменем. Це було вбивчою причиною використовувати пітон.
Ми розглядали Java, але вона не здійснювала доставку на всіх платформах у той момент.

(Інтерфейс користувача для нашої системи контролю вихідного коду використовував веб-браузер, оскільки це було портативним на всій платформі. Це було за 6 місяців до того, як у нас було з'єднання з Інтернетом. Нам довелося завантажити браузер через X25!)

— Ян
джерело

Працюючи над декількома великими системами, я іноді відчуваю, що маю ручку щодо масштабів розвитку. Потім я читав подібні історії. Шиш.

— dmckee

@immibis Це було модно робити 15 років тому. Тим більше, що ця практика була фактично схвалена та заохочена провідними постачальниками Unix (зокрема, SGI та DEC, але й IBM).

— oakad

1

Люди, як правило, забувають, що Unix означав "дорого". Windows виграла війну на робочому столі / робочих станціях, дешевшим. Це з тієї ж причини, що пізніше Linux виграв війну серверів.

— slebetman

1

Якщо я хочу, щоб комп'ютер запускав програмне забезпечення, яке я написав сам, я хочу, щоб він був гнучким і мав 101 варіант, як складати ядра і т. Д. Однак, якщо я продаю програмне забезпечення для встановлення на комп'ютер замовника, я хочу, щоб клієнт був запуск ОС, яка не є гнучкою, так що я знаю, що вона буде працювати на їхньому комп’ютері, якщо вона працює на моєму. Це було великим фактором, коли дивитися на Linux як на постачальника програмного забезпечення - підтримка виглядала занадто дорого. Linux виграв війни, в яких розміщено серверне програмне забезпечення, де сервер надається постачальником програмного забезпечення - наприклад, більшість розгорнутих програм в Інтернеті.

— Ян

3

@slebetman Це справедливо - Unix виграв попередню "війну", дешевше (порівняно з LISPM та подібними машинами). Це був абсолютно жахливий, жахливо розроблений і постійно випадає з ладу (але він завантажується набагато швидше, ніж LISPM!: P), використовуючи C як основну мову програмування (досить високе падіння з LISP та подібних), але це було набагато дешевше. Насправді, багато хто прийняв його тому, що він був безкоштовним (багато Linux безкоштовних мутацій було задовго до Linux). Насправді я зустрічав безліч старих шкіл LISPers, які віддавали перевагу MS-DOS перед тим, що було уніфіковано. Так, це жахливо.

— Луань

3

Коротка відповідь на це запитання полягає в тому , що це інструмент збирання . Інструмент, що автоматизує використання інших інструментів з метою створення кінцевого продукту з деяких вихідних файлів. Якщо ми пишемо скрипт збірки на тій же мові, що і сам продукт, ми потрапляємо у сфери мовних інструментів, які не розглядалися б інструментами збирання однаково.

Це викликає питання - чому компілятори не надають таку автоматизацію побудови, до якої ми звикли, з таких інструментів, як make? На що відповідь - просто тому, що існує . Філософія Unix "зроби одну справу і зроби це добре" говорить про те, що не обов'язок компілятора надавати це *. Це означає, що я особисто переживав свою частку головних болів, і мені було б цікаво спробувати компілятор, який передбачає власну цитату-цитата "рідної" системи побудови.

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

_{* Погляд на Visual Studio Microsoft покаже вам приклад протилежної філософії. :)}

— CD Хеддона.
джерело

2

Інструмент збирання - це насамперед інструмент, подібно до 'gcc', 'ls', 'awk' або 'git'. Ви подаєте інструменту вхід (ім'я файлу, параметри тощо), і він буде виконувати деякі речі відповідно.

Усі ці інструменти дозволяють передати свої дані способами, які повинні бути досить простими для написання та розуміння. У конкретному випадку інструментів збирання вхід - це файл рецептів, файл, який описує, як ваш проект переходить від вихідних файлів до готового продукту.

Якщо ваш рецепт настільки простий, як перехід у папку, яка містить проект та компілятор, який потрібно використовувати, то декларативної "мови" достатньо. Як тільки рецепт стає все складнішим, з більшою логікою, стає важко обробляти його деклараційними мовами і використовуються більш загальні мови призначення.

Тепер має бути очевидним, що між мовою, що використовується для написання рецептів збирання, та мовами, які використовуються для написання коду вашого продукту, немає зв’язку лише тому, що вони мають різні цілі та вимоги. Немає зв'язку навіть між мовою, на якій написаний інструмент збирання, та "мовою", в якій повинні бути записані рецепти збирання. Завжди використовуйте найкращий інструмент для роботи!

— Тібос
джерело