xeno_by (xeno_by) wrote,
xeno_by
xeno_by

Мое видение программирования

Этот пост - одна из частей моего рассказа о том, чем я занимался и чему я научился за 2009й год. В индексном посте серии можно прочитать саммари сгенеренного текста и заиметь линки на отдельные посты.

В этом году все с большей силой прояснялся лейтмотив моего творчества, который, в меру понимания жизни на сегодняшний день, я считаю смыслом своего программирования - наиболее выразительно описывать свои мысли в понятном для компьютера виде, а также своим примером помогать это делать другим хуманам (в контексте недавнего дискашена о направленности творчества хочу заметить что последнюю часть предложения о "помогать другим хуманам" я написал здесь сознательно, ибо это действительно созвучно моим мыслям).

Вот почему я тащусь от квиксорта в две строчки (хоть он и не является хорошим примером функционального программирования - спасибо antilamer за это замечание), функциональной композиции и доменно-специфических языков. И поэтому же терпеть не могу низкоуровневые API, на которых пишут живые люди, текстогенераторы и программирование на XML.

Здесь я очень благодарен Саше, который открыл мне глаза на вещи, которые я считал эталоном хорошего программирования - язык C#, дизайн-паттерны, намеренная verbosity в угоду тому, что так делают все. Оказалось, что в мире программирования есть концепции настолько более изящные, что они ставят под сомнение не только целесообразность, но и вообще существование вещей, упомянутых выше. Жаль, конечно, что в рассказе о красивых вещах приходится идти от противного, но так получится ярче всего.

***

Рассмотрим мирок, который буквально лет 5-10 назад активно пропагандировался идеологами разработки софта (к слову, в нем и по сей день находится куча людей, даже не подозревая о том, что они обмануты). Он выражается несложной формулой - "ООП есть инкапсуляция, наследование и полиморфизм, выраженные в статически типизированном языке" и легко транслируется через бложеки, книжки и туториалы. Вроде бы все ничего - писать программы таким образом можно, кастомеры довольны, и все идет по плану. Но при ближайшем рассмотрении альтернативных концепций становится заметно, что системы, разработанные при помощи мейнстримного "ООП" (пишу в кавычках, ибо такое "ООП" - это совсем не то ООП, которое провозглашал Алан Кей) имеют концептуальные недостатки.

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

Соответственно, много эксерсайзов по борьбе с ограничениями "ООП" - абсолютно бессмысленное приложение творческой энергии. При знакомстве в более совершенными концепциями приходит понимание того, что 90% наунов из Джаваланда (очень рекомендую эту ссылку!) отпадают, а набор костылей, широко известный нам под названием Design Patterns, совсем не нужен.

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

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

А ведь прекрасное в программировании это не комбинация уже созданных кем-то абстракций, а создание новых. Сколько уже лет люди писали DAL-ы для джавы и дотнета с использованием "ООП" - все морщились, но для выражения запросов ничего лучшего, чем критерионы, придумать не могли. А вот пришли LINQ-подобные идеи (хз кто тут был первый, ибо кроме линка я знаю как минимум еще одну разработку в этом направлении) и всем сразу стало ясно, как это круче всего, что было раньше.

***

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

Если можно не писать класс, а написать лямбду - пишем. Если можно проанализировать код и что-то вывести вместо того, чтобы писать явно - анализируем и генерим (см. мои каменты к посту Аенде - я там постился под именем Eugene). FluentNHibernate прекрасен. Code as data великолепен. Если какой-то фреймворк или тул для разработки не подходит под этот императив, каким бы он ни был известным или типо крутым - он не рулит, думаем, как это исправить.

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

Естественно, этот взгляд весьма идеалистичен и реальность зачастую вносит свои коррективы (см. каменты Аенде к моим каментам), но что, как не стремление к прекрасному, делает наш мир лучше.

***

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

Это объясняет, почему over-engineering может порождать проблемы. Устраненное дублирование через кучу всяких интерфейсиков и классиков, сценарии юнит-тестов, разнесенные по пачке классов и методов - в большинстве случаев они порождают неприятное ощущение не потому, что содержат один из задокументированных в книжке запахов, а просто потому, что не так выразительны, как их возможные аналоги.
Tags: confession2009, dreams2010
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic
  • 5 comments