Зберігайте мову програмування сумісною назад, виправляючи її недоліки

По-перше, деякий контекст (речі, які більшість із вас все одно знає):

Кожна популярна мова програмування має чітку еволюцію, більшість часу відзначається її версією: у вас Java 5, 6, 7 і т.д., PHP 5.1, 5.2, 5.3 і т.д. Випуск нової версії робить нові API доступними, виправляє помилки, додає нові функції, нові рамки і т. д. Отже, загалом: це добре.

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

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

Найкращий спосіб пояснити моє питання - це використовувати PHP як приклад:

PHP люблять і ненавидять тисячі людей. Усі мови мають вади, але, мабуть, PHP є особливим. Перегляньте цю публікацію в блозі . У ньому дуже довгий список так званих недоліків у PHP. Зараз я не розробник PHP (поки що), але я прочитав все це і впевнений, що великий фрагмент цього списку справді є справжніми проблемами. (Не все це, оскільки це потенційно суб'єктивне).

Тепер, якби я був одним із хлопців, які активно розробляють PHP, я б точно хотів виправити ці проблеми по черзі. Однак якщо я це зробити, то код, який спирається на певну поведінку мови, порушиться, якщо він працює на новій версії. Підсумовуючи це в 2 слова: зворотна сумісність.

Я не розумію: чому я повинен підтримувати PHP сумісним назад? Якщо я випускаю PHP версії 8 з усіма виправленими проблемами, чи не можу я просто поставити на це велике попередження: "Не запускайте старий код на цій версії!"?

Існує річ, яка називається зневагою. Ми мали це роками і це працює. У контексті PHP: подивіться, як в ці дні люди активно заважають використовувати mysql_*функції (а натомість рекомендують mysqli_*і PDO). Депресація працює. Ми можемо ним скористатися. Ми повинні його використовувати. Якщо він працює для функцій, чому він не повинен працювати для цілих мов?

Скажімо, я (розробник PHP) так:

• Запустіть нову версію PHP (скажімо 8) з усіма виправленими вадами
• Нові проекти почнуть використовувати цю версію, оскільки вона набагато краща, чіткіша, безпечніша тощо.
• Однак, щоб не відмовлятися від старих версій PHP, я постійно випускаю оновлення до нього, виправляючи проблеми із безпекою, помилки тощо. Це має сенс з тих причин, які я тут не перелічую. Це звичайна практика: подивіться, наприклад, те, як Oracle продовжував оновлювати версію 5.1.x MySQL, хоча вона в основному зосереджена на версії 5.5.x.
• Приблизно через 3 або 4 роки я припиняю оновлювати старі версії PHP і залишаю їх гинути. Це добре, оскільки за ці 3 чи 4 роки більшість проектів все одно перейшли на PHP 8.

Моє запитання: чи всі ці кроки мають сенс? Це було б так важко зробити? Якщо це можна зробити, то чому б це не зробити?

Так, недоліком є ​​те, що ви порушуєте зворотну сумісність. Але це не ціна, яку варто заплатити? Зрештою, через 3 або 4 роки у вас з’явиться мова, на якій 90% проблем виправлено .... з мовою набагато приємніше працювати. Його ім’я забезпечить його популярність.

EDIT : Гаразд, тому я не висловив себе правильно, коли сказав, що через 3 або 4 роки люди перейдуть до гіпотетичного PHP 8. Що я мав на увазі: через 3 або 4 роки люди будуть використовувати PHP 8, якщо вони починають новий проект.

Це звучить прекрасно, але рідко виходить на практиці; люди вкрай неохоче змінюють запущений код, і навіть для нових проектів із зеленим полем вони дуже неохоче переключаються з мови / версії, яку вони вже знають.

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

(Очевидно, більшість цього не стосується проектів, написаних хобістами, лише для власного задоволення. Однак (тут бути вогнем ...) PHP хакери непропорційно рідко обирають, оскільки в першу чергу таке задоволення писати. )

Ви недооцінюєте вплив зворотної сумісності; Ваша оцінка, що всі активні проекти мігруватимуть через 3 або 4 роки, є надто оптимістичною.

Припустимо, я розробник PHP. У PHP є недоліки, але я знаю, як подолати ці вади - це частина причини, за яку я отримую зарплату як розробник PHP. Тепер припустимо, що PHP 8 виходить і виправляє ці недоліки, але це не сумісно назад. Як результат:

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

Враховуючи це, є сильний стимул ніколи не переходити на PHP 8, навіть якщо це "краще, чіткіше, безпечніше тощо". За підрахунками, є ще мільярди рядків COBOL (!) - хоча, очевидно, доступні набагато кращі технології, вартість оновлення в поєднанні з ризиком помилок просто не робить цього вартим.

По-друге, навіть якщо я вирішу мігрувати власний код, будь-яке нетривіальне додаток залежить від сторонніх бібліотек, і немає гарантії, що сторонні бібліотеки перенесуть. Наприклад, Python 3 був випущений у грудні 2008 року, але Django (можливо, провідна веб-рамка Python) майже п'ять років не мала стабільної, готової до виробництва підтримки Python 3 (див. Тут і тут ).

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

Подивіться на приклад пітона. 3.x доступний протягом чотирьох років, і досі його широко не прийняли. Люди намагаються використовувати його для абсолютно нових проектів, але я думаю, ви недооцінюєте лише те, наскільки працює робота з кодом.

Звичайно, більшість людей не вважають python 2.x "хибним". У них не було скарг, як у користувачів PHP. Php перебуває в набагато більш невдалому становищі, оскільки багато людей дотримуються його лише через велику існуючу кодову базу. Якщо ви втратили зворотну сумісність, багато людей скористалися б можливістю перейти на пітон.

Для будь-якої мови, окрім PHP, я б сказав, так, це абсолютно має сенс! Саме так займається Python з переходом на Python 3.

Однак проблема PHP полягає в тому, що в самому дизайні мови занадто багато недоліків, тому те, що ви називаєте "PHP 8", було б зовсім іншою мовою. І якщо вам доведеться перейти на іншу мову, чому б ви дотримувалися нового PHP, а не будь-якої з існуючих і стабільних альтернатив?

Також PHP-спільнота надзвичайно повільна, щоб адаптувати щось нове. Подивіться, скільки часу потрібно було позбутися register_globals. Відомо, що це ризик для безпеки з 2000 року. Це було остаточно знято через 12 років. Інший приклад, коли PHP5 був представлений, це було величезне поліпшення порівняно з PHP4, але громада не адаптувала його. Я взяв 4 роки і масовані дії, такі як GoPHP5, щоб швидко приступити до усиновлення. І це навіть не мало значної кількості зворотних несумісних змін.

Відмова: Я керую групою користувачів ColdFusion.

ColdFusion страждає одними і тими ж проблемами: люблять багато хто, зневажають багато. Крім того, тонни і тонни FUD базуються на попередніх версіях Java. ColdFusion 10 вийшов минулого року, є величезним продавцем, і минулого тижня я зареєструвався, щоб протестувати передвипуск версії 11. Також є дві основні альтернативи з відкритим кодом, одну підтримує JBoss.

У CF10 є TONS нових функцій, які я б хотів реалізувати, але перехід із CF 7 або 8 може бути складним залежно від розміру кодової бази, кількості майбутніх проектів та ресурсів, які вам доведеться регресувати, протестуйте все, щойно Остання версія. Я зіткнувся з низкою синтаксичних відмінностей між 8 і 9, а також крайовими випадками, коли код не компілюється однаково. Знайшовши їх, я задокументував їх у наших стандартах кодування, щоб вони не використовувались у майбутніх проектах чи нових розробниках.

Це означає, що якщо ColdFusion 11 (або будь-яка мова програмування) повністю знищить певні функції та синтаксис, рівень зусиль для пошуку та заміни функціональності може бути величезним. Намагання тестування можуть бути вельми прихильними. Чи заплатять компанії своїм розробникам, контролерам якості та керівникам проектів, щоб вони знайшли, замінили і протестували всі ці застарілі речі? Сумнівні.

Якщо остання версія мови зворотно сумісна, але вводить підвищення продуктивності без змін коду (CF9 приблизно на 30% швидше, ніж CF8, а CF10 набагато швидше, ніж CF9), хто піклується про зміну функціональних викликів, якщо вони все ще працюють?

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

FWIW, я хотів би перенести нас на останню версію jQuery в якийсь момент, але оскільки деякі функції були застаріли кілька версій після того, що ми використовуємо, і враховуючи обсяг JavaScript, який ми маємо в системі, я не знаю, як ми збираємося зняти це.

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

Це (на мій погляд) різниця між основними випусками, незначними випусками та переглядами. Як загальний принцип:

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

Наприклад, якщо я щось пишу на v2.3 мови, я не сподівався б помітити будь-яку різницю, якщо я перейду до версії v2.3.2. Якщо я перейду до версії v2.4, то декілька речей можуть змінитися - невеликі налаштування синтаксису, деякі функції поводяться дещо інакше, тому мені доведеться налаштовувати логіку і т. Д. Якщо я перейду до версії v3.0, я не здивуюся, якби вона зламалася повністю - застарілі або відсутні функції, операції не підтримуються і не змінюються настільки сильно, що я не можу просто змінити її назад у відповідність, я фактично повинен переписати деякі функції для врахування нових змін.

Редагувати:

У статті Стіва Ванса про розширені стратегії розгалуження SCM :

Як правило, є два-три рівні випуску, названі номерами, пов'язаними з періодами (наприклад, 1.2.3). [...] У цій структурі перше число пов'язане з основною версією, що вказує на те, що воно має значні особливості та функціональні удосконалення від попереднього; також можуть бути значні несумісності, які потребують міграції. Другий номер представляє незначну версію, яка містить менші покращення функцій та функцій, значну кількість виправлень помилок та відсутність несумісностей. Третє число відноситься до рівня виправлення, що означає майже виключно колекцію виправлень помилок; жодні покращення функцій або функцій та несумісність між рівнями патчів не допускаються.

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

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

Наприклад, ігноруючи Android, Java здебільшого використовується у великих корпоративних системах та середньому виробництві; ці типи додатків, як правило, стають дуже великими як за розмірами, так і за часом. Це має певні наслідки; уявіть систему з 500K + LoC, на якій робітники 50+ інженерів на стадії розробки. Зазвичай цей тип системи надходить в технічне обслуговування після цього, говорять 10 розробників; Тепер, якщо мова змінюється і зміни не є сумісними назад, проект не можна легко перенести на нову версію, тому що програмісти, які написали деякі частини, відпали, і ніхто не хоче її торкатися. Це менша проблема, тим більша проблема полягає в тому, що дорого адаптувати 500 LoC-додаток до нових мовних обмежень. Наприклад, якщо дженерики не були реалізовані при стиранні типу таList list = new List(); не складатимуть мільйони рядків коду, потрібно було б переписати - що коштує дуже дорого.

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

Можна стверджувати, що Microsoft здійснила подібну зміну з ASP.NET (як наступник класичного ASP) або з VB.NET (хоча вони зробили настільки багато поступок з останнім, що більшість переваг "перезавантаження" мови були втрачені).

У будь-якому випадку, якщо хтось пам’ятає кошмар міграції коду VB6 на VB.NET навіть за допомогою інструмента міграції, він погодиться, що інструменти міграції мови не дуже добре працюють для основних оновлень мови.

Можливо, можливо, переміщення платформи вперед, але все ж слід надати підтримку "застарілих" API через хоча б кілька змін.

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

Відсутність закриттів у Java - класичний приклад. Це зовсім не вада в мові, і зміна мови (як це на жаль на порядку денному) включити їх, IMO принципово покалічить її або, принаймні, зробить її набагато важче для читання та розуміння.

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

Додайте, як зазначають інші, що зворотна сумісність є життєво важливою для утримання існуючих користувачів, багато з яких НЕ збираються витрачати тисячі годин і мільйонів доларів / євро на переобладнання своїх мільйонів лінійних кодових баз на те, що ви вважаєте "кращим" ніж версія мови, якою вони користуються протягом багатьох років, і ти маєш безліч гарних аргументів, щоб залишити достатньо добре в спокої, і якщо ти хочеш пограти з якоюсь новою завищеною ідеєю, яка нібито є наступним "вбивцею Java", ти " Буде найкраще грати з цією іграшкою, а не кричати, що "Java iz ded", якщо її "не виправлять", щоб бути клоном цієї іграшки.

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

Наприклад, якщо я розробляв нову мову, схожу на Java або C #, я заборонив би конверсії неявного типу в деяких контекстах, де ці мови дозволяють їх. Наведений простий приклад в C #

int someInt;
double someDouble;

вираз someInt.Equals(someDouble)гарантовано повертає помилкове значення, незалежно від вмісту змінних. Вона компілюється, тому що doubleможе бути перетворена в Objectі intмає Equalsперевантаження для цього типу, тому компілятор робить перетворення та здійснює виклик. Якби я розробляв нову версію C # та .NET Framework, я б заборонив перетворення боксу, оскільки він не може зробити нічого корисного. Можливо, є якась програма, яка робить таке порівняння таким чином, який марний, але нешкідливий, і, якщо компілятор відкидає такий код, може порушити цю програму, але виправлення та видалення такого непотрібного коду було б вдосконаленням.

Як трохи менш зрозумілий приклад, припустимо

float f=16777216f;
int i=16777217;

і розглянути вираз f==i. Цілком можливо , що якийсь - то код робить поплавок / цілочисельні порівняння і працює правильно, але код повинен бути переписаний або як f==(float)i, (double)f==i;або (double)f==(double)i;[ intдля doubleпросування відбувається без втрат, тому останні два будуть еквівалентні]. Деякий код , який безпосередньо порівнює floatі integerзначення завжди може мати справу з числами , які досить малі , що floatі doubleпорівняння будуть вести себе однаково, але компілятор зазвичай не може знати , що; код повинен чітко пояснювати, яке саме порівняння потрібне, а не сподіватися, що правила мови будуть відповідати наміру програміста.

Найкраще ніколи не порушувати зворотну сумісність.

Microsoft замінила мову програмування VB6 на нову, яка повністю порушила сумісність. Тож навіть сьогодні 16-річний VB6 все ще користується популярністю, ніж версія dotNet (індекс Tiobe, серпень 2014 року). І за оцінками Gartner, 14 мільярдів рядків коду VB6 досі використовуються.

У 2014 році Microsoft знову довелося оголосити, що не оновлюватиме або відкриватиме VB6, незважаючи на вимоги спільноти програмування Visual Basic. Але вони розширили підтримку VB6 до 'принаймні' 2024 року, і він працює чудово в Windows 7 і 8. Це буде понад 26 років підтримки для тієї ж версії VB6.

Чому існуюче робоче програмне забезпечення потрібно переписувати, навіть Microsoft ніколи не "оновлював" Office для використання dotNet?

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

A. Код, написаний у більш старих версіях, не отримає переваги нових версій, які покращують продуктивність, безпеку чи функції. Ви можете пом'якшити цю проблему, підтримуючи кілька основних версій компілятора / інтерпретатора, але це величезна витрата ресурсів (тобто її дорогий або тривалий час, і це біль у дупі).

B. Код, написаний для новіших версій, може бути не сумісний з кодом, написаним у старих версіях. Ви могли б обійти це за допомогою інтерпретатора / компілятора, який може обробляти декілька основних версій мови, але це більше біль у дупі, ніж підтримка окремих перекладачів / компіляторів (вирішення для A).

C. Основні зміни, якщо вони трапляються занадто часто / швидко, також просто ускладнюють використання мови, оскільки вам доведеться більше вивчати та вивчати. Зміни мови можуть підштовхнути людей через край до переходу на нову мову або можуть змусити людей продовжувати використовувати застарілі версії мови та просто ніколи не переходити на нову версію (як це сталося з python). Знову ж таки, зміни можуть також привернути нових користувачів і викликати збудження старих.

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

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

Facebook дратує людей, коли вони змінюють інтерфейс користувача або свої API розробника. У минулому його платформа ускладнювала роботу. У деяких випадках API просто перестали працювати назовні. Але люди продовжували його використовувати, і тепер API та інтерфейси користуються швидкістю, ніж 5 років тому. Люди будуть скаржитися на зміни, добре чи погано для них, але це (скарги) - не вагомий привід відмовитись від змін. На жаль, розробники мови програмування використовують це як причину, щоб зберегти проблеми своєї мови недоторканими.

Отже, ще одна пара причин того, що мови не вносили кардинальних змін, щоб поліпшити себе:

E. Розробники мов вважають, що їхні користувачі побоюються змін - це вагома причина застою їхньої мови

F. Мовчани начебто сподобалися їхній мові, коли вони її склали, і вони, напевно, вважають її просто чудовою та її вадами.

Г. Мови, коли вони дорослішають, зазвичай перестають мати невеликий набір розробників і перетворюються на більше звірів, створених комітетом. Це означає, що рішення щодо цих мов є повільними і часто консервативними та нетворчими.

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

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

1. Знищити речі заздалегідь, коли вони будуть вилучені.

2. Надайте хороший , стандартний інструмент для перетворення. Python надав інструмент 2to3, але він недостатньо добре рекламувався, не став стандартним для python 3, як я пам’ятаю, і навіть не дуже добре працював (пам’ятаю, потрібно було вручну пройти програми, створені 2to3, щоб виправити проблеми не виправили). Цей інструмент перетворення навіть можна автоматично запустити, якщо ваш компілятор / інтерпретатор виявить старішу версію. Що може бути простіше?

Я не знаю, чи це проблема для PHP-коду, але в багатьох мовах старий застарілий код ніколи не оновлюється через роки або, іноді, навіть десятиліття, тому що він працює, є критичним для бізнесу, в якому він працює, і занадто великий (скажімо, мільйони SLOC), тому не було б сенсу переписувати його. Це причина, чому java зробила зворотну сумісність майже релігійною проблемою, незважаючи на старі проблеми, особливо в бібліотеках (навіть якщо їх легше оновлювати). Думаю, багато коду з ядра Linux теж не оновлювались десятиліттями, незважаючи на прийняття таких стандартів, як C99 та C11.

Навіть у мовах, які є менш "entreprisey", порушення старого функціонального коду може бути проблемою. Саме так сталося з Python 2 -> 3. Ціла купа бібліотек та системних скриптів були стабільними і більше не підтримувались не тому, що їх покинули, а тому, що вони були стабільними і виконували свою роботу. На їх адаптацію йде кілька років. Отже, як розробник, ви не можете обов'язково перейти на python 3, якщо ваша улюблена бібліотека ще не зробила переїзд, тому ваш власний код також не працюватиме під python 3, що призведе до фрагментації спільноти.

Проблема полягає в проблемі сумісності ззаду. Більшість сценаріїв PHP, які я виконую, виконуються на старішому сервері RedHat. Якби я використовував новішу версію мови для майбутніх сценаріїв, мені доведеться оновити PHP на цьому сервері - і ризикую зірвати мої старіші сценарії / доведеться витратити години, щоб переписати весь старий код на новий стандарт. Крім того, всі мої розробники звикли до того, що PHP певним чином реагує (незалежно від того, «цей спосіб зламаний» чи ні). Якщо вона більше не реагує таким чином, це може стати головною перешкодою для підвищення продуктивності, оскільки розробникам, можливо, доведеться в основному перевчити себе PHP.