Tag Archives: software development

OAuth2 – промінчик світла в темному царстві?

OAuth2 logo

З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/e-mail процедуру це мене запросто може відлякнути від реєстрації взагалі. Потім з’явилися всякі OpenID, Facebook Connect, OAuth і життя стало налагоджуватись – реєстрації на одному з популярних сервісів типу Google/Facebook/Twitter зазвичай вистачає аби мати можливість логінитись на нормальні сайти в один клік: наприклад той самий Покупон ніколи б не отримав моїх грошиків ні за які знижки аби у нього не було реєстрації через Facebook та оплати по Webmoney, коли можна було придбати купончика фактично не торкаючись клавіатури, а просто в кілька тицків мишкою. І впевнений, що я такий не один. Тому останнім часом завжди коли доводиться писати сайт з реєстрацією мну намагається всунути туди реєстрацію через “3rd party” сервіси. Але ще рік тому це була нефігова проблема, бо усі ці сервіси використовували різні протоколи і незважаючи на те, що всі вони намагались зробити якнайкраще – виходило як завжди, бо об’єднати все це в якусь уніфіковану систему не так вже й тривіально. Чи не найбільше мене напрягав OAuth, бо при першому знайомстві з його процесом обмінами токенів наскоком без півлітри не розібратися. Причому мало того, кожен сервіс часто використовував свою варіацію протоколу, що знову ж таки ускладнювало написання гнучкого коду.

Коли довелося причіплювати мультиавторизацію останній раз, я вже поступово готувався засісти в ці окопи надовго. Хоча в цьому випадку було простіше – у Django принаймні добрі люди написали django-publicauth. Документація там бідненька, тому як правильно його заюзати довелося гуглити по коду інших open-source проектів, які його використовували. Facebook тим не менш завівся досить живенько, а от на ВКонтакті вже мило чекали перші граблі: модуль більше року не оновлювався і там API для авторизації встиг змінитися. Доктор сказав “Різати!” Як виявилося, російський недофейсбук встиг перейти на OAuth2 і (о, диво!) там все було просто як гранчастий стакан (щоб отримати токен для подальших запитів треба зробити лише один редірект та один фоновий запит з мінімумом параметрів). Причому там все було настільки просто і так чудово лягло на архітектуру бекендів django-publicauth, що все пофіксилось буквально за пару годин (включно з вдуплянням в те як все парцює, першим прототипом та подальшим рефакторингом). Мало того, при пошуку інформації про новий протокол виявилося, що Google та Facebook вже теж його підтримують. Коротше кажучи, наступного вечора я переписав і ці дві системи під OAuth2 і все працювало як швейцарський годинник. На все про все менше 8 годин часу і майже готовий патч. Кароче, вирішив я форкнутиdjango-publicauth на bitbucket та влити туди свої правки 😎 Єдина поки що паршива вівця – це Twitter, який поки не підтримує другу версію, але благо перша там працює нормально.

OAuth2 server-side app flow
OAuth2 flow for server-side applications

Ложка дьогтю: не дивлячись на простоту реалізації стандарт OAuth2 ще не затверджено остаточною. Існує кілька його драфтів і всі використовують свої власні інтерпретації. Але за рахунок його простоти складність правок під конкретну реалізацію зазвичай є справою перевизначення пари методів. Причому насправді відмінності дуже тупі. Вконтакт повертає JSON-відповідь із “зайвим” рівнем вкладеності, Гугл вимагає авторизувати токен через POST-запит, а Фейсбук повертає результат не в JSON, а в urlencoded query string 😕

Стандартизація рулить 😎

OAuth2 – промінчик світла в темному царстві?

OAuth2 logo

З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/e-mail процедуру це мене запросто може відлякнути від реєстрації взагалі. Потім з’явилися всякі OpenID, Facebook Connect, OAuth і життя стало налагоджуватись – реєстрації на одному з популярних сервісів типу Google/Facebook/Twitter зазвичай вистачає аби мати можливість логінитись на нормальні сайти в один клік: наприклад той самий Покупон ніколи б не отримав моїх грошиків ні за які знижки аби у нього не було реєстрації через Facebook та оплати по Webmoney, коли можна було придбати купончика фактично не торкаючись клавіатури, а просто в кілька тицків мишкою. І впевнений, що я такий не один. Тому останнім часом завжди коли доводиться писати сайт з реєстрацією мну намагається всунути туди реєстрацію через “3rd party” сервіси. Але ще рік тому це була нефігова проблема, бо усі ці сервіси використовували різні протоколи і незважаючи на те, що всі вони намагались зробити якнайкраще – виходило як завжди, бо об’єднати все це в якусь уніфіковану систему не так вже й тривіально. Чи не найбільше мене напрягав OAuth, бо при першому знайомстві з його процесом обмінами токенів наскоком без півлітри не розібратися. Причому мало того, кожен сервіс часто використовував свою варіацію протоколу, що знову ж таки ускладнювало написання гнучкого коду.

Коли довелося причіплювати мультиавторизацію останній раз, я вже поступово готувався засісти в ці окопи надовго. Хоча в цьому випадку було простіше – у Django принаймні добрі люди написали django-publicauth. Документація там бідненька, тому як правильно його заюзати довелося гуглити по коду інших open-source проектів, які його використовували. Facebook тим не менш завівся досить живенько, а от на ВКонтакті вже мило чекали перші граблі: модуль більше року не оновлювався і там API для авторизації встиг змінитися. Доктор сказав “Різати!” Як виявилося, російський недофейсбук встиг перейти на OAuth2 і (о, диво!) там все було просто як гранчастий стакан (щоб отримати токен для подальших запитів треба зробити лише один редірект та один фоновий запит з мінімумом параметрів). Причому там все було настільки просто і так чудово лягло на архітектуру бекендів django-publicauth, що все пофіксилось буквально за пару годин (включно з вдуплянням в те як все парцює, першим прототипом та подальшим рефакторингом). Мало того, при пошуку інформації про новий протокол виявилося, що Google та Facebook вже теж його підтримують. Коротше кажучи, наступного вечора я переписав і ці дві системи під OAuth2 і все працювало як швейцарський годинник. На все про все менше 8 годин часу і майже готовий патч. Кароче, вирішив я форкнути django-publicauth на bitbucket та влити туди свої правки :cool: Єдина поки що паршива вівця – це Twitter, який поки не підтримує другу версію, але благо перша там працює нормально.

OAuth2 server-side app flow

OAuth2 flow for server-side applications

Ложка дьогтю: не дивлячись на простоту реалізації стандарт OAuth2 ще не затверджено остаточною. Існує кілька його драфтів і всі використовують свої власні інтерпретації. Але за рахунок його простоти складність правок під конкретну реалізацію зазвичай є справою перевизначення пари методів. Причому насправді відмінності дуже тупі. Вконтакт повертає JSON-відповідь із “зайвим” рівнем вкладеності, Гугл вимагає авторизувати токен через POST-запит, а Фейсбук повертає результат не в JSON, а в urlencoded query string :???:

Стандартизація рулить :cool:

Перемогти посередність

Нарешті в мене дійшли руки перекласти ще одну повчальну статтю Пола Грема про мови програмування, яку я вже згадував у минулому перекладі про “дух міста”. Зазвичай подібні “євангелістичні” речі я сприймаю вельми критично, оскільки я чудово знаю, що срібних куль не існує, але тим не менш думаю, що основна ідея вірна. Читаючи статтю зробіть поправку на те, що вона написана в 2003-му, тобто майже десятиріччя тому і з тих пір дещо змінилося, а Lisp вже не одна така мова-д’Артаньян 😉

Велика подяка Тарасу за виправлення купи помилок 🙂

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Beating the Averages

meditation [1]

Влітку 1995-го я та мій друг Роберт Морріс запустили стартап під назвою Viaweb. Нашою метою було написати програмне забезпечення, що дозволило б користувачам створювати власні онлайн-магазини. Інновацією на той час було те, що наш софт працював на нашому сервері, а інтерфейсом були звичайні веб-сторінки.

Я впевнений, що у багатьох людей виникла подібна ідея в той час, але наскільки я знаю, Viaweb був першим web-додатком. Це виглядало настільки ново для нас, що ми навіть компанію назвали аби підкреслити це: Viaweb, бо наше програмне забезпечення працювало “через Веб” (англ. “via Web”, – прим. пер.), а не на персональному комп’ютері.

Іншою назвичністю було те, що наш софт було написано здебільшого на мові програмування Lisp. Це був один із найперших великих додатків націлених на кінцевого користувача, написаних на Lisp, який до того часу був прерогативою університетів та дослідницьких лабораторій. [2]

Таємна зброя

Ерік Реймонд написав ессе під назвою “Як стати хакером” і в ньому, окрім усього іншого, він розповідає майбутнім хакерам про мови, які варто вивчати. Він пропонує розпочати з Python та Java, тому що їх просто вивчити. Серйозний хакер також захоче вивчити C, аби хакати Unix, та Perl для системного адміністрування й cgi-скриптів. І нарешті справжні хакери-аксакали мають подумати про Lisp:

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

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

Але хвилиночку. Ця метафора не поширюється так сильно. Причина того, що знання латини не забезпечить вас роботою тому що нею ніхто не розмовляє. Якщо ви писатимете латиною, ніхто вас не зрозуміє. Але Lisp – це мова програмування і комп’ютер розмовляє тією мовою, якою до нього спілкуєтсья програміст.

Тож якщо Lisp зробить з вас кращого розробника, як стверджує Ерік, то чому не використовувати його? Якщо художнику дати пензля, який дозволить йому стати кращим художником, то мені здається, що він почав би використовувати його у всіх своїх роботах, чи не так? Я не намагаюсь поглузувати з Еріка Реймонда. В цілому його порада – слушна. Те що він каже про Lisp – це загальноприйнятий міф. Але в цьому міфі є суперечність: Lisp зробить вас кращим розробником, але ви не будете його використовувати.

А чому ні? Зрештою, мови програмування – це всього на всього інструменти. І якщо Lisp справді вирощує кращих програмістів, використовуйте це. А якщо ні, то кому він здався?

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

Роберт та я, обидва знали Lisp непогано і ми не бачили жодної причини не довіритись власним інстинктам і обрати його. Ми знали, що всі інші пишуть софт на C++ чи Perl. Але ми також знали, що це ще нічого не означає. Якби ви обирали технологію з цих міркувань, то писали б під Windows. Коли ви обираєте технологію краще ігноруйте те що роблять інші і думайте лише про те, що працюватиме найкраще.

Це особливо справедливо по відношенню до стартапів. У великих компаніях ви можете робити лише те, що роблять інші великі компанії. Але у стартапі ви не можете робити те, що роблять інші стартапи. І я не думаю, що багато людей це розуміють навіть у стартапах.

Середня велика компанія росте приблизно на 10% за рік. Тож якщо ви керуєте великою компанією і працюєте як середньостатистична велика компанія, то ви можете розраховувати, що ви і зростати будете як середньостатистична велика компанія: на 10% в рік.

Звісно ж, ситуація зі стартапами – аналогічна. Якщо ви робите все як середній стартап, ви очікуєте на середню продуктивність. Проблема в тому, що для стартапа середня продуктивність дорівнює провалу. Коефіцієнт виживання у стартапів набагато менший за 50%. Тож якщо ви започатковуєте стартап – краще робіть щось дуже дивне. Якщо ви цього не робите – чекайте проблем.

Тоді в 1995 ми знали те, чого не розуміли наші конкуренти, а деякі не розуміють і досі: коли ви пишете ПЗ, яке працює на ваших серверах, то ви можете самі обрати будь-яку мову, яку захочете. Коли ви пишете програми для ПК, то ваші вподобання будуть схилятися до того, що найближче до ОС під яку ви пишете. Десять років тому (відносно моменту написання статті, тобто 2003 р., – прим. пер.) під розробкою ПЗ малося на увазі написання програм на C. Але з web-додатками, особливо коли у вас є програмні коди як ОС, так і мови програмування, ви можете обрати будь-яку мову.

Ця нова свобода, щоправда, палка з двома кінцями. Коли ви можете обирати будь-яку мову, треба вже замислитись на вибором: яку? Компанії, які роблять вигляд, що нічого не змінилося ризикують одного разу помітити, що їх конкуренти так не думають.

Якщо обирати будь-яку мову, то яку? Ми обрали Lisp. З одного боку очевидним було, що швидка розробка дуже важлива на цьому ринку. Ми розпочинали з чистого листа, тож компанія, яка могла б запропонувати нові можливості раніше інших, отримувала перевагу. Ми знали, що Lisp – це гарний вибір для того, аби писати софт швидко, а серверні додатки збільшували цей ефект тим, що ви могли релізитись тої ж хвилини, коли код було написано.

Якщо інші компанії не хотіли його використовувати – нам же ліпше. Він зробив нас передовиками, але ми не відмовлялись від будь-яких поступок. Коли ми розпочинали Viaweb, ми нічого не тямили в бізнесі. Ми нічого не знали про маркетинг, чи найм працівників, чи залучення інвестицій, чи роботу з клієнтами. У жодного з нас навіть не було досвіду справжньої роботи. Єдина річ, яку ми робили добре – це написання софту. І ми сподівались, що це допоможе нам. Ми використовували будь-яку перевагу, яку могли собі забезпечити.

Можна сказати, що використання Lisp було експериментом. Нашим припущенням було те, що пишучи софт на Lisp ми могли б впроваджувати нові можливості швидше за наших конкурентів. А оскільки Lisp дуже високорівневий, нам не потрібна була б велика команда розробників, тому наші витрати мали бути значно меншими. Якщо це так, то ми могли б запропонувати кращий продукт за менші гроші і отримати прибуток. Ми б забрали всіх користувачів, а конкуренти не отримали б жодного і пішли б з ринку. Це те на що ми сподівались.

Які ж результати нашого експерименту? В певному сенсі дивовижно, але це спрацювало. Ми мали багато конкурентів, приблизно 20-30, але жоден з них не міг з нами тягатись. Ми мали WYSIWYG-майстерню створення онлайн магазинів, яка працювала через web, але виглядала як додаток для ПК.. У наших конкурентів були CGI скрипти. І могли завжди попереду них по функціональним можливостям. Інколи, у розпачі, конкуренти намагалися реалізувати щось, чого не було у нас. Але цикл розробки на Lisp був настільки швидким, що ми могли реалізувати їх аналог за день чи два після того, як конкуренти анонсували їх у прес-релізі. До того часу, коли журналісти що висвітлювали прес-реліз дзвонили нам, у нас вона вже теж була.

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

Коли мені було років дев’ять, я отримав книжку “День Шакала” Фредеріка Форсайта. Головним героєм був вбивця, якого найняли “прибрати” президента Франції. Він мав пройти повз поліцію, аби дістатися до номера з якого було видно маршрут президента. Він пройшов повз них перевдягнувшись стариганом у лахмітті, якого вони б ніколи не запідозрили.

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

Отож, мені трохи ніяково казати, але я ніколи не говорив публічно про Lisp поки ми працювали у Viaweb. Ми ніколи не згадували про нього в ЗМІ, а якщо виконати пошук по сайту компанії, то знайшлася б лише згадка двох книжок у моїй біографії. І це не випадковість. Стартап має давати настільки мало інформації, наскільки можливо. Якщо вони не знали на чому ми писали чи їм було все одно, я намагався підтримувати цей статус-кво. [3]

Люди, які розуміли наші технології найкраще – це клієнти. Їм було все одно на якій мові було написано Viaweb, але вони помічали, що все працювало справді чудово. Вони могли створювати чудові онлайн магазини буквально за хвилини. І таким чином, в основному завдяки їх порадам, ми отримували все більше клієнтів. На початку 1996-го у нас було 70 магазинів. На кінець 1997 – вже 500, а шість місяців потому, коли нас купив Yahoo!, у нас уже було 1070 користувачів. Зараз під маркою Yahoo Store цей софт досі є лідером на ринку. Це одна з найбільш прибуткових частин Yahoo і магазини створені завдяки ньому стали основою Yahoo Shopping. Я покинув Yahoo в 1999, тож не знаю скільки зараз у них користувачів, але остання цифра, яку я чув – це 20000.

Blub-парадокс

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

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

Думаю навряд знайдеться багато людей, які заперечуватимуть, що вискорівневі мови програмування більш потужні за машинний код. Більшість програмістів погодяться, що зазвичай писати на машинній мові – це не дуже гарна ідея. Натомість краще використовувати високорівневі мови і дати можливість компілятору перевести її в машинний код за вас. Цю ідею зараз навіть використовують у апаратному забезпеченні: з 80-х років набори інструкцій розроблялися для компіляторів, а не для людей.

Кожен знає, що писати всю програму вручну в машинних кодах неправильно. Але мало хто розуміє, що цей принцип можна узагальнити: якщо у вас є вибір мов програмування, то при всіх інших рівних умовах правильно обрати найбільш потужну. [4]

Є багато виключень з цього правила. Якщо вам потрібно написати програму, яка має тісно співпрацювати з програмою написаною на певній мові, то краще використовувати саме ту мову. Якщо ви пишете програму, яка робить щось дуже просте, типу обробки чисел чи бітових маніпуляцій, можливо краще використовувати менш абстрактні мови, тим паче, що це може дати помітний приріст у швидкодії. Якщо ж ви пишете маленьку програмку “на викинути”, найкраще використати ту мову, у якої найбільш підходящий набір бібліотечних функцій. Але в цілому для розробки ПЗ вам варто використовувати найбільш потужну (і достатньо ефективну) мову програмування яку тільки зможете, а використання всього іншого – помилка того ж типу, хоч і в меншій мірі, як і програмування в машинних кодах.

Ви бачите, що машинні коди дуже низькорівневі. Але в певному загальноприйнятому сенсі всі високорівневі мови програмування вважаються еквівалентними. Але вони такими не є. Технічно термін “високорівнева мова” не має під собою чіткого визначення. Немає чіткої границі між машинними мовами з одного боку та всіма високорівневими мовами з іншого. Мови розподіляються по спектру [5] абстрактності від найбільш потужних і до машинних мов, які самі по собі різняться за потужністю.

Наприклад Cobol. Cobol – високорівнева мова в тому сенсі, що він компілюється в машинний код. Але ви що, правда сперечатиметесь, що Cobol не є еквівалентом, наприклад, Python? Та він мабуть ближчий до машинних мов, аніж до Python.

А як щодо Perl 4? Між Perl 4 та Perl 5 в мову були додані лексичні замикання. І більшість Perl-хакерів погодяться, що Perl 5 потужніший за Perl 4. Але визнаючи це, ви також визнаєте що одна високорівнева мова може бути потужніша за іншу високорівневу мову. І невмолимим є висновок, що окрім певних винятків, ви повинні використовувати найпотужнішу доступну мову.

Щоправда цю ідею рідко доводять до кінця. Після певного віку програмісти рідко добровільно змінюють мовні вподобання. Яку б мову вони не використовували, вони вважають її “достатньо хорошою”.

Програмісти дуже прив’язуються до улюблених мов і я не хочу образити нічиїх почуттів, тому я поясню все на прикладі гіпотетичної мови Blub. Blub знаходиться рівно посередині спектру абстрактності. Він не є найбільш потужним, але значно потужніший за Cobol чи машинний код.

І насправді наш гіпотетичний Blub-розробник не буде використовувати жоден з них. Звісно, він не писатиме в машинних кодах. Для цього є компілятори. А щодо Cobol, то він не знає як на ньому написати все, що йому треба. У нього ж просто немає X (бідь-яка фіча Blub на ваш вибір).

До тих пір поки гіпотетичний Blub-розробник дивиться на спектр вниз він знає, що він дивиться вниз. Мови менш потужні за Blub очевидно менш потужні, бо в них нема тих можливостей до яких він звик. Але коли цей розробник подивиться в іншу сторону, вверх по спектру потужності, він не розумітиме, що дивиться вверх. Все, що він бачить – це лише дивні мови. Він мабуть навіть вважає їх еквівалентними Blub по потужності, але з усіма цими незрозумілими заморочками. Blub для нього “достатньо гарний”, бо він думає на ньому.

Коли ми поглянемо на те саме з точки зору програміста, який використовує мову, що знаходиться вище по спектру потужності, ми побачимо, що він дивиться на Blub згори. Як на ньому взагалі можна писати? У нього ж нема Y!

По індукції лише програмісти, що дивляться з висоти достатньої аби оцінити всю різницю в потужності різних мов можуть сказати які з них насправді найбільш потужні (і мабуть це саме те, що мав на увазі Ерік Ремонд, коли казав, що Lisp зробить з вас кращого розробника). Ви не можете довіритись думці інших через Blub-парадокс:: всі задоволені тією мовою, якою їм доводиться користуватись, тому що вона диктує їм те як писати.

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

П’ять мов, що рекомендує Ерік Реймонд, розташовані в різних точках спектру потужності. Питання відносних відстаней між ними дуже чутлива тема. Я б помістив Lisp на його вершину. І аби підкріпити це твердження я скажу про одну з речей, якої мені бракує в чотирьох інших. Я думаю: “як на них взагалі можна щось написати без макросів?” [5]

Багато мов мають особливість, яка називається називається макросами. Але макроси Lisp унікальні. І хочете – вірте, хочете – ні, але це пов’язано з дужками. Дизайнери Lisp засунули туди ці дужки не просто аби відрізнятись від інших. Для Bulb-програміста код на Lisp виглядає дивно. Але дужки там не просто так. Вони очевидний доказ фундаментальної різниці між Lisp там всіма іншими мовами.

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

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

Програми, що пишуть програми? Вам це взагалі потрібно? Не дуже, якщо ви думаєте на рівні Cobol. Ввесь час, якщо ви думаєте на рівні Lisp. Зручно було б якби я міг навести тут приклад потужного макросу і сказати: “Ось! Як вам таке?” Але якби я це зробив, це виглядало б повною тарабарщиною для людини, яка не знає Lisp; і тут не вистачить місця, аби описати все, що вам потрібно знати, аби зрозуміти його значення. В Ansi Common Lisp я намагався проходити всі теми якомога швидше і все одно дістався до макросів лише на 160-й сторінці.

Але я думаю, що зможу навести приклад, який може бути переконливим. Програмний код Viaweb редактора складався з макросів на 20-25%. Макроси важче писати, аніж звичайні функції Lisp і використовувати їх там де це не обов’язково – ознака поганого тону. Тому кожен макрос в тому коді був там, тому що він мав там бути. Це означає, що як мінімум 20-25% коду програми роблять речі, які не так-то легко зробити засобами інших мов. Яким би скептиком не був Blub-програміст відносно моїх заяв про потужність Lisp, цього має бути достатньо аби розпалити його зацікавленість. Ми не писали код заради власного задоволення. Ми були крихітним стартапом і програмували щосили аби звести технічні мури між нами та нашими конкурентами.

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

Айкідо для стартапів

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

Якщо ви думаєте використовувати Lisp у стартапі, не переживайте, що не всі вас зрозуміють. Вам навпаки краще сподіватись на цей статус-кво. І скоріш за все так і буде. Така природа мов програмування: програмісти задовольняються тим, що в них є. Апаратне забезпечення змінюється набагато швидше ніж звички, тому практики програмування вже відстають від потужності процесорів на 10-20 років. У закладах типу Массачусетського технологічного університету пишуть програми на високорівневих мовах з середини 60-х, але багато компаній продовжували писати програми в машинних кодах аж до 80-х. Я впевнений, що багато хто продовжував писати на машинних мовах поки процесор, як бармен, що взяв, закрив заклад і просто пішов додому, нарешті залишив їх не при справах переходом на RISC інструкції.

Звичайні технології змінюються швидко. Але мови програмування інші: вони представляють собою не просто технологію, а те як програмісти мислять. Вони наполовину – технології, а наполовину – релігія. [6] І середньостатистична мова (тобто будь-яка мова, якою користується середньостатистичний програміст) розвивається зі швидкістю айсберга. Garbage collection, що з’явився в Lisp ще у 60-х зараз вважається гарною річчю. Runtime-типізація теж набирає популярність. Лексичні замикання, що з’явились в Lisp ще на початку 70-х зараз лише з’явились на “радарах”. Макроси, запропоновані в Lisp в середині – 80-х і досі “terra incognita”

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

Якщо ви працюєте у великій компанії – це буде нелегко. Вам складно буде переконати тупуватого начальника дозволити написати щось на Lisp, коли він лише щойно прочитав, що якась інша мова програмування приречена на успіх, як пророкували мові Ada 20 років тому. Але якщо ви працюєте у стартапі, у якого ще немає тупуватого начальства, ви можете використати Blub-парадокс на власну користь: використати технологію, яку ваші конкуренти, скуті середньостатистичними мовами, ніколи не зможуть перевершити.

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

За роки роботи у Viaweb я прочитав багато описів вакансій. Нові конкуренти, здається, з’являлись нізвідки майже кожен місяць. Перша річ, яку я перевіряв після їх online-демо, це відкриті вакансії. Після кількох років я вже розумів, які компанії могли представляти потенційну загрозу, а які – ні. Чим більше звичних речей було в описів вакансій, тим меншу небезпеку вона представляла. Найбільш безпечними були ті, що вимагали досвід роботи з Oracle. Про них можна було одразу забути. Вам також не треба було особливо переживати відносно компаній, що шукали C++ та Java розробників. Якщо компанія шукала розробників на Perl чи Python – її вже треба було остерігатися, адже це компанії, де принаймні за технічну сторону відповідали справжні хакери. Якби я зустрів опис вакансії на місце Lisp-розробника, то це мене б дуже сильно занепокоїло.


  1. Photo by AlicePopkorn ↩︎

  2. Viaweb складався з двох частин: редактор, насписаний на Lisp за допомогою якого люди будували сайти та система замовлень написана на C. Перша реалізація була написана на Lisp майже повністю, бо система замовлень була дуже простою. Пізніше ми додали ще два модулі: генератор картинок написаний на C та back-office менеджер написаний здебільшого на Perl.
    У січні 2003 Яху випустила нову версію редактора написану на C++ та Perl. Але важко було сказати, що це вже не був Lisp, бо для того, аби переписати код на C++ їм фактично довелось написати власний інтерпретатор: програмні коди генератора сторінок, наскільки мені відомо, досі написані на Lisp. ↩︎

  3. Роберт Морріс каже, що мені не треба було цього приховувати, бо навіть якби наші конкуренти знали, що ми використовуємо Lisp, вони не зрозуміли б чому: “Якби вони були достатньо розумними для цього, то самі використовували б Lisp.” ↩︎

  4. Всі мови рівнопотужні в сенсі еквівалаентності машині Тюрінга, але програмісти ніколи не мають на увазі саме цю еквівалентність (ніхто ж не пише для машини Тюрінга). Потужність про яку говорять програмісти складно визначити формально, але одним із способів описати її буде: можливість мови більш потужної може бути реалізована на мові менш потужній лише шляхом написання інтерпретатора більш потужної мови. Якщо у мові А є оператор для видалення пробілів з рядка, а у мові Б – ні, то це не робить мову А більш потужною, бо ви можете написати функцію, яка робитиме те саме в Б. Але якщо А підтримує, скажімо, рекурсію, а Б – ні, то це вже не реалізуєш простим написанням бібліотечної функції. ↩︎

  5. Примітка для нердів: можливо це решітка, що звужується догори; форма не має значення, але ідея в тому, що там є принаймні частковий порядок. ↩︎

  6. В результаті порівняння мов програмування або приймає вид релігійних воєн, або книжок для школярів показово нейтральних, як взірець гуманізму. Люди, що знаю ціну своєму часу та душевний спокій оминають цю тему. Але це питання релігійне лише наполовину; його варто вивчати, особливо якщо ви хочете винайти нову мову. ↩︎

Перемогти посередність

Нарешті в мене дійшли руки перекласти ще одну повчальну статтю Пола Грема про мови програмування, яку я вже згадував у минулому перекладі про “дух міста”. Зазвичай подібні “євангелістичні” речі я сприймаю вельми критично, оскільки я чудово знаю, що срібних куль не існує, але тим не менш думаю, що основна ідея вірна. Читаючи статтю зробіть поправку на те, що вона написана в 2003-му, тобто майже десятиріччя тому і з тих пір дещо змінилося, а Lisp вже не одна така мова-д’Артаньян ;)

Велика подяка Тарасу за виправлення купи помилок :)

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Beating the Averages

meditation

Photo by AlicePopkorn

Влітку 1995-го я та мій друг Роберт Морріс запустили стартап під назвою Viaweb. Нашою метою було написати програмне забезпечення, що дозволило б користувачам створювати власні онлайн-магазини. Інновацією на той час було те, що наш софт працював на нашому сервері, а інтерфейсом були звичайні веб-сторінки.

Я впевнений, що у багатьох людей виникла подібна ідея в той час, але наскільки я знаю, Viaweb був першим web-додатком. Це виглядало настільки ново для нас, що ми навіть компанію назвали аби підкреслити це: Viaweb, бо наше програмне забезпечення працювало “через Веб” (англ. “via Web”, – прим. пер.), а не на персональному комп’ютері.

Іншою назвичністю було те, що наш софт було написано здебільшого на мові програмування Lisp. Це був один із найперших великих додатків націлених на кінцевого користувача, написаних на Lisp, який до того часу був прерогативою університетів та дослідницьких лабораторій. [1]

Таємна зброя

Ерік Реймонд написав ессе під назвою “Як стати хакером” і в ньому, окрім усього іншого, він розповідає майбутнім хакерам про мови, які варто вивчати. Він пропонує розпочати з Python та Java, тому що їх просто вивчити. Серйозний хакер також захоче вивчити C, аби хакати Unix, та Perl для системного адміністрування й cgi-скриптів. І нарешті справжні хакери-аксакали мають подумати про Lisp:

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

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

Але хвилиночку. Ця метафора не поширюється так сильно. Причина того, що знання латини не забезпечить вас роботою тому що нею ніхто не розмовляє. Якщо ви писатимете латиною, ніхто вас не зрозуміє. Але Lisp – це мова програмування і комп’ютер розмовляє тією мовою, якою до нього спілкуєтсья програміст.

Тож якщо Lisp зробить з вас кращого розробника, як стверджує Ерік, то чому не використовувати його? Якщо художнику дати пензля, який дозволить йому стати кращим художником, то мені здається, що він почав би використовувати його у всіх своїх роботах, чи не так? Я не намагаюсь поглузувати з Еріка Реймонда. В цілому його порада – слушна. Те що він каже про Lisp – це загальноприйнятий міф. Але в цьому міфі є суперечність: Lisp зробить вас кращим розробником, але ви не будете його використовувати.

А чому ні? Зрештою, мови програмування – це всього на всього інструменти. І якщо Lisp справді вирощує кращих програмістів, використовуйте це. А якщо ні, то кому він здався?

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

Роберт та я, обидва знали Lisp непогано і ми не бачили жодної причини не довіритись власним інстинктам і обрати його. Ми знали, що всі інші пишуть софт на C++ чи Perl. Але ми також знали, що це ще нічого не означає. Якби ви обирали технологію з цих міркувань, то писали б під Windows. Коли ви обираєте технологію краще ігноруйте те що роблять інші і думайте лише про те, що працюватиме найкраще.

Це особливо справедливо по відношенню до стартапів. У великих компаніях ви можете робити лише те, що роблять інші великі компанії. Але у стартапі ви не можете робити те, що роблять інші стартапи. І я не думаю, що багато людей це розуміють навіть у стартапах.

Середня велика компанія росте приблизно на 10% за рік. Тож якщо ви керуєте великою компанією і працюєте як середньостатистична велика компанія, то ви можете розраховувати, що ви і зростати будете як середньостатистична велика компанія: на 10% в рік.

Звісно ж, ситуація зі стартапами – аналогічна. Якщо ви робите все як середній стартап, ви очікуєте на середню продуктивність. Проблема в тому, що для стартапа середня продуктивність дорівнює провалу. Коефіцієнт виживання у стартапів набагато менший за 50%. Тож якщо ви започатковуєте стартап – краще робіть щось дуже дивне. Якщо ви цього не робите – чекайте проблем.

Тоді в 1995 ми знали те, чого не розуміли наші конкуренти, а деякі не розуміють і досі: коли ви пишете ПЗ, яке працює на ваших серверах, то ви можете самі обрати будь-яку мову, яку захочете. Коли ви пишете програми для ПК, то ваші вподобання будуть схилятися до того, що найближче до ОС під яку ви пишете. Десять років тому (відносно моменту написання статті, тобто 2003 р., – прим. пер.) під розробкою ПЗ малося на увазі написання програм на C. Але з web-додатками, особливо коли у вас є програмні коди як ОС, так і мови програмування, ви можете обрати будь-яку мову.

Ця нова свобода, щоправда, палка з двома кінцями. Коли ви можете обирати будь-яку мову, треба вже замислитись на вибором: яку? Компанії, які роблять вигляд, що нічого не змінилося ризикують одного разу помітити, що їх конкуренти так не думають.

Якщо обирати будь-яку мову, то яку? Ми обрали Lisp. З одного боку очевидним було, що швидка розробка дуже важлива на цьому ринку. Ми розпочинали з чистого листа, тож компанія, яка могла б запропонувати нові можливості раніше інших, отримувала перевагу. Ми знали, що Lisp – це гарний вибір для того, аби писати софт швидко, а серверні додатки збільшували цей ефект тим, що ви могли релізитись тої ж хвилини, коли код було написано.

Якщо інші компанії не хотіли його використовувати – нам же ліпше. Він зробив нас передовиками, але ми не відмовлялись від будь-яких поступок. Коли ми розпочинали Viaweb, ми нічого не тямили в бізнесі. Ми нічого не знали про маркетинг, чи найм працівників, чи залучення інвестицій, чи роботу з клієнтами. У жодного з нас навіть не було досвіду справжньої роботи. Єдина річ, яку ми робили добре – це написання софту. І ми сподівались, що це допоможе нам. Ми використовували будь-яку перевагу, яку могли собі забезпечити.

Можна сказати, що використання Lisp було експериментом. Нашим припущенням було те, що пишучи софт на Lisp ми могли б впроваджувати нові можливості швидше за наших конкурентів. А оскільки Lisp дуже високорівневий, нам не потрібна була б велика команда розробників, тому наші витрати мали бути значно меншими. Якщо це так, то ми могли б запропонувати кращий продукт за менші гроші і отримати прибуток. Ми б забрали всіх користувачів, а конкуренти не отримали б жодного і пішли б з ринку. Це те на що ми сподівались.

Які ж результати нашого експерименту? В певному сенсі дивовижно, але це спрацювало. Ми мали багато конкурентів, приблизно 20-30, але жоден з них не міг з нами тягатись. Ми мали WYSIWYG-майстерню створення онлайн магазинів, яка працювала через web, але виглядала як додаток для ПК.. У наших конкурентів були CGI скрипти. І могли завжди попереду них по функціональним можливостям. Інколи, у розпачі, конкуренти намагалися реалізувати щось, чого не було у нас. Але цикл розробки на Lisp був настільки швидким, що ми могли реалізувати їх аналог за день чи два після того, як конкуренти анонсували їх у прес-релізі. До того часу, коли журналісти що висвітлювали прес-реліз дзвонили нам, у нас вона вже теж була.

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

Коли мені було років дев’ять, я отримав книжку “День Шакала” Фредеріка Форсайта. Головним героєм був вбивця, якого найняли “прибрати” президента Франції. Він мав пройти повз поліцію, аби дістатися до номера з якого було видно маршрут президента. Він пройшов повз них перевдягнувшись стариганом у лахмітті, якого вони б ніколи не запідозрили.

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

Отож, мені трохи ніяково казати, але я ніколи не говорив публічно про Lisp поки ми працювали у Viaweb. Ми ніколи не згадували про нього в ЗМІ, а якщо виконати пошук по сайту компанії, то знайшлася б лише згадка двох книжок у моїй біографії. І це не випадковість. Стартап має давати настільки мало інформації, наскільки можливо. Якщо вони не знали на чому ми писали чи їм було все одно, я намагався підтримувати цей статус-кво. [2]

Люди, які розуміли наші технології найкраще – це клієнти. Їм було все одно на якій мові було написано Viaweb, але вони помічали, що все працювало справді чудово. Вони могли створювати чудові онлайн магазини буквально за хвилини. І таким чином, в основному завдяки їх порадам, ми отримували все більше клієнтів. На початку 1996-го у нас було 70 магазинів. На кінець 1997 – вже 500, а шість місяців потому, коли нас купив Yahoo!, у нас уже було 1070 користувачів. Зараз під маркою Yahoo Store цей софт досі є лідером на ринку. Це одна з найбільш прибуткових частин Yahoo і магазини створені завдяки ньому стали основою Yahoo Shopping. Я покинув Yahoo в 1999, тож не знаю скільки зараз у них користувачів, але остання цифра, яку я чув – це 20000.

Blub-парадокс

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

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

Думаю навряд знайдеться багато людей, які заперечуватимуть, що вискорівневі мови програмування більш потужні за машинний код. Більшість програмістів погодяться, що зазвичай писати на машинній мові – це не дуже гарна ідея. Натомість краще використовувати високорівневі мови і дати можливість компілятору перевести її в машинний код за вас. Цю ідею зараз навіть використовують у апаратному забезпеченні: з 80-х років набори інструкцій розроблялися для компіляторів, а не для людей.

Кожен знає, що писати всю програму вручну в машинних кодах неправильно. Але мало хто розуміє, що цей принцип можна узагальнити: якщо у вас є вибір мов програмування, то при всіх інших рівних умовах правильно обрати найбільш потужну. [3]

Є багато виключень з цього правила. Якщо вам потрібно написати програму, яка має тісно співпрацювати з програмою написаною на певній мові, то краще використовувати саме ту мову. Якщо ви пишете програму, яка робить щось дуже просте, типу обробки чисел чи бітових маніпуляцій, можливо краще використовувати менш абстрактні мови, тим паче, що це може дати помітний приріст у швидкодії. Якщо ж ви пишете маленьку програмку “на викинути”, найкраще використати ту мову, у якої найбільш підходящий набір бібліотечних функцій. Але в цілому для розробки ПЗ вам варто використовувати найбільш потужну (і достатньо ефективну) мову програмування яку тільки зможете, а використання всього іншого – помилка того ж типу, хоч і в меншій мірі, як і програмування в машинних кодах.

Ви бачите, що машинні коди дуже низькорівневі. Але в певному загальноприйнятому сенсі всі високорівневі мови програмування вважаються еквівалентними. Але вони такими не є. Технічно термін “високорівнева мова” не має під собою чіткого визначення. Немає чіткої границі між машинними мовами з одного боку та всіма високорівневими мовами з іншого. Мови розподіляються по спектру [4] абстрактності від найбільш потужних і до машинних мов, які самі по собі різняться за потужністю.

Наприклад Cobol. Cobol – високорівнева мова в тому сенсі, що він компілюється в машинний код. Але ви що, правда сперечатиметесь, що Cobol не є еквівалентом, наприклад, Python? Та він мабуть ближчий до машинних мов, аніж до Python.

А як щодо Perl 4? Між Perl 4 та Perl 5 в мову були додані лексичні замикання. І більшість Perl-хакерів погодяться, що Perl 5 потужніший за Perl 4. Але визнаючи це, ви також визнаєте що одна високорівнева мова може бути потужніша за іншу високорівневу мову. І невмолимим є висновок, що окрім певних винятків, ви повинні використовувати найпотужнішу доступну мову.

Щоправда цю ідею рідко доводять до кінця. Після певного віку програмісти рідко добровільно змінюють мовні вподобання. Яку б мову вони не використовували, вони вважають її “достатньо хорошою”.

Програмісти дуже прив’язуються до улюблених мов і я не хочу образити нічиїх почуттів, тому я поясню все на прикладі гіпотетичної мови Blub. Blub знаходиться рівно посередині спектру абстрактності. Він не є найбільш потужним, але значно потужніший за Cobol чи машинний код.

І насправді наш гіпотетичний Blub-розробник не буде використовувати жоден з них. Звісно, він не писатиме в машинних кодах. Для цього є компілятори. А щодо Cobol, то він не знає як на ньому написати все, що йому треба. У нього ж просто немає X (бідь-яка фіча Blub на ваш вибір).

До тих пір поки гіпотетичний Blub-розробник дивиться на спектр вниз він знає, що він дивиться вниз. Мови менш потужні за Blub очевидно менш потужні, бо в них нема тих можливостей до яких він звик. Але коли цей розробник подивиться в іншу сторону, вверх по спектру потужності, він не розумітиме, що дивиться вверх. Все, що він бачить – це лише дивні мови. Він мабуть навіть вважає їх еквівалентними Blub по потужності, але з усіма цими незрозумілими заморочками. Blub для нього “достатньо гарний”, бо він думає на ньому.

Коли ми поглянемо на те саме з точки зору програміста, який використовує мову, що знаходиться вище по спектру потужності, ми побачимо, що він дивиться на Blub згори. Як на ньому взагалі можна писати? У нього ж нема Y!

По індукції лише програмісти, що дивляться з висоти достатньої аби оцінити всю різницю в потужності різних мов можуть сказати які з них насправді найбільш потужні (і мабуть це саме те, що мав на увазі Ерік Ремонд, коли казав, що Lisp зробить з вас кращого розробника). Ви не можете довіритись думці інших через Blub-парадокс:: всі задоволені тією мовою, якою їм доводиться користуватись, тому що вона диктує їм те як писати.

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

П’ять мов, що рекомендує Ерік Реймонд, розташовані в різних точках спектру потужності. Питання відносних відстаней між ними дуже чутлива тема. Я б помістив Lisp на його вершину. І аби підкріпити це твердження я скажу про одну з речей, якої мені бракує в чотирьох інших. Я думаю: “як на них взагалі можна щось написати без макросів?” [5]

Багато мов мають особливість, яка називається називається макросами. Але макроси Lisp унікальні. І хочете – вірте, хочете – ні, але це пов’язано з дужками. Дизайнери Lisp засунули туди ці дужки не просто аби відрізнятись від інших. Для Bulb-програміста код на Lisp виглядає дивно. Але дужки там не просто так. Вони очевидний доказ фундаментальної різниці між Lisp там всіма іншими мовами.

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

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

Програми, що пишуть програми? Вам це взагалі потрібно? Не дуже, якщо ви думаєте на рівні Cobol. Ввесь час, якщо ви думаєте на рівні Lisp. Зручно було б якби я міг навести тут приклад потужного макросу і сказати: “Ось! Як вам таке?” Але якби я це зробив, це виглядало б повною тарабарщиною для людини, яка не знає Lisp; і тут не вистачить місця, аби описати все, що вам потрібно знати, аби зрозуміти його значення. В Ansi Common Lisp я намагався проходити всі теми якомога швидше і все одно дістався до макросів лише на 160-й сторінці.

Але я думаю, що зможу навести приклад, який може бути переконливим. Програмний код Viaweb редактора складався з макросів на 20-25%. Макроси важче писати, аніж звичайні функції Lisp і використовувати їх там де це не обов’язково – ознака поганого тону. Тому кожен макрос в тому коді був там, тому що він мав там бути. Це означає, що як мінімум 20-25% коду програми роблять речі, які не так-то легко зробити засобами інших мов. Яким би скептиком не був Blub-програміст відносно моїх заяв про потужність Lisp, цього має бути достатньо аби розпалити його зацікавленість. Ми не писали код заради власного задоволення. Ми були крихітним стартапом і програмували щосили аби звести технічні мури між нами та нашими конкурентами.

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

Айкідо для стартапів

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

Якщо ви думаєте використовувати Lisp у стартапі, не переживайте, що не всі вас зрозуміють. Вам навпаки краще сподіватись на цей статус-кво. І скоріш за все так і буде. Така природа мов програмування: програмісти задовольняються тим, що в них є. Апаратне забезпечення змінюється набагато швидше ніж звички, тому практики програмування вже відстають від потужності процесорів на 10-20 років. У закладах типу Массачусетського технологічного університету пишуть програми на високорівневих мовах з середини 60-х, але багато компаній продовжували писати програми в машинних кодах аж до 80-х. Я впевнений, що багато хто продовжував писати на машинних мовах поки процесор, як бармен, що взяв, закрив заклад і просто пішов додому, нарешті залишив їх не при справах переходом на RISC інструкції.

Звичайні технології змінюються швидко. Але мови програмування інші: вони представляють собою не просто технологію, а те як програмісти мислять. Вони наполовину – технології, а наполовину – релігія. [6] І середньостатистична мова (тобто будь-яка мова, якою користується середньостатистичний програміст) розвивається зі швидкістю айсберга. Garbage collection, що з’явився в Lisp ще у 60-х зараз вважається гарною річчю. Runtime-типізація теж набирає популярність. Лексичні замикання, що з’явились в Lisp ще на початку 70-х зараз лише з’явились на “радарах”. Макроси, запропоновані в Lisp в середині – 80-х і досі “terra incognita”

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

Якщо ви працюєте у великій компанії – це буде нелегко. Вам складно буде переконати тупуватого начальника дозволити написати щось на Lisp, коли він лише щойно прочитав, що якась інша мова програмування приречена на успіх, як пророкували мові Ada 20 років тому. Але якщо ви працюєте у стартапі, у якого ще немає тупуватого начальства, ви можете використати Blub-парадокс на власну користь: використати технологію, яку ваші конкуренти, скуті середньостатистичними мовами, ніколи не зможуть перевершити.

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

За роки роботи у Viaweb я прочитав багато описів вакансій. Нові конкуренти, здається, з’являлись нізвідки майже кожен місяць. Перша річ, яку я перевіряв після їх online-демо, це відкриті вакансії. Після кількох років я вже розумів, які компанії могли представляти потенційну загрозу, а які – ні. Чим більше звичних речей було в описів вакансій, тим меншу небезпеку вона представляла. Найбільш безпечними були ті, що вимагали досвід роботи з Oracle. Про них можна було одразу забути. Вам також не треба було особливо переживати відносно компаній, що шукали C++ та Java розробників. Якщо компанія шукала розробників на Perl чи Python – її вже треба було остерігатися, адже це компанії, де принаймні за технічну сторону відповідали справжні хакери. Якби я зустрів опис вакансії на місце Lisp-розробника, то це мене б дуже сильно занепокоїло.

Примітки

[1] Viaweb складався з двох частин: редактор, насписаний на Lisp за допомогою якого люди будували сайти та система замовлень написана на C. Перша реалізація була написана на Lisp майже повністю, бо система замовлень була дуже простою. Пізніше ми додали ще два модулі: генератор картинок написаний на C та back-office менеджер написаний здебільшого на Perl.

У січні 2003 Яху випустила нову версію редактора написану на C++ та Perl. Але важко було сказати, що це вже не був Lisp, бо для того, аби переписати код на C++ їм фактично довелось написати власний інтерпретатор: програмні коди генератора сторінок, наскільки мені відомо, досі написані на Lisp.

[2] Роберт Морріс каже, що мені не треба було цього приховувати, бо навіть якби наші конкуренти знали, що ми використовуємо Lisp, вони не зрозуміли б чому: “Якби вони були достатньо розумними для цього, то самі використовували б Lisp.”

[3] Всі мови рівнопотужні в сенсі еквівалаентності машині Тюрінга, але програмісти ніколи не мають на увазі саме цю еквівалентність (ніхто ж не пише для машини Тюрінга). Потужність про яку говорять програмісти складно визначити формально, але одним із способів описати її буде: можливість мови більш потужної може бути реалізована на мові менш потужній лише шляхом написання інтерпретатора більш потужної мови. Якщо у мові А є оператор для видалення пробілів з рядка, а у мові Б – ні, то це не робить мову А більш потужною, бо ви можете написати функцію, яка робитиме те саме в Б. Але якщо А підтримує, скажімо, рекурсію, а Б – ні, то це вже не реалізуєш простим написанням бібліотечної функції.

[4] Примітка для нердів: можливо це решітка, що звужується догори; форма не має значення, але ідея в тому, що там є принаймні частковий порядок.

[5] Це трохи невірно трактувати макроси як окрему фічу. На практиці їх користь значно збільшується завдяки іншим можливостям Lisp типу лексичних замикань та залишкових параметрів.

[6] В результаті порівняння мов програмування або приймає вид релігійних воєн, або книжок для школярів показово нейтральних, як взірець гуманізму. Люди, що знаю ціну своєму часу та душевний спокій оминають цю тему. Але це питання релігійне лише наполовину; його варто вивчати, особливо якщо ви хочете винайти нову мову.