Python 3.0 и эволюция языка

C# и .NET framework нарушили совместимость между версиями 1.0 и 1.1, а также между 1.1 и 2.0. Для запуска приложений в разных версиях требовалось установить несколько версий среды выполнения .NET.

По крайней мере, они включали мастер обновления для обновления исходного кода с одной версии на другую (он работал для большей части нашего кода).

Perl 6 прямо сейчас проходит через этот тип разделения. Программы Perl 5 не будут работать непосредственно на Perl 6, но будет переводчик для перевода кода в форму, которая может работать (я не думаю, что он может обрабатывать 100% случаев).

Perl 6 даже имеет свою статью в Википедии.

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

Единственный язык, который я могу придумать, чтобы попытаться сделать такое промежуточное изменение, - это Perl. Конечно, Python опережает Perl на этом финише, выпуская его первым. Однако следует отметить, что изменения Perl намного шире, чем изменения Python, и, вероятно, их будет труднее распутать.

(Есть цена за философию Perl «Есть больше, чем один способ сделать это».)

Есть примеры, такие как изменения от версии к версии языков на основе .NET (иронично, учитывая, что весь смысл .NET должен был заключаться в стабильности API и кроссплатформенной совместимости). Однако я бы вряд ли назвал эти языки «зрелыми»; Это всегда был подход к вещам: «проектируй на ходу» и «строи самолет по ходу полета».

Или, как я склонен думать, большинство языков возникло в результате «органического роста» или «инженерного строительства». Perl - прекрасный пример органического роста; он начинался как причудливый инструмент обработки текста ala awk / sed и превратился в полноценный язык.

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

Идея внесения таких далеко идущих изменений в языки программирования в некоторой степени нова, потому что сами языки программирования изменились по своей природе. Раньше методы программирования менялись только тогда, когда выходил новый процессор с новым набором команд. Ранние языки, как правило, были либо настолько низкоуровневыми и сочетались с языком ассемблера (например, C), либо были настолько динамичными по своей природе (Forth, Lisp), что такое промежуточное изменение даже не рассматривалось бы.

Что касается хороших изменений или нет, я не уверен. Однако я склонен доверять людям, руководящим разработкой Python; изменения в языке до сих пор были в основном к лучшему.

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

Команда разработчиков python очень усердно работала над тем, чтобы сделать отсутствие обратной совместимости как можно более безболезненным, до такой степени, что версия python 2.6 была создана с расчетом на безболезненный процесс обновления. После обновления до версии 2.6 вы можете запускать сценарии, которые без проблем переместят вас на версию 3.0.

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

кроме того, Lua с 4 по 5 был довольно значительным; но ядро ​​языка настолько минимально, что даже масштабные изменения документируются на нескольких страницах.

Стоит отметить, что обратная совместимость сама по себе требует затрат. В некоторых случаях практически невозможно развить язык идеальным способом, если требуется 100% обратная совместимость. Реализация дженериков в Java (которая стирает информацию о типах во время компиляции для обеспечения обратной совместимости) является хорошим примером того, как реализация функций со 100% обратной совместимостью может привести к неоптимальной языковой функции.

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

Думаю, есть много примеров поломок обратной совместимости. Многие из языков, которые сделали это, были либо маленькими, либо вымерли по пути.

Многие примеры этого включают переименование языка.

Алгол 60 и Алгол 68 были настолько разными, что встречи на Алголе 68 разбились на фракции. Фракция Algol 68, фракция Паскаля и фракция PL / I.

Паскаль Вирта превратился в Модулу-3. Он был очень похож на паскаль - очень похожий синтаксис и семантика - но с несколькими новыми функциями. Был ли это действительно Паскаль-2 без обратной совместимости?

Дело в том, что Lisp to Scheme требует переименования.

Если вы проследите просмотр старого руководства Язык программирования B, вы увидите, что эволюция до C выглядит как постепенная, а не радикальная, но она нарушила совместимость.

Фортран существовал во многих формах. Я не знаю наверняка, но думаю, что Fortran 90 от Digital для VAX / VMS не был полностью совместим с древними программами Fortran IV.

RPG пережила серьезные потрясения - я думаю, что действительно существует два несовместимых языка, называемых RPG.

Нижняя граница Я считаю, что мышление и учусь неизбежны. У вас есть три ответа на изучение ограничений языка.

1. Изобретите новый язык, который совершенно несовместим.

2. Постепенное изменение, пока вы не будете вынуждены изобрести новый язык.

3. Контролируемое и вдумчивое нарушение совместимости.

Я думаю, что №1 и №2 - оба пути для трусов. Выбросить старое легче, чем пытаться его сохранить. Сохранение каждой тонкой функции (независимо от того, насколько она плохая) - это большая работа, а некоторые из них мало или не имеют никакой ценности.

Коммерческие предприятия выбирают трусливые подходы во имя «нового маркетинга» или «сохранения наших существующих клиентов». Вот почему коммерческое программное обеспечение не является рассадником инноваций.

Я думаю, что проекты с открытым исходным кодом Только могут включать инновации в том, как сообщество Python занимается этим изменением.

Цена настаивания на почти абсолютной обратной совместимости слишком высока. Потратьте две минуты на программирование на C++, если хотите понять, почему.

Разве VB6 для VB.net не будет самым ярким примером этого? Или вы все считаете их двумя разными языками?

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

Новая версия языка программирования Ruby также нарушит совместимость.

И подумайте о библиотеках, которые можно использовать: gtk, Qt и так далее (у них также есть несовместимые версии).

Я думаю, что несовместимость иногда необходима (но не слишком часто) для поддержки прогресса.