Python 3.0 разбивает обратную совместимость с предыдущими версиями и разбивает язык на два пути (по крайней мере временно). Знаете ли вы о каком-либо другом языке, который прошел через такой важный этап проектирования во время зрелости?
Кроме того, вы считаете, что так развиваются языки программирования или стоит слишком дорого платить?
Единственным языком, который я могу придумать для попыток такого изменения в среднем потоке, будет Perl. Конечно, Python избивает Perl этой конкретной финишной линии, сначала отпустив ее. Следует отметить, однако, что изменения в Perl гораздо более обширны, чем Python, и, вероятно, будет сложнее распутать.
(Там есть цена на философию Perl "Больше, чем один способ сделать это" ).
Есть примеры, такие как изменения с версии на версию .NET-языков (иронично, учитывая, что вся точка .NET должна быть стабильностью API и кросс-платформенной совместимостью). Однако я вряд ли назвал бы эти языки "зрелыми"; это всегда было скорее концепцией "дизайн-на-ходу", "построение-плоскость-как-мы-летать" для вещей.
Или, как я обычно думаю об этом, большинство языков происходит от "органического роста" или "инженерного строительства". Perl - прекрасный пример органического роста; он начинался как инструмент для обработки текстовых сообщений ala awk/sed и перерос в полноценный язык.
Python, с другой стороны, гораздо более разработан. Проведите немного времени, блуждая по обширным документам на своем веб-сайте, чтобы увидеть обширные дискуссии, которые вступают в каждое незначительное изменение синтаксиса и реализации языка.
Идея сделать такие разнородные изменения несколько нова для языков программирования, потому что сами языки программирования изменились по своей природе. Раньше считалось, что методологии программирования изменяются только тогда, когда появился новый процессор, у которого был новый набор команд. Ранние языки, как правило, были либо низкоуровневыми, либо вступали в брак с языком ассемблера (например, C) или настолько совершенно динамичным по своей природе (Forth, Lisp), что такое изменение среднего потока даже не было рассмотрено.
Что касается того, являются ли изменения хорошими, я не уверен. Тем не менее, я склонен верить в людей, направляющих развитие Питона; изменения в языке до сих пор были в основном к лучшему.
Я думаю, что в ближайшие дни Global Interpreter Lock станет более центральным, чем синтаксические изменения. Хотя новая многопроцессорная библиотека может облегчить большую часть этого.
Цена настаивания на почти абсолютной обратной совместимости слишком высока. Проведите двухминутное программирование на С++, если вы хотите понять, почему.
Команда python очень усердно работала над тем, чтобы отсутствие обратной совместимости было настолько безболезненным, насколько это возможно, до того момента, когда выпуск python 2.6 был создан с умом в сторону безболезненного процесса обновления. После того, как вы обновили до версии 2.6, вы можете запустить скрипты, которые перейдут на 3.0 без проблем.
Следует отметить, что обратная совместимость берет на себя расходы. В некоторых случаях практически невозможно развить язык идеальным образом, если требуется 100% обратная совместимость. Java-реализация generics (которая стирает информацию о типе во время компиляции, чтобы быть обратно совместимой) является хорошим примером того, как реализация функций со 100% обратной совместимостью может привести к неоптимальной языковой функции.
Таким образом, это может привести к выбору между плохо реализованной новой функцией, совместимой с обратной совместимостью, или с хорошо реализованной новой функцией, которой нет. Во многих случаях последний является лучшим выбором, особенно если есть инструменты, которые могут автоматически переводить несовместимый код.
Я думаю, что есть много примеров поломки обратной совместимости. Многие из языков, которые делали это, были либо маленькими, либо вымерли на этом пути.
Многие примеры этого связаны с переименованием языка.
Алгол 60 и Алгол 68 были настолько разными, что встречи на Алголе 68 распались на фракции. Фракция "Алгол 68", фракция Паскаля и фракция PL/I.
Вирт Паскаль превратился в Модулу-3. Он был очень похож на pascal - очень похожий синтаксис и семантика - но несколько новых функций. Был ли это действительно Pascal-2 без обратной совместимости?
Элемент Lisp to Scheme включает переименование.
Если вы отследите сканирование старого языка программирования B, вы увидите, что эволюция в C выглядит несколько поэтапно - - не радикально, - но он нарушил совместимость.
Фортран существовал во многих формах. Я не знаю точно, но я думаю, что Digital Fortran 90 для VAX/VMS не был полностью совместим с древними программами Fortran IV.
RPG пережила серьезные потрясения - я думаю, что есть действительно два несовместимых языка, называемых RPG.
Bottom Line Я думаю, что мышление и обучение неизбежны. У вас есть три ответа на изучение ограничений языка.
Создайте новый язык, который совершенно несовместим.
Инкрементальная чана, пока вы не будете вынуждены изобретать новый язык.
Совместимость с ошибками контролируется, продуманно.
Я думаю, что №1 и №2 - оба трусости. Забрасывать старое легче, чем пытаться сохранить его. Сохранение любой нюансной функции (как бы плохо она ни была) - это большая работа, часть из которой имеет мало или вообще не имеет значения.
Коммерческие предприятия выбирают трусливые подходы во имя "нового маркетинга" или "сохранения наших существующих клиентов". То, что коммерческие программные предприятия не являются горячими новинками.
Я думаю, что только проекты с открытым исходным кодом могут включать инновации в том, как сообщество Python решает это изменение.
С# и .NET Framework нарушили совместимость между версиями 1.0 и 1.1, а также между 1.1 и 2.0. Для запуска приложений в разных версиях требуется наличие нескольких версий среды выполнения .NET.
По крайней мере, они включили мастер обновления для обновления исходного кода с одной версии на другую (он работал для большей части нашего кода).
Не будет ли VB6 на VB.net самым большим примером этого? Или вы все считаете их двумя отдельными языками?
В мире Lisp это произошло несколько раз. конечно, язык настолько динамичен, что обычно эволюция - это просто абсурдная часть стандартной библиотеки и стандартная другая часть.
также, Lua 4-5 был довольно значительным; но ядро языка настолько минимально, что даже широкомасштабные изменения документируются на нескольких страницах.
Perl 6 также проходит через этот тип раскола прямо сейчас. Программы Perl 5 не будут запускаться непосредственно на Perl 6, но будет переводчик, чтобы перевести код в форму, которая может работать (я не думаю, что она может обрабатывать 100% случаев).
Perl 6 даже имеет свою собственную статью о Википедии.
Во-первых, здесь представлена видео-беседа об изменениях, которые пройдут Python. Во-вторых, изменения бесполезны. В-третьих, я за одну приветственную эволюцию и считаю, что это необходимо.
gcc регулярно изменяет, как обрабатывает С++ почти каждую младшую версию. Конечно, это скорее следствие gcc, затягивающего то, как они следуют правилам, и меньше меняет С++.
Новая версия языка программирования Ruby также нарушит совместимость.
И подумайте о библиотеках, которые можно использовать: gtk, Qt и т.д. (они также имеют несовместимые версии).
Я считаю, что иногда несовместимость необходима (но не слишком часто) для поддержки прогресса.