Расмус Лердорф , творець PHP: «Я хочу робити речі для реальних людей»

Людина, що придумала один з найпоширеніших мов програмування - 44 -річний Расмус Лердорф ( Rasmus Lerdorf ) , - народився в Гренландії , а останні роки проживає в США . Втім , «живе» - голосно сказано : за словами самого Лердорфом , дуже багато часу він проводить в подорожах по самих різних країнах , зустрічаючись з людьми, які використовують PHP в самих різних сферах життя.

На початку жовтня Расмус Лердорф брав участь у конференції IDCEE'13 в Києві , де я і зміг поспілкуватися з ним і поставити частина питань , запропонованих читачами DOU на форумі .

- Як просувається робота над PHP 5.6 ?

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

- В одному з попередніх інтерв'ю ви говорили , що в команді розробників PHP немає структури . Чи справді це так , і як взагалі виглядає процес розробки?

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

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

- Значить , добровольці працюють над чим хочуть , а ви робите все інше ?

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

- Це анархія.

- Можна і так сказати . З іншого боку , якщо люди пишуть код не за гроші , а просто тому , що їм це цікаво , то в підсумку виходить багато цікавих речей. Часто буває , що програмісти імплементують можливості , які потрібні їм самим: скажімо , вони працюють в компанії , і для їхнього продукту не вистачає якоїсь фічі в PHP . Загалом, ніякої структури дійсно немає , і через це складно відповідати на питання, що стосуються можливостей наступної версії мови або строку її запуску.

- А ви самі не думали про те , щоб заснувати компанію начебто MySQL і структурувати розробку PHP?

- Ні .

- Вам не подобається , як компанії розробляють мови ?

- PHP - просто інструмент , за допомогою якого можна сколотити класні штуки. І мені подобається саме це - те , що створено за допомогою PHP . Я ніколи не працював у компанії, що виробляє інструменти; багато років я пропрацював в Yahoo , потім в WePay , зараз - у Etsy . Це компанії , які працюють для нормальних , звичайних людей , і PHP - їх невід'ємна частина . Це інструмент , яким ми користуємося , щоб робити речі для реальних людей.

А компанії , які роблять інструменти , працюють не для людей , а для програмістів - як Mongo , як MySQL і т.п. Якщо вийти на вулицю і запитати звичайних людей , чи чули вони про Mongo або MySQL , ніхто не відповість ствердно. І про PHP ніхто з них не чув , і це добре.

З іншого боку , якщо вийти на вулицю і запитати людей , чи чули вони про Facebook , що вони дадуть відповідь ? Всі скажуть , що чули. Мене цікавлять саме такі продукти , я хочу робити речі для реальних людей. Ви питаєте , чому я не хочу заснувати компанію для розробки PHP? Він не стосується реальних людей , тільки придурків типу мене ; до того ж робити щось для програмістів - дуже дражливе заняття.

- Чи означає це , що в якийсь момент ви закинете PHP або станете приділяти йому менше часу?

- Єдина причина існування PHP полягає в тому , що це інструмент для створення продуктів для реальних людей. І мені потрібен цей інструмент , без нього я не можу цього робити ; це ж відноситься і до багатьох компаніям. Мені подобається займатися PHP , але мені потрібно бачити ефект для реальних людей : якщо я його не бачу , мені немає сенсу продовжувати це робити.

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

- До речі , про інструменти . Багато розробники на інших мовах часто дивляться на PHP зверхньо. Ви напевно чули думки , що це мова для низькокваліфікованих програмістів , що на PHP не можна написати щось серйозне і т.п. Що ви про це думаєте ?

- Просто подивіться на частку ринку , на те , на скількох серверах працює PHP -код . І це неправда , що на PHP не можна написати щось серйозне. Я бачив дослідження, згідно якому 72% з 1 млн найбільш відвідуваних сайтів працюють на PHP .

- Враховуючи всі останні скандали з американськими спецслужбами , я не можу не задати це питання : чи є в PHP бекдори ?

- Що чудово в проектах з відкритим кодом , так це те , що я взагалі ніяк не можу сховати в ньому бекдор . Якщо ви завантажуєте скомпільований додаток від Microsoft або Oracle , ви поняття не маєте, що там всередині. Звичайно , більшість користувачів завантажують PHP теж у вже скомпільованому вигляді разом з операційною системою - Ubuntu , або Debian , або RedHat ... Але ми публікуємо вихідний код , а значить , що якщо з'являється бекдор , то його могли додати тільки вже на рівні ОС. Якби ми це зробили в исходниках ... уявляєте , скільки людей їх читають ?

- Чесно кажучи , ні.

- Дуже , дуже , дуже багато людей з самих різних країн. Ми б при всьому бажанні не змогли вбудувати бекдор , тому що це було б настільки очевидно, що нам би цього не спустили . Виробники ОС могли б зробити щось таке , якби дуже захотіли , але як тільки про це стало б відомо , вони б втратили всю репутацію і довіру. Ризик дуже вже великий.

Втім , небезпека все одно є , але на набагато нижчому рівні. NSA може мати вплив на стандарти шифрування , на криптографічні бібліотеки , від яких багато що залежить. Не тільки PHP , але практично все, що можна уявити , базується на певних криптографічних алгоритмах ; і якби хтось вмонтував бекдор на цьому рівні , то так, ніхто б цього не побачив. Але в самому PHP - ні в якому разі .

Минуле і сьогодення

- Якби ви могли змінити щось із того , що зробили (або не зробили) за роки роботи над PHP , що б це було?

- Загалом, все , що я зробив , мало сенс з урахуванням того , як у той час виглядав веб і скільки людей використовувало PHP. Але якби 20 років тому я знав , що PHP проживе так довго і їм будуть користуватися мільйони людей , я б прибрав звідти багато чого з того , що ми прибрали пізніше.

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

Спочатку я уявляв PHP як шаблонний мову , де можна було додавати власні спеціальні теги ; і теги PHP були схожі на HTML , щоб людям було простіше його освоювати . Але в якийсь момент PHP став чимось більшим , і чутливість до регістрів стала мати сенс . Я повинен був ввести її прямо тоді , але я пам'ятаю свої думки: « PHP використовується на 20 тисячах серверів , і всім цим людям доведеться правити свій код! » Звичайно , зараз я розумію , що краще було зробити це з 20 тисячами серверів , ніж з мільйонами , як зараз.

Є ще кілька подібних прикладів . Якби я знав , що мова проживе 20 років і збере мільйони користувачів , я б брав інші рішення . Але в той час це був просто молоток , який я зробив для себе.

- Тобто , планів підкорити світ не було?

- Абсолютно . Це був просто інструмент , з яким я міг програмувати швидше і ефективніше і не писати один і той же код багато разів. Я просто упакував його в бібліотеку функцій і опублікував її . У мене була шаблонна система , і в підсумку я міг розгортати динамічні веб -додатки дуже швидко: там , де іншим потрібні два тижні , я робив все за день . Багато хто цікавився , як я роблю все так швидко , і просили дозволу використовувати цей « молоток ». Я дозволяв, без проблем.

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

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

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

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

Коли з одного боку є код на PHP , написаний початківцями програмістами в якості хобі , а з іншого - компаніями на зразок Wikipedia , Yahoo або Facebook , розвиток мови ускладнюється на порядки. Просунуті розробники будуть скаржитися на можливості , створені для любителів , і навпаки ; неможливо зробити всіх щасливими. Щоб всі були задоволені , потрібно було б зосередитися тільки на одній групі , і ми могли б це зробити , але ж набагато цікавіше створювати мову, якою можуть користуватися всі .

- Чи задоволені ви тим , як розвивається PHP?

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

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

Оскільки розробка нових можливостей рухається досить швидко - скажімо , часовий розрив між PHP 5.4 та 5.5 був невеликим , плюс в PHP 5.6 теж буде багато нових фіч , - я переживаю за надійність всіх цих нововведень . Перевірка всіх « крайніх випадків » з їх використанням займає деякий час , і часто розробники прагнуть швидше рухатися далі , до нових завдань .

- Ви дійсно бачите зменшення надійності мови , чи це тільки теорія?

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

Ліричний відступ : підтримка Unicode

- Що зараз відбувається з нативної підтримкою Unicode ? У чому полягає головна проблема?

- Власне , додатки з підтримкою Unicode можна писати на PHP і зараз , питання в тому , як саме це робиться. У нас є розширення для бібліотеки ICU від IBM , і ця бібліотека може зробити все що завгодно. Будь-яку проблему з Unicode зараз можна вирішити . Але зазвичай людей цікавить можливість робити це легко і не замислюватися на цю тему; саме це ми і хотіли зробити в PHP 6 .

Головне питання з Unicode полягає в тому , як спростити роботу з ним і зробити її приємною . Зараз вже можна вирішити будь-яку проблему , пов'язану з Unicode , але це не виглядає красиво , Unicode - не замовчування . Нам в першу чергу заважає той факт , що бібліотека ICU заснована на UTF -16; до того ж вона велика і складно організована , і робота з нею дратує. Що нам дійсно потрібно - та й не тільки нам , а , думаю , всьому співтовариству Open Source , - так це хороша стандартна бібліотека, заснована на UTF -8 , яку використовуватимуть все. Але її немає , і це проблема .

Однією з серйозних складнощів в спробі створення PHP 6 було те , що нам потрібно було працювати з UTF -16 всередині , але при цьому бути повністю сумісними з UTF -8 зовні. Тобто кожного разу при введенні і виведенні даних потрібно було конвертувати їх з UTF -16 в UTF -8 або навпаки.

Я сподіваюся , що з часом все в світі буде працювати з UTF -8. Я чекаю , коли всі зрозуміють , що їм потрібно користуватися UTF -8 , і з'явиться ця сама бібліотека. Якби вона була , все можна було б зробити красиво і зручно. Взагалі , в умовах такого бардаку я вражений тим , як вдало деякі проекти змогли організувати роботу з UTF -8. Багатьом , втім , це не вдалося: мені не подобається ідея з ustring в Python , наприклад, де потрібно окремо вказувати Unicode - рядка.

- І хто , по-вашому , повинен і/або може написати таку бібліотеку ? Чи може в цьому допомогти PHP -спільнота ?

- Бібліотека ICU за обсягом приблизно в 10 разів більше і складніше , ніж весь PHP. Відповідно, коли ми додали підтримку ICU в PHP , це скоріше було додавання маленького PHP до ICU . Вона величезна .

У принципі , ми б могли написати нову бібліотеку , але тоді нам довелося б витратити на це наступні три роки , протягом яких ми б не торкалися до PHP. Та й взагалі я б вважав за краще , щоб цим заімаются Unicode - гіки . Може , й сама команда , яка займається ICU , могла б зробити наступне покоління бібліотеки - менше , швидше , сучасніше . Поточної версії вже 15 років , і це відчувається - вона дуже громіздка . Було б здорово , якби IBM виділила 50 розробників на таку задачу.

- І яка вірогідність того , що це трапиться ?

- Поняття не маю .

Технічні питання

- Які зміни відбуваються в підтримці MySQL ?

- Підтримка нікуди не дівається , але ми намагаємося скасувати саме розширення MySQL , щоб люди користувалися MySQLi або PDO_MYSQL . Це має сенс , тому що вони - і особливо MySQLi з нативним драйвером Mysqlnd , - дійсно краще і зручніше. MySQLi використовує менеджер пам'яті PHP , може зберігати копії і купу всього іншого , дозволяє виконувати асинхронні запити і т.п. Ми хочемо , щоб люди могли всім цим користуватися , але це неможливо через старий API.

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

- А що з підтримкою NoSQL ?

- У нас є підтримка для всіх баз даних. Непогана підтримка для MongoDB - до речі , кілька розробників PHP працюють в Mongo , і ще декілька - в Oracle ; є хороша підтримка Redis , ми й самі використовуємо його для деяких речей.

PHP дійшов до стадії розвитку , коли ми вже не повинні самі займатися підтримкою таких речей.

Опубліковано: 20/11/13 @ 08:54
Розділ php

SEO Блог