IT + Код

Почему языки умирают?

Языки программирования — как виды в природе: одни выживают, другие вымирают. Причины всегда одни и те же:

- Технологический прогресс — появляются более удобные и мощные альтернативы.
- Потеря поддержки — компании перестают вкладываться в развитие.
- Смена парадигм — то, что было актуально 20 лет назад, сегодня выглядит архаично.
- Смерть платформы — нет системы — нет и языка (R.I.P. Flash и ActionScript).

Кто в зоне риска?

1. Perl
Когда-то был королём скриптов, но сегодня его почти полностью вытеснили Python и Ruby. Остался только в старых системных скриптах и legacy-коде.

2. Objective-C
Apple сделала ставку на Swift, и Objective-C медленно, но верно уходит в прошлое. Новые проекты почти никто на нём не пишет.

3. VBScript
Microsoft официально похоронил его в 2023 году. Если где-то и остался, то только в очень старых Windows-скриптах.

4. CoffeeScript
Был популярен в начале 2010-х, но современный JavaScript (ES6+) вобрал все его плюшки. Теперь он никому не нужен.

5. ActionScript
Умер вместе с Flash. Сегодня анимации делают на HTML5 + JS или в Unity.

6. Pascal / Delphi
Когда-то его учили в школах и вузах, но сейчас он почти не используется. Разве что в некоторых банковских системах.

7. Haskell
Красивый, мощный, но слишком сложный для массового использования. Rust и современный Python отбирают его нишу.

8. Lua
Ещё держится в играх (например, Roblox), но в целом теряет актуальность.

9. Fortran
Долгое время был стандартом в научных расчётах, но теперь учёные переходят на Python и Julia.

10. Visual Basic (.NET)
Microsoft давно делает ставку на C#, и VB.NET медленно, но верно умирает.


Что дальше?
К 2040 году под угрозой могут оказаться PHP, Java и даже C++ — технологии не стоят на месте.

Как думаете, кто следующий?

На картинке написано:

— Я прогаю на Haskell

— Это что значит?

— Это значит, что он боится побочных эффектов!

— Ничего подобного!

— printf («Hello world!"\n);

— Патрик, хорош, ты его перепугал!

Поясняет Паша Вавилин, наставник на курсе по Python.

В функциональном программировании есть понятие side-эффекта: это когда функция не только возвращает результат, но и делает что-то кроме. Например, вывести что-то на экран, записать в файл, поменять что-то внутри какой-то другой переменной в программе — это всё побочные эффекты (side effects).

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

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

Например, у нас есть переменная в корне программы. Мы её используем, чтобы считать какие-то нужные нам события. Если какая-то функция в программе добавляет что-то в эту переменную, это побочный эффект.

Вот мы программируем себе и положили побочный эффект «Увеличить глобальный счётчик» в одну из функций. Вызвали её по делу. Она правильно всё посчитала и увеличила счётчик. Пока что ничего страшного.

Через полгода другой программист поддерживает за нас программу. Видит: «О, эта функция делает то, что мне нужно, вызову её». И он не знает, что, помимо своей основной работы, она ещё увеличивает глобальный счётчик (забыл про побочный эффект). Он её вызывает в цикле тысячу раз, и она тысячу раз увеличивает счётчик. А счётчик, в свою очередь, завязан на что-то другое в программе. И в итоге вся программа ломается.

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

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

Условно говоря, если у тебя алгоритм обрабатывает 100 единиц данных за 1 секунду, то сколько секунд ему понадобится на 1000 единиц? В идеале — чтобы это было не 10 секунд, а, например, 3. Ещё бывает, что данных стало в 10 раз больше, а алгоритм обрабатывает их в 25 раз дольше. Вот это дурной знак.

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

Но квадратичной сложности всё же лучше избегать.