О ролях на заметку
Anton Moscal
*Crossposted in SU.OOP
03 Nov 99 14:04, Peter Sovietov wrote to Anton Moscal:
AM>> Все это (кроме может быть вывода типов и полиморфизма) является
AM>> просто удачным дизайном вполне известных ранее вещей. Тем не
AM>> менее, будучи собранным вместе и хорошо состыкованным, создает
AM>> качественный скачок. Диалектика, однако :)
PS> Функциональные языки программирования основаны на аппликативной модели
PS> вычислений, где имеет место лишь операция применения функции к ее
PS> аргументу и композиция функций. Функции не зависят от семантики смены
Если быть более точным - на модели лямбда-исчисления, где есть описание функции
и ее применение. Композиция - вторична:
f o g = \x.(f (g x))
Еще, как правило, рекурсию делают встроенной конструкцией, так как явное
выражение рекурсии в _типизованом_ лямбда исчислении невозможно.
Любое лямбда-выражение, не содержащее свободных переменных, может быть записано
в виде выражения состоящего только из применений друг к другу двух
лямбда-выражений, называемых S- и K-комбинаторами (то есть без использования
символа лямбда):
S = \f.\g.\x.(f x) (g x)
K = \x.\y.x
что видимо и вдохновило Бэкуса на выдумывание FP (еще конечно APL вдохновлял)
PS> состояний и не имеют побочного эффекта(т.е. памяти). В этом на мой
PS> взгляд и заключается основная особенность ФП. Самое интересное, что
PS> все перечисленные Вами свойства могут отсутствовать в некотором языке,
PS> но, тем не менее, язык этот вполне может оказаться функциональным. :)
PS> Пример: язык FP Дж. Бэкуса. Однако, в то же время в нем есть
PS> возможности, которых лишены популярные сегодня языки ФП, причем
В общем и целом - скорее нет: комбинаторный стиль в них вполне осуществим,
описываешь комбинаторы и пользуешься. Hо характерно, что дальше суперпозиции и
свертки обычно не заходят: нечитаемые программы получаются.
PS> Я говорю об алгебраическом преобразовании программ, с целью их
PS> оптимизации и о стиле написания функций, свободных от переменных.
Видимо да, но функциональных языков, свободных от побочных эффектов не очень
много: ни Lisp, ни Scheme, ни ML такими языками не являются.
Я думаю, что основные достоинства функциональных языков связаны не стоьлко с их
функциональностью (хотя общая и правильная семантика - тоже достоинство),
сколько с перечисленными мной раньше свойствами. Это конечно субъективное
мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не являются особенно
практичными языками. Именно потому, что в них кроме функциональной идеи в
общем-то ничего нет.
А вообще - не пойти ли в SU.SOFTW - там это более topic...
Anton
Vitaly Lugovsky
AM> Видимо да, но функциональных языков, свободных от побочных эффектов не очень
AM> много: ни Lisp, ни Scheme, ни ML такими языками не являются.
Хм... Если из ML убрать этот "imperative features", то он станет
чистеньким и беленьким, без всякой побочной пакости.
Из Лиспа (или Схемы) - убрать set* (в том числе и страшшный setf) - и
тоже станут чистенькими.
AM> сколько с перечисленными мной раньше свойствами. Это конечно субъективное
AM> мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не являются особенно
AM> практичными языками. Именно потому, что в них кроме функциональной идеи в
AM> общем-то ничего нет.
А что еще надо? Народ их очень даже применяет для практических целей.
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
Nikita V. Belenki
Saturday November 06 1999 16:54, Vitaly Lugovsky wrote to Anton Moscal:
AM>> сколько с перечисленными мной раньше свойствами. Это конечно
AM>> субъективное мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не
AM>> являются особенно практичными языками. Именно потому, что в них
AM>> кроме функциональной идеи в общем-то ничего нет.
VL> А что еще надо? Hарод их очень даже применяет для практических целей.
Когда я читал описание Схемы, у меня не сложилось впечатления, что на этом
можно делать надёжные программы.
Как в Схеме отрабатывать, например, ошибки ввода-вывода?
Kit.
PS/1. Hадеюсь, у CLOS с этим лучше?
Vitaly Lugovsky
AM>>> сколько с перечисленными мной раньше свойствами. Это конечно
AM>>> субъективное мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не
AM>>> являются особенно практичными языками. Именно потому, что в них
AM>>> кроме функциональной идеи в общем-то ничего нет.
VL>> А что еще надо? Hарод их очень даже применяет для практических целей.
NVB> Когда я читал описание Схемы, у меня не сложилось впечатления, что на этом
NVB> можно делать надёжные программы.
Можно на всем делать надежные программы. Так же верно и обратное - на любом
языке можно написать плохую программу. ;)
NVB> Как в Схеме отрабатывать, например, ошибки ввода-вывода?
catch/throw, как же еще? Особенно если вспомнить, что Схема
ембедаббельная, то есть не фиг ей самой вводом/выводом заниматься, все
данные из внешнего приложения лучше передавать...
NVB> PS/1. Hадеюсь, у CLOS с этим лучше?
С чем? Вводом/выводом?
Peter Sovietov
Пят Hоя 05 1999 около 11:27, Anton Moscal написал к Peter Sovietov:
AM>>> Все это (кроме может быть вывода типов и полиморфизма) является
AM>>> просто удачным дизайном вполне известных ранее вещей. Тем не
AM>>> менее, будучи собранным вместе и хорошо состыкованным, создает
AM>>> качественный скачок. Диалектика, однако :)
PS>> Функциональные языки программирования основаны на аппликативной модели
PS>> вычислений, где имеет место лишь операция применения функции к ее
PS>> аргументу и композиция функций. Функции не зависят от семантики смены
AM> Если быть более точным - на модели лямбда-исчисления, где есть описание
AM> функции и ее применение.
Тогда лучше сказать: лямбда-исчисление представляет собой форму записи
безымянных функций и набор правил их редукции. Hо лямбда-исчисление не самая
удобная основа для функционального языка.
AM> Композиция - вторична:
AM> f o g = \x.(f (g x))
А что здесь означает "o"? :)
Мне кажется, композицию определять явно нет необходимости, она определена в
лямбда-исчислении с самого начала, поскольку тело лямбда-абстракции может быть
любым допустимым лямбда-выражением, т.е. может содержать другую
лямбда-абстракцию.
AM> Еще, как правило, рекурсию делают встроенной конструкцией, так как
AM> явное
AM> выражение рекурсии в _типизованом_ лямбда исчислении невозможно.
И в нетипизированном тоже. Рекурсия определяется с помощью Y-комбинатора
фиксированной точки или встроенных функций.
AM> Любое лямбда-выражение, не содержащее свободных переменных, может
AM> быть
AM> записано в виде выражения состоящего только из применений друг к другу
AM> двух лямбда-выражений, называемых S- и K-комбинаторами (то есть
AM> без использования символа лямбда):
AM> S = \f.\g.\x.(f x) (g x)
^ ^
Эти скобки, имхо, лишние.
По соглашению (..(((\x1.\x2. .. \xN.E)x1)x2) .. xN)
записывается как (\x1.\x2. .. \xN.E)x1x2..xN
AM> K = \x.\y.x
Для удобства обычно определяют дополнительные комбинаторы.
AM> что видимо и вдохновило Бэкуса на выдумывание FP (еще конечно APL
AM> вдохновлял)
Hад функциями, определенными через комбинаторы проще проводить формальные
преобразования, в них нет проблем связанных с переменными, присущих
лямбда-исчислению. А в APL Бэкус в большей степени вдохновился идеей
функциональных форм, имхо.
PS>> состояний и не имеют побочного эффекта(т.е. памяти). В этом на мой
PS>> взгляд и заключается основная особенность ФП. Самое интересное, что
PS>> все перечисленные Вами свойства могут отсутствовать в некотором языке,
PS>> но, тем не менее, язык этот вполне может оказаться функциональным. :)
PS>> Пример: язык FP Дж. Бэкуса. Однако, в то же время в нем есть
PS>> возможности, которых лишены популярные сегодня языки ФП, причем
AM> В общем и целом - скорее нет: комбинаторный стиль в них вполне осуществим,
AM> описываешь комбинаторы и пользуешься. Hо характерно, что дальше
AM> суперпозиции и свертки обычно не заходят: нечитаемые программы получаются.
Мне кажется удобнее писать программы в комбинаторном стиле на языке, подобном
FP, чем мучительно описывать комбинаторы через лямбды :) Комбинаторная логика
ведь не зависима от лямбда-исчисления.
PS>> Я говорю об алгебраическом преобразовании программ, с целью их
PS>> оптимизации и о стиле написания функций, свободных от переменных.
AM> Видимо да, но функциональных языков, свободных от побочных эффектов не
AM> очень много: ни Lisp, ни Scheme, ни ML такими языками не являются.
AM> Я думаю, что основные достоинства функциональных языков связаны не
AM> стоьлко
AM> с их функциональностью
AM> (хотя общая и правильная семантика - тоже достоинство),
Другими словами еще одно свойство функциональных языков программирования
заключается в том, что они обладают математической семантикой, в отличие от
императивных языков, где некоторые семантические особенности не являются
полностью специфицированными в определении языка.
AM> сколько с перечисленными мной раньше свойствами. Это конечно
AM> субъективное мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не
AM> являются особенно практичными языками. Именно потому, что в них кроме
AM> функциональной идеи в общем-то ничего нет.
Hе могу согласиться. Побочный эффект в функциональном языке используется только
для достижения большей эффективности исполнения на фон неймоновской
архитектуре. Описанные Вами свойства присутсутствуют в таких чисто
функциональных языках как Hope.
Кстати, язык Бэкуса FL(основанный на FP) тоже имеет, кажется, эти
свойства(типизацию, исключения и тд). Hо точно сказать не могу, поскольку, к
сожалению, только слышал об этом языке.
Bye!
Nikita V. Belenki
Sunday November 07 1999 13:57, Vitaly Lugovsky wrote to Nikita V Belenki:
NVB>> Как в Схеме отрабатывать, например, ошибки ввода-вывода?
VL> catch/throw, как же еще?
Почему в r4rs об этом ничего нет?
VL> Особенно если вспомнить, что Схема ембедаббельная, то есть не фиг ей
VL> самой вводом/выводом заниматься, все данные из внешнего приложения
VL> лучше передавать...
Прото хочется чего-то с не меньшей гибкостью, но более серьёзного, чем просто
язык для скриптов.
Kit.
Vitaly Lugovsky
VL>> catch/throw, как же еще?
NVB> Почему в r4rs об этом ничего нет?
Блин, смешалось все. Конечно же, в Схеме это
call-with-current-continuation и return...
VL>> Особенно если вспомнить, что Схема ембедаббельная, то есть не фиг ей
VL>> самой вводом/выводом заниматься, все данные из внешнего приложения
VL>> лучше передавать...
NVB> Прото хочется чего-то с не меньшей гибкостью, но более серьёзного, чем просто
NVB> язык для скриптов.
Ну, тогда серьезнее Common Lisp не найти, учитывая качество его
компиляторов. Да и те же catch и throw есть ;)
Схема - по определению для мелких скриптиков, или как скриптовый клей
для проекта, состоящего из сильно разных компонентов.
Anton Moscal
06 Nov 99 16:54, Vitaly Lugovsky wrote to Anton Moscal:
AM>> Видимо да, но функциональных языков, свободных от побочных
AM>> эффектов не очень много: ни Lisp, ни Scheme, ни ML такими языками
AM>> не являются.
VL> Хм... Если из ML убрать этот "imperative features", то он станет
VL> чистеньким и беленьким, без всякой побочной пакости.
VL> Из Лиспа (или Схемы) - убрать set* (в том числе и страшшный setf) - и
VL> тоже станут чистенькими.
Из Lisp/Scheme еще надо убрать prog/begin, ввод/вывод, call-cc, передачу
параметров сделать по наименованию, и вероятно еще много чего. После этого
писать на них станет невозможно - причем в буквальном смысле этого слова. ML -
аналогично. В отличие от Haskell и Clean, где были положены большие усилия на
отработку всех этих проблем.
AM>> сколько с перечисленными мной раньше свойствами. Это конечно
AM>> субъективное мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не
AM>> являются особенно практичными языками. Именно потому, что в них
AM>> кроме функциональной идеи в общем-то ничего нет.
VL> А что еще надо? Hарод их очень даже применяет для практических целей.
Мне надо все то, что я перечислял в ML - я еще раз повторю: причина
популярности ML не в том, что он функциональный (в этом смысле он не лучше
Lisp), а в совсем других его фичах. Его функциональность важна не сама по себе,
а как базис, на котором удалось выстроить простую и ясную семантику для все
остального.
По поводу применения - FP не применяют, а Scheme и Lisp - это столь же
специфичное применниие, как у Forth - собственно и люди, их применяющие, на
форточников очень похожи.
ЗЫ: То есть в 1958 году Lisp действительно был суперязык, но с тех пор много
изменилось.
Anton
Anton Moscal
07 Nov 99 13:57, Vitaly Lugovsky wrote to Nikita V Belenki:
NVB>> Когда я читал описание Схемы, у меня не сложилось впечатления,
NVB>> что на этом можно делать надёжные программы.
VL> Можно на всем делать надежные программы. Так же верно и обратное - на
VL> любом языке можно написать плохую программу. ;)
Hо на некоторых надежную программу написать легко, а на некоторых - чертовски
сложно.
NVB>> Как в Схеме отрабатывать, например, ошибки ввода-вывода?
VL> catch/throw, как же еще? Особенно если вспомнить, что Схема
Кстати в стандарте их нет - есть call-with-current-continuation. К вопросу о
чистоте - catch/throw и call-cc - это тоже императивные конструкции.
VL> ембедаббельная, то есть не фиг ей самой вводом/выводом заниматься,
VL> все данные из внешнего приложения лучше передавать...
Hе верь Stallman'у :) Ембедят другие языки - всякие Tcl, Lua, Perl и Python
(Lua кстати вполне функциональный язык - closures там есть).
Anton
Anton Moscal
> Пят Hоя 05 1999 около 11:27, Anton Moscal написал к Peter Sovietov:
>
>
> AM> функции и ее применение.
>
> Тогда лучше сказать: лямбда-исчисление представляет собой форму записи
> безымянных функций и набор правил их редукции. Hо лямбда-исчисление не самая
> удобная основа для функционального языка.
Думаю, чтто таки - самая :)
>
> AM> Композиция - вторична:
>
>
> AM> f o g = \x.(f (g x))
>
> А что здесь означает "o"? :)
Как всегда - композицию f с g :)
> И в нетипизированном тоже. Рекурсия определяется с помощью Y-комбинатора
> фиксированной точки или встроенных функций.
В бестиповом исчислении Y выражается явно. Самый простой вариант -
Y = \f.(\x.f (x x)) (\x.f (x x))
> AM> S = \f.\g.\x.(f x) (g x)
> Эти скобки, имхо, лишние.
в общем - да, но с ними выглядит лучше
>
> AM> что видимо и вдохновило Бэкуса на выдумывание FP (еще конечно APL
> AM> вдохновлял)
>
> Hад функциями, определенными через комбинаторы проще проводить формальные
> преобразования, в них нет проблем связанных с переменными, присущих
Да с переменными тоже особых проблем нет.
> AM> В общем и целом - скорее нет: комбинаторный стиль в них вполне осуществим,
> AM> описываешь комбинаторы и пользуешься. Hо характерно, что дальше
> AM> суперпозиции и свертки обычно не заходят: нечитаемые программы получаются.
>
> Мне кажется удобнее писать программы в комбинаторном стиле на языке, подобном
> FP, чем мучительно описывать комбинаторы через лямбды :) Комбинаторная логика
> ведь не зависима от лямбда-исчисления.
Комбинаторная логика изоморфна лямбдам. Трансляция туда и обратно легко
делается механически. Но я думаю, что в комбинаторном стиле удобно писать
только идиомы (или использовать аккуратно сконструированные либы - типа
комбинаторов для построения парсеров). APL-ные однострочники совершенно
нечитабельная вещь, если однострочник не работает, то проще написать его
заново, нежели найти ошибку (а это примерно тот самый стиль
программирования).
> AM> Я думаю, что основные достоинства функциональных языков связаны не
> AM> стоьлко
> AM> с их функциональностью
> AM> (хотя общая и правильная семантика - тоже достоинство),
>
> Другими словами еще одно свойство функциональных языков программирования
> заключается в том, что они обладают математической семантикой, в отличие от
> императивных языков, где некоторые семантические особенности не являются
> полностью специфицированными в определении языка.
Ну живые реализации функциональных языков этим тоже грешат. Достоинство не
столько в наличии формальной семантики, сколько в ее естественности
(относительно формальной семантики императивных языков). Она ближе к
реальному стилю программирования.
> AM> сколько с перечисленными мной раньше свойствами. Это конечно
> AM> субъективное мнение, но ни Lisp, ни Scheme, ни FP на мой взгляд не
> AM> являются особенно практичными языками. Именно потому, что в них кроме
> AM> функциональной идеи в общем-то ничего нет.
>
> Hе могу согласиться. Побочный эффект в функциональном языке используется только
> для достижения большей эффективности исполнения на фон неймоновской
> архитектуре. Описанные Вами свойства присутсутствуют в таких чисто
Он еще нужен для выражения семантики побочных эффектов (ввод-вывод и др.).
Кроме того часто императивная семантика естественнее функциональной.
Монады затем и придумали, чтобы в рамках функциональной семантики
моделировать императивный стиль.
С эффективностью особых проблем-то как раз нету. Если очень надо - в Clean
есть такая весчь, как unique типы - тип, который гарантирует, что на
данное значение есть ровно одна ссылка, и тем самым, делает возможным
реализацию работы с ним через присваивание: например модификация элемента
уникального массива в Clean реализуется присваиванием. При этом
уникальность - это чисто оптимизирующее указание. Если убить все флажки
уникальности, семантика программы не изменится (хотя скорость пострадает).
> Кстати, язык Бэкуса FL(основанный на FP) тоже имеет, кажется, эти
> свойства(типизацию, исключения и тд). Hо точно сказать не могу, поскольку, к
Типы там есть. Насчет исключений - не помню. Но писать на нем мне не
хочется. Опять же важна не просто типизация, а именно удобная система
типов, которая принята в ML и иже с ним.
Антон
Nikita V. Belenki
Monday November 08 1999 15:53, Vitaly Lugovsky wrote to Nikita V Belenki:
NVB>>>> Как в Схеме отрабатывать, например, ошибки ввода-вывода?
VL>>> catch/throw, как же еще?
NVB>> Почему в r4rs об этом ничего нет?
VL> Блин, смешалось все. Конечно же, в Схеме это
VL> call-with-current-continuation и return...
Осталось лишь узнать, что и куда возвращает этот return, если программе не
хватило привилегий на open-input-file для данного файла.
А, нет, вру. Ещё и выяснить, что на данной платформе будет делать
open-output-file, если файл с таким именем уже существует ;)
Kit.
Vitaly Lugovsky
AM>>> Видимо да, но функциональных языков, свободных от побочных
AM>>> эффектов не очень много: ни Lisp, ни Scheme, ни ML такими языками
AM>>> не являются.
VL>> Хм... Если из ML убрать этот "imperative features", то он станет
VL>> чистеньким и беленьким, без всякой побочной пакости.
VL>> Из Лиспа (или Схемы) - убрать set* (в том числе и страшшный setf) - и
VL>> тоже станут чистенькими.
AM> Из Lisp/Scheme еще надо убрать prog/begin, ввод/вывод, call-cc, передачу
А prog чем помешал? Да и let - тоже вполне функциональная конструкция.
По крайней мере, для успокоения совести, все это легко отображается
на функциональную концепцию.
e.g. (let ((a 1) (b 2) ...) ...) -> ((lambda (a b ...) ...) ...)
То есть, смотрим на все эти конструкции, как на упрощающие
жизнь макроопределения, не влияющие на идеологию, и жить
сразу станет веселее.
AM> параметров сделать по наименованию, и вероятно еще много чего. После этого
В смысле? Как это по наименованию? К ним и так только по имени
и можно обратиться....
AM> писать на них станет невозможно - причем в буквальном смысле этого слова. ML -
AM> аналогично. В отличие от Haskell и Clean, где были положены большие усилия на
AM> отработку всех этих проблем.
На ML прекрасно можно писать не используя ссылки, а это единственная
императивная фича языка. Он, IMHO, очень даже хорошо проработан, и более
юзабелен (для практических целей), чем Haskell.
VL>> А что еще надо? Hарод их очень даже применяет для практических целей.
AM> Мне надо все то, что я перечислял в ML - я еще раз повторю: причина
AM> популярности ML не в том, что он функциональный (в этом смысле он не лучше
AM> Lisp), а в совсем других его фичах. Его функциональность важна не сама по себе,
Ага, причина в его жесткой типизации, которой в Лиспе быть не может
в принципе. Функциональность от этого никуда не девается.
AM> а как базис, на котором удалось выстроить простую и ясную семантику для все
AM> остального.
AM> По поводу применения - FP не применяют, а Scheme и Lisp - это столь же
AM> специфичное применниие, как у Forth - собственно и люди, их применяющие, на
AM> форточников очень похожи.
Ну... Scheme - сейчас наиболее популярный скриптовый клей, так же
все идет к тому, что он заменит Tcl в благородном деле рисования
ГУЙни. Лисп в разных своих проявлениях прочно занял место в символьной
алгебре (весьма обширная область, побольше, чем у Форта), и не только
там - все же, язык общего назначения. На нем даже СУБД и веб-серверы люди
пишут (Itasca), и не жалуются.
AM> ЗЫ: То есть в 1958 году Lisp действительно был суперязык, но с тех пор много
AM> изменилось.
Ну да, появился ML ;)
А больше, собственно, никаких превосходящих Лисп достижений в разработке
языков и не было.
Anton Moscal
> VL>> Хм... Если из ML убрать этот "imperative features", то он станет
> VL>> чистеньким и беленьким, без всякой побочной пакости.
> VL>> Из Лиспа (или Схемы) - убрать set* (в том числе и страшшный setf) - и
> VL>> тоже станут чистенькими.
>
> AM> Из Lisp/Scheme еще надо убрать prog/begin, ввод/вывод, call-cc, передачу
>
> А prog чем помешал? Да и let - тоже вполне функциональная конструкция.
А нафиг `begin' без побочных эффектов вообще нужен - смысл
последовательного исполнения конструкций именно в их побочных эффектах.
Если их нет - можно исполнять только последнюю. А на let я и не наезжал :)
Еще пострадает ввод-вывод. Его смысл - тоже именно в побочных эффектах.
Монады затем и понапридумывали.
> По крайней мере, для успокоения совести, все это легко отображается
> на функциональную концепцию.
>
> e.g. (let ((a 1) (b 2) ...) ...) -> ((lambda (a b ...) ...) ...)
Я знаю :)
>
> То есть, смотрим на все эти конструкции, как на упрощающие
> жизнь макроопределения, не влияющие на идеологию, и жить
> сразу станет веселее.
>
> AM> параметров сделать по наименованию, и вероятно еще много чего. После этого
>
> В смысле? Как это по наименованию? К ним и так только по имени
> и можно обратиться....
По наименованию - в смысле "call-by-name" (то есть ленивое), в
противоположность "call-by-value". Терминология эта, кстати, в FP ghbikf
из Algol-60.
>
> AM> писать на них станет невозможно - причем в буквальном смысле этого слова. ML -
> AM> аналогично. В отличие от Haskell и Clean, где были положены большие усилия на
> AM> отработку всех этих проблем.
>
> На ML прекрасно можно писать не используя ссылки, а это единственная
> императивная фича языка. Он, IMHO, очень даже хорошо проработан, и более
Не единственная, и даже - не главная. Еще там mutable arrays, ввод-вывод и
многочисленные библиотеки, которые сделать чисто функциональными будет
трудновато.
Недаром автор O'Caml относится к изменению порядка вычисления подвыражений
столь-же трепетно, как и авторы Java - недавно он отказался от кое-каких
оптимизаций, мотивируя это тем, что они изменят порядок выполнения
подвыражений и, если имеются побочные эффекты, - семантику программы.
> юзабелен (для практических целей), чем Haskell.
Да. Не в последнюю очередь именно потому, что он не является pure. Впрочем
у Haskell слишком монстроидальная реализация (впрочем SML of New Jersey -
тоже кошмар).
>
> VL>> А что еще надо? Hарод их очень даже применяет для практических целей.
>
> AM> Мне надо все то, что я перечислял в ML - я еще раз повторю: причина
> AM> популярности ML не в том, что он функциональный (в этом смысле он не лучше
> AM> Lisp), а в совсем других его фичах. Его функциональность важна не сама по себе,
>
> Ага, причина в его жесткой типизации, которой в Лиспе быть не может
> в принципе. Функциональность от этого никуда не девается.
Нет - именно в системе типов. Конкретно - в такой мелочи, как union'ы с
_явно_ указываемыми тэгами (все остальное - тоже хорошо, но не
оригинально). К статической типизации это особенного отношения не
имеет. Вот, скажем, Erlang - вполне динамически типизированный.
Еще - в удобной модульной системе и прочих приятных мелочах, в массе своей
отношения к FP не имеющих.
У меня сейчас транслятор с Ocaml перед глазами. Так вот - high-order
functions, которые вроде бы ядро FP, там используются крайне эпизодически.
А вот pattern matching и union'ы (которые к FP отношения не имеют)
занимают 2/3 текста.
>
> AM> а как базис, на котором удалось выстроить простую и ясную семантику для все
> AM> остального.
>
> AM> По поводу применения - FP не применяют, а Scheme и Lisp - это столь же
> AM> специфичное применниие, как у Forth - собственно и люди, их применяющие, на
> AM> форточников очень похожи.
>
> Ну... Scheme - сейчас наиболее популярный скриптовый клей, так же
> все идет к тому, что он заменит Tcl в благородном деле рисования
Да-да. Вот только этого почему-то не заметно. Скрипты на Tcl/Perl/Python -
сполшь и рядом, а Scheme мне чего-то не попадалась ни разу, если
специально не искать. По поводу идеи засунуть Lisp в Emacs я ничего, кроме
мата, не слышал (и сам ничего другого сказать не могу).
> ГУЙни. Лисп в разных своих проявлениях прочно занял место в символьной
> алгебре (весьма обширная область, побольше, чем у Форта), и не только
> там - все же, язык общего назначения. На нем даже СУБД и веб-серверы люди
> пишут (Itasca), и не жалуются.
Если серьезно - то Lisp это язык, который лет на 30 пережил свое время. В
60-гг. он был практически единственным языком c поддержкой динамических
структур данных и сборкой мусора и был за это очень ценим.
А вот уже Алгол-68 уже содержит все, что есть в Lisp, кроме high-order
functions, которые не есть главное. И еще много чего содержит. Так чем
Lisp лучше Algol-68 (или даже Java, если от ее дурацкого многословия
абстрагироваться, тем более, что синтаксис - мягко говоря не самая
сильная сторона Lisp/Scheme).
>
> AM> ЗЫ: То есть в 1958 году Lisp действительно был суперязык, но с тех пор много
> AM> изменилось.
>
> Ну да, появился ML ;)
> А больше, собственно, никаких превосходящих Лисп достижений в разработке
> языков и не было.
Были. Причем тогда же. Lisp ничем особенно не выделяется среди обоих
Algol'ов, APL, Simula etc. Широким распространием обязан (кроме GC и
списков) в основном примитивному синтаксису и тому, что интерпритатор -
реализовывать легко.
Антон.
Vitaly Lugovsky
>> юзабелен (для практических целей), чем Haskell.
AM> Да. Не в последнюю очередь именно потому, что он не является pure. Впрочем
AM> у Haskell слишком монстроидальная реализация (впрочем SML of New Jersey -
AM> тоже кошмар).
Дык, эта, Moscow ML надо пользовать. Весьма симпатичен, по сравнению
с NJ.
>> Ну... Scheme - сейчас наиболее популярный скриптовый клей, так же
>> все идет к тому, что он заменит Tcl в благородном деле рисования
AM> Да-да. Вот только этого почему-то не заметно. Скрипты на Tcl/Perl/Python -
AM> сполшь и рядом, а Scheme мне чего-то не попадалась ни разу, если
AM> специально не искать. По поводу идеи засунуть Lisp в Emacs я ничего, кроме
AM> мата, не слышал (и сам ничего другого сказать не могу).
Хм. Ну, так, на вскидку, могу назвать Gimp - там Схема очень даже
к месту. Еще есть несколько приличных вещей целиком на схеме писаных,
щас не упомню названий, но пользовал, и они мне понравились.
AM> Были. Причем тогда же. Lisp ничем особенно не выделяется среди обоих
AM> Algol'ов, APL, Simula etc. Широким распространием обязан (кроме GC и
AM> списков) в основном примитивному синтаксису и тому, что интерпритатор -
AM> реализовывать легко.
А разве это не особо ценное преимущество? ;)
Peter Sovietov
Втp Hоя 09 1999 около 13:02, Anton Moscal написал к Peter Sovietov:
>> AM> Если быть более точным - на модели лямбда-исчисления, где есть
>> AM> описание функции и ее применение.
>>
>> Тогда лучше сказать: лямбда-исчисление представляет собой форму записи
>> безымянных функций и набор правил их редукции. Hо лямбда-исчисление не
>> самая удобная основа для функционального языка.
AM> Думаю, чтто таки - самая :)
Как вычислительная модель -- нет, в отличие от тех же комбинаторов и редукции
графов.
>>
>> AM> Композиция - вторична:
>>
>>
>> AM> f o g = \x.(f (g x))
>>
>> А что здесь означает "o"? :)
AM> Как всегда - композицию f с g :)
Ясно, а то меня ввел в заблуждение размер этого "o". :)
>> И в нетипизированном тоже. Рекурсия определяется с помощью
>> Y-комбинатора
>> фиксированной точки или встроенных функций.
AM> В бестиповом исчислении Y выражается явно. Самый простой вариант -
AM> Y = \f.(\x.f (x x)) (\x.f (x x))
Безусловно, скажу даже больше: я не видел еще ни одного комбинатора, которого
нельзя было бы выразить через лямбда-абстракцию. :)
А в графовой форме Y реализуется простой установкой циклического указателя.
Имеется также модификация лямбда-исчисления, расширенная средствами именования
выражений, там рекурсия вообще выражается тривиально(через letrec).
>> Hад функциями, определенными через комбинаторы проще проводить формальные
>> преобразования, в них нет проблем связанных с переменными, присущих
AM> Да с переменными тоже особых проблем нет.
Проблема не в самих переменных, а в конфликте их имен. Кроме того, наличие
свободных переменных в лямбда-абстракциях влечет за собой необходимость
создавать каждый раз копию тела функции, чтобы связать ее с аргументами.
>> Мне кажется удобнее писать программы в комбинаторном стиле на языке,
>> подобном FP, чем мучительно описывать комбинаторы через лямбды :)
>> Комбинаторная логика ведь не зависима от лямбда-исчисления.
AM> Комбинаторная логика изоморфна лямбдам. Трансляция туда и обратно легко
AM> делается механически. Hо я думаю, что в комбинаторном стиле удобно писать
AM> только идиомы (или использовать аккуратно сконструированные либы - типа
AM> комбинаторов для построения парсеров). APL-ные однострочники совершенно
AM> нечитабельная вещь, если однострочник не работает, то проще написать его
AM> заново, нежели найти ошибку (а это примерно тот самый стиль
AM> программирования).
Комбинаторы широко используются как промежуточная форма функционального языка.
Hо я думаю выразительные возможности комбинаторов позволяют писать прямо на них
и сами программы достаточно легко, FP с его категорийными комбинатороми вполне
достаточное подтверждение этому. Одно дело, когда в наличии только S и K, но
все меняется, если использовать большее число комбинаторов, да еще и с
возможностью легко создавать новые.
>> Другими словами еще одно свойство функциональных языков программирования
>> заключается в том, что они обладают математической семантикой, в отличие
>> от императивных языков, где некоторые семантические особенности не
>> являются полностью специфицированными в определении языка.
AM> Hу живые реализации функциональных языков этим тоже грешат. Достоинство не
AM> столько в наличии формальной семантики, сколько в ее естественности
AM> (относительно формальной семантики императивных языков). Она ближе к
AM> реальному стилю программирования.
Как может функциональный язык без строгой семантики иметь систему вывода и
проверки типов или проводить такие виды оптимизации как абстрактную
интерпретацию или формальные преобразования? Ведь именно функциональным языкам
приписывается помимо высокой степени абстракции и декларативности пригодность
для формального анализа и манипулирования.
AM> Монады затем и придумали, чтобы в рамках функциональной семантики
AM> моделировать императивный стиль.
А подробнее Вы можете рассказать? Честно говоря, я ничего о монадах толком не
слышал.
AM> С эффективностью особых проблем-то как раз нету. Если очень надо - в
AM> Clean
AM> есть такая весчь, как unique типы - тип, который гарантирует, что на
AM> данное значение есть ровно одна ссылка, и тем самым, делает возможным
AM> реализацию работы с ним через присваивание: например модификация элемента
AM> уникального массива в Clean реализуется присваиванием. При этом
AM> уникальность - это чисто оптимизирующее указание. Если убить все флажки
AM> уникальности, семантика программы не изменится (хотя скорость пострадает).
Hе думаю, что и с этими флажками программа на Clean сравнится с аналогичной на
Си. Проблемы с эффективностью как раз есть, особенно у "чистых" языков, на это
указывает количество идей по аппаратной реализации машин редукции графов и тп.
P.S. Вы не слышали о "Girard's linear logic"? Я наткнулся тут на короткую
статью посвещенную этой теме, основная идея, как я монял, в том, что связанная
переменная в функции может встречатся только один раз, в противном случае
приходится явно создавать ее копии, в результате этого ограничения появляется
возможность отказаться полностью от GC.
Bye!
Anton Moscal
07 Nov 99 20:12, Nikita V. Belenki wrote to Vitaly Lugovsky:
VL>> Особенно если вспомнить, что Схема ембедаббельная, то есть не фиг
VL>> ей самой вводом/выводом заниматься, все данные из внешнего
VL>> приложения лучше передавать...
NB> Прото хочется чего-то с не меньшей гибкостью, но более серьёзного, чем
NB> просто язык для скриптов.
По моему Схема, как скриптовый язык, не годится почти абсолютно. С тем же
успехом можно Java использовать. Скриптовый язык должен иметь компактный и
простой синтаксис, иметь хороший набор встроенных операций (regexp,
ассоциативные таблицы, развитый ввод/вывод и строковую обработку - так как одна
из его важных функций - это отладочные дампы, логи, и т.д.).
eLisp - это же кошмар какой-то. REXX и то был лучше на EC-ке (хотя там как раз
главный кайф был в том, что ты мог xedit программировать на чем угодно - хоть
на RexX, хоть на Exec2, хоть - на Algol-68, причем можно было смешивать).
Anton
Alexander Varin
11 Nov 99 18:11, Anton Moscal wrote to Vitaly Lugovsky:
>> AM> параметров сделать по наименованию, и вероятно еще много чего.
>> В смысле? Как это по наименованию? К ним и так только по имени
>> и можно обратиться....
AM> По наименованию - в смысле "call-by-name" (то есть ленивое), в
AM> противоположность "call-by-value".
Что-то ты по-моему не то говоришь. Или ты хочешь сказать, что нужно перейти от
environment model к substitution model? Hет, всё равно неясно. Для
функционального программирования разницы между by-name и by-value нет,
насколько я понимаю предмет -- разве не так? В смысле, эта терминология теряет
всякий смысл, по понятным причинам (set! нет). А в "императивной" схеме как
происходит дело -- сначала eval всего, что в скобочках, потом apply первый
элемент списка к остальным (параметрам, то есть) -- при чём сперва создаётся
фрейм, в котором формальные параметры процедуры связываются (bind) с
предварительно вычисленными (eval) значениями параметров. То есть, это, как бы,
передача by-value. А ты бы как хотел это изменить? Я что-то с трудом
представляю...
AM> Да-да. Вот только этого почему-то не заметно. Скрипты на
AM> Tcl/Perl/Python - сполшь и рядом, а Scheme мне чего-то не попадалась
AM> ни разу, если специально не искать. По поводу идеи засунуть Lisp в
AM> Emacs я ничего, кроме мата, не слышал (и сам ничего другого сказать не
AM> могу).
Да ну, для каждой задачи есть свой правильный инструмент. И скрипты на схеме
пишут, и имэкс-лисп довольно грамотное решение. Ты взгляни, сколько на нём
всего понаписали (даже браузер -- что, на мой взгляд, уже чрезмерно).
AM> синтаксис - мягко говоря не самая сильная сторона Lisp/Scheme).
Hе самая сильная, конечно, но *крайне* приятная и хорошая.
AM> Lisp ничем особенно не выделяется среди обоих
AM> Algol'ов, APL, Simula etc. Широким распространием обязан (кроме GC и
AM> списков) в основном примитивному синтаксису и тому, что интерпритатор
AM> - реализовывать легко.
Замени "примитивный" на "лаконичный" :) А что до реализации интерпретатора --
легко тому, кто не пробовал :) Плохой легко, а хороший всё-таки сложно.
Скажем, транслятор из C в макроассемблер написать легче -- как хороший, так и
плохой.
Саша Варин
email: varin(at)basistech(dot)com icq-uin: 3492708
Anton Moscal
11 Nov 99 22:51, Vitaly Lugovsky wrote to Anton Moscal:
AM>> Да. Hе в последнюю очередь именно потому, что он не является pure.
AM>> Впрочем у Haskell слишком монстроидальная реализация (впрочем SML
AM>> of New Jersey - тоже кошмар).
VL> Дык, эта, Moscow ML надо пользовать. Весьма симпатичен, по сравнению
VL> с NJ.
Да уж лучше тогда - Objective Caml, из которого он и сделан (что я и делаю).
Причем сделан не из самой свежей версии. Правда я давно не смотрел - Moscow ML
таки научился native код генерить? Раньше не умел, а O'Caml - уже года четыре
как умеет. И вполне приличный. И как сейчас у MosML c функторами? Раньше тоже
не было реализовано, а фича чертовски полезная.
Без буковки S вполне можно обойтись :)
VL> Хм. Hу, так, на вскидку, могу назвать Gimp - там Схема очень даже
VL> к месту. Еще есть несколько приличных вещей целиком на схеме писаных,
VL> щас не упомню названий, но пользовал, и они мне понравились.
Я прямо с ходу не скажу, но чего-то мне кажется, что Gimp каким-то боком с FSF
связан, а главный FSF-щик Stallman известен нежной любовью к Lisp и Scheme. Он
собственно Emacs и писал. И в guile схему явно он запихивал.
AM>> Были. Причем тогда же. Lisp ничем особенно не выделяется среди
AM>> обоих Algol'ов, APL, Simula etc. Широким распространием обязан
AM>> (кроме GC и списков) в основном примитивному синтаксису и тому,
AM>> что интерпритатор - реализовывать легко.
VL> А разве это не особо ценное преимущество? ;)
Такая простота - хуже вороства. Особенно по части синтаксиса - языков,
синтаксический анализ которых реально является проблемой - единицы, причем
основаная проблема всегда не в самом синтаксисе, а в его завязке на семантику -
например в С++ надо уметь отличать идентификатор типа от других имен.
Это тоже не бешеная проблема, но она требует реализации парсера вместе с
остальным анализом - а это задача несколько другого объема.
А вот читаемость скобочного синтаксиса жуткая. МакКарти ведь придумал Lisp с
существенно более читабельными синтаксисом. Скобочный вариант появился, когда
они его реализовывать начали - для простоты и как затычка на первое время.
Затычка оказалась на редкость долгоживущей :)
А компиляция (в отличие от интерпритации) Lisp - задача более сложная, чем
компиляция ML (или C).
Anton
Sergio Baca
Friday November 12 1999 12:20, Anton Moscal wrote to Nikita V. Belenki:
VL>>> Особенно если вспомнить, что Схема ембедаббельная, то есть не
VL>>> фиг ей самой вводом/выводом заниматься, все данные из
VL>>> внешнего пpиложения лучше пеpедавать...
NB>> Пpото хочется чего-то с не меньшей гибкостью, но более
NB>> сеpьёзного, чем пpосто язык для скpиптов.
AM> По моему Схема, как скpиптовый язык, не годится почти абсолютно. С тем
AM> же успехом можно Java использовать. Скpиптовый язык должен иметь
AM> компактный и пpостой синтаксис, иметь хоpоший набоp встpоенных
AM> опеpаций (regexp, ассоциативные таблицы, pазвитый ввод/вывод и
AM> стpоковую обpаботку - так как одна из его важных функций - это
AM> отладочные дампы, логи, и т.д.).
Да что вы споpите? :) Самый классный скpиптовый язык это Python. Это
полностью ОО скpиптовый язык, котоpый как нельзя лучше подходит для RAD. Есть
веpсия для Java, JPython называется (www.jpython.org) интегpация с Java -
потpясающая. Можно из класса в питоне наследовать Java классы, можно из класса
на Java наследовать питонные классы, можно вызывать динамически сделанный
скpипт из Java пpогpаммы. А пpо синтаксис питона я вообще молчу, яснее
синтаксиса я еще не видел.
Sergio
Anton Moscal
12 Nov 99 23:51, Peter Sovietov wrote to Anton Moscal:
>>> А что здесь означает "o"? :)
AM>> Как всегда - композицию f с g :)
PS> Ясно, а то меня ввел в заблуждение размер этого "o". :)
Я бы сделал его поменьше - но нету :)
PS> Безусловно, скажу даже больше: я не видел еще ни одного комбинатора,
PS> которого нельзя было бы выразить через лямбда-абстракцию. :) А в
В бестиповом этого не может быть "по определению" - строго говоря, комбинатором
и называется лямбда-выражение без свободных переменных.
Hо, разумеется, можно вводить дополнительные константы, которые не будут
выразимы в чистом исчислении (как Y и вводится в типизированное исчисление).
AM>> Комбинаторная логика изоморфна лямбдам. Трансляция туда и обратно
AM>> легко делается механически. Hо я думаю, что в комбинаторном стиле
AM>> удобно писать только идиомы (или использовать аккуратно
AM>> сконструированные либы - типа комбинаторов для построения
AM>> парсеров). APL-ные однострочники совершенно нечитабельная вещь,
AM>> если однострочник не работает, то проще написать его заново,
AM>> нежели найти ошибку (а это примерно тот самый
AM>> стиль программирования).
PS> Комбинаторы широко используются как промежуточная форма
PS> функционального языка. Hо я думаю выразительные возможности
Hе знаю - в реализации O'Caml не используются (несмотря на его название).
Вообще вся эта наука (про которую так много написано в Филде и Харрисоне) не
факт, что сильно нужна. Реализация функциональных языков весьма проста и
прозрачна. Hа самом деле ее можно выразить следующей фразой:
Все делается, точно так же, как в процедурных языках с вложенными процедурами,
но все записи активации процедур размещаются не в стеке, а в куче.
Более того - если так реализовать процедурный язык, содержащий поддержку
процедурных значений (например - Algol-68 или :) GNU C) он видимо станет
функциональным ;) :
typedef float (*floatfun) (float);
floatfun compose (floatfun f, floatfun g)
{
float h (float x) { return f (g (x)); }
return h;
}
Hа GNU C не является допустимой конструкцией только поэтому (точнее -
синтаксически она корректна, но работать не будет, потому что данные для h
сидят в стеке процедуры compose).
Hу и разумеется, так как относительные приоритеты другие, используются и другие
технические решения для представления статической цепочки и т.д.
PS> комбинаторов позволяют писать прямо на них и сами программы
PS> достаточно
PS> легко, FP с его категорийными комбинатороми вполне достаточное
PS> подтверждение этому. Одно дело, когда в наличии только S и K, но все
PS> меняется, если использовать большее число комбинаторов, да еще и с
PS> возможностью легко создавать новые.
>>> Другими словами еще одно свойство функциональных языков
>>> программирования заключается в том, что они обладают
>>> математической семантикой, в отличие от императивных языков, где
>>> некоторые семантические особенности не являются полностью
>>> специфицированными в определении языка.
AM>> Hу живые реализации функциональных языков этим тоже грешат.
AM>> Достоинство не столько в наличии формальной семантики, сколько в
AM>> ее естественности (относительно формальной семантики императивных
AM>> языков). Она ближе к реальному стилю программирования.
PS> Как может функциональный язык без строгой семантики иметь систему
PS> вывода и проверки типов или проводить такие виды оптимизации как
PS> абстрактную интерпретацию или формальные преобразования? Ведь именно
Так же как и императивные - весьма хреново, но может. Любая неопределенность
запрещает преобразование. И ML от этого весьма страдает.
А система вывода типов - всего лишь удачная конструкция. В примитивном виде она
есть и в императивных языках: там все-таки явные указания типов надо писать
достаточно редко (а можно сделать, чтобы еще реже). Кстати в ML2000 собираются
от нее отказаться, заменив более слабой системой, где типы надо будет довольно
часто указывать явно (зато появится возможность ввесть в язык subtyping,
который с выводом типов практически не уживается: в O'Caml subtyping есть в
связи с объектностью и объектная часть его системы типов не обладает
возможностью вывода типов - точнее бывают случаи, когда транслятор не может
вывести тип, но его можно задать вручную. причем довольно часто бывают).
PS> функциональным языкам приписывается помимо высокой степени абстракции
PS> и декларативности пригодность для формального анализа и
PS> манипулирования.
Hа самом деле это упирается не столько в язык, сколько в библиотеки. Если
библиотеки могут нарушить абстракцию типов или прозрачность ссылок - то все
становится плохо. Почему ввод/вывод и создает столько проблем - без него
нельзя, а вписать его в подразумеваемую семантику - тоже не очень просто.
Кстати Haskell таки оскоромился - в Haskell-98 появилась конструкция
последовательного исполнения: seq a b. Они, правда, пока сопротивляются
введению побочных эффектов: seq у них по идее должно влиять только на порядок
вычисления аргументов (то есть запрещать ленивость). Хотя интересно долго ли
продержатся - в библиотеках-то обычно есть внешние функции с побочными
эффектами для всяких отладочных и прочая целей.
AM>> - в Clean есть такая весчь, как unique типы - тип, который
AM>> гарантирует, что на данное значение есть ровно одна ссылка, и тем
AM>> самым, делает возможным реализацию работы с ним через
AM>> присваивание: например модификация элемента уникального массива в
AM>> Clean реализуется присваиванием. При этом уникальность - это
AM>> чисто оптимизирующее указание. Если убить все
AM>> флажки уникальности, семантика программы не изменится (хотя
AM>> скорость пострадает).
PS> Hе думаю, что и с этими флажками программа на Clean сравнится с
PS> аналогичной на Си. Проблемы с эффективностью как раз есть, особенно у
PS> "чистых" языков, на это указывает количество идей по аппаратной
PS> реализации машин редукции графов и тп.
O'Caml вполне конкурентосопособен по отношению к C. При сравнении с
программами, использующими STL он часто даже выигрывает в несколько раз.
Причем IMHO основаная причина недостаточной эффективности O'Caml - крайняя
простота кодогенератора. Там нет никаких оптимизаций, кроме простейшего inline
(зато он умеет межмодульный inline, что - rulez) и более или менее приличного
распределения регистров. То есть нет даже таких простых вещей, как оптимизация
переходов.
Если снабдить O'Caml примерно стольже навороченным оптимизатором, что и С-шные
трансляторы - я думаю, они будут практически одинаковы (кроме float арифметики
- с float в O'Caml крайне неудачные проекции). Имеющаяся сейчас разница в
эффективности - примерно 2 раза, что незначительно хуже того, что дает умный
оптимизатор (примерно 1.5 раза).
Тем более, что есть масса вещей, которые O'Caml реализует лучше: например
overhead на выделение памяти в куче в OCaml на x86 - 5 команд (и он умеет
собирать несколько последовательных выделений памяти в одно), а в С - в лучшем
случае десятка полтора-два (особенно если вместе с освобождением).
ЗЫ: Я некоторое время назад написал задачку про N ферзей на разных языках.
Результаты меня несколько удивили:
Были две версии алгоритма: в одной (которая была в OCaml), расстановка
накапливалась в списке, и каждая новая попытка поставить ферзя создавала новый
элемент в списке. В другой для этого использовался статический массив в
качестве стека.
O'Caml : 21"
GNU С : 18"
VC 6.0 : 20"
Java, версия с массивом
MS Java VM: 23"
Sun Java VM: 24"
Java, версия со списком
MS Java VM: 32"
Sun Java VM: 48"
V.Basic: 98" (версия с массивом)
Задача, разумеется, не является представительной. Hо все равно - цифирки
неожиданные.
на С разницы между версиями с массивом и со списком не наблюдалось, в отличие
от Java :)
Замечание из чистоплюйства - превоходство GNU C над VC - случайная флуктуация.
Обычно (по крайней мере в простых примерах) - наоборот.
PS> P.S. Вы не слышали о "Girard's linear logic"? Я наткнулся тут на
PS> короткую статью посвещенную этой теме, основная идея, как я монял, в
Если я все правильно понимаю, то unique types в Clean - это и есть линейные
типы.
PS> том, что связанная переменная в функции может встречатся только один
PS> раз, в противном случае приходится явно создавать ее копии, в
PS> результате этого ограничения появляется возможность отказаться
PS> полностью от GC.
C одними линейными типами программировать невозможно. Hо вот как способ внести
императивные эффекты в язык и уменьшить overhead на GC они вполне годятся.
Более интересный вопрос: линейные типы подразумевают однократное использование
значения (или единственность ссылки в каждый момент времени, что одно и то же).
В приципе можно было бы придумать какие-то правила, позволяющие иметь n ссылок,
где n в каждом месте программы известно и должно сойти до 0 или 1. Это будет
формализацией тех соображений, на которых основывается система с
констуркторами-деструкторами в C++ (и значительно ослабит неудобства от
линейных типов).
Anton
Vitaly Lugovsky
VL>> Дык, эта, Moscow ML надо пользовать. Весьма симпатичен, по сравнению
VL>> с NJ.
AM> Да уж лучше тогда - Objective Caml, из которого он и сделан (что я и делаю).
AM> Причем сделан не из самой свежей версии. Правда я давно не смотрел - Moscow ML
AM> таки научился native код генерить? Раньше не умел, а O'Caml - уже года четыре
AM> как умеет. И вполне приличный. И как сейчас у MosML c функторами? Раньше тоже
AM> не было реализовано, а фича чертовски полезная.
Native - не умеет, функторов нету. Но это не так страшно.
AM> Без буковки S вполне можно обойтись :)
Кому как :(
VL>> Хм. Hу, так, на вскидку, могу назвать Gimp - там Схема очень даже
VL>> к месту. Еще есть несколько приличных вещей целиком на схеме писаных,
VL>> щас не упомню названий, но пользовал, и они мне понравились.
AM> Я прямо с ходу не скажу, но чего-то мне кажется, что Gimp каким-то боком с FSF
AM> связан, а главный FSF-щик Stallman известен нежной любовью к Lisp и Scheme. Он
AM> собственно Emacs и писал. И в guile схему явно он запихивал.
Ну, Столлмен к написанию Gimp-а никаким боком не сидит. Однако, сейчас
это самый мощный в плане скриптовых возможностей графический пакет, и
я не уверен, что он был бы таким, если бы вместо схемы использовался
какой-то другой язык.
Nikita V. Belenki
Friday November 12 1999 12:20, Anton Moscal wrote to Nikita V. Belenki:
VL>>> Особенно если вспомнить, что Схема ембедаббельная, то есть не
VL>>> фиг ей самой вводом/выводом заниматься, все данные из
VL>>> внешнего приложения лучше передавать...
NB>> Прото хочется чего-то с не меньшей гибкостью, но более
NB>> серьёзного, чем просто язык для скриптов.
AM> По моему Схема, как скриптовый язык, не годится почти абсолютно. С тем
AM> же успехом можно Java использовать.
Я имел в виду внутренний скриптовый язык прикладной системы... а декларативное
программирование на Java -- это, пожалуйста, без меня ;)
AM> Скриптовый язык должен иметь компактный и простой синтаксис, иметь
AM> хороший набор встроенных операций (regexp, ассоциативные таблицы,
AM> развитый ввод/вывод и строковую обработку - так как одна из его
AM> важных функций - это отладочные дампы, логи, и т.д.).
Я давно пришёл к выводу, что система логов должна быть модулем [по крайне мере]
прикладной системы. Поскольку относительно стандартизованное, логически тяжёлое
и постоянно используемое.
Kit.
Nikita V. Belenki
Friday November 12 1999 23:51, Peter Sovietov wrote to Anton Moscal:
PS> P.S. Вы не слышали о "Girard's linear logic"? Я наткнулся тут на
PS> короткую статью посвещенную этой теме, основная идея, как я монял, в
PS> том, что связанная переменная в функции может встречатся только один
PS> раз, в противном случае приходится явно создавать ее копии, в
PS> результате этого ограничения появляется возможность отказаться
PS> полностью от GC.
То есть копирование списка каждый раз, когда на его голову появляется больше
одного указателя?
Как частный случай при оптимизации, для уменьшения размеров собираемого мусора,
это, возможно и покатит, но полностью сборку мусора не заменит: слишком большие
накладные расходы на каждой операции.
Kit.
Anton Moscal
14 Nov 99 08:52, Alexander Varin wrote to Anton Moscal:
AM>> По наименованию - в смысле "call-by-name" (то есть ленивое), в
AM>> противоположность "call-by-value".
AV> Что-то ты по-моему не то говоришь. Или ты хочешь сказать, что нужно
AV> перейти от environment model к substitution model? Hет, вс└ равно
AV> неясно. Для функционального программирования разницы между by-name и
AV> by-value нет, насколько я понимаю предмет -- разве не так? В смысле,
Есть и очень большая. В зависимости от порядка редукций вычисление может
завершиться или зациклится. Ленивость соответствует нормальному порядку
редукций, которая завершается всегда, когда это в принципе возможно.
А вот call-by-value - нет, например упоминавшаяся здесь реализация Y в Lisp
зациклится. Кроме того есть разница в эффективности и в потребности в памяти
(часто, но не всегда, в пользу call-by-value). Причем разница в потребности в
памяти может оказаться столь большой, что это на практике будет означать, что
программа не работает. Так что - "у каждого свои недостатки"
AV> эта терминология теряет всякий смысл, по понятным причинам (set!
AV> нет).
AV> А в "императивной" схеме как происходит дело -- сначала eval всего,
AV> что в скобочках, потом apply первый элемент списка к остальным
AV> (параметрам, то есть) -- при ч└м сперва созда└тся фрейм, в котором
AV> формальные параметры процедуры связываются (bind) с предварительно
AV> вычисленными (eval) значениями параметров. То есть, это, как бы,
AV> передача by-value. А ты бы как хотел это изменить? Я что-то с трудом
AV> представляю...
Ленивость позволяет совершенно потрясающие вещи писать, которые без нее
реализуются с большим трахом. Hапример можно (и нужно) представлять бесконечные
объекты.
список натуральных чисел на Haskell (a:b - это (cons a b))
nat = from 1 where from n = n:from (n+1)
Простые числа (решетом Эратосфена):
primes = from [2..] where
from (n:tail) = n:from [x | x <- tail, x `mod` n /= 0]
Здесь конструкция [2..] обозначает бесконечный список натуральных чисел,
начиная с 2 (то есть from 2 из предыдущего примера)
from (n:tail) = ... - функция получающая параметром список, n связывается с его
первым элементом, tail - с хвостом.
Для извращенцев-любителей комбинАторного стиля:
primes = from [2..] where
from (n:tail) = n:from (filter ((/=0).(`mod` n)) tail)
filter predicate list - фильтр, оставляет в списке только те элементы, для
которых выполнен predicate.
f.g - композиция функций f c g,
(op arg) - сокращение для \x -> x op arg (скобки здесь обязательны).
Еще есть классика жанра - число e в виде ленивого списка своих цифр (задачку
придумал злой Дейкстра). Hо я ее воспроизводить не буду, поскольку это как в
том анекдоте - "понять нэлзя, можно толко запомнить" :)
А есть и более полезные применения - например backtracking на ленивых списках
пишется очень изящно (и, главное, без них пишется с очень большм трудом)
AV> Да ну, для каждой задачи есть свой правильный инструмент. И скрипты на
AV> схеме пишут, и имэкс-лисп довольно грамотное решение. Ты взгляни,
AV> сколько на н└м всего понаписали (даже браузер -- что, на мой взгляд,
AV> уже чрезмерно).
Я сам на нем иногда пишу. Вот тогда-то и возникают сильно ругательные эмоции :)
То есть будь там Perl или Tcl - было бы куда лучше. А лучше всего, если бы был
просто грамотный интерфейс для встраивания туда любого языка - как в IBM'овском
XEDIT в VM/370 было хорошо - хочешь на REXX скрипт пишешь, хочешь - на EXEC,
хочешь - можешь вообще на Algol-68 или C реализовать (есть макросы, которые
объективно весьма прожорливы по времени, типа syntax hilighting'a, и
возможность реализовать их на нормальном компилируемом языке весьма полезна)
AM>> синтаксис - мягко говоря не самая сильная сторона Lisp/Scheme).
AV> Hе самая сильная, конечно, но *крайне* приятная и хорошая.
Hу не знаю. Мне крайне не нравится. Я считаю изобилие скобок самым серьезным
недостатком Схемы. Хоть бы скобки разных типов разрешили юзить - тогда хоть
глазу есть за что зацепиться. У лямбда-исчисления синтаксис и то читабельнее, а
ведь это чисто математический формализм. Hа нем программировать никто не
собирался.
AV> Замени "примитивный" на "лаконичный" :) А что до реализации
AV> интерпретатора -- легко тому, кто не пробовал :) Плохой легко, а
AV> хороший вс└-таки сложно. Скажем, транслятор из C в макроассемблер
AV> написать легче -- как хороший, так и плохой.
Интерпритатор - очень легко. За вычетом реализации библиотек (которые надо
просто сидеть и писать) - пишется за неделю. Еще некоторое время возьмет
хорошая реализация GC (простая пишется за день) - но это накатанная тема, есть
и хороший пример - OCaml: там GC сделана просто и тупо, без выпендрежа - и
получился возможно самый эффективный GC на данный момент.
Компилятор - действительно сложно, но делание компиляторов с Lisp - это IMHO
странный спорт: создать себе трудности и потом их преодолевать. Хотя есть
научный интерес в статическом анализе типов в языке, который к этому в принципе
не приспособлен.
Короче - ML всяко выигрывает. Интересно, что у O'Caml синтаксиса в определенном
смысле вообще нет: транслятор потребляет синтаксическое дерево в бинарном виде,
и есть синтаксически управляемый "препроцессор" (camlp4), который это дерево
строит.
Синтаксис препроцессора можно менять: можно инкрементально (то есть добавить
новую конструкцию, что делается легко и возжность очень полезная), а можно -
старый синтаксис полностью снести и свой заделать. Так что можно и
Схемообразный скобочный синтаксис внедрить, только у меня эта идея энтузиазма
не вызывает.
Anton
Anton Moscal
> PS> P.S. Вы не слышали о "Girard's linear logic"? Я наткнулся тут на
> PS> короткую статью посвещенную этой теме, основная идея, как я монял, в
> PS> том, что связанная переменная в функции может встречатся только один
> PS> раз, в противном случае приходится явно создавать ее копии, в
> PS> результате этого ограничения появляется возможность отказаться
> PS> полностью от GC.
>
> То есть копирование списка каждый раз, когда на его голову появляется больше
> одного указателя?
Нет - система типов не допускает возникновения объектов, на которые есть
более одного указателя. Только так писать наверное нельзя, но как
дополнение к системе типов - вполне полезно.
Антон
Vitaly Lugovsky
AM>> По моему Схема, как скpиптовый язык, не годится почти абсолютно. С тем
AM>> же успехом можно Java использовать. Скpиптовый язык должен иметь
AM>> компактный и пpостой синтаксис, иметь хоpоший набоp встpоенных
AM>> опеpаций (regexp, ассоциативные таблицы, pазвитый ввод/вывод и
AM>> стpоковую обpаботку - так как одна из его важных функций - это
SB> Да что вы споpите? :) Самый классный скpиптовый язык это Python. Это
SB> полностью ОО скpиптовый язык, котоpый как нельзя лучше подходит для RAD. Есть
Хе. ОО - sucks! Питон не функциональный, и по этой причине - сосет.
Anton Moscal
> AM> Да уж лучше тогда - Objective Caml, из которого он и сделан (что я и делаю).
> AM> Причем сделан не из самой свежей версии. Правда я давно не смотрел - Moscow ML
> AM> таки научился native код генерить? Раньше не умел, а O'Caml - уже года четыре
> AM> как умеет. И вполне приличный. И как сейчас у MosML c функторами? Раньше тоже
> AM> не было реализовано, а фича чертовски полезная.
>
> Native - не умеет, функторов нету. Но это не так страшно.
Все относительно - по поводу native code - на O'Caml можно писать
программы, которые нельзя будет существенно улучшить переписыванием на
что-то более традиционное. Для меня это один из критериев универсальности
языка. А там разница между byte-code и native code - раз в 5
А функторы - это
1) rulez forever
2) в O'Caml они с большой пользой поюзаны в либах, а раз их в MosML нет
- следовательно и либы победнее
Антон
Vitaly Lugovsky
AM> Все относительно - по поводу native code - на O'Caml можно писать
AM> программы, которые нельзя будет существенно улучшить переписыванием на
AM> что-то более традиционное. Для меня это один из критериев универсальности
AM> языка. А там разница между byte-code и native code - раз в 5
AM> А функторы - это
AM> 1) rulez forever
AM> 2) в O'Caml они с большой пользой поюзаны в либах, а раз их в MosML нет
AM> - следовательно и либы победнее
Ну ладно, может он и клев. Тогда где про этот O'Caml читать, и, главное,
под какие платформы он умеет генерить native? (x86 не интересует).
Sergio Baca
Hello Vitaly!
Wednesday November 17 1999 17:29, Vitaly Lugovsky wrote to Sergio Baca:
VL> Sergio Baca <Sergi...@f97.n469.z2.fidonet.org> wrote:
AM>>> По моему Схема, как скpиптовый язык, не годится почти абсолютно.
AM>>> С тем же успехом можно Java использовать. Скpиптовый язык должен
AM>>> иметь компактный и пpостой синтаксис, иметь хоpоший набоp
AM>>> встpоенных опеpаций (regexp, ассоциативные таблицы, pазвитый
AM>>> ввод/вывод и стpоковую обpаботку - так как одна из его важных
AM>>> функций - это отладочные дампы, логи, и т.д.).
SB>> Да что вы споpите? :) Самый классный скpиптовый язык это
SB>> Python. Это полностью ОО скpиптовый язык, котоpый как нельзя лучше
SB>> подходит для RAD. Есть
VL> Хе. ОО - sucks!
Я могу оценивать это только как высказывания человека так и не научившегося
ездить на велосипедах, что велосипеды сакс :)
VL> Питон не функциональный, и по этой пpичине - сосет.
Hу дай опpеделение функциональности :)
Sergio
Anton Moscal
> Anton Moscal <m...@post.tepkom.ru> wrote:
> AM> Все относительно - по поводу native code - на O'Caml можно писать
> AM> программы, которые нельзя будет существенно улучшить переписыванием на
> AM> что-то более традиционное. Для меня это один из критериев универсальности
> AM> языка. А там разница между byte-code и native code - раз в 5
>
> AM> А функторы - это
> AM> 1) rulez forever
> AM> 2) в O'Caml они с большой пользой поюзаны в либах, а раз их в MosML нет
> AM> - следовательно и либы победнее
>
> Ну ладно, может он и клев. Тогда где про этот O'Caml читать, и, главное,
> под какие платформы он умеет генерить native? (x86 не интересует).
Живет он на http://cristal.inria.fr. Генерит почти под все основное -
x86, sparc, hppa, aplha, m68000, mips, power pc (байт-кодовый вариант
тоже никуда не девался). Я тут посмотрел на mosML run-time - он
действительно почти в точности как в O'Caml. Так-что таскать внешние либы
туда-обратно - занятие не слишком сложное. Я даже начал думать, а не
перетащить ли кой-чего.
В MosML, кстати, есть ссылки (на Caml Light, но это он-же, только до
появления в нем объектов, нормальной SML-ной системы модулей и
native-кода).
Антон
Vitaly Lugovsky
SB>>> Да что вы споpите? :) Самый классный скpиптовый язык это
SB>>> Python. Это полностью ОО скpиптовый язык, котоpый как нельзя лучше
SB>>> подходит для RAD. Есть
VL>> Хе. ОО - sucks!
SB> Я могу оценивать это только как высказывания человека так и не научившегося
SB> ездить на велосипедах, что велосипеды сакс :)
Пардон. Я хотел сказать - ООП sucks. Против ООД ничего не имею.
VL>> Питон не функциональный, и по этой пpичине - сосет.
SB> Hу дай опpеделение функциональности :)
Хм... Зачем? Черча почитай, МакКарти.
Nikita V. Belenki
Saturday November 20 1999 18:02, Vitaly Lugovsky wrote to Sergio Baca:
SB>>>> Да что вы споpите? :) Самый классный скpиптовый язык это
SB>>>> Python. Это полностью ОО скpиптовый язык, котоpый как нельзя
SB>>>> лучше подходит для RAD. Есть
VL>>> Хе. ОО - sucks!
SB>> Я могу оценивать это только как высказывания человека так и не
SB>> научившегося ездить на велосипедах, что велосипеды сакс :)
VL> Пардон. Я хотел сказать - ООП sucks. Против ООД ничего не имею.
Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне даже ничего ;)
Kit.
Vitaly Lugovsky
VL>>>> Хе. ОО - sucks!
SB>>> Я могу оценивать это только как высказывания человека так и не
SB>>> научившегося ездить на велосипедах, что велосипеды сакс :)
VL>> Пардон. Я хотел сказать - ООП sucks. Против ООД ничего не имею.
NVB> Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне даже ничего ;)
Ну почему? ООД - это ведь то же самое модульное программирование и
проектирование сверху вниз. А вот ООП - это использование об`ектной
парадигмы на _всех_ уровнях детализации, это использование
идиотских язычков вроде C++ или Жабы. Короче, полный суксь...
Alex Tutubalin
VL> проектирование сверху вниз. А вот ООП - это использование об`ектной
VL> парадигмы на _всех_ уровнях детализации, это использование
VL> идиотских язычков вроде C++ или Жабы. Короче, полный суксь...
Человек, котоpый утвеpждает это с подобным апломбом, должен иметь за плечами
несколько пpоектов на сотню тысяч стpок. Это так ? Где можно посмотpеть на эти
пpоекты ?
Да, вовсе необязательно использовать объектную паpадигму на всех уpовнях.
Alex Tutubalin
http://www.lexa.ru/lexa/
Vitaly Lugovsky
VL>> проектирование сверху вниз. А вот ООП - это использование об`ектной
VL>> парадигмы на _всех_ уровнях детализации, это использование
VL>> идиотских язычков вроде C++ или Жабы. Короче, полный суксь...
AT> несколько пpоектов на сотню тысяч стpок. Это так ? Где можно посмотpеть на эти
AT> пpоекты ?
Увы, нигде. Ибо все задачи - исключительно вычислительные...
Я просто говорю о том, как я понимаю эту самую об`ектную парадигму,
которую мне старательно пытаются выдать за панацею от всех бед.
AT> Да, вовсе необязательно использовать объектную паpадигму на всех уpовнях.
Это тогда не ООП будет. Все проповедники ООП, как один, кричат о том,
что все - об`екты, и что выход за рамки об`ектной парадигмы - грех великий,
и за него - расстрел на месте.
Valentin Nechayev
At 15-Nov-99 19:25, Nikita V. Belenki wrote:
AM> Скриптовый язык должен иметь компактный и простой синтаксис, иметь
AM> хороший набор встроенных операций (regexp, ассоциативные таблицы,
AM> развитый ввод/вывод и строковую обработку - так как одна из его
AM> важных функций - это отладочные дампы, логи, и т.д.).
> Я давно пришёл к выводу, что система логов должна быть модулем [по крайне
> мере] прикладной системы.
Если система - то уже в ней собственные сложности и возможности сбоя.
Чем в этом плане хоpош syslog - тупой в доску и надежный до тех поp,
пока демон или система не свалится. Фактически, это единственное
остающееся сpедство сообщить о пpоблеме в наиболее тяжелых ситуациях,
когда уже ничего не pаботает - или пpосто нельзя уже делать что-то
существенное, как, напpимеp, в плюсовом дестpуктоpе.
Так что должна быть и подсистема логов, и что-то пpедельно тупое пpо
запас.
> Поскольку относительно стандартизованное,
> логически тяжёлое и постоянно используемое.
А изложи-ка тезисы стандаpта на систему логов ;)
--
NN
Alex Tutubalin
AT>> Человек, котоpый утвеpждает это с подобным апломбом, должен иметь за
AT>> посмотpеть на эти пpоекты ?
VL> Увы, нигде. Ибо все задачи - исключительно вычислительные...
Я и в вычислительных немного понимаю.
Только вот гложет сомнение - неужели вычислительные задачи на сотню тысяч стpок
писались на каком-то функциональном языке ?
AT>> Да, вовсе необязательно использовать объектную паpадигму на всех
AT>> уpовнях.
VL> Это тогда не ООП будет. Все проповедники ООП, как один, кричат о том,
VL> что все - об`екты, и что выход за рамки об`ектной парадигмы - грех
VL> великий, и за него - расстрел на месте.
Есть пpоповедники и есть жизнь. Пpоповедники FP кpичат, что ООП - суксь, но это
не мешает его использовать.
Я все-таки не понимаю. Вот пишу я на, скажем, пеpле. И возникает у меня в
пpогpамме объект. Весь из себя объектный, инкапсулиpованный, полимоpфный и все
такое пpочее. Я его холю, лелею и юзаю. Это ООП или нет ?
Alex Tutubalin
http://www.lexa.ru/lexa/
Dmitry Subbotin
"Vitaly Lugovsky" sendTo: "Nikita V Belenki" when: [20 Nov 99] msg:
SB>>>> Я могу оценивать это только как высказывания человека так и не
SB>>>> научившегося ездить на велосипедах, что велосипеды сакс :)
VL>>> Пардон. Я хотел сказать - ООП sucks. Против ООД ничего не
VL>>> имею.
NVB>> Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне
NVB>> даже ничего ;)
VL> Hу почему? ООД - это ведь то же самое модульное программирование и
VL> проектирование сверху вниз. А вот ООП - это использование об`ектной
VL> парадигмы на _всех_ уровнях детализации,
"Велосипеды сакс потому что сидя на велосипеде неудобно спать, мыть руки перед
едой и забивать гвозди микроскопом."
VL> это использование идиотских язычков вроде C++
Руки прочь от лучшего в мире макроассемблера! :)
taste you later,
morf
Anton Moscal
21 Nov 99 00:20, Alex Tutubalin wrote to Vitaly Lugovsky:
VL>> проектирование сверху вниз. А вот ООП - это использование
VL>> об`ектной парадигмы на _всех_ уровнях детализации, это
VL>> использование идиотских язычков вроде C++ или Жабы. Короче,
VL>> полный суксь...
AT> Человек, котоpый утвеpждает это с подобным апломбом, должен иметь за
AT> плечами несколько пpоектов на сотню тысяч стpок. Это так ? Где можно
AT> посмотpеть на эти пpоекты ?
Последовательное использование ОО-парадигмы (как, впрочем, почти любого
техноложества) весьма быстро превращает сравнительно несложную задачу в проект
на сотню (и больше) тысяч строк. Я это сейчас у себя на работе в очередной раз
наблюдаю.
Вообще, когда я встречаю в программистском тексте слово "парадигма" в
положительном смысле, для меня это признак того, что данный текст с весьма
высокой вероятностью является туфтой.
А С++ - и в самом деле - суксь редкостная. В отличие от Java - Java это простой
язык, по своему статусу напоминающий нечто среднее между C и Pascal: по
дизайнерским установкам авторов он близок к Pascal - маленький, простой и
логичный. C C его сближают развитые библиотеки. А его тотальная объектность не
слишком существенна - это в основном дань современной моде (как и фигурные
скобки).
Anton
Sergio Baca
Saturday November 20 1999 18:02, Vitaly Lugovsky wrote to Sergio Baca:
SB>>>> Да что вы споpите? :) Самый классный скpиптовый язык это
SB>>>> Python. Это полностью ОО скpиптовый язык, котоpый как нельзя
SB>>>> лучше подходит для RAD. Есть
VL>>> Хе. ОО - sucks!
SB>> Я могу оценивать это только как высказывания человека так и не
SB>> научившегося ездить на велосипедах, что велосипеды сакс :)
VL> Паpдон. Я хотел сказать - ООП sucks. Пpотив ООД ничего не имею.
А в чем конкpетно его sucks?
VL>>> Питон не функциональный, и по этой пpичине - сосет.
SB>> Hу дай опpеделение функциональности :)
VL> Хм... Зачем? Чеpча почитай, МакКаpти.
Hу кpатко, в нескольких словах.
Sergio
Vitaly Lugovsky
VL>>>> Хе. ОО - sucks!
SB>>> Я могу оценивать это только как высказывания человека так и не
SB>>> научившегося ездить на велосипедах, что велосипеды сакс :)
VL>> Паpдон. Я хотел сказать - ООП sucks. Пpотив ООД ничего не имею.
SB> А в чем конкpетно его sucks?
В том, что им все щели не заткнешь, как некоторые предлогают. Это
просто одна из технологий, а не Величайшая Панацея От Всего.
И область применения ООП достаточно узка. Так что sucks заключается
в том, что его _навязывают_ к употреблению.
VL>>>> Питон не функциональный, и по этой пpичине - сосет.
SB>>> Hу дай опpеделение функциональности :)
VL>> Хм... Зачем? Чеpча почитай, МакКаpти.
SB> Hу кpатко, в нескольких словах.
В качестве примера: чисто функциональная программа на SML.
-------
(* Conversion to Roman numerals. ses...@dina.kvl.dk
This problem can be solved the same way as paying an amount of money
using as large bills as possible. The legal letter combinations (`bills')
are
M, CM, D, CD, C, XC, L, XL, X, IX, V, IV, I
with values
1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1
*)
local
val romannum =
[(1000, "M"), (900, "CM"), (500, "D"), (400, "CD"),
(100, "C"), (90, "XC"), (50, "L"), (40, "XL"),
(10, "X"), (9, "IX"), (5, "V"), (4, "IV"), (1, "I")]
fun choose (n : int, []) = []
| choose (n, romans as ((s, name) :: romanr)) =
if n >= s then name :: choose(n - s, romans) else choose(n, romanr)
in
fun roman n = concat (choose (n, romannum))
end
------
IMHO, красиво. А теорию коротко расписать не получится.
Vitaly Lugovsky
NVB>>> Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне
NVB>>> даже ничего ;)
VL>> Hу почему? ООД - это ведь то же самое модульное программирование и
VL>> проектирование сверху вниз. А вот ООП - это использование об`ектной
VL>> парадигмы на _всех_ уровнях детализации,
DS> "Велосипеды сакс потому что сидя на велосипеде неудобно спать, мыть руки перед
DS> едой и забивать гвозди микроскопом."
Естественно, я бы предпочел аналог велосипеда, которые предоставляем
мне еще и все эти перечисленные возможности ;)
VL>> это использование идиотских язычков вроде C++
DS> Руки прочь от лучшего в мире макроассемблера! :)
Не. MACRO-11 - лучший. И, что смешно, портабельный.
Vitaly Lugovsky
AT>>> Человек, котоpый утвеpждает это с подобным апломбом, должен иметь за
AT>>> плечами несколько пpоектов на сотню тысяч стpок. Это так ? Где можно
AT>>> посмотpеть на эти пpоекты ?
AT> Только вот гложет сомнение - неужели вычислительные задачи на сотню тысяч стpок
AT> писались на каком-то функциональном языке ?
Зачем так жестоко? А Фортран на что? На всем из себе функциональном языке
Mathematica писалась только морда, и небольшая часть вычислений.
AT>>> Да, вовсе необязательно использовать объектную паpадигму на всех
AT>>> уpовнях.
VL>> Это тогда не ООП будет. Все проповедники ООП, как один, кричат о том,
VL>> что все - об`екты, и что выход за рамки об`ектной парадигмы - грех
VL>> великий, и за него - расстрел на месте.
AT> Есть пpоповедники и есть жизнь. Пpоповедники FP кpичат, что ООП - суксь, но это
AT> не мешает его использовать.
AT> Я все-таки не понимаю. Вот пишу я на, скажем, пеpле. И возникает у меня в
AT> пpогpамме объект. Весь из себя объектный, инкапсулиpованный, полимоpфный и все
AT> такое пpочее. Я его холю, лелею и юзаю. Это ООП или нет ?
Нет конечно. Вот если в программе все - об`екты, то тогда это - суксьный
ООП. А так - можно и не заметить, что есть какой-то там об`ект.
Nikita V. Belenki
Saturday November 20 1999 22:56, Vitaly Lugovsky wrote to Nikita V Belenki:
VL>>>>> Хе. ОО - sucks!
SB>>>> Я могу оценивать это только как высказывания человека так и не
SB>>>> научившегося ездить на велосипедах, что велосипеды сакс :)
VL>>> Пардон. Я хотел сказать - ООП sucks. Против ООД ничего не
VL>>> имею.
NVB>> Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне
NVB>> даже ничего ;)
VL> Hу почему? ООД - это ведь то же самое модульное программирование и
VL> проектирование сверху вниз.
Даже если это было бы всего лишь новое название старого подхода (что не так),
это мастдай хотя бы потому, что это новое название старого подхода.
Практически же это более _ограниченная_ версия старого подхода, под новым
маркетинговым соусом.
VL> А вот ООП - это использование об`ектной парадигмы на _всех_ уровнях
VL> детализации, это использование идиотских язычков вроде C++ или Жабы.
VL> Короче, полный суксь...
"Полный суксь" -- это претензии к молотку, что он вместо гвоздей бъёт по
пальцам. Hе умеешь пользоваться инструментом -- не пользуйся. Забивай гвозди
подушкой.
Kit.
Vitaly Lugovsky
VL>> детализации, это использование идиотских язычков вроде C++ или Жабы.
VL>> Короче, полный суксь...
NVB> "Полный суксь" -- это претензии к молотку, что он вместо гвоздей бъёт по
NVB> пальцам. Hе умеешь пользоваться инструментом -- не пользуйся. Забивай гвозди
NVB> подушкой.
Не, предпочитаю делать на гвоздях резьбу, и ввинчивать. Грохоту меньше,
и держит надежнее ;)
Victor V. Metelitsa
20 Nov 99, Vitaly Lugovsky написал(а|o) Nikita V Belenki:
[...]
NVB>> Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне
NVB>> даже ничего ;)
VL> Hу почему? ООД - это ведь то же самое модульное программирование и
VL> проектирование сверху вниз.
(1)
VL> А вот ООП - это использование об`ектной
VL> парадигмы на _всех_ уровнях детализации,
(2)
VL> это использование
VL> идиотских язычков вроде C++ или Жабы. Короче, полный суксь...
C++ суксь, но потому (кроме всего прочего), что оно не настоящий ОО-язык. Какой
там ООП на C++??? Уродство сплошное. А ведь давным-давно придумали нормальный
язык, Smalltalk называется.
ВВМ/13.
Nikita V. Belenki
Tuesday November 23 1999 20:52, Victor V. Metelitsa wrote to Vitaly Lugovsky:
VVM> C++ суксь, но потому (кроме всего прочего), что оно не настоящий
VVM> ОО-язык. Какой там ООП на C++??? Уродство сплошное. А ведь
VVM> давным-давно придумали нормальный язык, Smalltalk называется.
Опус Бочарова про лампочку помнишь? Вот так и у тебя с C++ ;)
Kit.
Serge Shikov
>
> DS> Руки прочь от лучшего в мире макроассемблера! :)
>
> Не. MACRO-11 - лучший. И, что смешно, портабельный.
потом признались под пытками, что нифига ASM/360 не знают. Проверять бум
или ты тоже кроме МАКРО-11 ничего не знаешь?
Vitaly Lugovsky
>> DS> Руки прочь от лучшего в мире макроассемблера! :)
>>
>> Не. MACRO-11 - лучший. И, что смешно, портабельный.
SS> потом признались под пытками, что нифига ASM/360 не знают. Проверять бум
SS> или ты тоже кроме МАКРО-11 ничего не знаешь?
hint: имелся в виду VAX Macro-11. Со всеми соответствующими наворотами.
И он - ПЕРЕНОСИМЫЙ. В то, что я могу, к примеру, на Альфе скомпилить
программу на ASM/360 - я не верую.
Anton Moscal
> AT>> уpовнях.
> VL> Это тогда не ООП будет. Все проповедники ООП, как один, кричат о том,
> VL> что все - об`екты, и что выход за рамки об`ектной парадигмы - грех
> VL> великий, и за него - расстрел на месте.
> Есть пpоповедники и есть жизнь. Пpоповедники FP кpичат, что ООП - суксь, но это
> не мешает его использовать.
ООП примерно такая суксь как любая другая парадигма (включая FP). Все эти
попытки придумать единственно правильный способ программирования - по
больному счету - фигня.
ML хорош не тем, что функциональный, а тем что удобный. Причем удобства к
функциональности имеют мало отношения (а те, что имеют - в основном
косвенное: например использование присваиваний в ML херит полиморфизм в
тех местах, где они используются, херит по причинам чисто техническим, а
не высокоидейным)
У меня к нему отношение видимо примерно, как у тебя - к Perlу
Антон
Nikita V. Belenki
Wednesday November 24 1999 11:48, Serge Shikov wrote to All:
>> DS> Руки прочь от лучшего в мире макроассемблера! :)
>> Hе. MACRO-11 - лучший. И, что смешно, портабельный.
SS> Hу-ну. Мне уже кое-кто пытался доказать, что ASM/360 хуже МАКРО-11. А
SS> потом признались под пытками, что нифига ASM/360 не знают. Проверять
SS> бум или ты тоже кроме МАКРО-11 ничего не знаешь?
А вот сейчас ты попал. Рассказывай, что ты писал на _ваксовом_ MACRO-11 ;)
Kit.
Nikita V. Belenki
Tuesday November 23 1999 14:55, Vitaly Lugovsky wrote to Nikita V Belenki:
VL>>> А вот ООП - это использование об`ектной парадигмы на _всех_
VL>>> уровнях детализации, это использование идиотских язычков вроде
VL>>> C++ или Жабы. Короче, полный суксь...
NVB>> "Полный суксь" -- это претензии к молотку, что он вместо гвоздей
NVB>> бъёт по пальцам. Hе умеешь пользоваться инструментом -- не
NVB>> пользуйся. Забивай гвозди подушкой.
VL> Hе, предпочитаю делать на гвоздях резьбу, и ввинчивать. Грохоту
VL> меньше, и держит надежнее ;)
Типа, отвёрткой пользоваться уметь не надо? ;)
Kit.
Alex Tutubalin
AM> ООП примерно такая суксь как любая другая парадигма (включая FP). Все эти
AM> попытки придумать единственно правильный способ программирования - по
AM> больному счету - фигня.
И да и нет. Пpо эти пpавильные способы пишут пpавильные книжки (как их выбpать
из общей кучи - дpугой вопpос), котоpые можно почитать на ночь.
Hо я собственно о дpугом. Суксь или не суксь может pешить только человек,
котоpый конкpетный способ (паpадигму :) пытался использовать от души т.е. хотя
бы сотню-дpугую тысяч стpок написавший.
Alex Tutubalin
http://www.lexa.ru/lexa/
Vitaly Lugovsky
>>> Hе. MACRO-11 - лучший. И, что смешно, портабельный.
SS>> Hу-ну. Мне уже кое-кто пытался доказать, что ASM/360 хуже МАКРО-11. А
SS>> потом признались под пытками, что нифига ASM/360 не знают. Проверять
SS>> бум или ты тоже кроме МАКРО-11 ничего не знаешь?
NVB> А вот сейчас ты попал. Рассказывай, что ты писал на _ваксовом_ MACRO-11 ;)
Пардон, просто Macro. Путаю постоянно... У них там везде эта дурацкая
'11'. :(
Serge Shikov
>
> >> DS> Руки прочь от лучшего в мире макроассемблера! :)
> >>
> SS> Ну-ну. Мне уже кое-кто пытался доказать, что ASM/360 хуже МАКРО-11. А
> SS> потом признались под пытками, что нифига ASM/360 не знают. Проверять бум
> SS> или ты тоже кроме МАКРО-11 ничего не знаешь?
>
> hint: имелся в виду VAX Macro-11. Со всеми соответствующими наворотами.
> И он - ПЕРЕНОСИМЫЙ.
> В то, что я могу, к примеру, на Альфе скомпилить
> программу на ASM/360 - я не верую.
Кросс-средства никто не отменял. Хотя и непонятно, нафига оно в данном
случае.
А вообще надо было четче формулировать, что значит "лучший". Я вот тоже
вряд ли смогу скомпилить программу для VAX на i8080, значит МАКРО-11
тоже весьма ограниченно переносимый ;-) Уж всяко он хуже переносится,
чем C++, с которого все и началось. В _этом_ смысле (как сорт
ассемблера) C/C++ все-таки лучше.
koval
Vitaly Lugovsky wrote:
> Nikita V. Belenki <Nikita.V...@p28.f251.n5030.z2.fidonet.org> wrote:
> VL>>>> Хе. ОО - sucks!
> SB>>> Я могу оценивать это только как высказывания человека так и не
> SB>>> научившегося ездить на велосипедах, что велосипеды сакс :)
> VL>> Пардон. Я хотел сказать - ООП sucks. Против ООД ничего не имею.
>
> NVB> Ты всё перепутал. Это ООД сакс. А ООП (в разумных дозах) вполне даже ничего ;)
>
> Ну почему? ООД - это ведь то же самое модульное программирование и
> проектирование сверху вниз. А вот ООП - это использование об`ектной
> парадигмы на _всех_ уровнях детализации, это использование
> идиотских язычков вроде C++ или Жабы. Короче, полный суксь...
> ------------------------------------------------------------
Привет всем.
Объясните кто-нибудь, чем так плох С++. До выхода на эту конфу я вообще
не думал, что у него достойные конкуренты есть.
Vitaly Lugovsky
k> Привет всем.
k> Объясните кто-нибудь, чем так плох С++. До выхода на эту конфу я вообще
k> не думал, что у него достойные конкуренты есть.
О, у него масса недостатков. Этот язык - просто дополнение к C, и
унаследовал большую часть недостатков C. Можно долго рассуждать о том, что
он не то чтобы совсем ООПный язык, что он - винигрет из всего подряд, что он
всего лишь макроассемблер, что в C++ отсутствует должная строгость
типизации, и т.д. Но здесь разговор не об том идет. Речь идет о том,
что ООП - не есть нечто особенное и необходимое, что от императивных языков,
таких, как C++, далеко не всегда есть толк, и что во многих случаях FP
намного лучше подходит для решения задачи, чем ООП, далеко не лучшим
представителем коего и является C++.
--
Victor V. Metelitsa
Gotta be a spoof, but amusing none the less...
On the 1st of January, 1998, Bjarne Stroustrup gave an interview
to the IEEE's 'Computer' magazine.
Naturally, the editors thought he would be giving a retrospective
view of seven years of object-oriented design, using the language
he created.
By the end of the interview, the interviewer got more than he had
bargained for and, subsequently, the editor decided to suppress its
contents, 'for the good of the industry' but, as with many of these
things, there was a leak.
Here is a complete transcript of what was was said, unedited, and
unrehearsed, so it isn't as neat as planned interviews.
You will find it interesting...
__________________________________________________________________
Interviewer: Well, it's been a few years since you changed the
world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before
you arrived. Do you remember? Everyone was writing 'C'
and, the trouble was, they were pretty damn good at it.
Universities got pretty good at teaching it, too. They were
turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate. That's what caused the
problem.
Interviewer: Problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods.
Their salaries were high, and they were treated like royalty.
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and
invested millions in training programmers, till they were a
dime a dozen.
Interviewer: That's why I got out. Salaries dropped within a year,
to the point where being a journalist actually paid better.
Stroustrup: Exactly. Well, the same happened with 'C' programmers.
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I
thought of this little scheme, which would redress the
balance a little. I thought 'I wonder what would happen, if
there were a language so complicated, so difficult to learn,
that nobody would ever be able to swamp the market with
programmers? Actually, I got some of the ideas from X10,
you know, X windows. That was such a bitch of a graphics
system, that it only just ran on those Sun 3/60 things.
They had all the ingredients for what I wanted. A really
ridiculously complex syntax, obscure functions, and
pseudo-OO structure. Even now, nobody writes raw X-windows
code. Motif is the only way to go if you want to retain
your sanity.
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem.
Unix was written in 'C', which meant that any 'C' programmer
could very easily become a systems programmer. Remember
what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do.
Stroustrup: OK, so this new language had to divorce itself from
Unix, by hiding all the system calls that bound the two
together so nicely. This would enable guys who only knew
about DOS to earn a decent living too.
Interviewer: I don't believe you said that...
Stroustrup: Well, it's been long enough, now, and I believe most
people have figured out for themselves that C++ is a waste
of time but, I must say, it's taken them a lot longer than I
thought it would.
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought
people would take the book seriously. Anyone with half a
brain can see that object-oriented programming is
counter-intuitive, illogical and inefficient.
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear
of a company re-using its code?
Interviewer: Well, never, actually, but...
Stroustrup: There you are then. Mind you, a few tried, in the
early days. There was this Oregon company - Mentor
Graphics, I think they were called - really caught a cold
trying to rewrite everything in C++ in about '90 or '91. I
felt sorry for them really, but I thought people would learn
from their mistakes.
Interviewer: Obviously, they didn't?
Stroustrup: Not in the slightest. Trouble is, most companies
hush-up all their major blunders, and explaining a $30
million loss to the shareholders would have been difficult.
Give them their due, though, they made it work in the end.
Interviewer: They did? Well, there you are then, it proves O-O works.
Stroustrup: Well, almost. The executable was so huge, it took
five minutes to load, on an HP workstation, with 128MB of
RAM. Then it ran like treacle. Actually, I thought this
would be a major stumbling-block, and I'd get found out
within a week, but nobody cared. Sun and HP were only too
glad to sell enormously powerful boxes, with huge resources
just to run trivial programs. You know, when we had our
first C++ compiler, at AT&T, I compiled 'Hello World', and
couldn't believe the size of the executable. 2.1MB
Interviewer: What? Well, compilers have come a long way, since then.
Stroustrup: They have? Try it on the latest version of g++ - you
won't get much change out of half a megabyte. Also, there
are several quite recent examples for you, from all over the
world. British Telecom had a major disaster on their hands
but, luckily, managed to scrap the whole thing and start
again. They were luckier than Australian Telecom. Now I
hear that Siemens is building a dinosaur, and getting more
and more worried as the size of the hardware gets bigger, to
accommodate the executables. Isn't multiple inheritance a joy?
Interviewer: Yes, but C++ is basically a sound language.
Stroustrup: You really believe that, don't you? Have you ever sat
down and worked on a C++ project? Here's what happens:
First, I've put in enough pitfalls to make sure that only
the most trivial projects will work first time. Take
operator overloading. At the end of the project, almost
every module has it, usually, because guys feel they really
should do it, as it was in their training course. The same
operator then means something totally different in every
module. Try pulling that lot together, when you have a
hundred or so modules. And as for data hiding. God, I
sometimes can't help laughing when I hear about the problems
companies have making their modules talk to each other. I
think the word 'synergistic' was specially invented to twist
the knife in a project manager's ribs.
Interviewer: I have to say, I'm beginning to be quite appalled at
all this. You say you did it to raise programmers'
salaries? That's obscene.
Stroustrup: Not really. Everyone has a choice. I didn't expect
the thing to get so much out of hand. Anyway, I basically
succeeded. C++ is dying off now, but programmers still get
high salaries - especially those poor devils who have to
maintain all this crap. You do realise, it's impossible to
maintain a large C++ software module if you didn't actually
write it?
Interviewer: How come?
Stroustrup: You are out of touch, aren't you? Remember the typedef?
Interviewer: Yes, of course.
Stroustrup: Remember how long it took to grope through the header
files only to find that 'RoofRaised' was a double precision
number? Well, imagine how long it takes to find all the
implicit typedefs in all the Classes in a major project.
Interviewer: So how do you reckon you've succeeded?
Stroustrup: Remember the length of the average-sized 'C' project?
About 6 months. Not nearly long enough for a guy with a
wife and kids to earn enough to have a decent standard of
living. Take the same project, design it in C++ and what do
you get? I'll tell you. One to two years. Isn't that
great? All that job security, just through one mistake of
judgement. And another thing. The universities haven't
been teaching 'C' for such a long time, there's now a
shortage of decent 'C' programmers. Especially those who
know anything about Unix systems programming. How many guys
would know what to do with 'malloc', when they've used 'new'
all these years - and never bothered to check the return
code. In fact, most C++ programmers throw away their return
codes. Whatever happened to good ol' '-1'? At least you
knew you had an error, without bogging the thing down in all
that 'throw' 'catch' 'try' stuff.
Interviewer: But, surely, inheritance does save a lot of time?
Stroustrup: Does it? Have you ever noticed the difference between
a 'C' project plan, and a C++ project plan? The planning
stage for a C++ project is three times as long. Precisely
to make sure that everything which should be inherited is,
and what shouldn't isn't. Then, they still get it wrong.
Whoever heard of memory leaks in a 'C' program? Now finding
them is a major industry. Most companies give up, and send
the product out, knowing it leaks like a sieve, simply to
avoid the expense of tracking them all down.
Interviewer: There are tools...
Stroustrup: Most of which were written in C++.
Interviewer: If we publish this, you'll probably get lynched, you
do realise that?
Stroustrup: I doubt it. As I said, C++ is way past its peak now,
and no company in its right mind would start a C++ project
without a pilot trial. That should convince them that it's
the road to disaster. If not, they deserve all they get. You
know, I tried to convince Dennis Ritchie to rewrite Unix in C++.
Interviewer: Oh my God. What did he say?
Stroustrup: Well, luckily, he has a good sense of humor. I think
both he and Brian figured out what I was doing, in the early
days, but never let on. He said he'd help me write a C++
version of DOS, if I was interested.
Interviewer: Were you?
Stroustrup: Actually, I did write DOS in C++, I'll give you a demo
when we're through. I have it running on a Sparc 20 in the
computer room. Goes like a rocket on 4 CPU's, and only
takes up 70 megs of disk.
Interviewer: What's it like on a PC?
Stroustrup: Now you're kidding. Haven't you ever seen Windows '95?
I think of that as my biggest success. Nearly blew the game
before I was ready, though.
Interviewer: You know, that idea of a Unix++ has really got me
thinking. Somewhere out there, there's a guy going to try it.
Stroustrup: Not after they read this interview.
Interviewer: I'm sorry, but I don't see us being able to publish
any of this.
Stroustrup: But it's the story of the century. I only want to be
remembered by my fellow programmers, for what I've done for
them. You know how much a C++ guy can get these days?
Interviewer: Last I heard, a really top guy is worth $70 - $80 an
hour.
Stroustrup: See? And I bet he earns it. Keeping track of all the
gotchas I put into C++ is no easy job. And, as I said
before, every C++ programmer feels bound by some mystic
promise to use every damn element of the language on every
project. Actually, that really annoys me sometimes, even
though it serves my original purpose. I almost like the
language after all this time.
Interviewer: You mean you didn't before?
Stroustrup: Hated it. It even looks clumsy, don't you agree? But
when the book royalties started to come in... well, you get
the picture.
Interviewer: Just a minute. What about references? You must
admit, you improved on 'C' pointers.
Stroustrup: Hmm. I've always wondered about that. Originally, I
thought I had. Then, one day I was discussing this with a
guy who'd written C++ from the beginning. He said he could
never remember whether his variables were referenced or
dereferenced, so he always used pointers. He said the
little asterisk always reminded him.
Interviewer: Well, at this point, I usually say 'thank you very
much' but it hardly seems adequate.
Stroustrup: Promise me you'll publish this. My conscience is
getting the better of me these days.
Interviewer: I'll let you know, but I think I know what my editor
will say.
Stroustrup: Who'd believe it anyway? Although, can you send me a
copy of that tape?
Interviewer: I can do that.
Maxim Friedental
Vitaly Lugovsky wrote to koval:
VL> Речь идет о том, что ООП - не есть нечто особенное и необходимое, что
VL> от императивных языков, таких, как C++, далеко не всегда есть толк, и
VL> что во многих случаях FP намного лучше подходит для решения задачи,
VL> чем ООП, далеко не лучшим представителем коего и является C++.
Из чего совершенно не следует, что ООП - суксь. А вообще говоря, с этого нужно
было начинать. А то как-то странно народ собрался сравнивать языки, не задав
при этом прикладную область. Которых можно назвать по крайней мере пять:
1. Системные задачи - работа с железом, реальным временем, протоколами
2. Информационные системы - относительно простые алгоритмы обработки множества
объектов
3. Математические задачи - мат.модели, цифровая обработка сигналов, символьные
и численные вычисления
4. Инструментальные задачи - трансляторы, парсеры, фильтры...
5. Скрипты
Понятно, что сравнивать языки, предназначенные для решения задач разных
областей совершенно бессмысленно... Так в какой области работают многоуважаемые
участники дискуссии под данным сабжем?
See you.
Serguey Zefirov
Friday November 26 1999 01:32, Maxim Friedental wrote to Vitaly Lugovsky:
VL>> Речь идет о том, что ООП - не есть нечто особенное и необходимое,
VL>> что от императивных языков, таких, как C++, далеко не всегда есть
VL>> толк, и что во многих случаях FP намного лучше подходит для
VL>> решения задачи, чем ООП, далеко не лучшим представителем коего и
VL>> является C++.
MF> Из чего совершенно не следует, что ООП - суксь. А вообще говоря, с
MF> этого нужно было начинать. А то как-то странно народ собрался
MF> сравнивать языки, не задав при этом прикладную область. Которых можно
MF> назвать по крайней мере пять:
MF> 1. Системные задачи - работа с железом, реальным временем,
MF> протоколами
www.tunes.org - народ собрался писать ОС на FP. (Что-то типа Схемы)
MF> 2. Информационные системы - относительно простые алгоритмы обработки
MF> множества объектов
Здесь основная задача - писать как можно более короткие программы. Что и имеем,
используя FP. ;)
MF> 3. Математические задачи - мат.модели, цифровая обработка сигналов,
MF> символьные и численные вычисления
Hу, если едва ли не основной операцией является обработка списков - то насчет
символьных вычислений все понятно. В списке ссылок на готовые программы на
Haskell есть творения, используемого для моделирования процессов ЦОС.
Я сам подумываю о том, чтобы прикрутить Haskell(или что еще) к DSP.
MF> 4. Инструментальные задачи - трансляторы, парсеры, фильтры...
ghc - Glasgow Haskell Compiler.
MF> 5. Скрипты
hugs, OCaml байт-код. В исходниках hugs есть haskell server - ядро hugs,
которое можно использовать в своих программах.
MF> Понятно, что сравнивать языки, предназначенные для решения
MF> задач разных областей совершенно бессмысленно... Так в какой области
MF> работают многоуважаемые участники дискуссии под данным сабжем?
А не все ли равно?
Если язык в состоянии сам понять, какой тип данных я вычисляю, и из переменных
какого типа - то он явно впереди C/C++, где тип надо указывать, на что тратятся
и время, и еще время.
К тому же в Haskell есть классы, но нет объектов - чем он меня и радует. ;)
Bye.
Serguey
Anton Moscal
> VL> Речь идет о том, что ООП - не есть нечто особенное и необходимое, что
> VL> от императивных языков, таких, как C++, далеко не всегда есть толк, и
> VL> что во многих случаях FP намного лучше подходит для решения задачи,
> VL> чем ООП, далеко не лучшим представителем коего и является C++.
> Из чего совершенно не следует, что ООП - суксь. А вообще говоря, с этого нужно
> было начинать. А то как-то странно народ собрался сравнивать языки, не задав
> при этом прикладную область. Которых можно назвать по крайней мере пять:
> 1. Системные задачи - работа с железом, реальным временем, протоколами
ОО может бы и ничего - но в реальном времени не катит.
> 2. Информационные системы - относительно простые алгоритмы обработки множества
> объектов
Здесь оно может быть уместно
> 3. Математические задачи - мат.модели, цифровая обработка сигналов, символьные
> и численные вычисления
Здесь оно IMHO противопоказано. ОО просто неадекватно математическим
понятиям. Опять же - тут часто бывает надо получение максимальную
эффективность.
> 4. Инструментальные задачи - трансляторы, парсеры, фильтры...
Тут я вполне компетентно могут заявить - в трансляторах ОО абсолютно не в
тему. Единственный сереьезный пример использования ОО - SUIF, от которого
плеваться хочется. Авторы Zephyr произвели опыт - при переписывании
иерархии классов SUIF на ML объем текста сокращается в 20 раз :)
> 5. Скрипты
Вроде тоже не в тему, хотя тут можно съесть все, что угодно - главное,
чтобы писалось коротко и хорошая строковая обработка была.
Интересно где же ОО - rulez? Я так сходу могу про всякую GUI вспомнить.
А еще?
Антон
Maxim Friedental
Serguey Zefirov wrote to Maxim Friedental:
MF>> Понятно, что сравнивать языки, предназначенные для решения
MF>> задач разных областей совершенно бессмысленно... Так в какой области
MF>> работают многоуважаемые участники дискуссии под данным сабжем?
SZ> А не все ли равно?
Понятно, что есть языки, которые можно использовать сразу в нескольких
областях. Понятно, что даже есть языки, которые можно с той или иной степенью
изврата использовать во всех областях.
Hо я считаю, что более правильный вариант поведения программера - подыскивать
под себя и под конкретную предметную область оптимальный язык. И наоборот, я не
вижу плюса в том, чтобы минимизировать количество изученных языков - чем больше
разнообразных языков знает программер, тем разнообразнее у него возможные
взгляды на решение проблемы.
SZ> Если язык в состоянии сам понять, какой тип данных я вычисляю, и из
SZ> переменных какого типа - то он явно впереди C/C++, где тип надо указывать,
SZ> на что тратятся и время, и еще время.
Для меня (я пишу клиент-серверные приложения) это тоже скорее рулез. Hу а для
системного софта, особенно общающегося с железом - скорее сакс.
See you.
Maxim Friedental
Anton Moscal wrote to Maxim Friedental:
>> Из чего совершенно не следует, что ООП - суксь. А вообще говоря, с этого
>> нужно было начинать. А то как-то странно народ собрался сравнивать языки,
>> не задав при этом прикладную область. Которых можно назвать по крайней
>> мере пять: 1. Системные задачи - работа с железом, реальным временем,
>> протоколами
AM> ОО может бы и ничего - но в реальном времени не катит.
Согласен.
>> 2. Информационные системы - относительно простые алгоритмы обработки
>> множества объектов
AM> Здесь оно может быть уместно
Даже больше - одна из лучших областей для применения ОО, IMHO.
>> 3. Математические задачи - мат.модели, цифровая обработка сигналов,
>> символьные и численные вычисления
AM> Здесь оно IMHO противопоказано. ОО просто неадекватно математическим
AM> понятиям.
Совершенно согласен.
>> 4. Инструментальные задачи - трансляторы, парсеры, фильтры...
AM> Тут я вполне компетентно могут заявить - в трансляторах ОО абсолютно не в
AM> тему.
Угу.
>> 5. Скрипты
AM> Вроде тоже не в тему, хотя тут можно съесть все, что угодно - главное,
AM> чтобы писалось коротко и хорошая строковая обработка была.
IMHO здесь поддержка ООП не помешает. В конце-концов, не нравится - не ешь :)
AM> Интересно где же ОО - rulez?
Как где? А информационные-то системы? Я так нескромно берусь предположить, что
большинство прикладных программистов ими и занимается...
В том числе и я, собственно потому я и влез в обсуждение, что была резкая и
неаргументированная критика ОО, причем без указания предметной области.
See you.
Nikita V. Belenki
Thursday November 25 1999 18:10, Victor V. Metelitsa wrote to Nikita V.
Belenki:
VVM> :-)
VVM> Gotta be a spoof, but amusing none the less...
Фраза, хорошо сочетающаяся с сабжем ;)
Kit.
Alex Tutubalin
MF> Hо я считаю, что более
MF> правильный вариант поведения программера - подыскивать под себя и под
MF> конкретную предметную область оптимальный язык. И наоборот, я не вижу
MF> плюса в том, чтобы минимизировать количество изученных языков - чем больше
Да ну нафиг.
"Я считаю, что более пpавильный ваpиант поведения писателя/жуpналиста -
подыскивать под конкpетное пpоизведение оптимальный (человеческий) язык".
Hоpмально звучит ? Hа мой взгляд, диковато т.к. оптимальным языком является
тот, котоpым владеешь наилучшим обpазом. Да, встpечаются pедкие случаи
полиглотов, но кpайне малый пpоцент людей может использовать больше 2-3
(человеческих) языков с хоpошей эффективностью.
Так вот, пpогpаммиpование - это аккуpатное выpажение мыслей на некоем
специальном языке. Естественно, существуют понятия, котоpые невозможно или
очень тpудно выpазить на pусском (пеpевод поэмы с эскимосского языка о 40 видах
льда), pавно как стpанно было бы писать ядpо юникса на Delphi, но если нет
совсем уж экзотики, то подходит любой язык. Вот и в пpогpаммиpовании пpоисходит
пpимеpно так.
А что касается пpедложенного паpу писем назад "деления по тематикам", то мне
сложно сходу вспомнить неунивеpсальный совpеменный (доживший до сегодня) язык
пpогpаммиpования. То, что ОС-ы не пишут на C++ свидетельствует скоpее о том,
что писателям ОС-ов этот язык не нpавится т.к. каких-либо пpинципиальных
пpотивопоказаний не видно (загляните в ядpо какого-нибудь юникса - это
очевидный "C с классами" pеализованный на чистом C). Hесложные вычислительные
задачи я с успехом делаю на пеpле (PDL:), пpичем это постпpоцессинг того, что
насчитала C++-ная счетная пpогpамма (более того, OO-numeric сейчас достаточно
популяpный топик и даже такая уважаемая фиpма как NAG выпустила плюсовую веpсию
своей известной фоpтpановской библиотеки). MySQL (не к ночи будь помянут) имеет
заметную часть своего SQL-ного engine (кажется паpсеp, но вот не помню точно)
тоже на C++, что не мешает ему pаботать.
Я собственно к тому, что выбоp языка на котоpом пишутся доки, pавно как и выбоp
языка на котоpом пишется пpогpамма к этим докам, опpеделяется чаще некими
сообpажениями, котоpые не связаны впpямую с "пpигодностью" данных языков для
описания соответствующей пpедметной области.
Да, я не великий знаток FP, соответственно об этой части судить пpосто не могу.
Alex Tutubalin
http://www.lexa.ru/lexa/
p.s. Об инфоpмационных системах и клиент-сеpвеpах. CGI-скpипты подходят под оба
опpеделения.
Anton Moscal
> SZ> Если язык в состоянии сам понять, какой тип данных я вычисляю, и из
> SZ> переменных какого типа - то он явно впереди C/C++, где тип надо указывать,
> SZ> на что тратятся и время, и еще время.
> Для меня (я пишу клиент-серверные приложения) это тоже скорее рулез. Hу а для
> системного софта, особенно общающегося с железом - скорее сакс.
Речь скорее всего не идет о отсутствии строгой типизации. Речь о том, что
грамотно спроектированный язык вполне способен сам понять, что в let x = 1
x - целочисленная константа. По моему ML-ному опыту контроль даже
надежнее, так как изобилие явных указаний типа приводит в С/С++ (для и
почти во всех языках, где типы надо везде задавть явно) к возникновению
системы неявных преобразований типа, с весьма неочевидной семантикой,
тогда как в ML как ни странно, ошибок с типами практически не бывает.
Антон
Anton Moscal
> MF> назвать по крайней мере пять:
> MF> 1. Системные задачи - работа с железом, реальным временем,
> MF> протоколами
> www.tunes.org - народ собрался писать ОС на FP. (Что-то типа Схемы)
Уж тогда лучше Erlang вспомнить - Ericson на нем свое железо
программирует. Erlang, кстати, на мой взгляд очень красивый язык. Крайне
простой и мощный (но динамически типизированный).
> MF> 2. Информационные системы - относительно простые алгоритмы обработки
> MF> множества объектов
> Здесь основная задача - писать как можно более короткие программы. Что и имеем,
> используя FP. ;)
> MF> 3. Математические задачи - мат.модели, цифровая обработка сигналов,
> MF> символьные и численные вычисления
> Hу, если едва ли не основной операцией является обработка списков - то насчет
> символьных вычислений все понятно. В списке ссылок на готовые программы на
> Haskell есть творения, используемого для моделирования процессов ЦОС.
> Я сам подумываю о том, чтобы прикрутить Haskell(или что еще) к DSP.
У Haskell совершенно безобразная эффективность. Уж если на то пошло -
лучше Clean посмотреть. Язык от Haskell мало чем отличающийся (монад там
нет, но классы типов есть - так что можно и описать), но с намного более
быстрой реализацией (и транслятор шустро бегает). Но у меня все равно
сомнения - даже O'Caml (кой видимо в целом дает самые эффективные
программы) для критических по скорости вычислений не слишком подходит.
Хотя прототипы на Haskell писать - должно быть просто замечательно.
> MF> 4. Инструментальные задачи - трансляторы, парсеры, фильтры...
> ghc - Glasgow Haskell Compiler.
Там FP вообще нежно любят. GHC впрочем у меня не вызывает дикого восторга.
Вообще IMHO Haskell'исты и авторы SML/NJ очень сильно дискредитировали
FP своими крайне тяжеловесными и неэффективными системами (причем не по
делу тяжеловесными - см. Clean и O'Caml). Причем их системы - самые
заметные, я помню свои впечатления от первого знакомства с ними - что "да,
это все очень красиво, но пользоваться этим нельзя".
> MF> 5. Скрипты
> hugs, OCaml байт-код. В исходниках hugs есть haskell server - ядро hugs,
> которое можно использовать в своих программах.
На мой взгляд они для этого не слишком подходять. Разве что hugs.
Антон
Maxim Friedental
Alex Tutubalin wrote to Maxim Friedental:
MF>> Hо я считаю, что более правильный вариант поведения программера -
MF>> подыскивать под себя и под конкретную предметную область оптимальный
MF>> язык.
AT> "Я считаю, что более пpавильный ваpиант поведения писателя/жуpналиста -
AT> подыскивать под конкpетное пpоизведение оптимальный (человеческий)
AT> язык". Hоpмально звучит ?
Звучит замечательно. Просто твоя аналогия показывает ту же закономерность менее
четко - писатели/журналисты действительно несколько меняют язык в зависимости
от задачи, только это принятно называть разными стилями, а не разными языками.
Впрочем, канцелярит также сильно отличается от поэтически-возвышенного стиля,
как, скажем, C++ от Java.
Если взять другие творческие профессии, там различие можно наблюдать более
ярко. Hапример, художнику далеко не все равно, рисовать акварелью или, скажем,
углем. Музыкант вряд ли будет сочинять марш в исполнении скрипки.
Hу а наука, IMHO, тем более для каждой модели стремится выработать язык,
оптимально ее описывающий.
AT> Hа мой взгляд, диковато т.к. оптимальным языком является тот, котоpым
AT> владеешь наилучшим обpазом. Да, встpечаются pедкие случаи полиглотов,
AT> но кpайне малый пpоцент людей может использовать больше 2-3
AT> (человеческих) языков с хоpошей эффективностью.
IMHO нельзя так вот напрямую сравнивать естественные и искусственные языки.
Сложность в обучении естественным языкам вызвана нелогичностью, нерегулярностью
их структуры, из-за чего очень многое приходится тупо запоминать.
Изучение же языков программирования IMHO наоборот, ускоряется и упрощается с
каждым новым языком.
AT> Так вот, пpогpаммиpование - это аккуpатное выpажение мыслей на некоем
AT> специальном языке.
Конкретный выбранный язык навязывает свои парадигмы уже на этапе
проектирования, когда о программировании еще и речи нет.
AT> если нет совсем уж экзотики, то подходит любой язык.
Конечно, если выбор между C++, Java и Object Pascal, то проектирование
практически не меняется. А если выбор между алгоритмическим и функциональным
языками?
AT> А что касается пpедложенного паpу писем назад "деления по тематикам",
AT> то мне сложно сходу вспомнить неунивеpсальный совpеменный (доживший
AT> до сегодня) язык пpогpаммиpования.
Да, я уже говорил, что существуют языки, на которых можно решить практически
любую задачу, с той или иной степенью _изврата_. Речь идет о том, что, может
быть, при этом возникают ситуации забивания гвоздей микроскопом. Или ситуации
"в гамаке и с противогазом", т.е. создания себе лишних трудностей.
AT> Я собственно к тому, что выбоp языка на котоpом пишутся доки, pавно как и
AT> выбоp языка на котоpом пишется пpогpамма к этим докам, опpеделяется чаще
AT> некими сообpажениями, котоpые не связаны впpямую с "пpигодностью" данных
AT> языков для описания соответствующей пpедметной области.
Угу. И это приходится констатировать с сожалением.
AT> p.s. Об инфоpмационных системах и клиент-сеpвеpах. CGI-скpипты
AT> подходят под оба опpеделения.
Hу да, самый простой способ сделать тонкого клиента - это стандартный
WWW-браузер + CGI. Другое дело, на чем написаны CGI :)
See you.
Maxim Friedental
Anton Moscal wrote to Maxim Friedental:
>> SZ> Если язык в состоянии сам понять, какой тип данных я вычисляю, и из
>> Для меня (я пишу клиент-серверные приложения) это тоже скорее рулез.
AM> Речь скорее всего не идет о отсутствии строгой типизации.
А зря :( _IMHO_ строгая типизация - атавизм времен процедурных языков. Hу не
бывает такого в реальной жизни, чтобы "реальному" объекту соответствовал
фиксированный конкретный тип. По крайней мере, в моих задачах. Во-первых,
существуют различные уровни абстракции (например, в первом приближении некий
объект - double, во втором приближении - формула со связями на другие объекты,
которую нужно уметь считать), во-вторых, существует динамика объектов (у меня,
почему-то, объекты простых типов норовят превратиться в пару значений простых
типов). В C++ начали очень медленно и неохотно уходить от типизации (при помощи
templates), но IMHO пока это все в зачаточном состоянии :(
AM> Речь о том, что грамотно спроектированный язык вполне способен сам
AM> понять, что в let x = 1 x - целочисленная константа.
И это здорово. Между тем, первым мною изученным языком с такой возможностью был
как раз Clipper, и я до сих пор полагаю, что это наилучший язык для написания
процедурных программ в классе информационных систем под ДОС :)
See you.
Ivan_T...@f140.n5080.z2.fidonet.org
AM> Интересно где же ОО - rulez? Я так сходу могу про всякую GUI вспомнить.
AM> А еще?
В игрушках. :) Хотя тут скорее что-то типа оккама бы
помогло.
--
Serguey Zefirov
AT> Так вот, пpогpаммиpование - это аккуpатное выpажение мыслей на некоем
AT> специальном языке. Естественно, существуют понятия, котоpые невозможно
AT> или очень тpудно выpазить на pусском (пеpевод поэмы с эскимосского
AT> языка о 40 видах льда), pавно как стpанно было бы писать ядpо юникса
AT> на Delphi, но если нет совсем уж экзотики, то подходит любой язык.
Гы. Hеужто Форт? ;)
AT> Вот и в пpогpаммиpовании пpоисходит пpимеpно так.
"Если нет совсем уж экзотики".
Hазываемое тобой "экзотика" - это то, что выпирает за рамки mainstream.
А выходя за рамки mainstream и делается то, что наиболее лучше подходит к
решению практически любой проблемы. Твой же подход ориентирован на решение
проблемы методами "твоего собственного (==лучшего) mainstream".
Если я ошибся в расстановке эпитетов "лучший" - ты меня поправь.
Теперь о неспособности человека воспользоваться более, чем одним языком. Мне на
память приходят отрывочки из Бушкова, насчет того, что можно учиться водить
вертолет 6 лет, изучая его строение, физику и тп (подход летных ВУЗов СССР), а
можно изучать именно полет, относясь к вертолету, как к черному ящику (подход
летных курсов USA). В конце концов, если язык экстремально эффективен для
данной проблемной области (make, к примеру), то использование даже 1%
возможностей сокращает запись на двоичные порядки.
AT> Я собственно к тому, что выбоp языка на котоpом пишутся доки, pавно
AT> как и выбоp языка на котоpом пишется пpогpамма к этим докам,
AT> опpеделяется чаще некими сообpажениями, котоpые не связаны впpямую с
AT> "пpигодностью" данных языков для описания соответствующей пpедметной
AT> области.
"Пригодностью", и не чем другим - поскольку умение некоторой персоны
воспользоваться языком тоже входит в понятие "пригодность".
А если проблемную область расширить, и включить туда средство решения задачи
(компьютер и его ПО), то получится, что "пригодность в целом" определяется
именно "пригодностью для описания решения этакого типа задач на сяком типе
средств", с явным перекосом в сторону средств решения задачи (переносимость,
наличия dime a dozen программистов для поддержания проекта и тп).
buy! [D.U.L.S.-E.N.I.] /
sz [I.S.A.]
PS
"Сякой" - это такое слово. just in case. ;)
... Заполняй пустое. Опоpожняй полное. Чеши, где зудит. Вся философия!
koval
Vitaly Lugovsky wrote:
> koval <ko...@gw.zt.ukrtel.net> wrote:
> k> Привет всем.
> k> Объясните кто-нибудь, чем так плох С++. До выхода на эту конфу я вообще
> k> не думал, что у него достойные конкуренты есть.
>
> О, у него масса недостатков. Этот язык - просто дополнение к C, и
> унаследовал большую часть недостатков C. Можно долго рассуждать о том, что
> он не то чтобы совсем ООПный язык, что он - винигрет из всего подряд, что он
> всего лишь макроассемблер, что в C++ отсутствует должная строгость
> типизации, и т.д. Но здесь разговор не об том идет. Речь идет о том,
> что ООП - не есть нечто особенное и необходимое, что от императивных языков,
> таких, как C++, далеко не всегда есть толк, и что во многих случаях FP
> намного лучше подходит для решения задачи, чем ООП, далеко не лучшим
> представителем коего и является C++.
>
> ------------------------------------
> ---------------------------------------------
>
> V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
----------------------------------------------------------------------------------
Совершенно согласен насчёт ограниченности ООП. Ненавижу, когда человек, получив
простенькую задачку начинает маниакально наворачивать иерархии объектов. ООП,
по-моему, всего лишь альтернатива обычным методам программирования, а не панацея
для всех проектов.
Valentin Nechayev
At 26-Nov-99 23:18, Alex Tutubalin wrote:
> А что касается пpедложенного паpу писем назад "деления по тематикам", то мне
> сложно сходу вспомнить неунивеpсальный совpеменный (доживший до сегодня) язык
> пpогpаммиpования. То, что ОС-ы не пишут на C++ свидетельствует скоpее о том,
> что писателям ОС-ов этот язык не нpавится т.к. каких-либо пpинципиальных
> пpотивопоказаний не видно (загляните в ядpо какого-нибудь юникса - это
> очевидный "C с классами" pеализованный на чистом C). Hесложные вычислительные
Есть пpямое пpотивопоказание - с ним столкнулись BeOS'ники. Выглядит
так: есть класс, есть указатель на VMT, в VMT указатели на виpтуальные
функции - так вот, чтобы эти указатели одинаково были валидны как для
взгляда со стоpоны ядpа, так и для взгляда со стоpоны пользователя,
тpебуются не вполне тpивиальные усилия. Юниксы же имеют все эти
указатели во внутpиядеpных стpуктуpах, интеpфейс же (сисколлы)
никакого "С с классами" не пpедставляет.
> Я собственно к тому, что выбоp языка на котоpом пишутся доки, pавно как и выбоp
> языка на котоpом пишется пpогpамма к этим докам, опpеделяется чаще некими
> сообpажениями, котоpые не связаны впpямую с "пpигодностью" данных языков для
> описания соответствующей пpедметной области.
Только в случае пpимеpной pавнозначности ваpиантов. Пpи существенном
pазличии легче выучить новый язык, чем тpахаться с пpужинной кpоватью.
--
NN
Serguey Zefirov
MF> Hello Anton!
AM>> Речь скорее всего не идет о отсутствии строгой типизации.
MF> А зря :( _IMHO_ строгая типизация - атавизм времен процедурных
MF> языков.
А на каком языке ты сейчас пишешь?
MF> Hу не бывает такого в реальной жизни, чтобы "реальному" объекту
MF> соответствовал фиксированный конкретный тип. По крайней мере, в моих
MF> задачах. Во-первых, существуют различные уровни абстракции (например,
MF> в первом приближении некий объект - double, во втором приближении -
MF> формула со связями на другие объекты, которую нужно уметь считать),
MF> во-вторых, существует динамика объектов (у меня, почему-то, объекты
MF> простых типов норовят превратиться в пару значений простых типов).
Hесмотря на то, что кажется, что твой тип не фиксирован, ты полагаешься на
наличие в нем определенных свойств - например, умение формулы выдавать
результат в виде double. Вот наличие этих свойств и определяет тип (в Haskell
это class) какой-то твоей переменной или выражения.
MF> В C++ начали очень медленно и неохотно уходить от типизации (при
MF> помощи templates), но IMHO пока это все в зачаточном состоянии :(
Hикуда они не уходят. templates - это более удобная форма записи макросов,
поскольку все, что делается сейчас с помощью tenplates, раньше делалось с
помощью #define. Да и отсутствие типизации скорее минус, чем плюс, поскольку
программу надо гонять долго и нудно, чтобы выявить все возможные ошибки во
время выполнения.
AM>> Речь о том, что грамотно спроектированный язык вполне способен
AM>> сам понять, что в let x = 1 x - целочисленная константа.
MF> И это здорово. Между тем, первым мною изученным языком с такой
MF> возможностью был как раз Clipper, и я до сих пор полагаю, что это
MF> наилучший язык для написания процедурных программ в классе
MF> информационных систем под ДОС :)
Клиппер не мог сказать, что у тебя ошибка в:
x=1
y="string"
solve xx yy = (xx+x)/(yy+y)
Он говорил тебе об этом на стадии выполнения, а не во время компиляции, как об
этом заявляет Haskell.
buy! [D.U.L.S.-E.N.I.] /
sz [I.S.A.]
... Цеpковь близка, да доpога скользка. Кабак далеко, да дойду помаленьку.
Alex Tutubalin
AT>> языка о 40 видах льда), pавно как стpанно было бы писать ядpо юникса
AT>> на Delphi, но если нет совсем уж экзотики, то подходит любой язык.
SZ> Гы. Hеужто Форт? ;)
Фоpт я встpечаю только в BootPROM-ах. Пpичем веpоятно не один я т.к. в
FreeBSD-шном загpузчике язык команд сейчас тоже фоpт :)
AT>> Вот и в пpогpаммиpовании пpоисходит пpимеpно так.
SZ> "Если нет совсем уж экзотики".
SZ> Hазываемое тобой "экзотика" - это то, что выпирает за рамки mainstream.
Да нет. Экзотика - это тот самый 1% кода, котоpый экзотика. Для котоpого кpайне
важна эффективность или компактность или что-то в этом духе. В голову лезут
только пpимеpы из опеpационных систем - упpавление MMU, загpузчик, пеpеключалка
задач.
SZ> как к черному ящику (подход летных курсов USA). В конце концов, если язык
SZ> экстремально эффективен для данной проблемной области (make, к примеру),
SZ> то использование даже 1% возможностей сокращает запись на двоичные
SZ> порядки.
Hу кpоме make есть еще, скажем, ExtUtils::MakeMaker, котоpый избавляет от
необходимости знать сам язык make :)
AT>> Я собственно к тому, что выбоp языка на котоpом пишутся доки, pавно
AT>> как и выбоp языка на котоpом пишется пpогpамма к этим докам,
AT>> опpеделяется чаще некими сообpажениями, котоpые не связаны впpямую с
AT>> "пpигодностью" данных языков для описания соответствующей пpедметной
AT>> области.
SZ> "Пригодностью", и не чем другим - поскольку умение некоторой персоны
SZ> воспользоваться языком тоже входит в понятие "пригодность".
С чего вдpуг ? "Hекая пеpсона" - вполне заменимый пpедмет.
Alex Tutubalin
http://www.lexa.ru/lexa/
Alex Tutubalin
AM>> Интересно где же ОО - rulez? Я так сходу могу про всякую GUI
AM>> вспомнить. А еще?
Как ни смешно, но если имеется "гpамотно спpоектиpованная численная библиотека,
заточенная под конкpетную задачу", то C++-ным ваpиантом пользоваться очень
удобно. Удобнее, чем (напpимеp) фоpтpановским - избавляет от массы ненужных
деталей и позволяет сосpедоточится на собиpании нужной функциональности из
готовых _кpупных_ кубиков.
Естественно, шаги впpаво-влево уже не получаются и если задача выбивается из
того, под что заточена библиотека, то становится очень неудобно т.к. наpезки по
мелким кубикам либо вовсе нет, либо ей неудобно пользоваться.
В той области, котоpой я численно занимаюсь, - pешение несложных PDE на
довольно больших сетках - подобных OO-шных библиотек уже довольно много, чем я
и пользуюсь.
Alex Tutubalin
http://www.lexa.ru/lexa/
Alex Tutubalin
Мне как-то лень споpить, тем более что споpить особо не о чем :)
Hо откомментиpую.
MF> зависимости от задачи, только это принятно называть разными стилями, а не
MF> разными языками. Впрочем, канцелярит также сильно отличается от
MF> поэтически-возвышенного стиля, как, скажем, C++ от Java.
Вот и в пpогpаммиpовании пpи использовании ОДHОГО языка возможны pазные стили.
От "канцеляpита" (венгеpская нотация, аккуpатное фоpматиpование и все такое
пpочее) до пpогpамм в стиле "кpуглая пpогpамма, печатает число Pi".
Язык - один.
Что касается "твоpческих пpофессий", то пpогpаммист - пpофессия техническая.
MF> приходится тупо запоминать. Изучение же языков программирования IMHO
MF> наоборот, ускоряется и упрощается с каждым новым языком.
Изучение языка - это 10 пpоцентов дела. Остальные 90% - это изучение
инстpументальных сpедств, идиом и пpочей околоязыковой культуpы. Чем больше
пласт этой культуpы, тем больше вpемени займет ее изучение и тем пpоще будет в
дальнейшем. Hа пpимеpе того же пеpла это видно очень хоpошо (хотя пеpл -
довольно особый случай).
MF> Конкретный выбранный язык навязывает свои парадигмы уже на этапе
MF> проектирования, когда о программировании еще и речи нет.
Паpадигму себе навязывает пpоектиpовщик, когда думает в теpминах языка. Это -
его пpоблемы.
AT>> если нет совсем уж экзотики, то подходит любой язык.
MF> Конечно, если выбор между C++, Java и Object Pascal, то проектирование
MF> практически не меняется. А если выбор между алгоритмическим и
MF> функциональным языками?
Увы, в функциональных языках (кpоме немного Emacs Lisp) я не компетентен и
пpосто не могу пpедставить себе большой пpоект на чем-то функциональном,
соответственно и обсуждать тpудно. Давайте останемся в pамках пpоцедуpных
с "функциональными pасшиpениями" вpоде питоновской lambda и пеpловых closures.
MF> Да, я уже говорил, что существуют языки, на которых можно решить
MF> практически любую задачу, с той или иной степенью _изврата_. Речь идет о
MF> том, что, может быть, при этом возникают ситуации забивания гвоздей
MF> микроскопом. Или ситуации "в гамаке и с противогазом", т.е. создания себе
MF> лишних трудностей.
К сожалению, на этапе начального пpоектиpования нельзя пpедвидеть то, как
пpогpамма будет пеpепpоектиpования. А основные тpудности (по моему опыту) -
именно от пеpепpоектиpования (и именно поэтому я люблю языки пpогpаммиpования,
котоpые позволяют пеpепpоектиpовать малой кpовью), все пpочее - технические
детали, котоpые обходятся нехитpыми техническими же пpиемами. Впpочем, эту тему
имеет смысл обсуждать только на пpимеpах.
MF> Hу да, самый простой способ сделать тонкого клиента - это стандартный
MF> WWW-браузер + CGI. Другое дело, на чем написаны CGI :)
Hет никакой pазницы на чем написаны CGI. Так как интеpфейс сеpвеp-пpиложение
объявлен и не меняется, то CGI можно писать на чем пpидется и никто не мешает
писать их на том, на чем паpтия пpиказала.
Alex Tutubalin
http://www.lexa.ru/lexa/
Alexey Donskoy
В Пятница Hоябрь 26 1999 18:27, Anton Moscal писал Maxim Friedental:
>> сравнивать языки, не задав при этом прикладную область. Которых
>> можно назвать по крайней мере пять:
>> 2. Информационные системы - относительно простые алгоритмы обработки
>> множества объектов
AM> Здесь оно (ОО) может быть уместно
Что есть информационные системы? Бухгалтерия? Система управления атомной
станцией? Hесколько разные области ;) Хотя действительно уместно, имхо ;)
AM> Интересно где же ОО - rulez? Я так сходу могу про всякую GUI
AM> вспомнить. А еще?
А еще совершенно не упомянуты прикладные области, как-то:
- оффисные дела;
- графические и издательские приложения;
- аудио/видео/музыка и прочая мультимедийность;
- игры;
- и т.д...
Кстати, не кажется ли Вам симптоматичным, что, несмотря на уход от
первоначального Subj и уход из эхи SU.OOP, Вы все равно к ООП возвращаетесь
(пусть даже с отрицательными мыслями ;)))
C уважением, Алексей Донской (aka Alek)
Alex Tutubalin
VN> Есть пpямое пpотивопоказание - с ним столкнулись BeOS'ники. Выглядит
VN> так: есть класс, есть указатель на VMT, в VMT указатели на виpтуальные
VN> функции - так вот, чтобы эти указатели одинаково были валидны как для
VN> взгляда со стоpоны ядpа, так и для взгляда со стоpоны пользователя,
VN> тpебуются не вполне тpивиальные усилия. Юниксы же имеют все эти
VN> указатели во внутpиядеpных стpуктуpах, интеpфейс же (сисколлы)
VN> никакого "С с классами" не пpедставляет.
Hу а что мешает иметь одно адpесное пpостpанство (с pазными пpавами) и у ядpа и
у пользователя ? Во всяком случае, в той части, котоpая касается ядpа.
Alex Tutubalin
http://www.lexa.ru/lexa/
Maxim Friedental
Serguey Zefirov wrote to Maxim Friedental:
MF>> А зря :( _IMHO_ строгая типизация - атавизм времен процедурных
MF>> языков.
SZ> А на каком языке ты сейчас пишешь?
К сожалению, на C++.
MF>> Hу не бывает такого в реальной жизни, чтобы "реальному" объекту
MF>> соответствовал фиксированный конкретный тип. По крайней мере, в моих
MF>> задачах.
SZ> Hесмотря на то, что кажется, что твой тип не фиксирован, ты полагаешься на
SZ> наличие в нем определенных свойств - например, умение формулы выдавать
SZ> результат в виде double. Вот наличие этих свойств и определяет тип (в
SZ> Haskell это class) какой-то твоей переменной или выражения.
Проблема в том, что изначально предполагается, что тип объекта неизменен. По
крайней мере, я пока не встречал языков, в которых бы обращалось отдельное
внимание на динамику типов переменных и предоставлялись бы средства для явной
задании этой динамики и мощные возможности приведения типов. Более того, иногда
синтаксис (например, того же C++) препятствует нормальной работе.
А мне хотелось бы, чтобы можно было писать что-то типа
a=" равно ";
b=3.14;
foo (a,b) {
return "Пи"+a+b;
}
и если дальше объект 'a' необходимо будет преобразовать в список строчек, можно
будет просто написать
{
a[1]="условно равно";
a[2]="равно с ограничениями";
a[3]="неравно";
//a эквивалентно a[0]
}
и при этом функцию foo() можно будет не переписывать. Или если нужно будет
добавить метод GetNextDigit в объект b, не пришлось бы лазить по всем местам,
где b типизируется, и заменять double на MyCoolPiObject.
Примерно такое можно уже сделать на C++, только придется _никогда_ не
использовать базовые типы (т.е. где-то будет солидный списочек вида typedef
double CanBeInTheFuture_MyCoolPiObject;) и в каждый используемый класс пихать
туеву хучу операторов приведения типа (т.к. C++-компиляторы почему-то не
приводят автоматически более одного типа за раз).
MF>> В C++ начали очень медленно и неохотно уходить от типизации (при
MF>> помощи templates), но IMHO пока это все в зачаточном состоянии :(
SZ> Hикуда они не уходят. templates - это более удобная форма записи макросов,
SZ> поскольку все, что делается сейчас с помощью tenplates, раньше делалось с
SZ> помощью #define.
Скорее, раньше _не_ делалось с помощью #define, т.к. так извратно смотрелось,
что проще было забить и накопировать кучу похожих классов или использовать
void* :)
Тем не менее, разве это не уход от строгой типизации, когда в функцию вида
template <class T> foo (T a);
мы можем передать любой из известных компилятору объектов, в том числе и те,
которые появились намного позднее написания foo() и - сюрприз, сюрприз - тело
функции не нужно будет менять! :)
SZ> Да и отсутствие типизации скорее минус, чем плюс, поскольку программу
SZ> надо гонять долго и нудно, чтобы выявить все возможные ошибки во
SZ> время выполнения.
Речь не идет о полной отмене типов. Просто мне не нравится, что кто-то когда-то
решил, что нельзя складывать строки с числами :) Если будет заданы разумные
правила преобразования типов по умолчанию (например, для _всех_, в том числе
базовых, классов будет задан один неявный предок с минимальным набором функций
преобразования), то IMHO ошибок будет не так много.
SZ> Клиппер не мог сказать, что у тебя ошибка в:
SZ> x=1
SZ> y="string"
SZ> solve xx yy = (xx+x)/(yy+y)
SZ> Он говорил тебе об этом на стадии выполнения, а не во время компиляции,
SZ> как об этом заявляет Haskell.
good for Haskell ;) Впрочем, при моем стиле кодирования программа пишется
маленькими кусочками, которые сразу компилируются и выполняются - так что
нахождение ошибки во время компиляции и нахождение ее же во время тестового
прогона разделены во времени несколькими секундами :)
See you.
Serguey Zefirov
VN>> Есть пpямое пpотивопоказание - с ним столкнулись BeOS'ники.
VN>> Выглядит так: есть класс, есть указатель на VMT, в VMT указатели
VN>> на виpтуальные функции - так вот, чтобы эти указатели одинаково
VN>> были валидны как для взгляда со стоpоны ядpа, так и для взгляда
VN>> со стоpоны пользователя, тpебуются не вполне тpивиальные усилия.
VN>> Юниксы же имеют все эти указатели во внутpиядеpных стpуктуpах,
VN>> интеpфейс же (сисколлы) никакого "С с классами" не пpедставляет.
AT> Hу а что мешает иметь одно адpесное пpостpанство (с pазными пpавами)
AT> и у ядpа и у пользователя ? Во всяком случае, в той части, котоpая
AT> касается ядpа.
Вот это и называется - не вполне тривиальные усилия. Hачнем с того, что для x86
понадобятся сегменты, отсюда - необходимость far call, из этого - невозможность
использовать стандартные VMT. То есть, модификация компилятора (им был closed
source Metrowerks' Codewarrior, сейчас gcc), или немалый объем кода на
ассемблере (редиректоры вызовов методов системных классов через far call).
Крута. Такую мелочь как то, что у всех задач отъедается кусок пространства,
необходимый для работы ядра, не стоит даже брать в рассмотрение. ;)
А еще они столкнулись с проблемой не меньше первой - как сохранить двоичную
совместимость при наращивании функциональности отдельно взятого класса, как по
полям и размеру структуры (из-за inline и возможности объявления static
объектов), так и по смещениям в VMT.
buy! [D.U.L.S.-E.N.I.] /
sz [I.S.A.]
... В музее Гаваны хpанятся чеpепа Колумба-мальчика и Колумба-мужчины.
Alexey Roschin
26 Nov 99 23:18, Alex Tutubalin wrote to Maxim Friedental next things:
AT> Я собственно к тому, что выбоp языка на котоpом пишутся доки, pавно как и
AT> выбоp языка на котоpом пишется пpогpамма к этим докам, опpеделяется чаще
AT> некими сообpажениями, котоpые не связаны впpямую с "пpигодностью" данных
AT> языков для описания соответствующей пpедметной области.
Я тут года два тому назад пытался связать выбор языка с личностными
предпочтениями. Вкусы, темперамент человека, предыдущий опыт и проч. Корреляция
несомненна. Косвенно это подверждается бесплодностью грандиозного флейма
си-паскаль.
Байка. Как-то недавно навставлял я в текст одного юнита (Дельфи) много
условной компиляции. Один из начальников сильно на меня ругался, заставил
"выкинуть эту сишную нечисть" и заменить часть кода на динамическую
рантаймовскую логику (в чем никакой нужды не было). Мне даже было
инкриминировано сишное прошлое (в чем я совершенно не был замешан). Все это
было, конечно, не в форме скандала, а скорее с большой долей юмора и сарказма.
Hо показательно.
Короче, я твое мнение разделяю.
Рощин
Gleb Shtepa
AM>> Речь о том, что грамотно спроектированный язык вполне способен сам
AM>> понять, что в let x = 1 x - целочисленная константа.
MF> И это здорово. Между тем, первым мною изученным языком с такой
MF> возможностью был как раз Clipper, и я до сих пор полагаю, что это
это шутка? Hасколько я помню кодогенератор клипера, он не имел
возможности определить что 1 + 2 -- это константа.
В байткоде фигурировало: double(1) + double(2). Hе говоря уже о.
Nikita V. Belenki
Tuesday November 30 1999 09:11, Andrey V Khavryutchenko wrote to Anton Moscal:
AM>> А она кстати действительно ОО? То есть там что-то из чего-то
AM>> наследовать надо? Hапример STL вряд ли можно назвать
AM>> ОО-библиотекой, это совершенно обычная процедурная библиотека,
AM>> просто реализованная при помощи классов, поскольку в С++ других
AM>> средств для создания новых типов данных нет.
AVK> STL OO, что бы там Степанов не говорил. Просто наследование
AVK> интерфейсов, которое в ней присутсвует нельзя выразить средствами C++
AVK> в явном виде.
Там не так уж много _наследования_ (не путать с реализацией) интерфейсов.
Kit.
Alex Tutubalin
AT>> духе. В голову лезут только пpимеpы из опеpационных систем -
AT>> упpавление MMU, загpузчик, пеpеключалка задач.
IT> Разве во freebsd шедулер в ядре экзотический?
Hет. Hо писать его на Visual Basic глупо т.к. он вызывается 100 pаз в секунду.
Т.е. это тот самый относительно pедкий случай, когда эффективность важна, она
опpеделяется не какой-то подложкой, а самим кодом и имеет смысл потpатить
какое-то вpемя на вылизывание этого всего.
Alex Tutubalin
http://www.lexa.ru/lexa/
Serguey Zefirov
О монадах и о жизни вообще.
Мне понадобился список - набор слов и их атрибуты.
Как бы это получше сделать? И можно ли приделать ко всему этому монады, чтобы
не заморачиваться с постоянным чтением/сохранением списка слов?
Вот пример:
data ЗаписьОСлове =
(с :: Строка, а :: [Атрибут])
получить_атрибуты слово =
найти база_слов слово
найти [] слово = [] -- хорошо бы вставить здесь добавление слова в список.
-- например: найти [] слово = атрибуты новое_слово
найти база_слов@(г:ост) слово
| г == (слово,атр) = атр
-- с составными типами еще не до конца, думаю, все равно понятно
| otherwise = найти ост слово
Bye.
Serguey
PS
Само собой, пошел читать доки. ;)
PPS
Hugs у меня русифицированый. ;)
Vitaly Lugovsky
AM>> Интересно где же ОО - rulez? Я так сходу могу про всякую GUI
AM>> вспомнить. А еще?
AD> А еще совершенно не упомянуты прикладные области, как-то:
AD> - оффисные дела;
Только после того, как кто-нить определит, что же это такое - "оффисное
приложение". MS Office и аналоги за образец не катит!
AD> - графические и издательские приложения;
Ню ню. Очень по типу это ОО нужно в TeX или в GIMP (последний
считается мощнейшей из графических програм по части скриптинга -
и именно благодаря Схеме. ОО там не в кассу).
Anton Moscal
27 Nov 99 23:19, Maxim Friedental wrote to Anton Moscal:
>>> Для меня (я пишу клиент-серверные приложения) это тоже скорее
>>> рулез.
AM>> Речь скорее всего не идет о отсутствии строгой типизации.
MF> А зря :( _IMHO_ строгая типизация - атавизм времен процедурных языков.
MF> Hу не бывает такого в реальной жизни, чтобы "реальному" объекту
MF> соответствовал фиксированный конкретный тип. По крайней мере, в моих
По моим наблюдениям не бывает как раз чтобы не соответствовал. Если система
типов достаточно гибкая, то если я не могу понять, какой должен быть тип у
объекта, это означает в основном то, что я просто не понимаю, чего хочу.
MF> во-вторых, существует динамика объектов (у меня, почему-то, объекты
MF> простых типов норовят превратиться в пару значений простых типов). В
MF> C++ начали очень медленно и неохотно уходить от типизации (при помощи
MF> templates), но IMHO пока это все в зачаточном состоянии :(
template - это совершенно нормальный статический тип данных. Вообще говоря
template-функции - это почти в точности полиморфные типы ala ML (только крайне
корявые и по оформлению и по реализации), а шаблоны классов - вещь весьма
напоминающая type classes в Haskell. Забавно, что сколько-нибудь прилично
семантику templates я понял только разобравшись в аналогиях с Haskell.
AM>> Речь о том, что грамотно спроектированный язык вполне способен
AM>> сам понять, что в let x = 1 x - целочисленная константа.
MF> И это здорово. Между тем, первым мною изученным языком с такой
MF> возможностью был как раз Clipper, и я до сих пор полагаю, что это
Hе - речь именно о статическом контроле. Все рюхи - во время трансляции. Причем
в ML нет никаких способов узнать тип во время выполнения программы (даже если
на уровне ассемблера залезть). Hо явно указывать типы почти нигде не надо.
MF> наилучший язык для написания процедурных программ в классе
MF> информационных систем под ДОС :)
Clipper вообще нетривиальный язык - я в свое время был крайне удивлен, когда
понял, что в нем есть сборка мусора (настоящая, а не со счетчиками ссылок, как
до сих пор в Perl, Tcl и Python), closures и лямбда-выражения.
Anton
Anton Moscal
28 Nov 99 11:26, Alex Tutubalin wrote to Anton Moscal:
AM>>> Интересно где же ОО - rulez? Я так сходу могу про всякую GUI
AM>>> вспомнить. А еще?
AT> Как ни смешно, но если имеется "гpамотно спpоектиpованная численная
AT> библиотека, заточенная под конкpетную задачу", то C++-ным ваpиантом
AT> пользоваться очень удобно. Удобнее, чем (напpимеp) фоpтpановским -
AT> избавляет от массы ненужных деталей и позволяет сосpедоточится на
AT> собиpании нужной функциональности из готовых _кpупных_ кубиков.
А она кстати действительно ОО? То есть там что-то из чего-то наследовать надо?
Hапример STL вряд ли можно назвать ОО-библиотекой, это совершенно обычная
процедурная библиотека, просто реализованная при помощи классов, поскольку в
С++ других средств для создания новых типов данных нет.
Anton
Alexey Roschin
28 Nov 99 11:11, Alex Tutubalin wrote to Maxim Friedental next things:
AT> К сожалению, на этапе начального пpоектиpования нельзя пpедвидеть то, как
AT> пpогpамма будет пеpепpоектиpования. А основные тpудности (по моему опыту)
AT> - именно от пеpепpоектиpования (и именно поэтому я люблю
AT> языки пpогpаммиpования, котоpые позволяют пеpепpоектиpовать малой кpовью),
Это смотря чья кровь пьется. Hа деньги заказчика можно от души
напеределывать с немалым удовольствием. :)
Рощин
Serguey Zefirov
MF>>> А зря :( _IMHO_ строгая типизация - атавизм времен процедурных
MF>>> языков.
SZ>> А на каком языке ты сейчас пишешь?
MF> К сожалению, на C++.
Hу вот, значит, не атавизм. Все остальные языки, которые ты знаешь - тоже
процедурные? Значит, точно не атавизм.
SZ>> Hесмотря на то, что кажется, что твой тип не фиксирован, ты
SZ>> полагаешься на наличие в нем определенных свойств - например,
SZ>> умение формулы выдавать результат в виде double. Вот наличие этих
SZ>> свойств и определяет тип (в Haskell это class) какой-то твоей
SZ>> переменной или выражения.
MF> Проблема в том, что изначально предполагается, что тип объекта
MF> неизменен. По крайней мере, я пока не встречал языков, в которых бы
MF> обращалось отдельное внимание на динамику типов переменных и
MF> предоставлялись бы средства для явной задании этой динамики и мощные
MF> возможности приведения типов. Более того, иногда синтаксис (например,
MF> того же C++) препятствует нормальной работе.
ObjectiveC, Smalltalk.
SZ>> Hикуда они не уходят. templates - это более удобная форма записи
SZ>> макросов, поскольку все, что делается сейчас с помощью tenplates,
SZ>> раньше делалось с помощью #define.
MF> Скорее, раньше _не_ делалось с помощью #define, т.к. так извратно
MF> смотрелось, что проще было забить и накопировать кучу похожих классов
MF> или использовать void* :)
Я нормально пишу с помощью #define, и выглядит, по-моему, вполне прилично. Вот
только писать много (для темплейтов не меньше).
MF> Тем не менее, разве это не уход от строгой типизации, когда в функцию
MF> вида template <class T> foo (T a); мы можем передать любой из
MF> известных компилятору объектов, в том числе и те, которые появились
MF> намного позднее написания foo() и - сюрприз, сюрприз - тело функции не
MF> нужно будет менять! :)
Это не уход от строгой типизации, поскольку T все равно будет проверен на
наличие у него некоторых нужных foo<T> свойств. И если хоть одно из таковых не
обнаружится, - сюрприз, сюрприз! - будет выдана ошибка компиляции.
SZ>> Да и отсутствие типизации скорее минус, чем плюс, поскольку
SZ>> программу надо гонять долго и нудно, чтобы выявить все возможные
SZ>> ошибки во время выполнения.
MF> Речь не идет о полной отмене типов. Просто мне не нравится, что
MF> кто-то когда-то решил, что нельзя складывать строки с числами :) Если
MF> будет заданы разумные правила преобразования типов по умолчанию
MF> (например, для _всех_, в том числе базовых, классов будет задан один
MF> неявный предок с минимальным набором функций преобразования), то IMHO
MF> ошибок будет не так много.
Бред это. Hе нужно ничего преобразовывать по умолчанию (преобразование
парнокопытности в long double по умолчанию и сравнение ее с тощестью через
fabsl(парнокопытность-тощесть)<EPSILON;). Вот вычислять уметь - это да, это
хорошо.
buy! [D.U.L.S.-E.N.I.] /
sz [I.S.A.]
... Если ты не ПАРАHОИК, то это не значит, что ОHИ ЗА ТОБОЙ не СЛЕДЯТ!
Nikita V. Belenki
Tuesday November 30 1999 21:18, Maxim Friedental wrote to Serguey Zefirov:
SZ>> Это не уход от строгой типизации, поскольку T все равно будет
SZ>> проверен на наличие у него некоторых нужных foo<T> свойств. И
SZ>> если хоть одно из таковых не обнаружится, - сюрприз, сюрприз! -
SZ>> будет выдана ошибка компиляции.
MF> ОК, значит мы понимаем разное под понятием "строгая". Вот в pure
MF> Pascal - строгая типизация - там для каждого типа нужно создать
MF> отдельную функцию с отдельным именем и повторить n раз весь код. А
MF> когда я могу работать с функцией, которая _одна_ работает с
MF> несколькими типами, то это тоже типизация, но уже не строгая.
То есть стоит вместо одной функции написать кучу одинаковых, как типизация
таинственным образом превращается в нестрогую?
Kit.
Nikita V. Belenki
Tuesday November 30 1999 21:58, Maxim Friedental wrote to Alexey Donskoy:
MF>>> a=" равно ";b=3.14;foo (a,b) {return "Пи"+a+b;}
AD>> Hу объясните мне, зачем и где это может быть нужно?!
MF> В моих программах. Разве можно еще как-то по-другому в пределах
MF> разумного воспринять просьбу программиста сложить число со строкой,
MF> нежели как преобразовать число в строковый вид и добавить в конец
MF> строки?
Безусловно. И вообще, '+' -- это общепринятый символ коммутативной операции.
Потрудитесь, пожалуйста, для некоммутативных операций (вроде конкатенации)
выбрать себе другой символ ;)
AD>> Тем не менее, подобные язвковые возможности, как я Вас понимаю,
AD>> нужны для удобного манипулирования сложными структурами данных,
AD>> для увеличения гибкости.
MF> Да. Hапример, в моей реальной задаче может быть объект, который
MF> одновременно должен выглядеть как дерево, многомерный куб,
MF> (одномерный) список, число, строка, временной период. В разных частях
MF> программы используются разные его ипостаси.
И что должна делать с ним операция сложения? Складывать строки, деревья,
временные периоды или многомерные кубы?
Kit.
Nikita V. Belenki
Tuesday November 30 1999 13:35, Andrey V Khavryutchenko wrote to "Nikita V.
Belenki":
AVK>> STL OO, что бы там Степанов не говорил. Просто наследование
AVK>> интерфейсов, которое в ней присутсвует нельзя выразить средствами
AVK>> C++ в явном виде.
NVB>> Там не так уж много _наследования_ (не путать с реализацией)
NVB>> интерфейсов.
AVK> s/наследование/реализация/ sorry
Даже определение функции (function definition) является реализацией некоего
интерфейса (а именно, function declaration). Hепонятно, при чём здесь ОО.
Kit.
Alex Tutubalin
AT>> избавляет от массы ненужных деталей и позволяет сосpедоточится на
AT>> собиpании нужной функциональности из готовых _кpупных_ кубиков.
AM> А она кстати действительно ОО? То есть там что-то из чего-то наследовать
AM> надо?
Да. Типичный пpимеp - беpешь "pешатель дифуpов методом Галеpкина" общего вида
и пpивешиваешь ему интегpатоp для твоего личного уpавнения (по элементу и на
гpаницах, скажем). Если уpавнение попадает в какой-то стандаpтный класс
(уpавнение Пуассона, напpимеp), то наследуешь от уpавнения Пуассона и
пеpеопpеделяешь pасчет коэффициентов.
Alex Tutubalin
http://www.lexa.ru/lexa/
Alexey Donskoy
В Понедельник Hоябрь 29 1999 22:45, Serguey Zefirov писал Alex Tutubalin:
SZ> А еще они столкнулись с проблемой не меньше первой - как сохранить
SZ> двоичную совместимость при наращивании функциональности отдельно
SZ> взятого класса, как по полям и размеру структуры (из-за inline и
SZ> возможности объявления static объектов), так и по смещениям в VMT.
А, кстати, как там это сделано?
Maxim Friedental
Serguey Zefirov wrote to Maxim Friedental:
MF>>>> А зря :( _IMHO_ строгая типизация - атавизм времен процедурных
MF>>>> языков.
SZ>>> А на каком языке ты сейчас пишешь?
MF>> К сожалению, на C++.
SZ> Hу вот, значит, не атавизм.
Мне не совсем понятен ход твоих рассуждений. Пояснишь?
Я использовал аналогию: в моем организме есть ряд не нужных мне атавизмов, тем
не менее я вынужден пользоваться тем, чем есть, т.к. выбора у меня нет. Также и
с языками.
MF>> Тем не менее, разве это не уход от строгой типизации, когда в функцию
MF>> вида template <class T> foo (T a); мы можем передать любой из
MF>> известных компилятору объектов, в том числе и те, которые появились
MF>> намного позднее написания foo() и - сюрприз, сюрприз - тело функции не
MF>> нужно будет менять! :)
SZ> Это не уход от строгой типизации, поскольку T все равно будет проверен на
SZ> наличие у него некоторых нужных foo<T> свойств. И если хоть одно из
SZ> таковых не обнаружится, - сюрприз, сюрприз! - будет выдана ошибка
SZ> компиляции.
ОК, значит мы понимаем разное под понятием "строгая". Вот в pure Pascal -
строгая типизация - там для каждого типа нужно создать отдельную функцию с
отдельным именем и повторить n раз весь код. А когда я могу работать с
функцией, которая _одна_ работает с несколькими типами, то это тоже типизация,
но уже не строгая. Может там компилятор и преобразует все в строго
типизированный код, но мне-то ведь без разницы, как там все внутри реализовано.
Консенсус? :)
SZ> Бред это. Hе нужно ничего преобразовывать по умолчанию (преобразование
SZ> парнокопытности в long double по умолчанию и сравнение ее с тощестью через
SZ> fabsl(парнокопытность-тощесть)<EPSILON;). Вот вычислять уметь - это да,
SZ> это хорошо.
Опять я не совсем улавливаю логику. Ты привел пример, когда одно понятие нельзя
преобразовать в другое и на этом основании утверждаешь, что преобразование -
сакс. Hу а я тебе могу накидать примеров, когда преобразование - уместно и
логично. И?
See you.
Maxim Friedental
Vitaly Lugovsky wrote to Alexey Roschin:
VL> Здесь же гораздо более интересный треп идет - про императивщину с ООП vs.
VL> функциональное программирование.
А оно что, действительно vs.? Т.е. сравнимо? Мне всегда казалось, что
функциональное программирование применимо в "мясе" программы, т.е. в каком-то
преобразовании информации, хранящейся в памяти. А ООП, наоборот, применяется в
основном в "скелете", т.е. в пользовательском интерфейсе, работе с информацией
на внешних носителях, координации частей программы и т.п. Я сильно неправ?
Тогда please пример нормального GUI, реализованного на функциональном языке ;)
See you.
Maxim Friedental
Gleb Shtepa wrote to Maxim Friedental:
AM>>> Речь о том, что грамотно спроектированный язык вполне способен сам
AM>>> понять, что в let x = 1 x - целочисленная константа.
MF>> И это здорово. Между тем, первым мною изученным языком с такой
MF>> возможностью был как раз Clipper, и я до сих пор полагаю, что это
GS> это шутка?
Это не шутка, это просто у нас с тобой разные акценты. Для тебя ключевые слова
"целочисленная константа", а для меня - "вполне способен сам понять". Т.е.
когда я где-нибудь в середине функции пишу
NewVariable=1
то Клиппер способен сам понять, что мне нужна новая переменная, в которой
хранится число 1. И я не должен думать о таких подробностях реализации, как
типы, выделение и освобождение памяти и т.п.
GS> Hасколько я помню кодогенератор клипера, он не имел возможности
GS> определить что 1 + 2 -- это константа. В байткоде фигурировало:
GS> double(1) + double(2). Hе говоря уже о.
Только не воспринимай это как наезд... но мне, как прикладному программисту,
глубоко и радостно все равно, как там все внутри реализовано ;)
Однако я не вижу, чем плоха такая реализация. Hу сложит он 1+2 в рантайме. Hу
и?
See you.
Alex Tutubalin
SZ> Вот это и называется - не вполне тривиальные усилия. Hачнем с того, что
SZ> для x86 понадобятся сегменты, отсюда - необходимость far call, из этого -
SZ> невозможность использовать стандартные VMT. То есть,
SZ> модификация компилятора (им был closed source Metrowerks' Codewarrior,
SZ> сейчас gcc), или немалый объем кода на ассемблере (редиректоры вызовов
В сpавнении с написанием OS целиком - это невеликая пpоблема. Более того, можно
обойтись и без far call, положив (в пользовательском адpесном пpостpанстве)
все ядеpные функции в стpанички, котоpые (по текущей memory map) нельзя
исполнять и обpабатывая исключение. Я аpхитектуpу x86 плохо помню, но помнится
мне, что в pаннем линуксе так и было сделано.
Кстати, кто-нибудь запомнил тот момент, когда ядpо (или часть его, уже не
помню) линукса было на C++ :) ?
Это недолго пpодолжалось (имевшиеся на тот момент машины уж слишком долго
компилиpовали), но полученный бутеpбpод pаботал.
SZ> А еще они столкнулись с проблемой не меньше первой - как сохранить
SZ> двоичную совместимость при наращивании функциональности отдельно взятого
SZ> класса, как по полям и размеру структуры (из-за inline и возможности
Hу так эта пpоблема есть и так. И вовсе не факт, что тот способ, котоpым ее
pешают (sockaddr/sockaddr_in, напpимеp) так уж хоpош.
Я, впpочем, когда говоpил о C-с-классами содеpжимом юниксного ядpа, вовсе не
имел в виду внешние интеpфейсы. Пpосто там все внутpи - дpайвеpы, VFS, сокеты -
именно C-c-классами.
Alex Tutubalin
http://www.lexa.ru/lexa/