Популярный программист-блоггер Майк Тейлор в одном из постов, вызвавших бурную полемику, сокрушается по поводу того, что настоящее программирование ушло в небытие и ему приходится заниматься складыванием каких-то не совсем квадратных кубиков. Многие его рассуждения спорны, но в целом интересное мнение о несовершенстве современных библиотек и фреймворков, превращающих программирование в какой-то совершенно другой род деятельности.
Что случилось с программированием?
Когда мне было четырнадцать лет, я написал игрушку про «инопланетное вторжение» на BASIC на VIC 20. Если вы интересовались компьютером в 1982 году, готов поспорить, что вы тоже делали что-нибудь подобное. Когда мне было 18, я написал многопользовательских «хранителей подземелья» на C для терминалов, приаттаченных к Sun 3. Когда мне было 22, я работал над системой текстовых баз данных, опять на C, но уже на своём собственном Sun 3/80. Я был в контакте с моими друзьями из университета: мы собирались писать компиляторы, операционные системы и прочие такие крутые штуки - и в какой-то мере даже пытались это делать. Мы посылали друг другу наш текущий код, жаловались друг другу на конструкции языков программирования и смеялись над своими нелепыми и бессмысленными перереализациями функции malloc().Это было тогда
Сегодня я в основном склеиваю вместе библиотеки. Так делаете и вы, если работаете в индустрии разработки ПО. Это выглядит не совсем логично, вы так не считаете? Мы проходили курсы параллельного программирования, изучали референционно прозрачные функциональные языки, мучились с Lisp, Prolog и APL, корпели над теорией операционных систем, инвариантами и формальными предусловиями. И что из этого мы используем? Огромная часть работы – это устранение противоречий между большими непрозрачными кусками библиотечного кода, которые почему-то не хотят вместе делать то, что предполагается моей программе. Ну, я не знаю. К примеру, перевод USMARC-записи в Dublin Core. Это программирование? Да? Конечно, всё это требует вкуса, проницательности и опыта, чтобы быть качественно реализованным, но совсем не требует какого-то блеска идей и не прибавляет особых эмоций. Это не то, о чём мы мечтали в 14 лет, или для чего начинали учиться в 18. Это не будоражит кровь. Это не созидание.
Если вы не верите моим словам и анализу, может вы поверите Дональду Кнуту? Вот несколько выдержек из его интервью в отличной книге Петера Зибеля (Peter Siebel) «Coders at Work»:
«Что меня действительно волнует, так это то, что сейчас в основном программирование превратилось во встраивание магических заклинаний: вы берёте куски чужого кода, делаете магические пасы и запускаете. В этом нет чего-то креативного или творческого. И это становится слишком скучным, потому что у вас нет возможности сделать ничего особого нового. Ваш эмоциональный профит – получить удовольствие от того, что из машины вышел хороший позитивный результат. Но это совсем не то, когда вы создаёте что-то новое. Сейчас сам процесс превратился в скучную рутину, а радость можно получить только от результата работы. Но сама работа не должна быть скучной! Это неправильно.» "Кодирование стало скучным, потому что всё, что вы можете сделать, так это вызвать какие-либо штуки из библиотеки (при условии, что вы не пишете библиотеки самостоятельно). Если работа по кодированию будет заключаться только в том, чтобы найти правильную комбинацию каких-то параметров, то довольно очевидно, что вряд ли кто-то захочет посвятить этому занятию свою карьеру. "(Стр. 581)
С Д. Кнутом, я полагаю, сложно не согласиться. Хочется делать вещи, а не склеивать их вместе. Когда меня спрашивают о том, что мне нравится в работе программиста, я отвечаю – это захватывает: начать с ничего и в процессе что-то создать. Для меня это и есть суть программирования, и весьма печально, что она сейчас перестаёт этим быть.
Все мы знаем, что самая интересная часть процесса программирования – это его начальные этапы: когда буфер редактора пуст, а мир свеж и полон возможностей. А затем наступает захватывающий момент, когда код начинает приобретать форму, структура данных выстраиваться, а алгоритмы сходиться. Код становится запускаемым, затем он начинает даже делать что-то нужное, проходит тесты и затем – да! Это уже не просто какая-то идея – это уже реализованная программа. Вы прошли Фазу 1 проекта.
И только потом понимаешь, где на самом деле начинается основный объём работы. Чтобы программа из личного проекта превратилась в продукт, она требует документации – API и command-line мануалы, туториалы. Ей требуются юнит-тесты, changelog’и и история релизов. Её необходимо проверить на портабельность. Её необходимо настраивать и дополнять. Возможно, ей потребуется определённая внутренняя реорганизация для более успешной совместной работы с другими приложениями. Всё это Фаза 2.
Фишка в том, что вряд ли найдётся профессиональный программист, который бы хотел всем этим заниматься. Но мы понимаем всю важность и необходимость данных действий и делаем их тщательно и правильно. Это часть профессионализма, часть того, чтобы чувствовать себя не только учёным и творцом программирования, но и инженером. Это всё хорошо.
Но Фаза 2 – это не ядро, не идея нашей работы. Весь смысл в Фазе 1. И даже если вторая фаза отнимает больше времени и усилий, то это всего лишь тщательная проверка всех деталей, необходимая для того, чтобы выпустить наш прекрасный код за пределы компьютера. А проблема современного программирования заключается в том, что всё оно, собственно, и заключается во второй фазе. Повсеместное наличие почти-подходящих-но-не-совсем библиотек и фреймворков, делающих-почти-всё-за-вас-кроме-того-что-они-делать-не могут фактически уничтожают всю радость от Фазы 1, но при этом оставляют нас один на один с возможно ещё более тяжелой и куда более нудной второй фазой. Вместо проектирования прекрасных структур данных и элегантных алгоритмов мы ищем класс EnterpriseFactoryBeanMaker в 3,456 страничном Сборнике Тупых Ужасных Классов, потому что мы не можем вспомнить какой из аргументов createEnterpriseBeanBuilderFactory() метода делает статичный чисто виртуальный паблик деструктор окончательным завершающим элементом декора интерфейса.
Я понимаю, что назад пути нет - мы уже во всём этом. Но хотелось бы узнать, как из этого выйти.
Из ответов автора на вопросы, проясняющие его позицию:
Может у тебя просто отвратительная работа?
Но вам бы не хотелось каждый раз писать print(f)?
-
Но библиотеки помогают нам быть более эффективными??
Например, у вас есть проблема X, состоящая из подзадач X1, X2, X3. Существуют доступные решения для X1 и X3. Если вам не нравится складывать кирпичики - кодируйте X. Я лучше закодирую X2, подключу решения X1 и X3 и проведу остаток дня за изучением и, возможно, решением проблемы Y.
По правде говоря, мне повезло попасть на одно из сравнительно малого числа рабочих мест, где действительно много именно программирования. Я работаю в небольшом open-source software-house, и мы в основном выпускаем тулы. Таким образом, моя работа don’t sucks.
Нет, конечно, я вовсе не хочу сказать, что месту для библиотек нет места в этом мире! Приятно иметь набор существующего функционала, который мы можем вызвать по первому требованию. Проблема возникает, когда все, что ты делаешь, это склейка библиотек вместе. Другими словами, библиотеки отличные слуги, но отвратительные хозяева процессов. Где-то что-то мы упустили - позволили им выбраться и закрепить власть. Вот правило (которое, как и все такие правила, часто нарушается, и не следует принимать слишком серьезно): остерегайся всего, что называет себя Фреймворком. Чего-нибудь того, что вместо предоставления функционала, говорит, как именно тебе надо кодировать, чтобы он мог вызвать что-нибудь.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.