<<<предыдущий список следующий>>>

Это - копия документа, находившегося на http://dz.ru. Авторские права, если не указано иначе, принадлежат Дмитрию Завалишину и/или Евгении Завалишиной. Все изменения, внесенные мной, находятся в этой рамочке.Пожалуйста, прочитайте disclaimer.


7 февраля

Компания Be ещё раз определилась со взглядами на своё будущее. Напомню, изначально она занялась разработкой компьютера Be Box и системы для него - BeOS. Всё это было сделано, но в некоторый момент выяснилось, что производить новую разновидность компьютерной платформы дорого, это не очень окупается и, в целом, не совсем понятно, зачем нужно - производителей компьютеров много, есть, из чего выбрать.

Правда, мне лично Be Box был весьма симпатичен. Была в нём прелесть, была. Ну да ладно - теперь он принадлежит истории. Be от него отказалась, сконцентрировавшись на ОС.

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

Отложив в сторону никому за пределами программерской тусовки непонятные изречения типа "ос с объектным API" маркетёры Be справедливо решили, что нужно назвать какое-то понятное людям свойство системы, и на него напирать. Итак, BeOS стала Media OS. Если быть проще - системой, в которой хорошо работать с аудио и видео.

Некоторый резон в этом есть. BeOS не так корява, как до сих пор базирующиеся на MS-DOS форточки серии 95-98-Millenium (Windows ME, точнее), не так тяжеловесна, как NT, и не так архаична в основе, как Unix.

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

Отныне Be будет выпускать OS для того, что называется internet appliances. Это, впрочем, не противоречит предыдущей цели - показ видео и прокрут аудио вполне уместны в новом применении, а компактность ОС и лёгкость программирования под неё, добротный и симпатичный интерфейс пользователя и наличие наработок делают систему довольно привлекательной. Даже при том, что конкурентов - хоть отбавляй.

Кстати, возвращаясь к недавнему разговору о Юниксе и красоте ОС. Победное шествие Юникса, я уверен, было обусловлено тем, что он вобрал в себя лучшее, что было придумано к тому времени, и кристаллизовал это всё, воплотив в компактном, лаконичном и цельном виде. Не секрет ведь, что ничего нового в Юниксе в момент его рождения не было - все идеи взяты из других работ. Тем не менее, это было событием - он подвёл черту под всем придуманным до, и потому стал классикой.

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

Когда тошнит от дерева...

   
From: Dmitri Startsev
Subject: lseek() vs. OO. Maybe classless objects?

"А вот когда кто-то ругает C++ и хвалит Юникс можно отметить любопытную деталь. "Дикая", неформализованная и неназванная объектная ориентированность, которая ярко присуща Юниксу, многим апологетам очень нравится. Именно её они называют красотой - обобщённые механизмы взаимодействия, вразумительно классифицированные сущности - всё приятно глазу и душевно. Вот если сказать, что Юникс хорош тем, что lseek позволяет позиционироваться хоть в файлах, хоть в дисках целиком - это понятно и лепо. А если сказать, что lseek - метод класса random_access_data, от которого порождаются классы disk_file и special_device_with_random_access - это фу, это вонючий плюсплюс с ООшными наворотами попёр. Сакс и мастдай, некрасиво. Хотя тождественно равно, за исключением того, что второй вариант - чуть более цивилизованный."

А вот как бы обойтись без иерархии классов? Ну влом мне выстраивать все объекты реального мира в дерево классов! А особенно не нравится то, что иерархия вообще говоря может быть произвольной и проектировать ее надо заранее. Может быть проще? Например объект обладает совокупностью свойств и интерфейсов. Если нужно поуправлять этим объектом - сначала выясняем в рантайме, поддерживает ли он необходимые интерфейсы, а потом, чтобы не выяснять это каждый раз, "компилируем" этот вызов на ходу, "связываем" объекты  и дальше работаем уже быстро, пока это возможно. Очень может быть, что именно так устроена модель COM у Microsoft, хотя у меня все руки не доходят почитать нужную книжку. А от дерева классов меня тошнит. Отдает какой-то дурной бесконечностью и "хрупкостью" построений.  

 

Тёзка, когда Вы говорите о том, что Вас тошнит от дерева классов, что именно Вы имеете в виду?

А. Вас тошнит от того факта, что lseek равноценно применим к нескольким разным сущностям? Классы ведь появляются не от злой воли программиста, заторчавшего на ОО, и не от использования ключевого слова class, и не от применения ОО-ного языка. Класс появляется тогда, когда вы начинаете обобщать. Когда вы говорите - вот это у нас - файлы, а это - пайпы. И всё, родились два класса. А напишете вы потом слова "class file; class pipe;" или нет - это вопрос чисто изобразительный. Так что - Вы против самой классификации вообще? Перенумеруем всё вокруг и торжественно поклянёмся не замечать у объектов наличия общих свойств?

Б. Или Вас напрягает необходимость проектировать программу, перед тем, как её писать? Действительно, объектный код этим сильно раздражает - вынуждает не сесть лепить код с первого дня, а 70% времени потратить на создание проекта, и только потом - писать сам код. И довольно тривиальный. Но вообще-то, если по хорошему, необъектный код точно так же надо сначала проектировать, а потом писать. И задачи при этом нужно решать те же. Если, собственно, напрягает проектирование, то, наверное, его нужно отдать на откуп другому человеку, а самому заниматься лишь кодерством - отдохнуть душой и телом.

Третьего, увы, не дано. Если Вам думается, что на свете бывают classless objects, попробуйте найти хоть один такой в окружающем мире. Это невозможно, так как классификация - свойство не объектов, а человеческого разума, сам принцип познания. Без неё не бывает (известной нам разновидности) разума.

О, вот, спасибо Яндексу, он нашёл мне то, что нужно. Я предположил, что Выготский не мог не сказать ничего на нужную мне тему. Правда, конкретная цитата принадлежит К. И. Алексееву, но без Выготского не обошлось :-), и вообще - очень кстати:

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

И это - приговор. От реального существования как-то ещё можно уйти, а от мышления не уйдёшь. :-)

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

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

Стоит лишь задуматься, зачем в Си ввели (его не было изначально) ключевое слово union и какова идея, стоящая за Паскалевскими (и не только) записями с вариантами. Смотрите:

struct A { union { struct B; struct C; }}

это "дикий" эквивалент записи

class B : public A;
class C : public A;

То есть мы имеем некоторое общее свойство A, и два наследующих его варианта B и C. В Паскале это сделано чуток культурнее, а наличие оператора with сильно облегчает работу с "дикими" подклассами, которые при необходимости выделяются этим оператором из массы. Это ещё раз к слову о том, что классы, наследование не привнесены ОО языками, а лишь озвучены, поименованы ими. Думать, что их не было до появления объектных языков - всё равно, что думать, что синего цвета не было до появления слова "синий". Или blue... не важно.