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

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

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

Хорошо, человек упрощает (как человеку кажется) себе жизнь моделями, но почему так не происходит в программировании? Ведь человек и в программировании также применяет модели - для того же упрощения умственной и ручной работы. Информационные технологии - нагромождение моделей в чистом виде. Базы данных, языки программирования, биты, байты, файлы, папки, программы, интерфейсы - это также все модели, которые человек придумал с целью упростить вычисления и взаимодействие с компьютерами. Но в сравнении с моделями физики, химии, математики модели программирования выглядят как чудовищно запутанная груда придуманных абстрактных сущностей, которые к реальности имеют весьма отдаленное отношение. Правило Бритвы Оккама ("не плоди сущностей сверх необходимого", делай все проще, Keep It Simple Stupid, KISS) тут хоть и действует, но звучит как насмешка над реальностью. И со временем упрощения не наблюдается, все становится сложнее и запутаннее.

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

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

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

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

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

Хорошее английское понятие - интерфейс - по сути тоже модель. Вообще самое трудное для меня, как программиста - это интерфейс. Именно его сложнее всего изучать. И самому создавать качественный интерфейс, чтобы он был быстрым, удобным и понятным - тоже весьма непросто. USB, Ethernet - интерфейсы, английский язык - интерфейс, язык C - тоже интерфейс, соглашения вызова функций - интерфейс. Не успеваешь освоить один интерфейс, как жизнь диктует освоение нового, придуманного кем-то. Купили новый осциллограф - получай еще один интерфейс (новый Tectronix до сих пор народ на работе использовать избегают - по причине навороченного интерфейса). Техзадание - опять-таки интерфейс, описывающий взаимодействие между Вами, заказчиком, компьютером и окружающим миром. Чтобы заставить сущности работать на себя, нужно в первую очередь изучить интерфейс общения с этими сущностями. Какие данные нужно подать на вход, и что нужно ожидать получить на выходе, и как это преобразовать, чтобы полученную информацию передать куда-то еще.