Пол Грем «Помста ботанів», частина 1
Продовжуємо переклад есе та книги Пола Грема «Хакери та Художники». Оригінал - Revenge of the Nerds(хто хоче приєднатися до перекладу - пишіть у личку)
За переклад спасибі Щікотовій Яні.Травень 2002
Неосвічений начальник чудовим чином поєднує в собі дві якості, які самі по собі досить поширені, але рідко, коли об'єднуються в одній особі: (а) він зовсім нічого не знає про технології, і (б) у нього завжди є найтвердіші переконання щодо будь-якого питання, що їх стосується.
Припустимо, наприклад, Вам треба написати програму. Ваш начальник-невіглас не має жодного поняття про те, як вона повинна працювати, і не може відрізнити одну мову програмування від іншої, і все ж він знає, якою мовою Вам слід писати цю програму. А саме він вважає, що Вам слід писати її на Java. Чому він так думає? Давайте подивимося, що коїться тим часом у голові начальника-профана. Те, що він думає, виглядає так. Java це стандарт. Я знаю, так має бути, тому що я постійно читаю про це у ЗМІ. Оскільки це стандарт, у мене не будепроблем через його використання, що також означає, що завжди буде купа програмістів Java. Тому, якщо програмісти, які зараз працюють на мене, звільняться, оскільки всі програмісти, які працюють у мене, так завжди і роблять з якоїсь таємничої причини, я можу з легкістю їх замінити.
Ну, це не має сенсу. Але це все засноване на одному негласному припущенні, яке насправді є хибним. Такий начальник вважає, що всі мови програмування досить схожі. Якби це було так, він потрапив би в саму точку. Якби всі мови були б взаємозамінними, то звичайно, можна було б використовувати будь-яку мову, якою користуються інші.
Але всі мови різні, і я вважаю, що можу довести це Вам без зайвих подробиць про їх відмінності. Якби Ви запитали начальника у 1992 році якою мовою програмування слід писати програму, він би без сумніву відповів так, як і сьогодні. Програмне забезпечення слід писати на С++. Але якщо всі мови рівносильні, чому тоді думка начальства має взагалі змінитись? Тобто чому Java розробникам взагалі слід турбуватися про створення нової мови?
Очевидно, якщо Ви створюєте нову мову, то тільки тому, що думаєте, що вона, певною мірою, краща, ніж те, що вже є у людей. І дійсно, Гослінг дає зрозуміти в першій офіційній документації з Java, що та (мова програмування Java), у свою чергу, була створена, щоб вирішити деякі проблеми С++. І ось, будь ласка. Не всі мови є рівносильними. Якщо Ви простежите за ходом думок у голові нашого начальника до Java і назад, через історію Java до його витоків, у Вас виникне здогад, що йде в розріз із припущенням, з якого Ви почали.
То хто ж правий? Джеймс Гослінг, чи наш неосвічений начальник?Не дивно, що має рацію Гослінг. Деякі мови краще за інші для конкретних завдань. І, знаєте, це порушує низку цікавих питань. Java був розроблений, щоб бути найкращим для деякого кола завдань, порівняно з С++. Яких завдань? Коли краще використовувати Java, а коли С++? Чи існують ситуації, коли інші мови кращі, ніж ці.
Як тільки Ви почнете роздумувати над цим питанням, Ви потрапите до заплутаної ситуації. Якби начальникові довелося думати про завдання комплексно, у нього б мізки вибухнули. Як тільки він визначить усі мови програмування як рівнозначні, все, що йому потрібно зробити, це вибрати ту, у якої виявляться найпотужніші темпи розвитку. І, т.к. це більше питання моди, ніж технологій, навіть він, ймовірно, зможе отримати правильну відповідь. Але якщо мови різні, йому раптом доводиться вирішувати дві системи рівнянь, намагаючись знайти оптимальний баланс між двома речами, про які йому нічого невідомо: відносна прийнятність 20, або близько того, провідних мов для завдання, яке йому потрібно вирішити, та складність пошуку програмістів, бібліотек і т.д. кожному з них. Якщо це те, що криється за дверима, не дивно, що неосвічений начальник не захоче її відчиняти.
Недолік переконання у цьому, що це мови програмування еквівалентні, у тому, що це насправді негаразд. Але перевага полягає в тому, що це значно спрощує ваше життя. І я думаю, це основна причина, через яку це переконання так широко поширене. Такзручно.
Якщо розглянути ці мови у такому порядку Java, Perl, Python, можна помітити цікаву схему. Принаймні ця схема помітна, якщо Ви використовуєте Lisp. Кожен з них все більше схожий на Lisp. Python копіює навіть такі особливості, якіБагато Lisp програмісти приймають помилки. Можна було б терміново перекласти прості програми Lisp на Python. На дворі 2002 рік і мови програмування майже зрівнялися тим, що було розроблено у 1958 році.
Ідучи в ногу з математикою
Що я хочу сказати, то це те, що Lips був вперше відкритий Джоном Маккарті в 1958 році, а популярні мови програмування тільки зараз підхоплюють ідеї, які він на той час розвивав.
Отже, як таке може бути? Хіба комп'ютерні технології не змінюються дуже швидко? Я тільки хочу сказати, що в 1958 році комп'ютери були гігантами завбільшки з холодильник з потужністю процесорів як у наручного годинника. Як могла така стара технологія залишатись актуальною, не кажучи вже про те, щоб перевершити останні розробки?
Я розповім вам як. Все тому, що Lisp насправді не розроблявся як мова програмування, принаймні не в тому сенсі, що ми розуміємо сьогодні. Те, що ми маємо на увазі під мовою програмування, є тим, чим ми користуємося для вказівки комп'ютера, що робити. Маккарті врешті-решт планував розробляти мову програмування в цьому сенсі, але Lisp, до якого ми прийшли, був заснований на деякій окремій його роботі, суто теоретичного характеру, — спробі визначити зручнішу альтернативу машині Тьюринга. Як Маккарті пізніше казав:
«Інший спосіб показати, що Lisp точніше машин Тьюринга, це написати універсальну Lisp функцію і показати, що вона коротша і зрозуміліша, ніж опис універсальної машини Тьюринга. Такою була Lisp функція eval …, яка обчислює значення Lisp вирази…. Опис eval вимагало створення нотації, що представляє функції Lisp як дані мови Lisp, і така нотація була розроблена заради самогодослідження, не замислюючись про те, що вона буде використовуватися для вираження Lisp програм на практиці.
А потім сталося ось що. Через деякий час наприкінці 1958 року Стів Рассел, один з аспірантів Маккарті, глянув на визначення eval і усвідомив, що якби він переклав це в машинну мову, то результатом був би інтерпретатор для Lisp.
Це була велика несподіванка в ті часи. І ось що пізніше в інтерв'ю Маккарті сказав із цього приводу:
Стів Рассел сказав: "Послухай, чому б мені не запрограмувати цю eval функцію." А я відповів йому: «Ха, ти плутаєш теорію із практикою. Ця eval функція призначена для читання, а не обчислень. Але він продовжив роботу та зробив її. Таким чином, він скомпілював eval функцію з моєї роботи в машинний код IBM 704, виправив помилки, а потім представив це як інтерпретатор для Lisp, чим це насправді було. Таким чином, з цієї точки зору Lisp мав переважно ту форму, яку має сьогодні…
Раптом, вважаю, за якісь кілька тижнів, Маккарті виявив, що цей суто теоретичний захід перетворився на справжню мову програмування, і навіть потужнішу, ніж він припускав.
Таким чином, коротким поясненням того, чому ця мова 1950-х років не відносять до застарілих, є те, що її основою була не технологія, а математика. Адже математика не має терміну придатності. Правильніше порівнюватиме Lisp не з апаратурою 1950 року, а, скажімо, з алгоритмом швидкого сортування, який був відкритий у 1960 році і все ще є найшвидшим алгоритмом сортування загального призначення.
Існує інша мова, яка вижила з часів 1950-х років, Fortran, і вона представляє протилежний підхід до розробки мов. Lisp був теорією, яка несподіваноперетворилася на мову програмування. Fortran спочатку розроблявся як мова програмування, але, як би ми зараз оцінили, як низькорівневий.
Fortran I, розроблений у 1956 році, був зовсім іншого поля ягоди, на відміну від нинішньої мови Fortran. Fortran I більшою мірою був мовою асемблера з математикою. До певної міри він був слабшим за новіші мови асемблера. Наприклад, у ньому були відсутні підпрограми, лише операції переходу. Сучасний Fortran зараз, можливо, ближче до Lisp, ніж Fortran I.
Lisp і Fortran були гілками двох різних дерев еволюції. Один брав свій початок із математики, а другий – з архітектури машин. Ці два дерева з того часу переплітаються. Lisp потужно вистрілив і впродовж наступних 20 років прискорився. Так звані панівні (mainstream) мови швидко стартували, але на даний момент найбільш просунуті з них навряд чи можуть зрівнятися з Lisp. Вони недалеко від нього пішли, але їм все ще бракує кількох речей.
П.С.Якщо вам цікаво потрапити в Y Combinator і вам близькі ідеї Грема, пишіть в личку, є в мене кілька задумів.
А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»