Re[12]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.01.06 22:02
Оценка:
Здравствуйте, CrazyPit, Вы писали:

VD>>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.


CP>Да, да — весьма новое, можно сказать революционное решение


Ага. Весма нове. Аналогов нет. Есть конечно прототипы, но похоже Нэмерл их превзошел.

Тут вот недавно задавался вопрос С++-ником по поводу метапрограммирования. Он как раз сказал, что ему не нравится, что препроцессор того же ОКамла не интегрируется с компилятором так же хорошо как С++. Он в общем-то не совсем прав, так как в С++ тоже хреново с этим делом. Но вот то что ОКамл не позволяет задействовать семантический анализ — это явный минус. Ведь без этого полученные в результате макросы будут куда примитивнее и порой будет очень не просто понять что за ошибка произошла. AST-то изменено, и компилятор будет орать на невидимое человеку его редставление, а не на исходное. А вот в Нэмерле можно легко реализовать дополнительные проверки.

Лисп тут тоже ничем не лучше. У него тольо больше тараконов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.01.06 22:02
Оценка: :)
Здравствуйте, CrazyPit, Вы писали:

CP>Да ну? В каких таких расширениях. Она есть в стандарте, которому около 20 лет. И которым пользуеться все реализации Common Lisp.


А какими расширениями пользуется Схема?

CP>http://www.supelec.fr/docs/cltl/clm/node104.html (искать "(declare (type" ). Так что вы ошиблись. И императивные конструкции все в стандарте.


В стандарте чего? Одно из диалектов?

CP>И ООП тоже в стандарте. Это всё есть в Common Lisp. Вообще CL не функциональный язык. Или может быть вы имели ввиду что Common Lisp — это "расширение", относительно некого мифического — труъ функионального лиспа?


Есть некий мифический Лисп с некой мифической функцией Eval и некими мифическими канонами которые придуманы в хрен знает каком коду. И есть набор языков которые могут подпадать или не подпадать под эти каноны.

Более того, даже в самых крутых диалектах Лиспа, насколько мне извесно, декларация типов не является обязательной. А без нее не всегда можно произвести вывод типов. К тому же есть конструкции принципиально не допускающие вывод типов или делающие его бесполезным.

По оеределению атом в Лиспе есть вещь динамически типизированная и всегда можно найти код который не сможет однозначно вычеслить тип на этапе компиляции.

Движение в стороу вывода типов безусловно очень верное движение, но без изменения языка оно не слишком эффективно. Язвк не рассчитанный на статическую типизацию принципиально будет уступать языку в который проектировался в расчете на статическую типизацию.

Есть языки кооторые проектировались в рассчете на статическую типизациб и вывод типов. И они в 100% случаев будут давать возможность породить оптимальный код. Лисп же к таковым не относится. Ну, а если вспомнит, что к Лиспам относятся тучи диалектов вообщ не знающие о аннотации типов, то вообще все обобщения по Лиспу являются обманом.

VD>>Лисп с выводм типов — это уже совсем не динамически типизированный язык. Это уже совсем другой язык, я бы сказал.


CP>Вывода типов нет. А декларация есть.




Я плакаль. А какй же тогда смысл в Лиспе если прийдется лепить типы везде? Это же будет монстр с типами, но без синтаксиса.

CP>А вообще при желание можно добавить в лисп возможности любого языка с помощью макр.


Да, ну, добавь мне, плиз возможности того же Немерла. И так чтобы диагностика ошибок не пострадала.

А я уж лучше предпочту пользоваться гтовым компилятором, а не писать его сам на совершенно сумашедем языке.


CP>>>По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.


VD>>Верь в эту сказку дальше.


CP>Мне вот интерестно вы думаете что люди которые проводят те бэнчмарки (для почти всех языков) такие ярые фанаты лиспа, эрланга, etc.


Нет. Они просто или халтурщики, или шарлотаны. Любому кто хоть что-то понимает в области производитльности достаточно часа чтобы понять, что эти тесты есть полнейшее фуфло. В них прост используются рзные реализации, разные структуры данных с разными алгоритмами и бечесные методы измерения производительности.

CP> Что они намеренно подрстраивают так чтоб лисп, скажем, рулил а джава наоборот?


Без разницы намеряно они это сделали или нет. Они это сделали и их работу можно назвать тольк позором.

Причем сами алгоритмы может и были бы интересыны, если бы авторы были бы более разумны в принципах тестирования и анализа тестов.

CP> Им это надо?


Видмо надо раз делают.

CP>Тем более лисп компилируеться в нативный код, а джава и C# нет.


Хм. В итоге получается машинный код который исполняется.

CP> ТАк что он быстрее — ничего удивительного нет.


Он не быстрее. Есть случае где Лисп сопоставим. А есть где просто безнадежно медлненее. И это ограничение архитектуры языка.

CP> И это заметим OpenSource реализации. Коммерческие генерят ещё более быстрый код.


Оставим эти высказывания до появления хотя бы певого подтверждения.

CP> Другое дело что лисп прожорлив до памати, почти как джава.


Вы придумали себе Лисп который и любите. Если бы Лисп действительно был так крут, то создаваемые на его основе продукты давно завоевали бы рынок. А рынок заваевали Ява да С/С++. Причем перераспределение рынка идет именно между ними. Ява и дотнет отжирают все больше рынка, а С++ пытается удержать позиции. Даже если сложить долю рынка приходящуюся на все диаликты лиспа вместе взятые, то их результат можно наблюдать разве что в микроскоп.

Теперь можно послушать, что это из-за того, что все вокруг тупые и не понимают где щастье.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.01.06 22:02
Оценка:
Здравствуйте, CrazyPit, Вы писали:

VD>>Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?


CP>Есть,


Можно ссылочку? А то я даже вопросов по этому поводу не слышал.

CP> а также есть серьёзное специальное руководство (http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/part.html) по созданию эффективных программ. Меня вообще очень радует дока по erlangу


Возможно такя есть и по Руби.

VD>>Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны. А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее. Ну, а если начать сравнивать Эрлэнг с какими ниубдь Нэмерал или Скалой, то и вовсе неизвесно что удобнее и лучше.


CP>Да ну нет. Есть куча тулзов и емакс с хорошей модой + esense. И вообще установите себе базовую систему эрланг и посмотрите сколько там всего есть.


Хм. 1. Я сказал в первую очередь о уровне языка. 2. Емаксом пусть пользуются те кто пиарит кайф жизни в командной строке. 3. Что-то не веристя, что возможности Эрлэнговских сред сопоставимы с IDEA или VS 2005 применительно к Яве и Шарпу. А без них у меня нет желания использовать даже куда более интересные языки типа Скалы.

VD>>Ну, а нафига тогда этот Эрланг, если я могу все писать на языке который сопостовим по уровню с ним, но при этом хорошо поддается компиляции и имеет в разу лучшую инфраструктуру? Что я мазахист ислледователь?


CP>Потомучто для тех задач где его используют — он лучший А для других действительно нужно что-то другое использовать.


Ну, там может сказать, что он лучший только в области многопоточных вычислений? А то со стороны, по вашим словам, он просто лучший. Никто бы и возражать не стал бы.

Я вот все думаю, а сколько нужно написать кода, чтобы для другого хорошего языка написать хороший многопоточный фрэймворк?

CP>Де юре общего назначения. А де факто используют его для определённого круга задач.


Дык, и где в этих сообщениях:
Re: преимущества erlang-а?
Автор: Mamut
Дата: 22.01.06

Re: преимущества erlang-а?
Автор: Lazy Cjow Rhrr
Дата: 23.01.06

Re: преимущества erlang-а?
Автор: pavel74
Дата: 25.01.06

то есть почти во всех сообщениях близких к корню темы, хоть одно упоминание о том, что Эрлэнг выгоден только в опеделенном круге задачь? Где вообще хоть одно слово про его проблемы?

CP>Я могу ошибаться, но помойму таки может оптимизировать.


Можашь и ошибашся. Возможно кгна-нибудь будет, так как на фрэймворке куча ФЯ теперь стали работать, но не факт.

CP>ЗЫ: насчёт тестов. Эти тесты открыты. Вы можете запостить туда менее ресурсоёмкую версию на С#.


Эти тесты просто некорректры. Постить туда что-либо это себя не уважать. Там некорректно все начиная, с того что не контролируются аспекты вроде разных реализаций алгоритмов и контейнеров, и до банальных измерений.

В противном случае верхние ступеньки там были бы просто в тупую забиты соревнованием Intel C++ с Intel Fortran. Ну, переодически между ними вклинивались бы ЖЦЦ и т.п.

Особой годостью этих тестов должны служить тесты где выводятся тонны данных в консоль. Это просто шедевр! Я плакал глядя на них.

Но даже если поглядеть на эти тесты, то не трудно найти среди них такие в которых Эрлэг или вообще не прошел тест так как код на нем не смог завешиться, или прошел с результатом близким к Руби. А лучше всего выглядели тесты очень приметивные и вычисление которых можно переложить на встроенную библиотеку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.01.06 22:02
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Влад, язык, который ради удобства программиста приципиально не жертвует производительностью уже есть, называется он С и других нафиг не нужно.


Понимаш ли. Есть языки которые способны породить сопостовимый с С результат и при этом обеспечивают удобство не меньшее, ну, чем, или сопоставимое с Эрлэнг.

ANS>Хочется именно удобный язык.


Мне тоже. Но, лично я, языки которые не рассматривают вопрос производительности сразу отметаю.

Мне кажется выбор языка — это набор компромисов и чем лучше эти компромисы будут сбалансированы, тем больший эффект я получу от языка, и тем больший класс задач я смогу на нем решить.

Я требую от языка следующее:
1. Легкость в понимании.
2. Легкость в использовании.
3. Гибкость.
4. Производительность получаемого кода и возможность оптимизировать код.
5. Степерь в которой язык позволяет избегать ошибко.
6. Качество инфраструктуры (компиляторы, отладчики, средства редктирования и рефакторинга).
7. Количество и качество библиотек.
8. Поддержку языком и его рантаймом компонентных подходов и вообще динамические всойсатва языка и то не ухудшают ли они другие аспекты языка.
9. Обладать хорошей поддержкой (документацией, форумами, экспертами, программами обучения и самим обучением).

Ну, а исходя из этих предпосылок получается, что нужен язык:
1. Хоршо поддерживающий максимум парадикм программирования.
2. Позволяющего изменять синтаксис.
3. Оберегающим от ошибок, статически типизированным, типобезопасным.
5. Компонентноориентированным.
6. Обладающий простым и понятным базовым синтаксисом. Лисп, например, вообще синтакисом не обладает .

Я не балдею от того, что язык функциональный или императивный. Я не прихожу в экстаз от того, что язык обладает крутыми фичами вроде макросов Лиспа. Я не тащусь от того что язык обладает крутым рефаторингом как Шарп/Ява. Мне нужен комплекс.

Думаю, что и большинству программистов нужен комплекс. Вопрос тольк в приоритетах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: преимущества erlang-а?
От: CrazyPit  
Дата: 28.01.06 23:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. Весма нове. Аналогов нет. Есть конечно прототипы, но похоже Нэмерл их превзошел.


VD>Тут вот недавно задавался вопрос С++-ником по поводу метапрограммирования. Он как раз сказал, что ему не нравится, что препроцессор того же ОКамла не интегрируется с компилятором так же хорошо как С++. Он в общем-то не совсем прав, так как в С++ тоже хреново с этим делом. Но вот то что ОКамл не позволяет задействовать семантический анализ — это явный минус. Ведь без этого полученные в результате макросы будут куда примитивнее и порой будет очень не просто понять что за ошибка произошла. AST-то изменено, и компилятор будет орать на невидимое человеку его редставление, а не на исходное. А вот в Нэмерле можно легко реализовать дополнительные проверки.


Я весьма поверхостно знаком с Нэмерле. Можно пример макроса, делаюищего то о чём вы говорите.

VD>Лисп тут тоже ничем не лучше. У него тольо больше тараконов.


Но и больше возможностей. В немерле макросы "гигиенические" — т.е. можно реализовать далеко не всё что можно на лиспе. Но правда и гемороя поменьше, это да. Но факт остаёться фактом — макросы у немерле не полноценные.
Re[13]: преимущества erlang-а?
От: CrazyPit  
Дата: 28.01.06 23:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, CrazyPit, Вы писали:


CP>>Да ну? В каких таких расширениях. Она есть в стандарте, которому около 20 лет. И которым пользуеться все реализации Common Lisp.


VD>А какими расширениями пользуется Схема?


Не занаю, может что и есть... В основном сейчас юзаються 4 диалекта лиспа, два из них встроенных в приложения (AutoLisp и Elisp). И 2 общего — схема и CL. Остальные практически отмерли. И когда говорят "лисп" обчно имеёт ввиду именно CL, а про схему так и говорят "схема". Так что я виду разговор о CL.

VD>В стандарте чего? Одно из диалектов?


Основного диалекта. см. выше.


VD>Более того, даже в самых крутых диалектах Лиспа, насколько мне извесно, декларация типов не является обязательной. А без нее не всегда можно произвести вывод типов. К тому же есть конструкции принципиально не допускающие вывод типов или делающие его бесполезным.


А ну да я ещё забыл Dylan — так как раз обязательная декаларация типов. Но это уже не совем лисп.


VD>По оеределению атом в Лиспе есть вещь динамически типизированная и всегда можно найти код который не сможет однозначно вычеслить тип на этапе компиляции.


Как же не может. Берём функцию. Определям типы всех используемых в ней переменных. Компилируем. И вуаля код оптимизирован. Тем более не нужно оптимизировать всё. Берём профайлер (который кстати замечательно интегрирован с IDE:) и оптимизируем самые прожорливые функции.


VD>Есть языки кооторые проектировались в рассчете на статическую типизациб и вывод типов. И они в 100% случаев будут давать возможность породить оптимальный код. Лисп же к таковым не относится. Ну, а если вспомнит, что к Лиспам относятся тучи диалектов вообщ не знающие о аннотации типов, то вообще все обобщения по Лиспу являются обманом.


Да нету почти диалктов. померли все.


CP>>Вывода типов нет. А декларация есть.


VD>:))


VD>Я плакаль. А какй же тогда смысл в Лиспе если прийдется лепить типы везде? Это же будет монстр с типами, но без синтаксиса.


ЗАЧЕМ? Только там где это влияет на производительность.


CP>>А вообще при желание можно добавить в лисп возможности любого языка с помощью макр.


VD>Да, ну, добавь мне, плиз возможности того же Немерла. И так чтобы диагностика ошибок не пострадала.


VD>А я уж лучше предпочту пользоваться гтовым компилятором, а не писать его сам на совершенно сумашедем языке. :)


Так компилятор писать не нужно будет. Компилятор уже есть в CL.

CP>>Мне вот интерестно вы думаете что люди которые проводят те бэнчмарки (для почти всех языков) такие ярые фанаты лиспа, эрланга, etc.


VD>Нет. Они просто или халтурщики, или шарлотаны. Любому кто хоть что-то понимает в области производитльности достаточно часа чтобы понять, что эти тесты есть полнейшее фуфло. В них прост используются рзные реализации, разные структуры данных с разными алгоритмами и бечесные методы измерения производительности.


Ну так по теории вероятности. В одном месте они должны были лучше сдеать в лисповой программе в другом в джавовой в третьем в эрланговом. Наверняка накосячили везде, а не только в C#. Так что средняя оценка должна быть близкой к правде. (Хотя если брать среднюю квалификацию прогарммистов на разных языках....:) )


CP>> Им это надо?


VD>Видмо надо раз делают.


Да нет же. вообще разные тесты писали разные люди. И любой может прислать программу проходящую тесты, но работающую бытрее и её поставят вместо старой.


CP>> ТАк что он быстрее — ничего удивительного нет.


VD>Он не быстрее. Есть случае где Лисп сопоставим. А есть где просто безнадежно медлненее. И это ограничение архитектуры языка.


В более больших случаях чем те тесты (где лисп таки уделывает джаву http://shootout.alioth.debian.org/benchmark.php?test=all&amp;lang=cmucl&amp;lang2=java, нету таких мест где бы она сильно была впереди почти всё на равне но лисп впереди). А в более больших случаях, за счёт макр, мы получам более эффективные абстакции. Сами подумайте что будет быстрее работать 20-строчный макр генерирующий 500 строк линейного кода, или тот же алгоритм на джаве со множеством вызовов методов.

CP>> И это заметим OpenSource реализации. Коммерческие генерят ещё более быстрый код.


VD>Оставим эти высказывания до появления хотя бы певого подтверждения.


Сам сравнивал ACL7 с CMUCL. ACL — быстрее :))



VD>Вы придумали себе Лисп который и любите. Если бы Лисп действительно был так крут, то создаваемые на его основе продукты давно завоевали бы рынок. А рынок заваевали Ява да С/С++. Причем перераспределение рынка идет именно между ними. Ява и дотнет отжирают все больше рынка, а С++ пытается удержать позиции. Даже если сложить долю рынка приходящуюся на все диаликты лиспа вместе взятые, то их результат можно наблюдать разве что в микроскоп.


VD>Теперь можно послушать, что это из-за того, что все вокруг тупые и не понимают где щастье. :)


Да причём здесь тупые. Так сложилось исторически, также как например с виндой. Рынок никогда не завоёвывают самые лучшие решения:( Тем более лисп всё-таки используеться во многих местах, и его популярность не собираеться снижаться.
Re[13]: преимущества erlang-а?
От: CrazyPit  
Дата: 29.01.06 00:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, CrazyPit, Вы писали:


VD>>>Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?


CP>>Есть,


VD>Можно ссылочку? А то я даже вопросов по этому поводу не слышал.


Как же, в том руководстве по эффективности — глава 8 profiling.


CP>>Да ну нет. Есть куча тулзов и емакс с хорошей модой + esense. И вообще установите себе базовую систему эрланг и посмотрите сколько там всего есть.


VD>Хм. 1. Я сказал в первую очередь о уровне языка. 2. Емаксом пусть пользуются те кто пиарит кайф жизни в командной строке. 3. Что-то не веристя, что возможности Эрлэнговских сред сопоставимы с IDEA или VS 2005 применительно к Яве и Шарпу. А без них у меня нет желания использовать даже куда более интересные языки типа Скалы.


1. Ну дык посмотрите на моду эрланговскую к емаксу, посмотрите на скриншоты http://esense.sourceforge.net/, чем не поддержка.
2. Это миф. Емакс самая настраиваемая и расширяема среда. Он поддерживает сотни языков. Интеграцию всех необходимых тулзов для огромного количества языков — профайлеры, дебагеры, автодополнения, поиск документации, навигация по коду, шаблоны, автоматический рефакторинг и.т.д и.т.п. Плюс кучу общих тулз — визуальная интеграция с текстовыми утилитам grep/find/diff. Работа почти со всеми ситемами контроля версий. Плюс работа с БД, файлами на удалённых компьютерах, работа с множеством интерактивных программ (например gnuplot, maxima). Плюс куча не относящихся к обраотке текстов тулз — Mail, IRC, Window Managers etc.. Вообщем монстр. Я перечислил едвали 10-20% возможностей. Никаким VS или IDEA не снилось.

CP>>Потомучто для тех задач где его используют — он лучший:) А для других действительно нужно что-то другое использовать.


VD>Ну, там может сказать, что он лучший только в области многопоточных вычислений? А то со стороны, по вашим словам, он просто лучший. Никто бы и возражать не стал бы. :xz:


Я этого не говорил. Лично я не собираюсь его использовать везде, а только там где он силён.



CP>>Де юре общего назначения. А де факто используют его для определённого круга задач.


VD>Дык, и где в этих сообщениях:

VD>Re: преимущества erlang-а?
Автор: Mamut
Дата: 22.01.06

VD>Re: преимущества erlang-а?
Автор: Lazy Cjow Rhrr
Дата: 23.01.06

VD>Re: преимущества erlang-а?
Автор: pavel74
Дата: 25.01.06

VD>то есть почти во всех сообщениях близких к корню темы, хоть одно упоминание о том, что Эрлэнг выгоден только в опеделенном круге задачь? Где вообще хоть одно слово про его проблемы?

Не ко мне вопрос. Я вообще не считаю эрланг каким-то супер языком, но в параленьных вычисления действительно силён, сволочь


CP>>Я могу ошибаться, но помойму таки может оптимизировать.


VD>Можашь и ошибашся. Возможно кгна-нибудь будет, так как на фрэймворке куча ФЯ теперь стали работать, но не факт.


Даже gcc умеет tail-recursion оптимизировать...

CP>>ЗЫ: насчёт тестов. Эти тесты открыты. Вы можете запостить туда менее ресурсоёмкую версию на С#.


VD>Эти тесты просто некорректры. Постить туда что-либо это себя не уважать. Там некорректно все начиная, с того что не контролируются аспекты вроде разных реализаций алгоритмов и контейнеров, и до банальных измерений.


Ну почему. Покажите что C# или Java лучше. Вы это сможите.

VD>В противном случае верхние ступеньки там были бы просто в тупую забиты соревнованием Intel C++ с Intel Fortran. Ну, переодически между ними вклинивались бы ЖЦЦ и т.п.


Ну дык так и есть. Fortran, C — на первых местах в общем случае.
Re[14]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 01:56
Оценка:
Здравствуйте, CrazyPit, Вы писали:

CP>Как же, в том руководстве по эффективности — глава 8 profiling.


Зачем мне глава? Ты мне ссылку на профалер дай, плиз.

CP>1. Ну дык посмотрите на моду эрланговскую к емаксу, посмотрите на скриншоты http://esense.sourceforge.net/, чем не поддержка.


Я на Емакс сотреть не хочу. Я предпочитаю редактор которые не нужно перед использованием изучать пол жизни.

CP>2. Это миф. Емакс самая...


Мне плевать что там в Емакс самого. Настраивать его на Лиспе я не буду. Я его даже открвать не буду. Мне уже хватало опыта работы с ним.

CP>...Никаким VS или IDEA не снилось.


Да уж им вообще ничего не снится. Они работают и на них работать удобно. Все что нужно настраивается визуально и сохраняется в отдельный файл настроек который куда угодно перетащить можно.
К томже хотелось бы еще и рефакторинг. Привык я к нему.

CP>Я этого не говорил. Лично я не собираюсь его использовать везде, а только там где он силён.


Ты, может и не говорил. Но и замечания не сделал тем кто говорил.

CP>Не ко мне вопрос. Я вообще не считаю эрланг каким-то супер языком, но в параленьных вычисления действительно силён, сволочь


Охоно верю. Но чесно говоря не вижу почему бы его опыт не перенести на другие расширяемые языки или не оформить в виде библиотеки.

CP>Даже gcc умеет tail-recursion оптимизировать...


Он и еще вроде бы Интел. Причем тут они и дотнет?

CP>Ну почему. Покажите что C# или Java лучше. Вы это сможите.


Мне не надо показывать, что что-то лучше. Я делал тесты и знаю что в них получается. А даказывать что-то этим уродам я не собираюсь. Как в прочем и серьезно смотреть на результаты их естов.

VD>>В противном случае верхние ступеньки там были бы просто в тупую забиты соревнованием Intel C++ с Intel Fortran. Ну, переодически между ними вклинивались бы ЖЦЦ и т.п.


CP>Ну дык так и есть. Fortran, C — на первых местах в общем случае.


Ды нет все немного. В половине тестов измеряется скорость вывода на консоль. В другой половине просто арзые алготмы. Время замеряется так, что средам с джитом никогда первыми не прийти. Все вместе это называется или профанство или жульничество. В зависимости от того специально или нет все это сделано.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 01:56
Оценка:
Здравствуйте, CrazyPit, Вы писали:

CP>Не занаю, может что и есть... В основном сейчас юзаються 4 диалекта лиспа, два из них встроенных в приложения (AutoLisp и Elisp). И 2 общего — схема и CL. Остальные практически отмерли. И когда говорят "лисп" обчно имеёт ввиду именно CL, а про схему так и говорят "схема". Так что я виду разговор о CL.


А я вообще-то не говорил о CL. А говорил о Лиспе вообще. Между прочим когда его на этоам форуме рекомендуют, то в первую очередь тыкают на Схему. И это разумно. Дейсвтиельно чистно функциональный язык, да еще и простой. А когда о производительности разговор заходит, то бурем значит самый узасный CL и используем в нем то, за что ругаем другие языки. Здорово!

К тому же еще раз повторю, что даже будучи скомпилированным многие Лисповые прогрммы останутся по сути интерпретирвемыми, так как в самом Лиспе заложено слишком много вольнотей. Да и типы то ведь опять таки только простые. Структуры не опишеш. А как тот же кортэж представить?

Ну, и возвращаясь к Эрэнгу... ОК, при анатации типов даже CL можно заставить порождать отличный код во многих случаях. Но разве у Эрлэгна вообще есть синтаксис декларации типов? Или где-то описан механизм их вывода?

CP>Ну так по теории вероятности. В одном месте они должны были лучше сдеать в лисповой программе в другом в джавовой в третьем в эрланговом. Наверняка накосячили везде, а не только в C#. Так что средняя оценка должна быть близкой к правде. (Хотя если брать среднюю квалификацию прогарммистов на разных языках.... )


Понимашь ли в чем дело. Если люди исходно применяют в тестах некорректные способы измерения, не следят за идентичностью алгоритмов и даже допускают такие вещи как включение в тесты вывода на консоль отнимающего большую часть тестов, то говорить с такими людьми смысла нет. Задолбашся убеждать. Я вон тебе то обяснить, на русском это никак не могу. А как объяснить это этим долболомам?

Мне проще сдалеть свои тесы. Что я и сделал. Правда там небыло ФЯ, так как тогда эта тема вообще была мало интересна.

Можно сделать еще одну попытку учтя ошибки прошлой и расширив список тестируемых функциональными языками. Но при этом нужно решить некоторые проблемы. Самой большой из них будет то кто будет проверять соотвествие реализаций условиям?

Я вижу только один вариант — делать не синтетические тесты, а прождающие осизаемый результат. Так же прийдется обсуждать каждый тест и надеяться на честность гуру в области конкретных языков.

CP>>> Им это надо?


VD>>Видмо надо раз делают.


CP>Да нет же. вообще разные тесты писали разные люди. И любой может прислать программу проходящую тесты, но работающую бытрее и её поставят вместо старой.


Я вижу результат. Он является полнейшей халтурой. Ну, может специальной подтасовкой. Называй как хочешь.

Да и мало интересны результаты на Линукс. Я дотнет там использовать не стану.

CP>В более больших случаях чем те тесты (где лисп таки уделывает джаву http://shootout.alioth.debian.org/benchmark.php?test=all&amp;lang=cmucl&amp;lang2=java, нету таких мест где бы она сильно была впереди почти всё на равне но лисп впереди). А в более больших случаях, за счёт макр, мы получам более эффективные абстакции. Сами подумайте что будет быстрее работать 20-строчный макр генерирующий 500 строк линейного кода, или тот же алгоритм на джаве со множеством вызовов методов.


Понимашь ли, я делая даже их тесты, при корректном измерении времени налюдаю что C# показывает результаты в основном на уровне VC 8.0.

Охотно верю, что хорошая реализация Лиспа с анотацией типов и компляцией на некотором классе задач может тоже сравняться с С++. Но вот я совсем не верю, что интерпретируемый Эрлинг соможет это сделать. Ну, и поять же есть куча тестов где без наличия типизированных массивов можно тихо и мирно отдыхать. Например, сортировка в памяти. В таких тестах Лисп будет не в лучшим свете если конечно не использовать совершенно императивных консрукций и массивов. Но используя их уже не ясно о каких таких различиях вообще идет речь.

VD>>Теперь можно послушать, что это из-за того, что все вокруг тупые и не понимают где щастье.


CP>Да причём здесь тупые. Так сложилось исторически,


А почему так сложилось исторически и не перекладывается сейчас?

CP>также как например с виндой. Рынок никогда не завоёвывают самые лучшие решения


Как раз рынок заваевываеют всегда исключительно самые лучше. Рынок можно обмануть на короткий период. Но нельзя обмануть в перспективе.

Просто у рынка другие критерии нежели от отдельных личностей. То что ты считашь важным, не важно для большинтсва и надоборот.

Ты вот считашь Емакс нормальным редактором, а большинство его на дух не переносит.

CP> Тем более лисп всё-таки используеться во многих местах, и его популярность не собираеться снижаться.


Ее в общем-то и нет. Языки намного моложе захатили рынок. И если один из ФЯ прийдет в массы, то это точно не будет Лисп. Уж больно он нечеловеколюбив .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 01:56
Оценка:
Здравствуйте, CrazyPit, Вы писали:

CP>Я весьма поверхостно знаком с Нэмерле. Можно пример макроса, делаюищего то о чём вы говорите.


Я к сожалению тоже в основном изучю его больше теоритически. Мешает отсуствие того самого сервиса. Уж больно не хочется затрачивать хрен знает сколько времени, чтобы запусткть раннюю версию примитивной поддржки среды. Но примеры есть и у них на сайте, и в поставке самого Нэмерла.

Вот здесь можно скачать исходники Немерла и его компилятор:
http://nemerle.org/download/snapshots/?C=M;O=D

Макросы можно поглядеть в следующих местах:
nemerle-0.9.2.99.6088\macros\ — Код стандартных макросов.
nemerle-0.9.2.99.6088\doc\html\metaprogramming.pdf — водная статья описывающая то как они утроены и как их использовать.

В статье, в качестве пример, приводится такая штука. В языке нет императивного if-else-а. Вместо этого используется универсальное сопоставление с образцом
mattc (что сопостоавляем)
    | паттерн => вывод/действие
    | другой паттерн => вывод/действие

так вот приводится пример того как на базе сопоставления с образцом делается тот самый if-else. В общем, проще процетировать:

8 Typing during execution of macro

Some more advanced techniques are also possible. They involve a closer interaction with the compiler, using its methods and data structures or even interweaving with internal compilation stages.
For example, we can ask the compiler to type some of object programs, which are passed to the macro, retrieve and compare their types, etc. This means that we can plug between many important actions performed by the compiler, adding our own code there. It might be just a nicer bug reporting (especially for macros defining complex syntax extensions), making code generation dependent on input program types or improving code analysis with additional information.

8.1 Example

Let us consider the following translation of the if condition to the standard ML
matching:
macro @if (cond, e1, e2)
syntax ("if", "(", cond, ")", e1, "else", e1)
{
    <[
        match ($cond)
        {    | true => $e1
            | false => $e2
        }
    ]>
}

When if ("bar") true else false was written, the compiler would complain that type of matched expression is not bool. Such an error message could be very confusing, because the programmer may not know, that his if statement is being transformed to the match statement. Thus, we would like to check such errors during the execution of the macro, so we can generate a more verbose message.

8.2 Usage

Instead of directly passing object expressions to the result of the macro, we can
first make the compiler type them and then find out if they have the proper
type. The body of the above if macro should be
def tcond = TypedExpr (cond);
def te1 = TypedExpr (e1);
def te2 = TypedExpr (e2);
if (tcond.Type == <[ ttype: bool ]> )
{
    <[
        match ($(tcond : typed))
        { | true => $(te1 : typed)
            | false => $(te2 : typed)
        }
    ]>
}
else
    FailWith("`if' condition must have type bool, "
        + "while it has " + tcond.Type.ToString())

Note that typed expressions are used again in the quotation, but with a
special splicing tag \typed". This means that the compiler does not have to
perform the typing (in fact, it cannot do this from now on) on the provided
syntax trees. Such a notation introduces some kind of laziness in typing, which
is guided directly by a programmer of the macro.


VD>>Лисп тут тоже ничем не лучше. У него тольо больше тараконов.


CP>Но и больше возможностей.


С чего бы это? Возможностей скорее меньше. Вернее не возможностей, а удобства.

CP> В немерле макросы "гигиенические" — т.е. можно реализовать далеко не всё что можно на лиспе. Но правда и гемороя поменьше, это да. Но факт остаёться фактом — макросы у немерле не полноценные.


Я не спец в Немерл. Но похоже, что все что нужно на них реализовать можно. Это коечно не чисто АСТ, но и писать предлагается не в АСТ, а на нормальном языке.

А вот то, что макросы имеют доступ к семантическому анализу делает их куда более мощьной вещью нежели макросы Лиспа.

Ну, а главное, что когда я вижу макрос Лиспа мне становится не посебе. Это нагрмождение бреда! А когда я вижу макрос Нэмерла я его понимаю практически без обяснений. А зачем мне геморрой?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: преимущества erlang-а?
От: CrazyPit  
Дата: 29.01.06 02:29
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Зачем мне глава? Ты мне ссылку на профалер дай, плиз.


Ну ё мое:
http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/profiling.html там описаны профайлеры.

CP>>1. Ну дык посмотрите на моду эрланговскую к емаксу, посмотрите на скриншоты http://esense.sourceforge.net/, чем не поддержка.


VD>Я на Емакс сотреть не хочу. Я предпочитаю редактор которые не нужно перед использованием изучать пол жизни.


Зато изучив работать можно работать намного эффективнее.


CP>>...Никаким VS или IDEA не снилось.


VD>Да уж им вообще ничего не снится. Они работают и на них работать удобно. Все что нужно настраивается визуально и сохраняется в отдельный файл настроек который куда угодно перетащить можно.

VD>К томже хотелось бы еще и рефакторинг. Привык я к нему. :xz:

Рефакторинг есть. Например http://xref-tech.com/xrefactory/main.html, Ну дык в емаксе всё что нужно настраиваеться визуально (customize) А то что нельзя (вообще нельзя нигде) пишеться на лиспе. И перетаскиваеться тоже свободно. Вообще некоторые емаксовские расширения-приложения могут автоматически скачивать свои настройки с единого сервера.

CP>>Я этого не говорил. Лично я не собираюсь его использовать везде, а только там где он силён.


VD>Ты, может и не говорил. Но и замечания не сделал тем кто говорил.


Я эрланг изучаю неделю. А те люди с ним работали долгое время, не мне пока судить.

VD>Охоно верю. Но чесно говоря не вижу почему бы его опыт не перенести на другие расширяемые языки или не оформить в виде библиотеки.


Видимо это сложно сдлеать не криво, раз никто ещё не сделал.

CP>>Даже gcc умеет tail-recursion оптимизировать...


VD>Он и еще вроде бы Интел. Причем тут они и дотнет?


Ну типа виртуальная машина дотнета поддерживает хвостовую рекурсию, в F# или Nemerle это работает. Почему бы не сделать это для C# — основного .net языка....
Re[15]: преимущества erlang-а?
От: CrazyPit  
Дата: 29.01.06 02:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А я вообще-то не говорил о CL. А говорил о Лиспе вообще. Между прочим когда его на этоам форуме рекомендуют, то в первую очередь тыкают на Схему. И это разумно. Дейсвтиельно чистно функциональный язык, да еще и простой. А когда о производительности разговор заходит, то бурем значит самый узасный CL и используем в нем то, за что ругаем другие языки. Здорово! :)


Да-да:) Вообще исходники самого CMUCL посмотреть — сполшная императившина. А схему советуют т.к. она проще, а CL более приспособлен к рельной жизни.

VD>К тому же еще раз повторю, что даже будучи скомпилированным многие Лисповые прогрммы останутся по сути интерпретирвемыми,

Почему-же это они будут интерпретируемы?

> так как в самом Лиспе заложено слишком много вольнотей. Да и типы то ведь опять таки только простые. Структуры не опишеш. А как тот же кортэж представить?


Есть и структуры и типизированные массивы и классы есть и хэши.


VD>Ну, и возвращаясь к Эрэнгу... ОК, при анатации типов даже CL можно заставить порождать отличный код во многих случаях. Но разве у Эрлэгна вообще есть синтаксис декларации типов? Или где-то описан механизм их вывода?


вроде нет.

VD>Можно сделать еще одну попытку учтя ошибки прошлой и расширив список тестируемых функциональными языками. Но при этом нужно решить некоторые проблемы. Самой большой из них будет то кто будет проверять соотвествие реализаций условиям?


VD>Я вижу только один вариант — делать не синтетические тесты, а прождающие осизаемый результат. Так же прийдется обсуждать каждый тест и надеяться на честность гуру в области конкретных языков.


Хорошая идея:))


VD>Охотно верю, что хорошая реализация Лиспа с анотацией типов и компляцией на некотором классе задач может тоже сравняться с С++. Но вот я совсем не верю, что интерпретируемый Эрлинг соможет это сделать. Ну, и поять же есть куча тестов где без наличия типизированных массивов можно тихо и мирно отдыхать. Например, сортировка в памяти. В таких тестах Лисп будет не в лучшим свете если конечно не использовать совершенно императивных консрукций и массивов. Но используя их уже не ясно о каких таких различиях вообще идет речь.


Ну дык можно же использовать...



CP>>Да причём здесь тупые. Так сложилось исторически,


VD>А почему так сложилось исторически и не перекладывается сейчас?


Потомучто зарули юникс и C вместе с ним. Лисп в то время не был так быстр и переносим. А уж когда все привыкли к C синтаксису, изучать лисп большинтву стало влом.



VD>Просто у рынка другие критерии нежели от отдельных личностей. То что ты считашь важным, не важно для большинтсва и надоборот.


VD>Ты вот считашь Емакс нормальным редактором, а большинство его на дух не переносит.


Большинтво ведёться на рекламу.

CP>> Тем более лисп всё-таки используеться во многих местах, и его популярность не собираеться снижаться.


VD>Ее в общем-то и нет. Языки намного моложе захатили рынок. И если один из ФЯ прийдет в массы, то это точно не будет Лисп. Уж больно он нечеловеколюбив :).


Да да я знаю. Когда нибудь через десятки лет изобретут идеальный язык. Он будет называться по другому но по сути это будет лисп:)
Re[16]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 02:53
Оценка:
Здравствуйте, CrazyPit, Вы писали:

CP>Ну ё мое:

CP>http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/profiling.html там описаны профайлеры.

К сожалению страничка не открылась.

CP>Зато изучив работать можно работать намного эффективнее.


Я и так работают намного эффективнее. А потеря пол жизни вряд ли улушит это.
В общем, Емакс идет в лес. Это на любителя головоломок. Я не из их числа. Да и большинство людей тоже.

CP>Рефакторинг есть. Например http://xref-tech.com/xrefactory/main.html, Ну дык в емаксе всё что нужно настраиваеться визуально (customize) А то что нельзя (вообще нельзя нигде) пишеться на лиспе. И перетаскиваеться тоже свободно. Вообще некоторые емаксовские расширения-приложения могут автоматически скачивать свои настройки с единого сервера.


Это рефакторинг для С++. По словам людей совершенно бездарный. Согласен, что лучше наверно для С++ нет, но от этого не легче. Но на С++ меня не тянет писать вообще.

Мы же вроде про Эрлэнг говорим. Есть для него рефакторинг? Мне вот с трудом веристя. Ведь рефакторинг тоже любит аннотацию типов. Ему ведь за что-то цепляться нужно. Ну, да хоть что-то можно сделать.

CP>Я эрланг изучаю неделю. А те люди с ним работали долгое время, не мне пока судить.


Ну, то есть я знаю, но кто я такой чтобы вывдавать тайну...

VD>>Охоно верю. Но чесно говоря не вижу почему бы его опыт не перенести на другие расширяемые языки или не оформить в виде библиотеки.


CP>Видимо это сложно сдлеать не криво, раз никто ещё не сделал.


Вот в том же Нэмерле вроде как есть макросы по этому поводу. Незнаю уж насколько оно удобно. Но все же есть. К С++ вроде тоже самое пытаются сейчас прикрутить. К Шарпу.

Думаю что до сих пор нет норальных реализаций только потому, что до недавнего времени вопрос был не актуален. Большинство потребителей имели однопроцессорные машины. А серверны пишутся штучно и скорее всего у их разработчиков свои фрэймворки есть.
VD>>Он и еще вроде бы Интел. Причем тут они и дотнет?

CP>Ну типа виртуальная машина дотнета поддерживает хвостовую рекурсию, в F# или Nemerle это работает. Почему бы не сделать это для C# — основного .net языка....


F# и Nemerle сами преобразуют все как надо. О расширении машины под ФЯ были разговоры, но пока ничено не сделано.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: преимущества erlang-а?
От: CrazyPit  
Дата: 29.01.06 03:01
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>
VD>def tcond = TypedExpr (cond);
VD>def te1 = TypedExpr (e1);
VD>def te2 = TypedExpr (e2);
VD>if (tcond.Type == <[ ttype: bool ]> )
VD>{
VD>    <[
VD>        match ($(tcond : typed))
VD>        { | true => $(te1 : typed)
VD>            | false => $(te2 : typed)
VD>        }
VD>    ]>
VD>}
VD>else
VD>    FailWith("`if' condition must have type bool, "
VD>        + "while it has " + tcond.Type.ToString())
VD>

VD>Note that typed expressions are used again in the quotation, but with a
VD>special splicing tag \typed". This means that the compiler does not have to
VD>perform the typing (in fact, it cannot do this from now on) on the provided
VD>syntax trees. Such a notation introduces some kind of laziness in typing, which
VD>is guided directly by a programmer of the macro.
VD>[/q]

Т.е. если в макр поступает выражение X > Y то всё ок. А если "asd" + "asa", то облом. Конечно в 6 утра я плохо соображаю, но здесь видимо нужне вывод типов из выражений. В лиспе его нет... А если нужно просто проверить на тип входной параметр то это легко.

VD>>>Лисп тут тоже ничем не лучше. У него тольо больше тараконов.


CP>>Но и больше возможностей.


VD>С чего бы это? Возможностей скорее меньше. Вернее не возможностей, а удобства.


AST намного удобнее управлять програмно, чем кодом, как в немерле. А некоторые вещи вообще не возможны, типа анофорических макр.

(awhen (compr x y)
   (blah it))


раскрывается в

(let (it (compr x y))
  (when it
   (blah it))
Re[17]: преимущества erlang-а?
От: CrazyPit  
Дата: 29.01.06 03:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>К сожалению страничка не открылась.


http://www.erlang-fr.org/erlang.org/doc/efficiency_guide/profiling.html

VD>Это рефакторинг для С++. По словам людей совершенно бездарный. Согласен, что лучше наверно для С++ нет, но от этого не легче. Но на С++ меня не тянет писать вообще. :))


Там и для джавы и для С.

VD>Мы же вроде про Эрлэнг говорим. Есть для него рефакторинг? Мне вот с трудом веристя. Ведь рефакторинг тоже любит аннотацию типов. Ему ведь за что-то цепляться нужно. Ну, да хоть что-то можно сделать.


Незнаю. Один небольшой авто-рефакторин:) я заметил. Если сохарнять модуль обазначенный одним именем в файл с дургим именем, емакс спрашивает, "а не поменять ли нам, дружок, имя модуля?" :)))

VD>Вот в том же Нэмерле вроде как есть макросы по этому поводу. Незнаю уж насколько оно удобно. Но все же есть. К С++ вроде тоже самое пытаются сейчас прикрутить. К Шарпу.


А в эрланге уже есть и уже работает и уже готова инфраструктура с кучей документов "как-правильно-реализовать-многопроцессное-приложениие-на-эрланге"


CP>>Ну типа виртуальная машина дотнета поддерживает хвостовую рекурсию, в F# или Nemerle это работает. Почему бы не сделать это для C# — основного .net языка....


VD>F# и Nemerle сами преобразуют все как надо. О расширении машины под ФЯ были разговоры, но пока ничено не сделано.


Я конкретно про хвостовую рекурсию. Она точно есть в виртуальной машине. http://www.google.ru/search?q=.net+vm+tail+recursion&amp;sourceid=mozilla-search&amp;start=0&amp;start=0&amp;ie=utf-8&amp;oe=utf-8&amp;client=firefox&amp;rls=org.mozilla:en-US:unofficial
Re[15]: преимущества erlang-а?
От: WFrag США  
Дата: 29.01.06 05:26
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А я вообще-то не говорил о CL. А говорил о Лиспе вообще. Между прочим когда его на этоам форуме рекомендуют, то в первую очередь тыкают на Схему. И это разумно. Дейсвтиельно чистно функциональный язык, да еще и простой. А когда о производительности разговор заходит, то бурем значит самый узасный CL и используем в нем то, за что ругаем другие языки. Здорово!


Так, замечание небольшое. С какой это радости Схема стала вдруг чисто функциональной? В ней же одна из специальных форм — присваивание:

(set! <name> <new-value>) -- присваивание
Re[18]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 05:45
Оценка:
Здравствуйте, CrazyPit, Вы писали:

CP>Там и для джавы и для С.


Еще раз, мы вроде о Эрлинге...

CP>Незнаю. Один небольшой авто-рефакторин я заметил. Если сохарнять модуль обазначенный одним именем в файл с дургим именем, емакс спрашивает, "а не поменять ли нам, дружок, имя модуля?"




CP>А в эрланге уже есть и уже работает и уже готова инфраструктура с кучей документов "как-правильно-реализовать-многопроцессное-приложениие-на-эрланге"


Дык я и не спорю, что это достоинство. Вопрос перевыешивает ли он недостатки Эрлэнга и достоинсво других языков.

CP>Я конкретно про хвостовую рекурсию. Она точно есть в виртуальной машине. http://www.google.ru/search?q=.net+vm+tail+recursion&amp;sourceid=mozilla-search&amp;start=0&amp;start=0&amp;ie=utf-8&amp;oe=utf-8&amp;client=firefox&amp;rls=org.mozilla:en-US:unofficial


Хм. Забавно. Я об этом не знал. Значит все таки ввели.
Вот только все же две проблемы остаются.
1. Моно != дотент и темболее != дотнет 2.0. А этот префикс введен во втором фрэймворке.
2. К сожалению даже компилятор C# 2.0 не использует эту инструкцию. А, как я понимаю, сам джит определением конечной рекурсии не занимается (хотя что ему стоит?).

Я провел простенький эксперемент. Вот такой код:
using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(Sum(10, 300));
    }

    static int Sum(int val, int count)
    {
        if (count <= 1)
            return val;

        return val + Sum(val, count - 1);
    }
}

Порождает вот такой мсил :
.method private hidebysig static int32  Sum(int32 val,
                                            int32 count) cil managed
{
  // Code size       18 (0x12)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4.1
  IL_0002:  bgt.s      IL_0006
  IL_0004:  ldarg.0
  IL_0005:  ret
  IL_0006:  ldarg.0
  IL_0007:  ldarg.0
  IL_0008:  ldarg.1
  IL_0009:  ldc.i4.1
  IL_000a:  sub
  IL_000b:  call       int32 Program::Sum(int32,
                                          int32)
  IL_0010:  add
  IL_0011:  ret
} // end of method Program::Sum
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: преимущества erlang-а?
От: Mikl Kurkov Россия  
Дата: 29.01.06 08:38
Оценка:
Здравствуйте, VladD2, Вы писали:

...
VD>Я провел простенький эксперемент. Вот такой код:
VD>
VD>using System;

VD>class Program
VD>{
VD>    static void Main()
VD>    {
VD>        Console.WriteLine(Sum(10, 300));
VD>    }

VD>    static int Sum(int val, int count)
VD>    {
VD>        if (count <= 1)
VD>            return val;

VD>        return val + Sum(val, count - 1);
VD>    }
VD>}
VD>

А где тут хвостовая рекурсия?

Может вот так все таки:

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(Sum(10, 300, 0));
    }

    static int Sum(int val, int count, int acc)
    {
        if (count <= 0)
            return acc;

          return Sum(val, count - 1, acc + val);
    }
}
Re[16]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 16:38
Оценка:
Здравствуйте, CrazyPit, Вы писали:

CP>Т.е. если в макр поступает выражение X > Y то всё ок. А если "asd" + "asa", то облом.


Ага. Причем макрос может проанализировать тип выражения и выдать осмысленный результата или предпринять некие действия.

CP> Конечно в 6 утра я плохо соображаю, но здесь видимо нужне вывод типов из выражений. В лиспе его нет...


Естественно, так как его макросы — это всего лишь преобразование над АСТ. К компилятору из них не обратишся.

CP> А если нужно просто проверить на тип входной параметр то это легко.


Интересно как? В конце концов параметр может быть функцией возвращающей булево значение при выполнении. К тому же большинство кода не типизированно так что с него вообще до выполнения ничего не получишь. Ну, и опять возвращаемся к вопросу что называть Лиспом. В Схеме макросы отличные, а средств работы с типами нема.

CP>AST намного удобнее управлять програмно, чем кодом, как в немерле.


Как видишь, особых проблем нет. Более того получается в сто раз понятнее. Причем без специальной дрисеровки пользователя.

Но тут дело даже не в том, чем удобнее манипулировать. Тут дело в том, что манипуляции с кодом не являются самоцелью. Это всего лишь способ расширеня возможностей языка. Кроме этого нужно чтобы сам язык был простым, понятным и удобным. Вот Лисп ну никак язык не поворачивается назвать понятным и удобным.

CP> А некоторые вещи вообще не возможны, типа анофорических макр.


Что означает "анофорических"?

CP>
CP>(awhen (compr x y)
CP>   (blah it))
CP>


CP>раскрывается в


CP>
CP>(let (it (compr x y))
CP>  (when it
CP>   (blah it))
CP>


Не въехал, а что тут необычного?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.06 16:38
Оценка:
Здравствуйте, Mikl Kurkov, Вы писали:

MK>Может вот так все таки:


MK>
MK>using System;

MK>class Program
MK>{
MK>    static void Main()
MK>    {
MK>        Console.WriteLine(Sum(10, 300, 0));
MK>    }

MK>    static int Sum(int val, int count, int acc)
MK>    {
MK>        if (count <= 0)
MK>            return acc;

MK>          return Sum(val, count - 1, acc + val);
MK>    }
MK>}
MK>


Все равно бестолку:
.method private hidebysig static int32  Sum(int32 val,
                                            int32 count,
                                            int32 acc) cil managed
{
  // Code size       19 (0x13)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4.0
  IL_0002:  bgt.s      IL_0006
  IL_0004:  ldarg.2
  IL_0005:  ret
  IL_0006:  ldarg.0
  IL_0007:  ldarg.1
  IL_0008:  ldc.i4.1
  IL_0009:  sub
  IL_000a:  ldarg.2
  IL_000b:  ldarg.0
  IL_000c:  add
  IL_000d:  call       int32 Program::Sum(int32,
                                          int32,
                                          int32)
  IL_0012:  ret
} // end of method Program::Sum


Провел еще один эксперемент. Сконвертировал код в Нэмерл и скормил его компилятору.
Вот конвертированный код:
using System;

class Program
{
    static Main() :  void
    {
        Console.WriteLine(Sum(10, 300, 0));
    }

    static Sum(mutable  val : int, mutable  count :  int, mutable  acc :  int) :  int
    {
        if (count <= 0)
             acc;
        else
         Sum(val, count - 1, acc + val);
    }
}

С виду почти идентичный.
А вот что получилось в результате в мсиле:
.method private hidebysig static int32  Sum(int32 val,
                                            int32 count,
                                            int32 acc) cil managed
{
  // Code size       32 (0x20)
  .maxstack  6
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4.0
  IL_0002:  bgt        IL_000d
  IL_0007:  ldarg.2
  IL_0008:  br         IL_001f
  IL_000d:  ldarg.0
  IL_000e:  ldarg.1
  IL_000f:  ldc.i4.1
  IL_0010:  sub.ovf
  IL_0011:  ldarg.2
  IL_0012:  ldarg.0
  IL_0013:  add.ovf
  IL_0014:  starg.s    acc
  IL_0016:  starg.s    count
  IL_0018:  starg.s    val
  IL_001a:  br         IL_0000
  IL_001f:  ret
} // end of method Program::Sum

Не вооруженным взглядом видно, что рекурсивный вызов устранен на проч.




Ну, что же... Проведем следственный эксперемент проверяющий мое предположение о влиянии устранения концевой рекурсии на результата упомянутого теста.

Возмем в качесте упомянутый тест Ackermann.

Вот его код модифицированный мной с целью измерения чистого времени выполнения функции Ack():
using System;
using System.Diagnostics;

class Ackermann
{
    public static int Ack(int m, int n)
    {
        if (m == 0)
            return n + 1;
        if (n == 0)
            return Ack(m - 1, 1);
        else
            return Ack(m - 1, Ack(m, n - 1));
    }

    static void Main(string[] args)
    {
        int n = 11;

        if (args.Length > 0)
            n = Int32.Parse(args[0]);

        Stopwatch timer = Stopwatch.StartNew();

        int res = Ack(3, n);

        Console.WriteLine("Ack(3,{0}): {1}   {2}", n, res, timer.Elapsed);
    }
}


А вот анлог этой функции на Нэмерл полученный мной путем конвертации шарповского кода и немного подчищенный (удалены лишние скобки и сделано верное выравнивание):
using System;
using System.Diagnostics;

class Ackermann
{
    public static Ack(mutable  m : int,mutable  n :  int) :  int
    {
        if (m == 0)
             n + 1;
        else     if (n == 0)
             Ack(m - 1, 1);
        else
             Ack(m - 1, Ack(m, n - 1));
    }

    static Main(mutable  args :  array [string]) :  void
    {
        mutable  n = 11;

        when (args.Length > 0)
            n = Int32.Parse(args[0]);

        mutable  timer = Stopwatch.StartNew();

        mutable  res = Ack(3, n);

        Console.WriteLine("Ack(3,{0}): {1}   {2}", n, res, timer.Elapsed);
    }
}

Результат при выолнении на Pentium M 1.7 MGhz:
C:\VS\Nemerle>Ackermann-n.exe
Ack(3,11): 16381   00:00:00.8386434

C:\VS\Nemerle>Ackermann-cs.exe
Ack(3,11): 16381   00:00:01.5771912


Результат на AMD 64 3500+:
c:\Temp\007>Ackermann-n.exe
Ack(3,11): 16381   00:00:00.6920116

c:\Temp\007>Ackermann-cs.exe
Ack(3,11): 16381   00:00:01.3395087


Неплохо! Да? Разница в два раза! А ведь исполняющая система одна и та же — .Net Framework 2.0!
Может по этому поводу запатентовать способ оптимизации C#-приложений? Ну, конвертируем их в Нэмерл... компилируем... получаем в два раза более быстрое приложение!

Для сравнения, вот мсил обоих вариантов.
C#:
.method public hidebysig static int32  Ack(int32 m,
                                           int32 n) cil managed
{
  // Code size       38 (0x26)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  brtrue.s   IL_0007
  IL_0003:  ldarg.1
  IL_0004:  ldc.i4.1
  IL_0005:  add
  IL_0006:  ret
  IL_0007:  ldarg.1
  IL_0008:  brtrue.s   IL_0014
  IL_000a:  ldarg.0
  IL_000b:  ldc.i4.1
  IL_000c:  sub
  IL_000d:  ldc.i4.1
  IL_000e:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_0013:  ret
  IL_0014:  ldarg.0
  IL_0015:  ldc.i4.1
  IL_0016:  sub
  IL_0017:  ldarg.0
  IL_0018:  ldarg.1
  IL_0019:  ldc.i4.1
  IL_001a:  sub
  IL_001b:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_0020:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_0025:  ret
} // end of method Ackermann::Ack

А вот код Нэмерла:
.method public hidebysig static int32  Ack(int32 m,
                                           int32 n) cil managed
{
  // Code size       57 (0x39)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldc.i4.0
  IL_0002:  bne.un     IL_000f
  IL_0007:  ldarg.1
  IL_0008:  ldc.i4.1
  IL_0009:  add.ovf
  IL_000a:  br         IL_0038
  IL_000f:  ldarg.1
  IL_0010:  ldc.i4.0
  IL_0011:  bne.un     IL_0023
  IL_0016:  ldarg.0
  IL_0017:  ldc.i4.1
  IL_0018:  sub.ovf
  IL_0019:  ldc.i4.1
  IL_001a:  starg.s    n
  IL_001c:  starg.s    m
  IL_001e:  br         IL_0000
  IL_0023:  ldarg.0
  IL_0024:  ldc.i4.1
  IL_0025:  sub.ovf
  IL_0026:  ldarg.0
  IL_0027:  ldarg.1
  IL_0028:  ldc.i4.1
  IL_0029:  sub.ovf
  IL_002a:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_002f:  starg.s    n
  IL_0031:  starg.s    m
  IL_0033:  br         IL_0000
  IL_0038:  ret
} // end of method Ackermann::Ack


Не надо быт семи пядей во лбу, чтобы понять, что второй вариант отличается как раз устранением концевой рекурсии.

В общем, если мы используем импиративный язык, то и алгоритмы на нем должны быть записаны соотвествующе если мы хотим увидить на что способен компилятор. Ведь в реальном приложении если нужна будет производительность мы просто заменим концевую рекурсию на цикл.

Я согласен, что конечно приятно когда компилятор выполняет такую оптимизацию сам. Но по жизни в императивных программах ведь не так то много концевой рекурсии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.