Ильф и Петров — Великого Комбинатора.
Та эпоха уже закончилась, эта — еще не началась.
Повсюду одно и то же: любое явление можно продолжать делить… нет, не до бесконечности, а до «атомов», которые получили такое название потому что, переводя дословно, «неделимы». Речь далеко не только про программирование: например, музыка и Бетховена, и Шнурова раскладывается всего лишь на семь основных нот и еще пять безымянных; кажущиеся незаконченными очерки Чехова, многословные романы Толстого, скупые и хмурые постулаты Эвклида раскладываются на не такое уж и большое количество букв. И так буквально во всем.
Не даром в Русском языке слово «сложный» есть сокращенное «сложенный»: потому что сложные («неатомарные») явления складываются из простых, атомарных. Причем складываются по вполне определенным законам — познанным или нет, но существующим объективно. Даже хаос статистически отличим от другого хаоса и в этом смысле есть разновидность порядка. Отсюда следует эпохальный вывод:
Акт познания двояк: это 1) и безостановочный поиск атомов, примитивов, первоэлементов, из которых можно что-либо собирать, и 2) не менее усердный поиск законов, определяющих что именно и с чем именно, и как именно соединяется.Программирование это акт познания. По меньшей мере, задачи, которую необходимо решить. На самом деле хороший программист ищет не только решение конкретной задачи, но (возможно, бессознательно; чаще же — осознанно) жаждет еще и освобождающего обобщения — "во всем ему хочется дойти до самой сути", до системообразующих принципов, сформулировать их насколько сможет четко и лаконично, и понести этот огонь дальше, и зажечь им других.
Поэтому война парадигм — как например ООП vs ФП или фашизм vs коммунизм — всегда война атомная в том смысле, что это сражение ведется в первую очередь именно за атомы, на уровне атомов и атомами, а не за более сложные — производные от атомов — конструкции и уж тем более не ими.Вместе с тем с точки зрения практики сами по себе атомы — бесполезны. Зачем палитра насыщенных красок, если нет художника, способного нарисовать завораживающую картину? Слышите звенящую тишину вокруг? Это мир замер в ожидании нового Великого Комбинатора — того, которому покорится сложность цифровых систем XXII века!
Моя карьера программиста начиналась с идей, заложенных в основу объектной ориентированности в ее нынешнем — изуродованном временем и business value — виде: в качестве атомов, мне обещали классы, которые инкапсулируют состояние и выставляют наружу только то, что дозволено; а полиморфизм и наследование мне выдавали за правила, по которым я могу управляемо наращивать сложность. Поначалу я поверил, но неизбывное ощущение, мол, «матрица не в порядке» усиливалось, и я решился на открытое плавание. Вскоре, скитаясь тут и там, случайно наткнулся на задолго до меня открытый континент под названием «функциональное программирование». Теперь моим примитивом стала функция, чья сигнатура нашептывает свою особенную историю. У меня (почти) нет состояния, мне в общем-то нечего скрывать и потому проблема инкапсуляции меня не беспокоит. В качестве комбинаторов мне предложены одноименные операторы композиции — очевидные, простые и неимоверно мощные. Но то ощущение почему-то не проходит…
Вот она — моя Атомная Третья Мировая:
IT как профессия, как дело жизни еще непозволительно молодо: медицине понадобилось лет двести, что утвердить самые базовые правила гигиены и врачебной дисциплины.Мы сейчас переживаем нечто похожее: препарируем трупов, павших в кровопролитных сражениях с избыточной сложностью, и вслепую наощупь выискиваем седьмое доказательство Бога; легки на суеверия и фанатизм, залечиваем недуги заклинаниями, обрядами и копипастой. Пенициллины еще не изобретены. В это нелегкое время нам жизненно необходим спор о сложности — в духе Сократовской диалектики, мы должны задавать себе наводящие вопросы и, в попытке ответить, целенаправленно доходить первопричин. Этих плодотворных душеспасательных бесед не достает настолько сильно, что иной раз на очередном бессмысленном митинге по дизайну для yet another one системы с плохо определенными ответственностью и инвариантами поведения становится душно и снова невольно вспоминаешь Федора Михайловича: «прежде всего воздуху нужно».
surVrus
Это уже примитивно и неактуально.
Вполне достаточно использовать теорию систем, системный подход.
В промышленном проектировании давно нашли оптимум вежду объектным и функциональным представлением моделей. Подробно этому посвящена серия стандартов ISO 81346.
Суть простая: на начальном этапе, при проектировании, статическая модель строится в виде набора действий (процессов, функций) выраженных в виде глаголов. Например, в химическом производстве это элемент модели «перекачивание». Чем качаем — а фиг его знает, пока не важно.
Потом, на следующих этапах цикла разработки часть процессов заменяется на объекты, выраженные уже существительными. Например, процесс «перекачивание» заменяется на «насос». В модели есть и «процессы», и «объекты» одновременно.
До какой степени детализировать (делить)? До какой удобно и понятно. Часть элементов модели делиться до винтиков и гаек, часть — до готовых изделий, часть остается в виде одного «черного ящика». Для каждого элемента модели можно по-разному.
Весь этот зоопарк спокойно живет в виде кучи моделей в единой системе. Например, это ePlan. Суть этой софтины простая: в базе висят все элементы системы, плюс все связи между ними. Связи выражены через кучу разных схем, диаграмм, списков. В общем, с какой удобно стороны смотреть на систему (частные модели с определенной точки зрения) — так и видно, так и можно делать. Причем схемы и графики вторичны. То есть нельзя ничего просто нарисовать или соединить. Надо создать элементы системы, создать связи, тогда появится графическое представление.
Ничего необычного, ничего нового, все давно известно в любой IDE для программирования.
Только программы — это в основном некий текст на более-менее натуральном языке.
А тут немного иное представление, не текстовое.