[prog.thoughts] Могут ли языки программирования существенно упростить разработку больших проектов?

Сначала состоялся вот этот разговор. Потом на глаза попалась вот эта тема на LOR-е. И только сейчас нашлось время дабы высказать свои соображения на счет того, имеет ли смысл ждать каких-то супер-пупер языков программирования, которые бы существенно упростили бы разработку больших программных проектов.

Прежде всего надо определиться, о чем именно идет речь. Под большими проектами я далее буду понимать такие проекты, объем которых многократно превосходит возможности одного разработчика. Даже возможности одного очень хорошего разработчика (коими мы все, безусловно, являемся, особенно в этих наших Интернетах).

На мой взгляд, необходимая база для существенного упрощения разработки больших программных проектов в языки программирования была заложена давным давно. Эту базу составляют такие привычные для нас вещи, как раздельная компиляция, модульность, выставление наружу интерфейсов и сокрытие реализации. То, что пришло в мейнстрим, если не ошибаюсь, на рубеже 1970-х и 1980-х годов. Раздельная компиляция появилась еще раньше, а вот модульность на уровне языка программирования -- это, на моей памяти, Modula-2 и Ada. Продолжили это дело языки вроде Oberon (и другие наследники Виртовского Паскаля, вроде Turbo Pascal от Borland-а), Eiffel (хотя там не так все однозначно), ну и Java с последователями. И это если говорить только про языки со статической типизацией, оставляя в стороне динамически типизированные языки, вроде Python-а. Ну а про динамически типизированные языки в контексте больших проектов лучше вообще не говорить ;)

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

Еще одна штука, которая очень существенно упрощает разработку больших проектов, -- это сборщик мусора. Штука эта так же далеко не новая. И о том, насколько она важна для разработки крупных приложений, так же известно очень давно. Как минимум, со времен Виртовского Oberon-а. По крайней мере мне почему-то помнится, что это Вирт говорил о том, что для разработки компонентного ПО сборщик мусора является необходимым условием. В противном случае ручное управлением временем жизни объектов, созданных одним компонентом, но используемых другим компонентом, превращается в постоянную головную боль. Ну и мне, как C++разработчику, сложно с Виртом не согласиться.

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

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

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

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

Ну, например, взять такую проблему, как сбор и формализация требований к проекту. Грубо говоря, написать нормальное ТЗ для небольшого проекта -- это уже не просто. Написать нормальное ТЗ, точнее, написать пакет из согласованных между собой ТЗ на отдельные куски большого проекта -- еще более сложно. А ведь потом эти ТЗ должны уйти в разработку. Скорее всего, в разные команды. С очень разным уровнем разработчиков, причем разным как в собственно программизме, так и в понимании предметной области. Работу этих команд нужно будет координировать. Результаты их работы как-то интегрировать и тестировать. И т.д., и т.п. Если кто-то думает, что все это может идти гладко и "по написанному", то тот, боюсь, выбрал себе неподходящую область деятельности.

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

Пора переходить к морали. Развитие языков программирования, конечно же, упрощает жизнь программистам. Даже в рамках одного и того же языка разработка большого проекта сейчас оказывается проще, чем таковая лет 10 назад. Что уж говорить про индустрию разработки ПО вообще.

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

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

По крайней мере мне так кажется.

PS. Наличие больших проектов на таких языках, как C или Objective-C, наглядно показывает, что перечисленные выше технические факторы способны упростить разработку большого проекта. Но вовсе не являются факторами, которые переводят задачу из категории "невозможно" в категорию "возможно".