Журнал Витуса

Придется все же вернуться к разбору объектно-ориентированной парадигмы и еще раз уточнить, почему она мне не нравится.

В первую очередь сам термин "объект". Он значит все и ничего. Все - потому что любая сущность, с которой мы оперируем явялется объектом. Ничего - потому что от того, что мы знаем, что это объект, мы фактически ничего об этой сущности не узнаем. Как максимум то, что эту штуку можно унаследовать и переопределить её поведение. И то - как максимум. Внешние по отношению к нашей программе COM или dbus-объекты этим свойством не обладают, а все равно - объекты.

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

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

Вот термин "число" это хороший термин. Зная что это число, мы уже очень много знаем об этом объекте. В частности мы знаем, что это число - объект immutable. Число четыре - всегда число четыре, в какую переменную его не засунь. В ранних версиях Fortran бывали ситуации, когда можно было по ошибке изменить значение константы 4 (отсюда и вопрос в hacker's test, вынесенный в заголовок поста), но это давно исправили.

А вот в ряде языков, которые считаются объектно-ориентированными, путаница между значеним и местом для хранения этого значения, сохраняется до сих пор. Возьмем, например, практически любую библиотеку для работы с длинной арифметикой. Скажем OpenSSL-евскую. Тамошний BIGNUM - это ни разу не число. Это буфер для хранения числа. Его можно изменять. А число изменить нельзя. Можно породить новое, посредством унарной (скажем факториал) или бинарной (скажем умножение) операции с существующими числами, можно присвоить другое значение числовой переменной. Но изменить значение числа нельзя. Оно всегда остается собой. И, собственно этот факт служит основой всей арифметики - науки весьма практически полезной.

Конечно, объектно-ориентированное программирование выросло из потребности моделировать объекты, куда более сложные, чем просто числа. Я уже тут недавно писал, что Симулу-67 изобрели для моделирования транспортных сетей.

Возьмем, к примеру, грузовик. Сегодня у него водитель Иванов, завтра - Петров. Сегодня он везет навоз, завтра - сено, после завтра вообще едет порожняком в областной центр за новой молотилкой.
И тем не менее, это тот же самый грузовик. Можно колесо поменять, но он останется тем же самым. Даже регистрационный номер можно поменять, но все равно это останется тот же самый грузовик. Правда, если мы поменяем двигатель, шасси и прочие нумерованные детали, у ГИБДД уже возникнут вопросы на тему того, тот же самый это грузовик или уже другой.

Кстати, вот эту разницу между объектом и переменной для хранения объекта весьма изящно учел Ларри Уолл в пятом перле. У него объектом становится (посредством применения оператора bless) ссылка на значение - хэш, скаляр или масси. Поэтому объект, пусть даже он вполне mutable, обязательно отвязан от переменной, через которую мы получаем к нему доступ. Видимо, лингвистичекое образование сказывается.

А вот в C++, где объекты выросли из структур данных весьма низкоуровневого языка C, путаница между объектом и местом для хранения - в полный рост. Тем более, наследство C дает в этом языке программисту доступ к менеджменту памяти.

Еще в ООП крайне расплывчата граница между классом и экземпляром класса. Хотя во всех учебниках эту границу пытаются провести, проводится она плохо. Потому что программирование по своей природе это мета-деятельность, составление инструкций для автоматизированного исполнителя. А в инструкциях обычно имеют дело с классами, а не с экземплярами.

В общем, если мы хотим чтобы какая-то фиговина была удобной в употреблении, не надо называть её объектом. Объектом она и так является. А вот если дать её какое-то более узкое имя, то осознать зачем эта фиговина нужна, и чем она отличается от других фиговин (которые тоже объекты) будет проще.

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

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

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

В процессе дискусси про проект UNG высказывались соображения вида "а вот давайте выкинем все языки кроме..." По-моему, это как раз то, чего ни в коем случае не следует делать.
Наоборот, следует постараться обеспечить большее равноправие языков, чем есть сейчас.
Сейчас некоторые языки явно "равнее других". На С можно написать библиотеку, которую можно использовать из любого другого языка. На фортране это уже несколько сложнее. А попробуйте написать библиотеку на Perl, которую будет потом удобно использовать из C. А использовать из Tcl библиотеку на Ocaml? Межъязыковые интерфейсы зачастую оказываются не проще интерфейсов пользователя.

Собственно по-моему это как раз тот фактор, который существенно сдерживает распространение языков высокого уровня. Их трудно комбинировать друг с другом, а каждый из них имеет свою область применения. Куски, написанные на этих языках трудно встраивать в существующие проекты.

Собственно это одна из причин по которым я рассматриваю модель "каждый компонент - отдельный процесс". Это автоматически уравнивает в правах все языки программирования. Ну может кроме Javascript, для которого просто пока не написали командно-строчного интерпретатора с правильной объектной моделью POSIX-окружения.

А напишу-ка я флеймогонный пост.

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

А теперь о том - что делать. Понятно, что прочитав все что ниже, вы скажете что это проект неподъемный. Ну так четверть века назад Столлману то же самое говорили. А у него - получилось.

Итак, переходим к делу. Я утверждаю что проект GNU как таковой - исчерпал себя. Он утонул в собственной сложности. Когда исходник hello world занимает под 200 строк, не считая вспомогательных библиотек для обеспечения переносимости, требует 10000-строчного скрипта для конфигурирования, а весь дистрибутив hello world - 400 килобайтный архив - так жить нельзя. О какой свободе модификации может идти речь, когда для того, чтобы разобраться как программа выводит одну строчку на экран, требуется читать две сотни строк, а для того чтобы разобраться, как это скомпилировать - несколько десятков тысяч?

Сравните с пятью строчками и однострочным Makefile у Кернигана и Ритчи.

Нет, бывает и хуже. Почитавши некоторые исходники OpenSolaris, я понял что Столлман и его последователи поначалу многое сделали для достижения удобопонятности софта. Но потом пришло поколение де-Иказ и Дрепперов.

В общем, похоже как в том позднесоветском анекдоте про Ленина - надо выезжать в Женеву и начинать все с начала.

Пытаться создать новый проект и еще раз реимплементировать POSIX userland. Начиная с libc. Впрочем, тут ембедщики поработали, и можно попробовать взять за основу uclibc.

Естественно, нужно сразу закладываться на то, что в итоге должна получиться система с GUI. Заменять X11 на 8¹/₂ или какой Оберон я пока мысленно не готов. Опять же сетевая прозрачность - штука полезная.

Поэтому понятие сессии нужно сразу закладывать такое, какое сложилось к концу первого десятилетия XXI века в десктопных системах. Так что сессионная шина сообщений (да и системная) нужна. Впрочем проект человекопонятной замены D-Bus я уже публиковал.

Возможно, начинать новый проект надо не с yet another реимплементации coreutils (хотя до этого дело неизбежно дойдет - я не зря начал с описания GNU hello - это наиболее концентрированная демонстрация всех пороков командно-строчных утилит GNU), а с чего-нибудь типа браузера. Поскольку с браузерами положение сейчас наиболее нетерпимое.

Тем более, если удастся разобрать браузер на кучку компонентов, работающих как отдельные процессы, общающихся между собой по удобопонятным протоколам и обрабатывающих ошибки (вплоть до падения в кору) друг друга без ущерба для user experience, это продемонстрирует, что можно делать сложные вещи простыми, понятными и удобными для модификации.

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

Собственно, основные принципы, которым должен следовать данный проект, проистекают из статьи Столлмана Opening the software toolbox про которые большая часть opensource программистов успешно забыли.

1. Каждая компонента делает только одну вещь, но делает её хорошо
2. Должно быть легко понять, как вызвать компоненту, чтобы она сделала то, что тебе нужно. Т.е. библиотека с развесистыми API имеет право на существование в исключительных случаях. В остальных - отдельный процесс, общающийся с другими с помощью легко анализируемого протокола межпроцессного взаимодействия - параметры командной строки, сообщения по сессионной/системной шине, имеющие тот же синтаксис командной строки, данные в очевидно понятном формате по пайпу, shared pixmap etc.
3. Если где-то мы предусматриваем не совсем очевидный формат (типа той же shared pixmap) то сначала мы делаем инструмент, позволяющий этот формат посмотреть, и только потом - компоненты
которые делают с этим что-то осмысленное.
4. Любые тулзы автоматической генерации кода (типа скриптов конфигурирования) должны генерировать код, в первую очередь понятный для человека.
5. Никаких врапперов вокруг компилятора, вроде libtool. Лучше отказаться от поддержки нескольких экзотических платформ, или написать для них отдельный makefile, чем оставить админов и программистов всех остальных платформ наедине с необъятными простынями неудобочитаемого кода с пятью уровнями include. Упрощение жизни сборщика ценой усложнения жизни разработчика - это обмен essential liberty на temporal safety. Тот же сборщик вас потом проклянет, когда выяснится что вы не все предусмотрели и ему надо что-то подкрутить. Кстати, возможно от make стоит сразу отказаться, заменив его на какой-нибудь bras.

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

Общесистемная/общесессионная шина сообщений, по которой приложения могут общаться между собой - штука полезная.
К сожалению, существующий кандидат на роль такой шины - D-Bus обладает рядом недостатков, затрудняющих понимание и использование её авторами приложений, и делающих практически невозможным использование этой технологии пользователями, обустраивающими свою рабочую среду с помощью наколенных скриптов.

Я бы сделал немножко по-другому

( Спецификация E-Bus )

Есть такой анекдот:

Диалог в бюрократическом учреждении:
- Имею ли я право?
- Конечно имеете!
- Так могу ли я?
- Нет, не можете!

Положение дел в области Free Software чем дальше, тем лучше описывается этим анекдотом.
Имею ли я право исправлять глюки и дописывать нужные мне фичи в Mozillу, OpenOffice, ядро Linux, Gimp etc - да сколько угодно. Лицензия позволяет.
Могу ли я? Увы, трудоемкость, необходимая для вникания в большой проект на несколько миллионов строк - соврешенно prohibitive. Даже при наличии квалификации. А протолкнуть свои изменения в upstream - еще сложнее.

Увы, свободу приспосабливать компьютер под наши потребности мы практически потеряли. Большая часть OpenSource продуктов используется так же, как и проприетарные - не как текст, который можно прочитать и адаптировать к своим нуждам, а как черный ящик.

Еще десять лет назад это было не так. Тогдашние OpenSource проекты были достаточно компактны, лучше документированы, и всё необходимое тайное знание содержалось в коде. Было дело в 99-м году я при каждом новом релизе ядра ветки 2.2 внимательно читал патчи чтобы решить - ставить это срочно на боевой сервер или погодить пока.

Сейчас я пожалуй, не пойму в этих патчах почти ничего. большая часть тайного знания необходимого для написания компонент ядра, из кода без больших усилий не извлекается. А отдельных источников этого знания почти и нет. Ну по ядру еще есть. А попробуйте найти вменяемое описание работы с Bluetooth. Содержащее внятные схемы стэка протоколов, описание общей идеологии и того как это раскладывается на API. Не существует такового в природе.

В 80-е годы, когда Столлман начинал проект GNU, взятая за основу модель - утилиты unix общающиеся между собой ыерез пайпы позволяла легко изолировать кусок кода, четко определить что у него на входе, а что на выходе и таким образом легко разобраться в его работе.

Сейчас reusable компоненты как правило делаются в виде динамических библиотек со сложным API. Где-то это реально необходимо, где-то это явный overkill. Особенно если учесть что с первого раза спроектировать хороший API для рещения любой задачи - весьма нетривиально. Поэтому API у многих opensource библиотек плывут. Совершенствуются. Но это приводит к головной боли при поддержке используещих их программ.

Более того, за последние 10 лет в Open Source пришло множество программистов воспитанных на Visual Basic и прочих изделиях Microsoft, где от программиста не предполагается четкого понимания задачи в целом - это понимание - коммерческая тайна Microsoft.
Вот пример в MSDN, делайте по образу и подобию. Воспринимайте эти слова как магическое заклинание, как ритуал.

Но там хотя бы сидят несколько сот человек, которые это дело документируют.

Заметим что микроядро в Hurd было на самом деле нужно не столько по тем техническим соображениям, которые приводил Таннебаум в споре с Линусом, сколько именно из соображений well-defined interfaces, которые позволили бы множеству независимых разработчиков работать над разными подсистемами ядра. Но ни Таннебаум, ни Столлман этого тогда сфонрулировать не могли. Потому что это на самом деле вопрос социальной психологии а не технологии.

Некторые решения, которые уже фактически приняты сообществом как стандарт, иначе как миной замедленного действия под идею свободного софта я назвать не могу. Ну про CUPS уже Раймонд всё написал. Ага, тот самый Раймонд, который выдумал термин Open Source как менее "страшный" чем "Свобода", чем немало способствовал возникновению данного положения. Еще большей миной замедленного действия я считаю D-Bus. Не то, чтобы плоха была самой идеи общесессионной или общесистемной шины сообщения. Но во-первых, реализация - нету стандартного набора утилит для работы с этим из shell. Не отладочних прибабахов вроде dbus-send и dbus-monitor, а полноценных инструментов для работы класса NetCat. Во вторых, документированность. Уже сколько лет в комплекте bluez, который иначе чем через dbus нынче с пинкодами не работает, идет passkey-agent, написанный настолько криво, что при его завершении libdbus ругается на stderr. И никто не соберется исправить.

К сожалению, в 96-97 году, когда начинались проекты KDE и GNOME не нашлось гения, который бы предложил архитектуру GUI-среды, способную развиватья в условиях Free Software, и при этом оставаться простой и понятной. Впрочем, это как раз был переломнымй момент, когда менялись условия Free Software - вместо немногочисленных, но весьма квалифицированных хакеров 80-х, кончавших одни и те же университеты, и понимавших друг друга с полуслова, повалила толпа любителей, осваивавших программирование на персональных компьютерах самостоятельно.

Как теперь из получившейся ямы вылезать я не знаю. Выкингуть существующие миллионы строк кода просто так не получится. Хотя место большей части этого кода - именно на помойке.