Pull to refresh

Евангелисты вместо бухгалтеров

Reading time5 min
Views12K
DesignerHipster.com
DesignerHipster.com

Я пишу в основном из желания поучаствовать в дискуссии, развернувшейся вокруг статьи «Доказательное программирование». Форма статьи была выбрана автором иронично-саркастическая, «первоапрельская», а вопросы затронуты, как мне кажется, очень даже серьёзные и важные, требующие долгого и обстоятельного комментария. С другой стороны, @wetnose «всё сказал», и вторгаться в его личное пространство после этого я не хочу. Поэтому − отдельная статья.

И всё-таки почему программисты постоянно создают новые языки программирования? Почему они так много внимания уделяют выбору языка? Существуют ли объективные критерии превосходства одного языка над другим?

(Кстати, другой важный вопрос, затронутый в статье − этично ли удовлетворять личное любопытство за счёт клиента, и нужен ли программистам свой кодекс профессиональной этики − я не хочу затрагивать. Если что, то на него отвечает дядюшка Боб в своей программной статье “The Programmer's Oath”. Видео.)

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

  • фазу отрицания, к счастью, мы уже прошли. Под отрицанием я имею в виду комментарии типа: «У TIOBE сломался алгоритм», «Неправильно выбрана целевая аудитория», и «А кто вообще сказал, что языки устаревают? COBOL и теперь живее всех живых!»,

  • языки, приходящие на смену прежним лидерам (Java и C++), сами если и моложе их, то ненамного (Scala, Python), так что возложить вину за происходящее на «хипстеров» автор уже не пытается,

  • комментаторы, оппонирующие автору, не уходят в глухую оборону, а вполне себе контратакуют:

Зачем усложнять, когда всё просто?!

«Выживают» те ЯП, которые приносят большую прибыль.

Конечно, насчёт «большей прибыли» − это чрезмерное обобщение, вроде «в программах на Rust нет ошибок». Но комментарий при этом содержит одну рациональную мысль: нельзя рассматривать индустрию программирования как «вещь в себе», исключая различные влияния извне. А что в наибольшей степени влияет на индустрию в период становления?

Финансы, конечно же.

Какими были 1990-е годы для бизнеса? Постиндустриальный уклад уже давал о себе знать возрастанием роли информационного обмена и снижением доли промышленного производства в экономике ведущих наций. Но крупным бизнесом ещё управляло поколение с индустриальным складом ума, которое привыкло иметь дело с материальной собственностью, с конкретным продуктом. Приобретение компьютеров вполне укладывалось в их образ мышления − примерно как приобретение станков и инструментов, но программы?…

Чтобы подписать топ-менеджера индустриальной эры на приобретение дорогого софта или участие в разработке ин-хаус, нужно было найти соответствующие аналогии в понятиях той эры. Поэтому с чьей-то лёгкой руки программы, перестав быть бесплатным приложением к компьютеру, стали считаться основными средствами. Можно купить лицензию и поставить на баланс, получив разовый налоговый вычет. Можно затратить N человеко-лет на разработку методом «Водопад», потом ввести в эксплуатацию и начать списывать амортизацию. Как будто программа − это сложная машина или здание. Как будто.

Java, несомненно − продукт этой переходной эпохи. Каждая её фича внушает высшему менеджменту уверенность в завтрашнем дне. Си-подобный синтаксис гарантирует, что ваши предыдущие вложения в обучение работников защищены. Виртуальная машина позволит в будущем обновлять компьютеры без дополнительных затрат на адаптацию программ. Спецификация стандартизована ISO, что обеспечивает независимость от вендора. Производительность, безопасность, гарантия обратной совместимости и другие баззворды конца 90-х тоже нашли своё место в маркетинге Sun. Java просто не могла не стать успешной с таким высочайшим уровнем соответствия запросам потребителя.

Прошло ни много ни мало − четверть века, и оказалось, что потребителю было нужно не то, что он хотел.

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

Другая причина того, что бизнес изменил отношение к программам − это их неизбежное устаревание, которое было здорово недооценено в 1990-х. Я не хочу здесь огульно хаять Java. Устаревание программ связано с разными факторами, и Java отлично позаботилась о многих из них в рамках стратегии “Write Once Run Anywhere”. Например, о закрытии уязвимостей, о поддержке новых операционных систем. Но с главным фактором устаревания программ − изменением требований − Sun ничего поделать не могла: этот фактор лежит целиком за пределами программной индустрии и совершенно ей неподконтролен.

А ещё за эти 25 лет внутри программной индустрии успела вырасти и набрать вес отдельная категория программ − программы со свободным и открытым кодом. Я лично затрудняюсь сказать, был ли успех FOSS следствием переоценки бизнесом отношения к программной отрасли, или же, наоборот, одной из причин этой переоценки. Факт в том, что если в отношении покупного или внутреннего ПО предприятие может выбирать, что с ним сделать − поставить на учёт как основное средство или списать на операционные расходы, то любая модификация, доработка, внедрение открытого ПО − это операционные расходы и только они.

Итак, бизнес не относится больше к софту как к материальному объекту, который, будучи однажды произведён (закуплен), должен оправдать свою стоимость за определённый период. Средства на разработку (продление подписки) просто списываются по мере необходимости. Что это значит для программной индустрии? Разумеется, программист по-прежнему должен минимизировать расходы на производство программ и вместе с тем повышать их качество. Однако требования к инструментам изменились.

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

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

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

  • простота. Мы будем писать много кода, для этого понадобится много программистов, а простой язык выучить легче. А ещё стоит подумать о не-программистах, которые смогут использовать наш инструмент в своих целях,

  • читаемость. Наш код − скорее натурный эксперимент, чем академическое упражнение, поэтому мы будем часто читать и изменять написанное. А ещё мы будем обучаться программированию скорее на конкретных примерах, чем штудируя документацию и учебники,

  • комфорт. Много синтаксического сахара. Мультипарадигменность. Мгновенная готовность к использованию, REPL, хорошие IDE, встроенные в язык средства документирования кода,

  • универсальность. Возможность легко адаптировать язык к различным предметным областям.

С учётом всего вышесказанного неудивительно, что новые стандарты не создаются, а старые − загнивают. И что рейтинги языков программирования выглядят так, как выглядят. И спрос на рынке труда, и средние зарплаты формируются именно таким образом.

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

Tags:
Hubs:
Total votes 14: ↑10 and ↓4+6
Comments12

Articles