Subject: Re: Сравнение по производительности Рефала с другими языками
From: Sergei Romanenko (roman@integrum.ru)
Date: Fri Feb 27 2004 - 15:28:15 MSK
Добрый день!
----- Original Message -----
From: "Mike Potanin" <potanin@mccme.ru>
To: "Refal" <refal@botik.ru>
Sent: Friday, February 27, 2004 12:25 PM
>> А ядро операционной системы - это как раз компактная штука (по
>> сравнению со всем остальным),
> Монолитное ядро, каким оно является в большенстве современных
> систем - сооружение очень большое.
Большое. Но, не "по сравнению со всем остальным" (как я предусмотрительно
уточнял).
Как-то раз мы (М.Р.Ковтун, Арк.В.Климов, я и др.) изготовили СПО
"Экономика". Это сооружение включало в себя многотерминальную операционную
систему и набор прикладных программ. И ядро операционной системы было самой
изящной, но далеко не самой объемной частью.
> но, в то же время, есть смысл сидеть и его тщательно
> вылизывать. И некоторые спецы посвящают свою жизнь именно этой,
> одной-единственной задаче: сидят и годами полируют одно ядро одной
> системы. При таких условиях становится уже не очень важно, на чем это
> ядро писать. Если ядро живет 30 лет, оно, по-определению, должно быть
> написано на языке 30-летней свежести.
Как я понимаю, эти пункты не вызвали никаких возражений.
> Более того - объектно-ориентированное. Там явно используются все
> ОО-приемы, включая множественное насследование (в
> частности в реализации) файловых систем в FreeBSD.
Да, по сути оно объектно-ориентированное, поскольку большинство услуг,
предоставляемых ядром, наиболее адекватно описываются в
объектно-ориентированных понятиях. Но маразм в том, что форма предоставления
этих услуг, как правило, не является объектной.
Например, файл, по смыслу, является объектом, но когда я "открываю файл", я
получаю от ядра не "объект" (в смысле языка программирования), а handle,
какое-то непонятное целое число. А потом, конечно, в программе этот handle
можно обернуть в какой-то объект. Но ведь это какое-то извращение:
фактически имеем "объект" в ядре, потом высовываем клиенту ядра handle, а
потом он обертывает этот handle в другой объект.
В этом смысле и Unix, и Win32 находятся на "пещерном" идеологическом уросне.
В BeOS, вроде бы, дело обстоит лучше, но индустриальные монстры сумели
вовремя сговориться между собой и придушить опасное для них начинание. Ну,
это - примерно как в американской политике: есть Республиканская и есть
Демократическая партии. Между собой они грызутся, но если появляется третий,
"независимый" кандидат в президенты, тут же сговариваются между собой, и
начинают дружно его душить.
> Более того, реализация наследования в VFS менее эффективна, чем это
> делает компилятор C++. Отказ от C++ был мотивирован соображениями
> стиля. Хорошую программу на C++ написать в 4 раза легче, чем на plan C.
> Плохую - в 32. FreeBSD Core Team испугались именно легкости, с которой
> пишутся плохие программы.
Да-с... Это соображение того типа, что маленьким детям можно, в качестве
игрушек, давать деревянные палки, но не следует давать огнестрельное оружие.
Это, конечно, разумный подход. Но из него не следует, что палка - это более
эффективное оружие, чем пистолет. И когда дело доходит до "серьезных"
разборок между "серьезными" дядями, огнестрельное оружие все же
используется.
Хотя, конечно, C++ - это штука с "легким спуском" и без предохранителя
(всегда может выстрелить прямо в кармане хозяина в его же ногу).
>> Кроме того, система понятий, заложенная в Unix (или в вариацию на его
>> тему - Win32), не является объектной. Поэтому как бы и не возникает
>> потребности в языке, который бы позволял в этих понятиях работать.
Здесь ключевой является оговорка "как бы". Ведь если при открытии файла я
получаю не объект, а какой-то handle, то я все равно не могу с ним работать
как с "нормальным" объектом. Тогда вроде бы и объектный язык не очень
нужен... А если язык - все же объектный, тогда требуется куча дурацких
телодвижений по обертыванию handle-а в объекты.
> Сама концепция файла уже шаг в сторону ООП. Общий интерфейс
> поддерживают самые разные объекты, начиная от дисковых файлов
> и кончас сетевыми соединениями и терминалами.
Бесспорно! Поэтому, когда прикладная программа сидит поверх изначально
"объектной" платформы (вроде Java или .NET), то при обращении к платформе
она сразу же получает "объекты". Поэтому не возникает вопрос, на каком языке
писать: C или C++ (имеется в виду С++ c Managed Extensions). Ведь если в
ответ на обращения к платформе я получаю "объект", то тогда, чтобы избежать
(из "идеологических" соображений) работы с объектами в прикладной программе,
придется делать "антиобъектную" обертку для платформы (чтобы обертка прятала
объекты в себе, а наружу высовывала их handle-ы)!
Поэтому, если приложение сидит поверх "необъектной" платформы, уже из-за
самого этого факта ценность "объектности" языка программирования
искусственно, принудительно снижается.
Сергей
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD