Что случилось с программированием?

[Ozerich]

Сегодня наткнулся на такую статью

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

Когда мне было четырнадцать лет, я написал игрушку про «инопланетное вторжение» на 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 проекта.

[Ozerich]

Продолжение

И только потом понимаешь, где на самом деле начинается основный объём работы. Чтобы программа из личного проекта превратилась в продукт, она требует документации – API и command-line мануалы, туториалы. Ей требуются юнит-тесты, changelog’и и история релизов. Её необходимо проверить на портабельность. Её необходимо настраивать и дополнять. Возможно, ей потребуется определённая внутренняя реорганизация для более успешной совместной работы с другими приложениями. Всё это Фаза 2.

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

Что случилось с программированиемНо Фаза 2 – это не ядро, не идея нашей работы. Весь смысл в Фазе 1. И даже если вторая фаза отнимает больше времени и усилий, то это всего лишь тщательная проверка всех деталей, необходимая для того, чтобы выпустить наш прекрасный код за пределы компьютера. А проблема современного программирования заключается в том, что всё оно, собственно, и заключается во второй фазе. Повсеместное наличие почти-подходящих-но-не-совсем библиотек и фреймворков, делающих-почти-всё-за-вас-кроме-того-что-они-делать-не могут фактически уничтожают всю радость от Фазы 1, но при этом оставляют нас один на один с возможно ещё более тяжелой и куда более нудной второй фазой. Вместо проектирования прекрасных структур данных и элегантных алгоритмов мы ищем класс EnterpriseFactoryBeanMaker в 3,456 страничном Сборнике Тупых Ужасных Классов, потому что мы не можем вспомнить какой из аргументов createEnterpriseBeanBuilderFactory( ) метода делает статичный чисто виртуальный паблик деструктор окончательным завершающим элементом декора интерфейса.

Я понимаю, что назад пути нет - мы уже во всём этом. Но хотелось бы узнать, как из этого выйти.

Простой выход

Из ответов автора на вопросы, проясняющие его позицию:

1.

Может у тебя просто отвратительная работа?

По правде говоря, мне повезло попасть на одно из сравнительно малого числа рабочих мест, где действительно много именно программирования. Я работаю в небольшом open-source software-house, и мы в основном выпускаем тулы. Таким образом, моя работа don’t sucks.

2.

Но вам бы не хотелось каждый раз писать print(f)?

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

Вот правило (которое, как и все такие правила, часто нарушается, и не следует принимать слишком серьезно): остерегайся всего, что называет себя Фреймворком. Чего-нибудь того, что вместо предоставления функционала, говорит, как именно тебе надо кодировать, чтобы он мог вызвать что-нибудь.

3.

Но библиотеки помогают нам быть более эффективными??

Например, у вас есть проблема X, состоящая из подзадач X1, X2, X3. Существуют доступные решения для X1 и X3. Если вам не нравится складывать кирпичики - кодируйте X. Я лучше закодирую X2, подключу решения X1 и X3 и проведу остаток дня за изучением и, возможно, решением проблемы Y.

Отмечу – звучит у вас всё круто и правильно. Но вы упускаете тот момент, что подключение решений X1 и X3 далеко не всегда может быть простым и очевидным. Очень часто это утомительное упражнение, требующее перерывания кучи плохо написанных мануалов, рассказывающих тебе не о сути твоей высокоуровневой проблемы, а о том, что тебе код и так сам по себе говорит. Так что возможно мою первоначальную претензию «Что случилось с программированием?» стоит переиначить на «Почему столько хреновых библиотек?»

Источник

[profi]

Мнения автора я поддерживаю только на 50%. Так как действительно. Многие "слепо" используют компоненты даже не зная "фундамент". Я про начинающих программистов. Кинут на форму кнопку и считают себя великим кодером. А остальные 50% я не поддерживаю автора. Так как зачем изобретать велосипед и тратить на это время, если за тебя уже это сделали, и ты должен с умом применить данное решение.

[Levsha100]

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

[spamer]

Соглашусь с ответом profi, да и по сути с ответом Levsha100 также.
Действительно, для чего изобретать велосипед? Ведь прогресс не стоит на месте, и нам не стоит писать то, что уже написано за нас, лучше написать решение - которого еще нету, для какой то новой задачи.
Ну на крайний случай, можно просто улучшить некий "велосипед", но не писать все с нуля.
Вот как то так

[CodeExpert]

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

[spamer]

Зачем кататься на чужом велосипеде, если можно сделать свой, при условии что на нем комфортнее и использовать его для себя во всяком случае намного лучше

Велосипед останется тем же, только ты его улучшишь и не более

[CodeExpert]

Да, но речи о создании нового велосипеда не было... Просто люди приспосабливаются так как им будет удобнее, и в настоящее время все равно приходится черпать из того что было и делать свою уникальную изюминку...Ну ведь почему же фирмы, подхватившие идею Линукс не стали все писать с 0, они просто дорабатывают из того что уже состоялось...
Если вы делаете для себя, то это уже не важно, но если для массового потребления, то здесь вас ждет либо успех, либо полное фиаско...

[JTG]

Кнут сраный теоретик, уж простите мой французский. Абельсон, Зибель и прочие SICP'ы, да если бы программированием занимались только такие фанатики - не было бы сейчас ни директикс, ни дотнета, сидели бы с ANSI C и лиспом и писали избранные с двумя В/О в unix-way стиле

В нынешних условиях пока контора ООО "Идеальный Софт Кнута&Пряника" 2 года будет писать отлично продуманный, красивый, расширяемый код без ошибок, конкуренты из индийской фирмы "Студенты с печатными машинками ltd." за месяц выпустят каку на палочке, подсадят на неё пользователей, пользуясь отсутствием альтернатив, и оставшееся время ещё будут заколачивать бабло на обновлениях/фиксах/новых версиях. Рынок.

[Simply-Art]

Сообщение от Levsha100

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

Не соглашусь, вот есть ОФИГЕННО оптимальный алгоритм поиска, и что, будем писать новый, с косяками, который медленно пашет, но свой?