Синій. Ні! Жовтий! — або — Дають нові мови програмування приріст швидкості розробки

Яку мову використовували для написання перших програм для найперших комп'ютерів із збереженою програмою?
Двійковий машинний мова, звичайно.

— Чому?
Очевидно тому, що не було символьного асемблера. Перші програми необхідно було писати двійковим кодом.

Наскільки легше писати програми на асемблері, ніж на двійковому машинному мовою?
Набагато легше.

Можна цифру? У скільки разів легше?
Ну, блін, асемблер робить всю важку «рутинну» роботу для вас. Тобто він розраховує всі фізичні адреси. Він складає всі фізичні машинні команди. Він забезпечує неможливість видачі фізично нереалізованих команд, наприклад, адресацію за межі адресного простору. І потім він створює легко завантажується двійковий висновок.

Економія обсягів роботи величезна.

Наскільки? Можна цифру?
OK. Якщо б я повинен був написати просту програму, як, наприклад, друк квадратів перших 25-ти цілих чисел, в асемблері на старій машині типу PDP-8, то мені знадобилося б приблизно дві години. Якщо б я повинен був написати ту ж програму на двійковому машинному мовою, це зайняло б удвічі більше часу.

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

Добре, досить. Таким чином, використання символьного асемблера знижує обсяг робіт у два рази?
Насправді, думаю, набагато більше. Зведення цілих чисел в квадрат є досить простою програмою. Чим більше програма, тим важче її вручну ассемблировать і завантажувати. Думаю, насправді виграш в трудомісткості залежить від розміру програми. Для великих програм економія часу значна.

будь Ласка, поясніть.
Добре, припустимо треба змінити один рядок у програмі на символьному асемблері. Це займе у мене 20 хвилин на старому PDP-8 з перфолентой. Але при ручному ассемблировании я повинен потім перерахувати всі адреси і реассемблировать всі машинні команди вручну. В залежності від розміру вихідної програми підуть годинник. Наступний ручне введення вимагає не менше часу.

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

Добре. Але, все ж, можна цифру? У середньому, наскільки використання асемблера полегшує роботу порівняно з написанням програми в двійковому коді?
Гаразд. Думаю, можна сказати, приблизно в 10 разів.

Іншими словами, символьний асемблер дозволяє одному програмісту виконувати роботу десяти програмістів, які працюють в двійковому коді?
Так, це, ймовірно, близько до правди.

Якщо символьний асемблер зменшив трудомісткість приблизно в 10 разів, то наскільки це зробив Фортран?
Дуже пристойно. Якщо ми говоримо про 50-х, то Фортран тоді був простим. Інакше кажучи, він був дещо більше, ніж символьний асемблер для символьного компонування, — не впевнений, чи ви розумієте, що я маю на увазі.

чи Означає це, що він зменшив трудомісткість ще в десять разів?
Що ви, звичайно, ні! «Рутинна» навантаження у символьного асемблера не була такою високою. Я б сказав, що Фортран зменшив трудомісткість порівняно небагато. Можливо, приблизно на 30%.

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

Продовжуємо — наскільки допомагає зберегти час таку мову як З порівняно з Фортраном?
Ну, З витрачає трохи менше часу на «рутинну» роботу, ніж Фортран. У старому Фортране потрібно було пам'ятати такі речі, як номери рядків і порядок загальних операторів. Було також неймовірну кількість операторів переходу по всьому тексту. Мова З набагато більш комфортний для програмування, ніж Фортран 1. Я б сказав, що він зменшив трудомісткість приблизно на 20%.

Добре. Тобто 10 програмістів на С можуть замінити 12 програмістів на Фортране?
Ну, це, звичайно, тільки припущення, але я б сказав, обґрунтоване припущення.

Добре. Тепер: наскільки С++ зменшив трудомісткість по відношенню до C?
Послухайте, давайте зупинимося. Зараз ми не згадуємо про набагато більшому впливі.

Хіба? Що саме?
Середовище розробки. Це означає, що в 50-х роках ми використовували перфокарти і паперові стрічки. Компіляція простий програми займала, як мінімум, півгодини. І то, якщо ви могли отримати доступ до машини. Але в кінці 80-х, коли С++ став популярним, програмісти зберігали свої програми на дисках, а компіляція простий програми тривала вже всього дві-три хвилини.

Це — зниження трудомісткості? Або просто зменшення часу очікування?
А. Так ось воно що. Питання зрозуміле. Так, тоді машину доводилося чекати довго.

Прохання: коли ви даєте ваші оцінки трудомісткості, виключайте, будь ласка, час очікування. Мені цікава економія часу, пов'язана тільки з самою мовою.
Зрозуміло, розумію. Отже, ви питали про C++. Взагалі-то, чесно, я не думаю, що C++ як-то значно знизило трудомісткість. Звичайно, щось, але, гадаю, не більше 5%. Це означає, що рутинна навантаження З просто була невеликою, і тому порівняльна економія часу при роботі в С++ не могла бути значною.

Якщо використовувати 5%, то це означає, що 100 програмістів на С++ можуть замінити 105 програмістів на С. Це, дійсно, так?
Загалом, так. Але тільки для невеликих і середніх за розміром програм. Для великих програм C++ надає деякі додаткові переваги.

Які?
Це досить складно пояснити. Але суть в тому, що об'єктно-орієнтовані характеристики C++, зокрема, поліморфізм, дозволили розділяти великі програми незалежно розробляються і розкривні модулі. І це — для дуже великих програм — значно зменшує рутинну навантаження.

Можна цифру?
Добре, ви, схоже, і далі збираєтеся викручувати мені руки… Враховуючи кількість дійсно великих програм, які створювалися в 80-е і 90-е роки, я скажу, що, в цілому, C++ зменшив трудомісткість, можливо, на 7%.

Це не прозвучало особливо впевнено.
Так. Але давайте використовувати це значення. 7%.

Добре. Отже, 100 програмістів на C++ можуть замінити 107 програмістів на C?
Схоже, так я і сказав. Давайте використовувати це значення.

Скільки часу зберігає Java порівняно з C++?
Важко сказати. Якесь час зберігає. Java — більш просту мову. У нього є автоматичне керування звільненням динамічної пам'яті («збірка сміття»). У нього немає файлів заголовків. Він працює на віртуальній машині. У нього є багато переваг. І трохи недоліків.

Як щодо цифри?
У мене відчуття, що ми буксуємо… Але оскільки ви так прессуете мене, то сказав би, що при інших рівних умовах (чого ніколи не буває) можна, працюючи з Java, отримати зниження трудомісткості на 5% порівняно з С++.

Отже, 100 програмістів на Java можуть замінити 105 програмістів на C++?
Так! Втім, немає. Це не так. Розкид дуже великий. Якщо вибрати випадковим чином 100 програмістів на Java і порівняти їх з так само обраними 105 програмістами на C++, то я не зважився б спрогнозувати результат. Щоб отримати реальний виграш, потрібно набагато більше програмістів.

Наскільки більше?
Як мінімум, на два порядки.

Інакше кажучи, 10 000 випадковим чином вибраних програмістів на Java можуть замінити 10 500 так само вибраних програмістів на C++?
Мабуть, так.

Дуже добре. Наскільки така мова, як Ruby, знижує трудомісткість порівняно з Java?
Ну, шановний! (зітхає). Про що ви? Дивіться, Ruby, дійсно, прекрасний мову. Він одночасно простий і складний, елегантний і химерний. Він набагато повільніше Java, але комп'ютери зараз такі дешеві, що…

Вибачте, але я питаю не про це.
Ви праві. Я знаю. Отже, головний напрям, на якому трудомісткість у Ruby менше порівняно з такою мовою, як Java, — це Types (Типи). В Java потрібно створювати формальну структуру типів і підтримувати її узгодженість. В Ruby можна грати з типами досить швидко і вільно.

Звучить як приріст продуктивності праці.
Загалом, немає. Виявляється, можливість грати швидко і вільно зі структурою типу веде до появи класу помилок часу виконання, які відсутні при програмуванні на Java. Тому програмісти на Ruby мають більш високу навантаження з тестування та налагодження програм.

Іншими словами, ці ефекти врівноважуються?
Це залежить від того, кого ви питаєте.

Я питаю вас.
Гаразд. Я б сказав, що ефекти не врівноважують один одного. Трудомісткість при роботі з Ruby нижче, ніж з Java.

Наскільки? 20%?
Люди звикли думати так. Дійсно, в 90-ті багато думали, що програмісти на Smalltalk працюють у багато разів продуктивніше, ніж на C++.

Ви запутываете мене. До чого згадувати ті мови?
Та тому, що C++ досить близький до Java, а Smalltalk — до Ruby.

Ясно. Таким чином, Ruby знижує трудомісткість в кілька разів порівняно з Java?
Ні, швидше за все, не так. Якщо озиратися на 90-е, то проблема з часом очікування була ще досить вираженою. Тривалість компіляції для типової програми на C++ становила кілька хвилин. Тривалість компіляції програми на Smalltalk була практично нульовою.

Нуль?
Практично, так. Проблема в тому, що при використанні таких мов як Java та C++ необхідно виконувати багато дій за погодженням усіх типів. При використанні Smaltalk і Ruby такої проблеми немає. Тому в 90-ті для них було потрібно час від хвилин до мілісекунд.

Ясно. Але оскільки все це — тільки час очікування, то ми можемо не розглядати його.
Не зовсім так. Бачте, якщо час компіляції практично нульове, то це породжує інші стиль і дисципліну програмування. Можна працювати з дуже коротким циклом — секунди замість хвилин. Це дає надзвичайно швидку зворотний зв'язок. При великій тривалості компіляції швидка зворотній зв'язок неможлива.

Швидка зворотній зв'язок знижує трудомісткість?
Так, певною мірою. Коли ваші цикли надзвичайно короткі, то «рутинна» навантаження в кожному циклу дуже мала. Ваша зайнятість, викликається необхідністю відстеження, знижується. Подовження циклів збільшує «рутинну» навантаження, причому нелінійно.

Нелінійно?
Так, «рутинна» навантаження зростає непропорційно тривалості циклу. Вона може рости як, наприклад, O(N^2). Я не знаю. Але я абсолютно впевнений, що залежність нелінійна.

Чудово! Значить, Ruby є лідером!
Немає. І в цьому суть. Завдяки вдосконаленню нашого апаратного забезпечення в останні двадцять років тривалість компіляції для Java стала практично нульовою. Час циклу у програміста Java стало не більше (або повинно не більше), ніж у програміста на Ruby.

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

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

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

Нуль?
Звичайно, ні, — більш ймовірно близько 5%. Але розкид буде гігантським.

Таким чином, 10 500 програмістів, які працюють в короткому циклі на Java, виконують ту ж роботу, що 10 000 програмістів в короткому циклі на Ruby?
Якщо додати ще один порядок для розміру вибірки, то я б ризикнув погодитися.

чи Існують мови, що перевершують Ruby?
Можна отримати ще 5%, використовуючи мову типу Clojure, оскільки він, з одного боку, досить простий, і, з іншого боку, функціональний.

Ви даєте лише 5% функціональним мови?
Ні, я кажу, що дисципліна короткого циклу практично стирає відмінності у продуктивності в сучасних мовах.

Якщо ви працюєте з короткими циклами, то чи має значення, який сучасний мову ви використовуєте.

тобто: Swift? Dart? Go?
Не має значення.

Scala? F#?
Не має значення.

Іншими словами, ми досягли вершини. Ніякої майбутній мова не буде краще того, що ми маємо тепер.
Не зовсім так. Я кажу лише, що ми йдемо по шляху зниження ефективності. Жоден майбутній мова не дасть виграш у 10 разів, як це було у асемблера по відношенню до двійкового коду. Жоден майбутній мова не дасть зниження трудомісткості на 50% або 20% або навіть 10% у порівнянні з наявними мовами. Дисципліна короткого циклу звела відмінності до практичної безмірності.

Тоді чому ж з'являються все нові мови?
Це пошук Святого Грааля.

А, так це всього лише питання рівня улюбленого кольору.


Примітка перекладача: Заголовок поста і його тематика є відсиланням до фрагменту фільму «Монті Пайтон і Священний Грааль», в якому лицарі Круглого столу відповідають на п'ять три питання, щоб перетнути Міст смерті
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.