Subject: Re: Сравнение по производительности Рефла с другими языкам
From: Mike Potanin (potanin@mccme.ru)
Date: Wed Feb 25 2004 - 18:43:33 MSK
On Wed, 25 Feb 2004 crocodil@croco.net wrote:
> В ООП основное - это смена состояний (об`екта) в ответ на события
> (сообщения). Основа императивного стиля - это смена состояний
> (всей программы или как минимум модуля, поскольку инкапсуляции
> нету) в результате отработки инструкций. И там, и там есть
> понятие состояния. А в логическом и функциональном
> программировании понятия состояния вообще нет. Если оно
> появляется - это уже проникновение императивщины.
Инкапсуляция - вопрос скорее дисциплины, нежели парадигмы.
А состояние в функциональных и логических языках может быть вырадено
адекватно. Наиболее простой способ - уникальные типы Clean и Mercury
(состояние внешней среды передается в функцию и возвращается новое
состояние, а компилятор следит что бы не появилось двух таких состояний).
С помощью некоторого синтаксического сахара программисту не приходится
самому передавать такое состояние. Несколько более сложный механизм -
монады в Haskell. Но и там можно было бы разработать эффективные
инструменты и приемы, если уделить этому хоть часть ресурсов, которые
сейчас вкладываются в ООП.
Кроме того состояние может хранить параллельный процесс, как это
реальзовано в функциональном Erlangе и легко делается на логических
языках.
>
> > Что касается событийно-ориентированности, то объектный стиль здесь
> > является скорее костылем. Обрабатывать события и сообщения прекрасно могут
> > процессы или модули без всякого ООПа.
>
> Конечно могут. А можно, например, писать в машинных кодах. Что
> касается удобства ООП для событийно-управляемых архитектур, то
> косвенным подтверждением этого является, например, то, что
> появление первого ОО-языка совпало с появлением первого оконного
> (текстового, естественно) интерфейса пользователя. И, насколько
А первые летательные аппараты были с подвижным крылом (птицы). Однако
скорость звука они приодолеть так и не смогли, в отличии от жесткого
крыла.
> мне известно, именно оконный интерфейс был изначальной целью
> проекта Smalltalk, а первый в мире об`ектно-ориентированный язык
> оказался побочным эффектом. Как говорится, что выросло, то
> выросло.
>
> > Что бы сами события удобно было
> > представлять ввиде объектов, требуются мультиметоды, а они (из известных
> > мне языков) реалилованы только в Comman Lisp. Без мультиметодов события
>
> Если я только правильно помню, что такое мультиметод (такая
> виртуальная операция, которая выбирается не по одному аргументу,
> а по двум и больше), то, ей-богу, оно требует слишком больших
> усилий при описании, не говоря уже о понимании. Я, честно говоря,
> сомневаюсь, что смог бы кому-то об`яснить, как этим пользоваться.
Основные сложности в событийно-управляемых системах совсем не в реализации
обработки события. Событие еще надо доставить обработчику. В результате
появляются сложные схемы маршрутизации событий и обработчики часто
вынуждены обрабатывать события многих типов. Это приводит к раздутым
интерфейсам этих обработчиков. Мультиметоды бы позвоили описать обработку
конкретного события конкретным обработчиком не усложняя дизайн системы.
>
> > удобнее представлять ввиде прологовских термов (обычная структура данных
> > в современных декларативных языках, правильное название я не помню).
>
> _Правильно_ события вообще не представлять данными. Событие - это
> событие. В ООП оно так и есть (событие есть получение об`ектом
> сообщения, или, иначе говоря, вызов метода об`екта; при этом
> событие совершенно не обязано нести на себе какие-то данные, хотя
> это и возможно -- сообщение может иметь параметры, иначе
> говоря, метод может иметь аргументы).
Событие еще нужно доставить обработчику. А по дороге оно является не более
чем данными.
>
> > Для
> > обработки таких структур данных во всех функциональных языках (кроме Lisp)
> > есть очень удобные средства.
>
> В функциональном языке _не_может_быть_ средства обработки
> события. Потому что нет ни понятия состояния, ни понятия
> побочного эффекта. Кое-как интерактивность сделать в рамках FP
> можно, если ввести ленивые вычисления, но, ей-богу, у меня сия
> концепция в мозгах укладывается с неким трудом.
Концепции не сложные. Если не смотреть на них сквозь объектные шоры.
>
> > Есть даже императивные (Cyclone) и ОО (Pizza)
> > языки, содержащие это расширения.
>
> От того, что в языке есть какие-то "средства", ничего не
> меняется. Определяющим является не общее количество возможностей
> конкретного языка, а тот стиль мышления, который означенный язык
> стимулирует. О событиях мыслить проще в ОО-стиле. И сложнее всего
> - в функциональном, за отсутствием адекватных терминов и по
> причине необходимости прибегать либо к императивным подпоркам,
> либо к совсем уже нетривиальной эмуляции через ленивость.
Проще/сложнее - вопрос привычки.
> > Раздельная компиляция частей программной системы написаных на разных
> > языках - давно существующая технология. Если есть желание, написать часть
> > программы на Lisp часть на C++ и собрать это в одину систему не сложно.
>
> Ага. И как будут представлены те же S-выражения на C++? Какие там
Как указатель на структуру.
> будут соглашения о вызовах и данных? Etc. К тому же мы получаем
Автоматически генерируемые stabы преобразуют соглашения из одного языка в
другой.
> использование в одном проекте двух и более систем
> программирования, что тоже не слишком удобно.
А для описания граматики yacc использовать неудобно, потому что к нему еще
что-то писать приходится.
Удобство определяется исключительно желанием/нежеланием осваивать новые
инструменты.
>
> Как показывает практика, этого всего оказывается достаточно,
> чтобы отказаться от идеи многоязычного проекта. Лично я, как
> можно заметить, писать на Лиспе умею и даже неоднократно страдал
> от невозможности вставить кусок на Лиспе в проект на C++, однако
> же трудности многоязычия меня каждый раз останавливали.
Практика показывает что очень мало систем пишется в срок и без большого
числа ошибок. И язык C++ здесь сыграл не последнюю роль.
>
> > Для этого куча готовых инструментов, от монстров типа CORBA, до
>
> Трудозатраты на поддержку корбовских об`ектов оказываются больше,
> чем экономия на написании некой части на альтернативном языке.
Не такие уж они и большие. Написать и откомпилировать описание интерфейса.
Поддерживать репозитарии интерфейсов и реализаций и прочие сервися в
болшенстве проектов не обязательно.
>
> > простинького swigа или специализированного GreenCard. И неделают это по
>
> Конкретно эти не видел. Ссылочки можно, pls, а то на слово
> GreenCard в-основном проблемы иммиграции в Америку вылезают ;-)
http://www.swig.org/ - для разных языков, в том числе для OCaml и двух
Scheme.
http://www.haskell.org/greencard/ - для взаимодействия Haskell и C.
>
> > тем же причинам, что и не пишут проекты целиком на функциональных языках.
> > Причина - банальное непонимение концепций отличных от ООП-расширения
> > императивной парадигмы.
>
> Вот уж это - совсем вряд ли. Из тех программистов, с которыми мне
> приходилось работать, примерно каждый второй прекрасно знает, что
> такое Лисп и как на нем писать.
Знать и уметь - две больших разницы.
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD