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

Этот вопрос не «Почему люди до сих пор используют старые языки программирования?» Я это прекрасно понимаю. Фактически, два языка программирования, которые я знаю лучше всего, это C и Scheme, оба из которых восходят к 70-м годам.

Недавно я читал об изменениях в C99 и C11 по сравнению с C89 (который, похоже, все еще является наиболее используемой версией C на практике и версией, которую я узнал от K & R). Оглядываясь вокруг, кажется, что каждый язык интенсивного использования получает новую спецификацию, по крайней мере, один раз в десятилетие или около того. Даже Fortran все еще получает новые версии, несмотря на то, что большинство людей, использующих его, все еще используют FORTRAN 77.

Сравните это с подходом, скажем, системы набора текста TeX. В 1989 году, с выпуском TeX 3.0, Дональд Кнут объявил, что TeX полностью функциональн, и в будущих выпусках будут только исправления ошибок. Более того, он заявил, что после его смерти «все оставшиеся ошибки станут функциями», и никаких дальнейших обновлений не будет. Другие могут свободно разворачивать TeX и сделали это, но полученные системы переименованы, чтобы указать, что они отличаются от официального TeX. Это не потому, что Кнут думает, что TeX совершенен, а потому, что он понимает ценность стабильной, предсказуемой системы, которая будет делать то же самое через пятьдесят лет, что и сейчас.

Почему большинство разработчиков языков программирования не следуют одному и тому же принципу? Конечно, когда язык является относительно новым, имеет смысл, что он пройдет период быстрых изменений, прежде чем успокоится. И никто не может на самом деле возражать против незначительных изменений, которые делают не намного больше, чем кодификация существующих псевдостандартов или исправление непреднамеренных чтений. Но если после десяти или двадцати лет язык все еще нуждается в улучшении, почему бы просто не раскошелиться или начать все сначала, а не пытаться изменить то, что уже используется? Если некоторые люди действительно хотят заниматься объектно-ориентированным программированием на Фортране, почему бы не создать для этой цели «Objective Fortran» и оставить сам Фортран в покое?

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

Это настоящий вопрос, а не приглашение спорить. Очевидно, у меня есть мнение по этому поводу, но сейчас я просто пытаюсь понять, почему это не просто так, как все уже сделано. Я предполагаю, что вопрос:

Каковы (реальные или предполагаемые) преимущества обновления языкового стандарта по сравнению с созданием нового языка на основе старого?

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

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

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

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

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

В качестве дополнительного комментария я считаю, что аргумент, разрешающий эволюцию при сохранении совместимости с унаследованным кодом, довольно слаб: Java может вызывать код C, Scala может легко интегрироваться с кодом Java, C # может интегрироваться с C ++. Есть много примеров, которые показывают, что вы можете легко взаимодействовать с унаследованным кодом, написанным на другом языке, без необходимости совместимости с исходным кодом.

НОТА

Из некоторых ответов и комментариев я, кажется, понимаю, что некоторые читатели интерпретировали вопрос как «Почему языки программирования должны развиваться».

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

Обратная совместимость - ваш ответ. Данный язык, особенно широко используемый, такой как C, может содержать код, который работает без изменений в течение десятилетий. Если требуется техническое обслуживание, это помогает иметь компиляторы, которые могут по-прежнему ориентироваться на платформу такого типа, работая на современных системах для разработки. Стандартизации и обновления языковых версий помогают поддерживать практику программирования в актуальном состоянии, в то же время обеспечивая знакомство для опытных программистов, которые могут быть невосприимчивы к изучению целого «нового» языка.

Имейте в виду, что многие из обновленных языков обновляются не столько, сколько «с новыми блестящими элементами». Звери прошлого часто все еще скрываются внутри.

Что касается Кнута, помните, что он академик и что TeX только проверен, но не обновлен.

Я думаю, что очевидный ответ заключается в том, что прогресс в области языкового дизайна и архитектуры системы все еще достигается, и достаточно людей заботятся о старых языках, которые хотят использовать преимущества более новых методов (многоядерные, улучшенные потоки или модели памяти), которые они получают на болтах. или запеченный в языковой стандарт. Это также помогает иметь «единственно верный способ» выполнять какие-либо действия (например, синтаксический анализ XML, доступ к БД), на которые можно рассчитывать, независимо от того, на каком компиляторе или платформе вы работаете, в отличие от сторонних разработчиков. библиотека, которая может или не может быть установлена ​​(и может быть, а может и не быть той версией, которая вам требуется, и т. д.)

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

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

Есть несколько случаев, когда «новые» функции добавляются к существующим языкам, но во многих случаях эти изменения сводятся к упрощению того, что люди уже делали трудным путем. (См. C ++ с использованием функций высокого порядка вместо указателей функций и функторов.)

Это немного похоже на разговорную речь.

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

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

Плохо: не так давно плохое имело только одно значение, теперь оно может означать что-то «супер-удивительное» (оно используется необычным образом (я, вероятно, скучаю по сказанному)!

Еще одна новая разработка - мобильный телефон «Говори текст» для письменных языков.

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

Я знаю людей, которые говорят на разных языках, и они часто предполагают, что после 3-го или 4-го легче будет выучить новый.

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

Я знаю, что чувствую себя счастливым, программируя на JAVA (так же, как я чувствую себя счастливым, когда говорю по-английски). Это не значит, что я не могу общаться на «американском английском» или «австралийском английском», хотя есть некоторые «ошибки», на которые стоит обратить внимание. , Подобно переходу с Java на PHP на Perl, конструкции похожи, но есть небольшие хитрости, которые меня поймают и заставят меня ударить головой о стену.

Это отличается от перехода с английского на французский или с Java на SAS. они настолько разные, что требуется довольно много времени, чтобы стать опытным в них.

Во всяком случае, это мой взгляд на это.