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

Question

Python 3.0 нарушает обратную совместимость с предыдущими версиями и разбивает язык на два пути (по крайней мере, временно). Знаете ли вы какой-либо другой язык, который прошел такой важный этап проектирования в зрелости?

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

Лисп к Схеме включал переименование.

Если вы отыщете отсканированное руководство по B старого языка программирования , вы увидите, что переход к C выглядит как постепенный, а не радикальный, но он нарушил совместимость.

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

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

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

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

2. Инкрементный шаг, пока вы не будете вынуждены изобретать новый язык.

3. нарушить совместимость контролируемым, вдумчивым образом.

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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