Держите язык программирования обратно совместимым, а не исправляйте его недостатки

Во-первых, некоторый контекст (вещи, которые большинство из вас все равно знают):

Каждый популярный язык программирования имеет четкую эволюцию, большую часть времени отмеченную его версией: у вас есть Java 5, 6, 7 и т. Д., PHP 5.1, 5.2, 5.3 и т. Д. Выпуск новой версии делает доступными новые API, исправляет ошибки, добавляет новые возможности, новые фреймворки и т. д. Итак, в общем, это хорошо.

Но как насчет проблем языка (или платформы)? Если и когда что-то не так в языке, разработчики либо избегают этого (если могут), либо учатся жить с этим.

Теперь разработчики этих языков получают много отзывов от программистов, которые их используют. Таким образом, имеет смысл, что со временем (и номера версий) проблемы в этих языках будут медленно, но верно исчезать. Ну не совсем. Почему? Обратная совместимость, вот почему. Но почему это так? Читайте ниже для более конкретной ситуации.

Лучший способ объяснить мой вопрос - использовать PHP в качестве примера:

PHP любят и ненавидят тысячи людей. Все языки имеют недостатки, но, очевидно, PHP особенный. Проверьте это сообщение в блоге . У него очень длинный список так называемых недостатков в PHP. Сейчас я не PHP-разработчик (пока), но я прочитал все это, и я уверен, что большая часть этого списка - действительно реальные проблемы. (Не все, так как это потенциально субъективно).

Теперь, если бы я был одним из тех, кто активно разрабатывает PHP, я бы наверняка хотел решить эти проблемы, одну за другой. Однако, если я это сделаю, то код, основанный на определенном поведении языка, сломается, если он будет работать в новой версии. Подводя итог в двух словах: обратная совместимость.

Что я не понимаю: почему я должен поддерживать обратную совместимость PHP? Если я выпускаю версию 8 PHP с устранением всех этих проблем, могу ли я просто предупредить об этом: «Не запускайте старый код в этой версии!»?

Есть вещь, называемая амортизацией. У нас это было годами, и оно работает. В контексте PHP: посмотрите, как в наши дни люди активно препятствуют использованию mysql_*функций (и вместо этого рекомендуют mysqli_*и PDO). Амортизационные работы. Мы можем использовать это. Мы должны использовать это. Если это работает для функций, почему это не должно работать для целых языков?

Допустим, я (разработчик PHP) делаю это:

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

Мой вопрос: все эти шаги имеют смысл? Это было бы так сложно сделать? Если это можно сделать, то почему это не сделано?

Да, недостатком является то, что вы нарушаете обратную совместимость. Но разве это цена не стоит платить? Как положительный момент, через 3 или 4 года у вас будет язык, в котором устранены 90% проблем ... язык, с которым гораздо приятнее работать. Его имя обеспечит его популярность.

РЕДАКТИРОВАТЬ : ОК, поэтому я не выразил себя правильно, когда я сказал, что через 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 (см. Здесь и здесь ).

Вы делаете много предположений о человеческом поведении. Если вы измените его слишком сильно, люди оценят ваших конкурентов, так как им все равно придется потратить значительные усилия на переключение. Для языков с открытым исходным кодом люди просто раскошелиться на старую версию.

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

Конечно, большинство людей не считают Python 2.x «ошибочным». У них не было жалоб, как у пользователей php. Php находится в гораздо более опасном положении, потому что многие люди придерживаются его только из-за его большой существующей кодовой базы. Если бы вы потеряли обратную совместимость, многие люди воспользовались бы возможностью, которую они ждали, чтобы перейти на python.

Для любого языка, кроме 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 есть тонны новых функций, которые я бы хотел реализовать, но переход с CF 7 или 8 может быть затруднен в зависимости от размера вашей кодовой базы, количества предстоящих проектов и ресурсов, которые вы должны регрессивно протестировать, как только вы на последней версии. Я столкнулся с рядом незначительных синтаксических различий между 8 и 9, а также с крайними случаями, когда код компилируется не так. Найдя их, я задокументировал их в наших стандартах кодирования, чтобы они не использовались в будущих проектах или новыми разработчиками.

Тем не менее, если бы ColdFusion 11 (или любой другой язык программирования) полностью отказался от определенных функций и синтаксиса, уровень усилий по поиску и замене функциональности мог бы быть огромным. Испытание может быть огромным. Будут ли компании платить своим разработчикам, QA и менеджерам проектов, чтобы найти, заменить и протестировать все эти устаревшие вещи? Сомнительно.

Если последняя версия языка совместима с предыдущими версиями, но обеспечивает повышение производительности без изменений кода (CF9 примерно на 30% быстрее, чем CF8, и CF10 намного быстрее, чем CF9), кого волнует изменение вызовов функций, если они все еще работают?

Как компания, мы должны заботиться о том, чтобы порадовать наших клиентов и удовлетворить их потребности, чтобы выставлять счета за услуги, строить бизнес и привлекать больше клиентов.

Кстати, мне бы очень хотелось, чтобы в какой-то момент мы познакомились с последней версией 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» вы » Лучше поиграть с этой игрушкой, чем кричать «Ява из дэда», если она не «исправится», чтобы стать клоном этой игрушки.

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

Например, если бы я проектировал новый язык, похожий на Java или C #, я бы запретил неявные преобразования типов в некоторых контекстах, где эти языки позволяют это. В качестве простого примера на C #, приведенного

int someInt;
double someDouble;

выражение someInt.Equals(someDouble)гарантированно вернет false независимо от содержимого переменных. Он компилируется, потому что 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?

Есть несколько разных проблем с нарушением обратной совместимости. Некоторые проблемы связаны с тем фактом, что большинство языков программирования также являются платформами (интерпретаторами / средами исполнения), а другие проблемы связаны с предположением о человеческой природе.

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

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

C. Серьезные изменения, если они происходят слишком часто / быстро, также просто затрудняют использование языка, так как вам нужно больше учиться и не учиться. Изменения в языке могут подтолкнуть людей к переходу на новый язык или могут заставить людей продолжать использовать устаревшие версии языка и просто никогда не переключаться на новую версию (как это произошло с python). Опять же, изменения могут также привлечь новых пользователей и возбудить старых.

D. Новая документация должна храниться и поддерживаться. Это всегда довольно запутанный опыт, чтобы искать вещи в Google и обнаруживать, что вы читаете документы для другой версии, чем вы используете в настоящее время.

В общем и целом, если вы создаете язык программирования, в котором внешним модулям не нужно заботиться о том, какую версию вы используете, нарушить обратную совместимость по правильным причинам (чтобы исправить основные недостатки в языке) - это почти определенно правильная вещь. , Вполне вероятно, что основная причина, по которой этого не сделано, заключается в том, что разработчики языка программирования переоценивают ( чтобы противоречить чужому ответу ) издержки нарушения совместимости, особенно на ранних этапах. Дело в том, что проблемы нарушения совместимости могут быть решены пользователями этого языка. И это касается не только языков программирования; это относится к API, пользовательским интерфейсам - действительно к любому интерфейсу в любой ситуации.

Facebook чертовски раздражает людей, когда они изменяют свой интерфейс или API-интерфейсы для разработчиков. В прошлом это затрудняло работу с платформой. В некоторых случаях API просто перестали работать на ровном месте. Но люди продолжали использовать его, и теперь API и пользовательские интерфейсы стали на дрожжах намного лучше, чем 5 лет назад. Люди будут жаловаться на перемены, хорошо это или плохо для них, но это (жалоба) не является веской причиной, чтобы отказаться от этих перемен. К сожалению, разработчики языка программирования используют это как причину, чтобы сохранить проблемы своего языка нетронутыми.

Итак, еще пара причин, по которым языки не вносят существенных изменений, чтобы улучшить себя:

Разработчики языка E. считают, что их пользователи боятся перемен - это хорошая причина стагнации их языка.

F. Разработчикам языка понравился их язык, когда они сделали его, и они, вероятно, думают, что он просто прекрасно с его недостатками.

G. Языки по мере взросления обычно перестают иметь небольшой основной набор разработчиков и превращаются в зверей, построенных комитетом. Это означает, что решения относительно этих языков медленные, часто консервативные и нетворческие.

H. Последняя причина заключается в том, что некоторые критические изменения требуют значительной переоценки проектных решений, принятых для интерпретатора / среды выполнения. Иногда усовершенствования языка просто требуют слишком много работы, чтобы быть осуществимыми. Я думаю, это более редкая проблема, чем у большинства.

Часто языковые дизайнеры не обязательно являются разработчиками инструментов, и поэтому они не думают о хороших решениях этой проблемы или не выполняют их хорошо. Вот некоторые решения, которые я могу придумать для решения проблемы критических изменений:

1. Устаревайте вещи задолго до того, когда они будут удалены.

2. Обеспечить хороший , стандартный инструмент конвертера. Python предоставил инструмент 2to3, но он не был хорошо прорекламирован, не соответствовал стандарту Python 3, насколько я помню, и даже не очень хорошо работал (я помню, что мне приходилось вручную проходить программы, сгенерированные 2to3, чтобы решить проблемы с ним) не исправить). Этот инструмент конвертера может даже автоматически запускаться, если ваш компилятор / интерпретатор обнаружит более старую версию. Что может быть проще?

Я не знаю, является ли это проблемой для PHP-кода, но во многих языках старый, устаревший код никогда не обновляется через годы, а иногда даже десятилетия, потому что он работает, очень важен для бизнеса, который его выполняет, и слишком велик (скажем, миллионов SLOC), поэтому не имеет смысла переписывать его. Это причина, почему java сделал обратную совместимость почти религиозной проблемой, несмотря на известные старые проблемы, особенно в библиотеках (даже если их легче обновлять). Я полагаю, что большая часть кода ядра Linux не обновлялась десятилетиями, несмотря на принятие таких стандартов, как C99 и C11.

Даже в языках, которые менее «энтрепризей», взлом старого, функционального кода может стать проблемой. Вот что произошло с Python 2 -> 3. Целая куча библиотек и системных скриптов были стабильны и больше не поддерживаются, не потому, что они были заброшены, а потому, что они были стабильны и выполняли свою работу. Адаптация их занимает несколько лет. Поэтому, как разработчик, вы не можете обязательно перейти к Python 3, если ваша любимая библиотека еще не перешла, поэтому ваш собственный код также не будет работать в Python 3, что приведет к фрагментации сообщества.

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