Subject: Re: Сравнение по производительности Рефла с другими языкам
From: Mike Potanin (potanin@mccme.ru)
Date: Tue Feb 24 2004 - 12:30:30 MSK
On Sun, 22 Feb 2004 crocodil@croco.net wrote:
>
> On Sat, 21 Feb 2004, Sergei M. Abramov wrote:
>
> > > В частности: задачи построения событийно-управляемых приложений,
> > > в т.ч. GUI - это однозначно объектно-ориентированная область,
> >
> > Однозначно? То есть, либо Tcl/Tk объектно-ориентированный, либо оно не для
> > GUI?
>
> Мммм... я бы сказал, что в моей фразе ключевым моментом была
> событийно-ориентированность. Tcl/Tk позволяет построить GUI, но я
Хорошо. Erlang чем не событийно-ориентированный? GUI на нем пишут редко,
но системы управления (для которых он создавался)
событийно-ориентированные в еще большей степени.
И вообще, что есть объектно-ориентированность? Классические
"наследование, полиморфизм, инкапсуляция"? Но все это ни как не связано с
императивным стилем. Так наследование и полиморфизм прекрасно используется
в "классах типов" в языках Haskell и Mercury, а наследование типов - в
O'Haskell и OCaml. Орератор new? Но как раз в декларативных языках
постоянно создаются новые объекты, от CONS в Lisp и термов в Prolog.
Что касается событийно-ориентированности, то объектный стиль здесь
является скорее костылем. Обрабатывать события и сообщения прекрасно могут
процессы или модули без всякого ООПа. Что бы сами события удобно было
представлять ввиде объектов, требуются мультиметоды, а они (из известных
мне языков) реалилованы только в Comman Lisp. Без мультиметодов события
удобнее представлять ввиде прологовских термов (обычная структура данных
в современных декларативных языках, правильное название я не помню). Для
обработки таких структур данных во всех функциональных языках (кроме Lisp)
есть очень удобные средства. Есть даже императивные (Cyclone) и ОО (Pizza)
языки, содержащие это расширения.
> Вот есть язык Лисп. Совершенно ясно, что существует множество
> задач, на которых Лисп просто великолепен. Теперь посмотрим на
> Common Lisp the Language, ed.2. 1029 страниц. Чего там только
> нет, в язык проникли не только откровенно императивные элементы,
> но даже ОО-составляющая (CLOS). Наличествуют массивы, структуры и
> прочие совершенно нелисповские средства.
>
> Откуда они там взялись? Возможно, кто-то из более опытных коллег
> укажет иные причины, но мне основная причина видится в стремлении
> писать на Лиспе целиком сложные программы. В том числе и
> программы с пресловутыми GUI, и т.п. Т.е. позиционировать Лисп
> как универсальный язык программирования. В итоге и язык
> оказывается засорен непойми чем, и до роли универсального
> средства он так и не дотягивает, ибо просто по закону больших
> чисел в серьезном проекте не может оказаться достаточного
> количества задач, на которых оный Lisp удобен.
Раздельная компиляция частей программной системы написаных на разных
языках - давно существующая технология. Если есть желание, написать часть
программы на Lisp часть на C++ и собрать это в одину систему не сложно.
Для этого куча готовых инструментов, от монстров типа CORBA, до
простинького swigа или специализированного GreenCard. И неделают это по
тем же причинам, что и не пишут проекты целиком на функциональных языках.
Причина - банальное непонимение концепций отличных от ООП-расширения
императивной парадигмы.
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD