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

46

Этот вопрос не «Почему люди до сих пор используют старые языки программирования?» Я это прекрасно понимаю. Фактически, два языка программирования, которые я знаю лучше всего, это 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 должно быть какое-то преимущество, достаточное для того, чтобы накладывать эти накладные расходы на всех, кто использует язык.

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

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


источник
2
Многие компиляторы могут вызываться с помощью переключателей, которые будут применять более старые стандарты (например, --std=xпереключатель GCC ), поэтому создание новых стандартов не приводит к созданию инструментов, дестабилизирующих старый код.
Blrfl
2
Как вы определяете «новый язык на основе старого»? Я бы сказал, что Fortran 90 - это «новый язык», основанный на старом F77. Он полностью изменил способ программирования - фиксированный по сравнению со свободным исходным кодом, динамический по сравнению со статической памятью и т. Д. Можно также утверждать, что Fortran 2003 - это «новый язык» на основе F90 - он добавил объектно-ориентированное программирование, сохранив совместимость с F90. Похоже, отношения между C ++ и C.
tpg2114
1
Я думаю, что этот вопрос очень важен, и я не понимаю, почему некоторые хотят закрыть его. Это очень интересное явление, которое, вероятно, имеет какое-то объяснение. Несколько (20?) Лет назад я читал о новых возможностях Fortran и спрашивал себя: если программисты на Fortran нуждаются в этих функциях, почему бы им просто не переключиться на C? Недавно у меня было аналогичное соображение относительно C ++: если разработчики на C ++ хотят использовать лямбды, почему бы не перейти, скажем, к OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php )? Почему они предпочитают создавать новый язык и все еще называть его C ++?
Джорджио
3
@ tpg2114 Разница между (FORTRAN 77: Fortran 90) и (C: C ++) заключается в том, что Fortran 90 считается заменой FORTRAN 77 до такой степени, что людям говорят: «Если вы хотите изучать Fortran, изучите Fortran 2003 или по крайней мере, 90, потому что это стандарт сейчас ". Никто не скажет что-то вроде: «Если вы хотите изучать C, изучайте C ++, потому что это новый стандарт», потому что они представлены как два разных языка. Как я уже сказал, коннотации имеют последствия.
6
ПОТОМУ ЧТО C никогда не умирает
Адель

Ответы:

13

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

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

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

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

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

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

НОТА

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

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

Джорджио
источник
Этот ответ имеет наибольшее значение для меня из всех, что я видел здесь: обновление языка позволяет вам наследовать (по крайней мере, некоторые из них) существующее сообщество, библиотеки и т. Д. Я вспоминаю, что читал, что самая большая проблема Lisp - это большое количество несовместимые диалекты, которые мешают поддерживать сообщество; Обновление существующего языка может быть способом избежать фрагментации других сообществ таким же образом.
@SunAvatar: Насколько я знаю, в Лиспе есть несколько диалектов, но некоторые из них более успешны, чем другие (Common Lisp, Scheme, Racket, Clojure). Каждый раз, когда вы начинаете новый язык, вы рискуете, что вокруг него соберется только очень небольшое сообщество. В сообществе Лисп это кажется обычной практикой: если у кого-то появляется новая идея, он разветвляется и видит, что происходит. Для создателей других языков потерять сообщество не вариант.
Джорджио
@SunAvatar: Я не вижу наследования существующих библиотек в качестве веского аргумента. Вам не нужна совместимость исходного кода для этого. Посмотрите, например, как Clojure и Scala могут использовать код Java.
Джорджио
1
Языки не умирают, только программисты, которые их используют.
Эван Плейс
@SunAvatar: Есть также сообщества, которые пытаются следовать другой политике: имя идентифицирует язык, и если часть сообщества создает диалект, который расходится слишком сильно, они используют новое имя, чтобы избежать путаницы. Смотрите, например, racket-lang.org/new-name.html
Джорджио
21

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

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

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

Мировой инженер
источник
14
Проблемная область Tex = формат научного текста статьи, не сильно изменилась. Область языков программирования = найти новые применения для новых компьютеров, довольно обширна. По той же причине, что латынь не добавляет так много новых слов, как английский
Мартин Беккет
Я не думаю, что обратная совместимость является уважительной причиной: Scala легко интегрируется с существующим кодом Java, но это не супер-набор Java. Поэтому я думаю, что в целом не обязательно, чтобы новый язык был совместим со старым на уровне исходного кода. Достаточно иметь четко определенный механизм для вызова унаследованного кода из нового кода.
Джорджио
@Martin Beckett: «Проблемная область текста научной статьи в формате Tex = не сильно изменилась». Я думаю, что вы упускаете суть вопроса. ОП не спрашивает, должны ли быть инновации в языках программирования (никто не может отрицать, что инновации необходимы), но почему старые языки пересматриваются вместо создания новых.
Джорджио
Системы построены на инвестициях времени, денег и опыта (опыт, полученный на определенном языке). Новые усилия стоят значительно больше, чем усилия по обслуживанию (во всех трех категориях). Без улучшений языка и платформы в целом стоимость обслуживания возрастет, а затем стоимость новой системы станет более привлекательной, и подлинный перенос приложения COBOL на совершенно другую платформу в восьмой раз за свою жизнь может не показаться как такая большая сделка.
JustinC
Если бы не обновленные стандарты языка COBOL и разработчики инструмента COBOL, добавившие свои уникальные возможности на этом пути, которые улучшили язык и улучшили способность работать на более широких, распространенных, современных платформах; приложение не пережило бы 60 лет. Несмотря на то, что относительные затраты, безусловно, выросли позже в его жизни, из-за растущей нехватки опыта, в целом усилия были копейки на доллар по сравнению с регулярной перепиской, когда появился язык момента.
JustinC
5

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

TMN
источник
Поэтому, если причиной является «достаточное количество людей, которые заботятся о старых языках», вы бы сказали, что ваш ответ можно перефразировать как «сентиментальная привязанность к существующим языкам»? Я не говорю это уничижительно, просто пытаюсь понять ваш ответ.
Авнер Шахар-Каштан
Нет, я имел в виду, что языки все еще активно используются, и ими пользуются люди, которые хотят воспользоваться новейшими технологиями. Я не думаю, что кто-то собирается добавить поддержку многопоточности в ALGOL, потому что (AFAIK) он не используется активно. FORTRAN и COBOL, тем не менее, все еще используются для разработки новых систем, поэтому их языковые спецификации периодически обновляются для включения новых методов и технологий.
TMN
1

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

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

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

Бен
источник
1
Изменения, которые вы описываете во втором абзаце, довольно неоспоримы (под этим я подразумеваю не только то, что я не возражаю, но что никто не может серьезно возражать). Что касается лямбд, я не могу комментировать их полезность в C ++, но зачем добавлять их, если не нужно менять способ выражения алгоритмов?
О, они невероятно полезны. Не пойми меня неправильно. Они являются наиболее важным дополнением в C ++ (IMO). Я думаю, что я не был ясно о том, что я имел в виду там. Обычно выбирают С ++, чтобы иметь прямой доступ к памяти, детерминированную производительность и высокий потенциал оптимизации. Это не меняется с недавними дополнениями. Мы упростили многие другие задачи программирования, связанные с тем, почему вы выбрали C ++, но C ++ по-прежнему действителен и полезен по тем же причинам. Схема обновляется с регулярностью, но код-как-данные и отсутствие ошибок не меняется, поэтому сегодня вы выбираете схему по тем же причинам, что и 20 лет назад.
Бен
«Что касается лямбд, я не могу комментировать их полезность в C ++, но зачем их добавлять, если не нужно менять способ выражения алгоритмов?»: Я иду еще дальше: зачем добавлять их в C ++ вместо переключения на язык, который были ли они с самого начала?
Джорджио
2
@ Джорджио Чтобы иметь возможность контролировать функции кэширования и абстракции в языке. Если ни один из существующих языков не предоставляет оба варианта, вы не можете переключать языки, не жертвуя им. Вы должны изменить язык или создать новый.
mike30
@mike: Что вы подразумеваете под "функциями кэширования"?
Джорджио
-2

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

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

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

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

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

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

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

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

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

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

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

DaveM
источник
Я думаю, что вы думаете о "шалости".
Uliwitness