Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Признаки устаревшего языка

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

  • имеет устаревшую конструкцию, например биплан,
  • изготовлен из «старых» материалов (дерево, полотно, и ряд металлов),
  • имеет неэффективный двигатель,
  • предоставляет низкий уровень комфорта экипажу и пассажирам,
  • имеет низкую надёжность, не эргономичен в управлении,
  • не использует последние достижения науки и техники.
            А что с языками программирования? Понятно, что они не подвержены износу и не знают, что такое «усталость металла». Но ясно, что они тоже могут иметь проблемы, особенно если они разработаны давно, а жизнь, которая никогда не останавливается, накопила опыт решения проблем. А поскольку язык был сделан давно, а опыт появился только недавно, то естественно, что он не учтён этим языком.

            Но старые языки программирования, хоть и остановились в своём развитии, зато обросли «мясом». Библиотеки, фреймворки, среды разработки, масса книг и учебников, тысячи или даже миллионы последователей — вот что имеют старые языки.

Признаки устаревшего языка
            Однако появляются новые языки. Но они, зачастую, ничем не лучше старых. Они ещё не «сошли с конвейера», а уже устарели. Или сошли, и в штампе об изготовлении стоит совсем свежая дата, но... Этот свежий автомобиль имеет устаревшие подвеску и тормоза, у него нет подушек безопасности, движок у него карбюраторный, а салоне — магнитола с кассетами и диапазоном «СВ» и «ДВ».

            Так и язык — он только что вышел из-под пера (простите, клавиатуры) программиста, для него даже тесты ещё не написаны — а он уже устарел. Эх, не получилось никого удивить, вся публика выпячивает губы: «Мы это уже видели».

            Конечно, цели создания языков могут быть разные, например Вы — завсегдатай выставок ретроавтомобилейкомпиляторов и «олдскульных» языков. Эти новые языки, которые лишь хорошо забытые старые, представлены в большом ассортименте в этих списках (разработки наших организаций и частников). Перед этими новыми языками вроде бы ставилась задача пододвинуть старые, но что делать, если они такие же, как и старые, но при этом ещё и «мясом» не обросли? Вот и курят они в сторонке, ожидая, что их компания будет пополнена другими образцами «нового слова в программировании». Такая картина наблюдается не только в родных палестинах, но и в Кремневой долине тоже. Ни Go, ни Swift точно не пошли дорогой революции.

            Рискую повторить классификацию Борхеса, но попробую описать формальные критерии отнесения того или иного языка к устаревшим. И так, каковы они, эти признаки или приметы? Это когда в языке есть:
  • оператор «goto»;
  • такая обработка исключений, которая ещё хуже «goto», когда исключение неизвестно где возникает и неизвестно куда передаёт управление;
  • постфиксные операции «++» и «--», которые для большинства — загадочны;
  • висячий «else»;
  • приведения типов, влекущие «тайное» изменения значения;
  • нулевой указатель и обращения по абсолютным адресам;
  • упор на мутабельные состояния;
  • возможность присвоить неинициализированное значение;
  • визуальный мусор типа «begin» и «end», особенно ЗАГЛАВНЫМИ буквами;
  • синтаксис, прогибающий под себя программистов, а-ля Forth;
  • развитый макроязык, который говорит о неразвитости собственно языка.
И когда в языке нет:
  • ключевых слов а-ля PL/1;
  • приоритетов операций а-ля Lisp или Forth;
  • контроля границ массивов а-ля Си;
  • контроля возможного переполнения при арифметических операциях;
  • функций — объектов первого класса;
  • оператора «for each»;
  • программирования в стиле доказательств;
  • вывода типов;
  • зрительных ориентиров в тексте, позволяющих отличить операции от операндов;
  • синтаксически обособленных чистых функций.
            Если программирование будет идти вперёд, то в том числе через новые языки с новыми подходами и парадигмами. Для того, чтобы оставаться в рамках старых парадигм и привычных подходов, новые языки не нужны. Для этого есть «старый добрый» Си или «тёплый ламповый» Паскаль. Новые Си и Паскаль с иной, пусть и эргономичной, с отшлифованной формой записи проиграют конкуренцию своим первоисточникам.

            Иногда языки могут «выстрелить» благодаря какой-то фишке, которой нет ни у кого. Например, у языка 1С — это русские идентификаторы. У PHP — и ориентированность на Web. Но не раз повторённое новшество теряет притягательность. Однако найти такую фишку при неизменном фундамента программирования сложно.

            Эволюционный путь развития языков «в возрасте» приведёт в итоге в тупик. В языке С++, к примеру, с каждое нововведение увеличивает число правил, усложняет язык. Чем сложнее язык, тем сложнее компилятор. Тем меньшим коллективам он под силу. Тем меньше конкурирующих компиляторов мы будем иметь. При отсутствии конкуренции начнает страдать качество компиляторов.

Опубликовано: 2019.09.05, последняя правка: 2019.09.12    18:48

ОценитеОценки посетителей
   ██████████████████████████████████████████ 2 (100%)
   ▌ 0
   ▌ 0
   ▌ 0

Отзывы

     2019/09/10 10:17, kt          # 

Да, получается так, что «обрастание мясом» (набирание сложности) становится признаком «устаревания». Пишутся возмущенные статьи, что «все сложно», «всего слишком много» и появляется очередной «маленький и простой» новый язык. Когда с новым языком начинают работать по-настоящему, он, естественно сам или через библиотеки начинает усложняться и круг замыкается — нужен опять новый простой и понятный язык. Который вскоре как цыганских детей перестают отмывать и рожают новых и т.п.
Я столкнулся с этим ещё в середине 90-х. В первой прочитанной мною брошюре по Паскалю введение начиналась словами: наконец-то, после «пудовых» описаний PL/1 и ассемблера ЕС ЭВМ, мы получили язык с описанием на нескольких страницах. Года через два наши соседи купили дистрибутив Турбо-Паскаля и упаковка весила (не поверите!) как раз 16 кг. Сам помогал тащить. Основная тяжесть — описание библиотек на хорошей бумаге. Библиотеки — это не язык? Но ведь и в «пудовых» описаниях для ЕС ЭВМ были рекомендации по оптимизации, описание ОС, файловой системы и т.д. А сам язык вполне можно было изложить на нескольких страницах.

     2019/09/10 16:42, MihalNik          # 

В первой прочитанной мною брошюре по Паскалю введение начиналась словами: наконец-то, после «пудовых» описаний PL/1 и ассемблера ЕС ЭВМ, мы получили язык с описанием на нескольких страницах. Года через два наши соседи купили дистрибутив Турбо-Паскаля

Надо понимать, что речь даже может идти о продукции совершенно разных людей. Но, например, и в то время, когда Турбо-Паскаль покупали ваши соседи, и когда Вы ещё читали книгу, в языках у Вирта скобочек begin ... end давно уже не было) Очевидно, удалить их (как и ещё что-то поправить) из турбо-паскаля никакой проблемы для разработчиков не было, вполне можно было выдвигать свои условия к синтаксису языка для закупок ПО.

     2019/09/10 16:48, kt          # 

Так речь не о скобочках, а о возрастании сложности при использовании языка на производстве. "Чистый" Паскаль, Лисп и другие годятся только для школьной информатики. И чем дольше используется язык в реальных задачах, тем больше он обрастает всякими возможностями и дополнениями. А потом дополнениями дополнений.

     2019/09/10 18:36, MihalNik          # 

Так речь не о скобочках, а о возрастании сложности при использовании языка на производстве.

А при чем тут сложность языка? 1с — сложный язык? Нет, это реально старый "бейсик". Программировать на 1с сложно? Да, это требует знания бухучета и кучи соответствующих модулей 1с-а. Но ведь бухучет — это не язык программирования, а прикладная область знания. Делфи сложный язык? Нет, но объектные модели вроде VCL там не маленькие, а это куча английских слов + их назначения и связи м/у ними в программной модели. Ни разу не видел, чтобы кто-то жаловался на добавление цилка "for each" в Delphi или операторов типа "+=" во FreePascal. Программы стало писать проще? Да. Способствует снижению дублирования лексем? Да. Что они там в компиляторе могли чересчур усложнить?
"Обрастание мясом" бычка и "приделывание костылей" к инвалиду — сильно разные явления.

     2019/09/10 21:10, kt          # 

Об этом писал и Автор сайта. Расширения языка просты для тех, кто усвоил язык ещё без них. А тем, кто начинает осваивать с нуля сложнее — они сразу сталкиваются со всем многообразием возможностей. Для тех, кто уже работает с данным языком — процесс его усложнения почти незаметен. Ну появилась ещё одна примочка и хорошо. Обычно понятно, где её использовать. Новичкам все осознать гораздо сложнее. Сравните, как пример усложнения, один из первых учебников по Лиспу (Лаврова) и описания его теперешних потомков.

     2019/09/10 22:25, MihalNik          # 

А тем, кто начинает осваивать с нуля сложнее — они сразу сталкиваются со всем многообразием возможностей.

Никто ж не виноват разрабам, что их компилятор не предупреждает об устаревании конструкций.

     2019/09/12 11:36, Автор сайта          # 

«Обрастание мясом» с большой вероятностью может говорить о том, что язык старый. А если старый, то и устаревший. А вот обратное часто неверно. Если язык не обзавёлся массой библиотек, то это может говорить не о его новизне, а о его непопулярности, у которой может быть много причин.

«Обрастание мясом» — это обзаведение кучей полезных вещей (типа библиотека) вокруг языка, а не в самом языке. От появления библиотек не увеличивается сложность языка, нет необходимости дорабатывать компилятор. «Всё сложно» и «всего много» становится тогда, когда меняют язык и усложняется язык. Документация же может весить 16 кг не к самому языку, который может быть очень мал, а к библиотекам, среде и проч., которые могут быть велики.

"Чистый" Паскаль, Лисп и другие годятся только для школьной информатики.

Если не сопровождаются библиотеками и прочим. А при их наличии они могут применяться много где, и в производстве тоже. Это в PL/1 много всего, что зашито прямо в язык. В других языках можно, не трогая язык, «обрастать мясом».

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

Глупо бороться с goto в старых языках. Этот оператор порою предлагает наиболее экономичные решения — в силу правил языка, которые у старых языков уже отлиты в бронзе. Бороться с памятниками — плохая идея. Но в новых языках можно построить правила так, что goto и близко будет не нужен. Однако в них порою предлагаются устаревшие подходы. Вот тогда смотришь на такой язык и приходит в голову классическое: «Молодая была немолода».

     2019/09/15 14:25, Александр Коновалов aka Маздайщик          # 

В статье, как мне кажется, смешиваются два понятия: устаревший и зрелый язык.

Устаревший язык — язык, в основе которого лежат устаревшие концепции, а современные концепции отсутствуют.

Зрелый язык — язык с развитой экосистемой: сообществом, библиотеками, инструментарием. На зрелых языках написаны огромные массивы кода, который должен оставаться работоспособным.

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

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

Но поскольку язык активно используется, расширения должны сохранять обратную совместимость, поэтому максимум что доступно — рекомендовать новые практики взамен старых. Например, в современном C++ не рекомендуются «сырые» указатели (T*), вместо них рекомендуется использовать классы «умных» указателей (std::shared_ptr<T>, std::unique_ptr<T>), а вместо выделения массивов объектов malloc()/new[], нужно использовать библиотечные контейнеры (std::vector<T>, std::list<T> и т.д.)

Устаревшие средства иногда можно удалить из стандартной библиотеки (например, gets() в последних стандартах Си и Си++ удалили), но из ядра уже не удалишь — унаследованный код должен продолжать работать.


Так что любой «зрелый» язык неизбежно будет «старым», т.е. будет допускать возможность писать код по устаревшим принципам. Но есть примеры, когда новая редакция языка предлагает некоторую директиву, которая запрещает в последующем тексте использовать (некоторые) устаревшие средства. Например, "use strict" в современном JavaScript, <!DOCTYPE html> для HTML5. Довольно любопытный способ сохранить «зрелость», избежав «старины».


В комментариях выше написано про килограммы справочников. Действительно, чтобы эффективно программировать на зрелом языке, нужно знать не только синтаксис/семантику (которые ещё и «распухают» при созревании), но и экосистему: библиотеки, среды разработки, хорошие практики программирования. Иначе программист просто не будет конкурентоспособен на рынке. Поэтому программисты вынуждены читать килограммы справочников.

     2019/09/15 19:32, kt          # 

В целом соглашусь.

Например, "use strict" в современном JavaScript


Еще один яркий пример — фортран. Все исправления — попытки удержаться на плаву (сохраняя огромный задел).
Во всех новых текстах обязательно есть директива "implicit none", запрещающая неописанные переменные. Тот самый случай отказа от старого, но сохраняя старые тексты.

     2019/09/15 21:18, Александр Коновалов aka Маздайщик          # 

Visual Basic (классический, VBScript, VBA, не уверен про VB.NET) имеет директиву с похожим именем и точно таким же смыслом — Option Explicit. В BASIC’е раньше тоже переменные неявно объявлялись.

Кстати, о признаках устаревших языков в самом посте. Неявные объявления переменных можно рассматривать как признак устаревшего языка (хотя в некоторых скриптовых языках они могут быть уместны).

Добавить свой отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Изобретение очередного велосипеда?

Все языки эквивалентны. Но некоторые из них эквивалентнее других

Признаки устаревшего языка

Лень — двигатель прогресса

О наименовании проекта и языка программирования

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее

Последние комментарии

2019/09/15 21:18 ••• Александр Коновалов aka Маздайщик
Признаки устаревшего языка

2019/09/15 14:53 ••• Александр Коновалов aka Маздайщик
Некошерный «goto»

2019/09/13 16:38 ••• Автор сайта
Программирование исчезнет. Будет дрессировка нейронных сетей

2019/09/13 16:35 ••• Автор сайта
Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

2019/09/12 20:40 ••• Александр Коновалов aka Маздайщик
Циклы

2019/08/30 07:57 ••• Noname
Почему обречён язык Форт

2019/08/29 09:07 ••• рст256
Устарел ли текст как форма представления программы

2019/08/19 19:19 ••• Автор сайта
Шестнадцатиричные и двоичные константы

2019/08/05 19:22 ••• Геннадий Тышов
Программирование без программистов — это медицина без врачей

2019/07/30 14:06 ••• Александр Коновалов aka Маздайщик
К вопросу о совершенствовании языка программирования

2019/07/21 20:30 ••• Автор сайта
Деньги = работа / знание

2019/07/20 19:42 ••• Александр Коновалов aka Маздайщик
Права доступа к переменным