Subject: Re: Сравнение по производительности Рефла с другими языкам
crocodil@croco.net
Date: Wed Feb 25 2004 - 17:41:29 MSK
On Tue, 24 Feb 2004, Mike Potanin wrote:
> И вообще, что есть объектно-ориентированность? Классические
> "наследование, полиморфизм, инкапсуляция"? Но все это ни как не связано с
> императивным стилем.
В ООП основное - это смена состояний (об`екта) в ответ на события
(сообщения). Основа императивного стиля - это смена состояний
(всей программы или как минимум модуля, поскольку инкапсуляции
нету) в результате отработки инструкций. И там, и там есть
понятие состояния. А в логическом и функциональном
программировании понятия состояния вообще нет. Если оно
появляется - это уже проникновение императивщины.
> Что касается событийно-ориентированности, то объектный стиль здесь
> является скорее костылем. Обрабатывать события и сообщения прекрасно могут
> процессы или модули без всякого ООПа.
Конечно могут. А можно, например, писать в машинных кодах. Что
касается удобства ООП для событийно-управляемых архитектур, то
косвенным подтверждением этого является, например, то, что
появление первого ОО-языка совпало с появлением первого оконного
(текстового, естественно) интерфейса пользователя. И, насколько
мне известно, именно оконный интерфейс был изначальной целью
проекта Smalltalk, а первый в мире об`ектно-ориентированный язык
оказался побочным эффектом. Как говорится, что выросло, то
выросло.
> Что бы сами события удобно было
> представлять ввиде объектов, требуются мультиметоды, а они (из известных
> мне языков) реалилованы только в Comman Lisp. Без мультиметодов события
Если я только правильно помню, что такое мультиметод (такая
виртуальная операция, которая выбирается не по одному аргументу,
а по двум и больше), то, ей-богу, оно требует слишком больших
усилий при описании, не говоря уже о понимании. Я, честно говоря,
сомневаюсь, что смог бы кому-то об`яснить, как этим пользоваться.
> удобнее представлять ввиде прологовских термов (обычная структура данных
> в современных декларативных языках, правильное название я не помню).
_Правильно_ события вообще не представлять данными. Событие - это
событие. В ООП оно так и есть (событие есть получение об`ектом
сообщения, или, иначе говоря, вызов метода об`екта; при этом
событие совершенно не обязано нести на себе какие-то данные, хотя
это и возможно -- сообщение может иметь параметры, иначе
говоря, метод может иметь аргументы).
> Для
> обработки таких структур данных во всех функциональных языках (кроме Lisp)
> есть очень удобные средства.
В функциональном языке _не_может_быть_ средства обработки
события. Потому что нет ни понятия состояния, ни понятия
побочного эффекта. Кое-как интерактивность сделать в рамках FP
можно, если ввести ленивые вычисления, но, ей-богу, у меня сия
концепция в мозгах укладывается с неким трудом.
> Есть даже императивные (Cyclone) и ОО (Pizza)
> языки, содержащие это расширения.
От того, что в языке есть какие-то "средства", ничего не
меняется. Определяющим является не общее количество возможностей
конкретного языка, а тот стиль мышления, который означенный язык
стимулирует. О событиях мыслить проще в ОО-стиле. И сложнее всего
- в функциональном, за отсутствием адекватных терминов и по
причине необходимости прибегать либо к императивным подпоркам,
либо к совсем уже нетривиальной эмуляции через ленивость.
> > Откуда они там взялись? Возможно, кто-то из более опытных коллег
> > укажет иные причины, но мне основная причина видится в стремлении
> > писать на Лиспе целиком сложные программы. В том числе и
> > программы с пресловутыми GUI, и т.п. Т.е. позиционировать Лисп
> > как универсальный язык программирования. В итоге и язык
> > оказывается засорен непойми чем, и до роли универсального
> > средства он так и не дотягивает, ибо просто по закону больших
> > чисел в серьезном проекте не может оказаться достаточного
> > количества задач, на которых оный Lisp удобен.
>
> Раздельная компиляция частей программной системы написаных на разных
> языках - давно существующая технология. Если есть желание, написать часть
> программы на Lisp часть на C++ и собрать это в одину систему не сложно.
Ага. И как будут представлены те же S-выражения на C++? Какие там
будут соглашения о вызовах и данных? Etc. К тому же мы получаем
использование в одном проекте двух и более систем
программирования, что тоже не слишком удобно.
Как показывает практика, этого всего оказывается достаточно,
чтобы отказаться от идеи многоязычного проекта. Лично я, как
можно заметить, писать на Лиспе умею и даже неоднократно страдал
от невозможности вставить кусок на Лиспе в проект на C++, однако
же трудности многоязычия меня каждый раз останавливали.
> Для этого куча готовых инструментов, от монстров типа CORBA, до
Трудозатраты на поддержку корбовских об`ектов оказываются больше,
чем экономия на написании некой части на альтернативном языке.
> простинького swigа или специализированного GreenCard. И неделают это по
Конкретно эти не видел. Ссылочки можно, pls, а то на слово
GreenCard в-основном проблемы иммиграции в Америку вылезают ;-)
> тем же причинам, что и не пишут проекты целиком на функциональных языках.
> Причина - банальное непонимение концепций отличных от ООП-расширения
> императивной парадигмы.
Вот уж это - совсем вряд ли. Из тех программистов, с которыми мне
приходилось работать, примерно каждый второй прекрасно знает, что
такое Лисп и как на нем писать.
С наилучшими,
Андрей Столяров
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD