Ответ на »сообщение 1118« (Geniepro)
___________________________
Спасибо за ссылку, очень толковая статья.
Кстати, многие аргументы могут быть перенесены и в ветку по Оберонам.

Ответ на »сообщение 1120« (Артем)
___________________________

Согласитесь, несколько странно смотрится, когда на основании одного простенького опыта кто-то радостно кричит, что ФЯ быстрее ИЯ ! :-) Как вам такое?.

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


Тем более, что действия в сравниваемом коде не совсем эквивалентены. :)

Ну как же не эквивалентны? Производится два инкремента на единицу, ещё одно сложение с единицей и сравнение двух значений.
Вроде бы эквивалентны...

Ответ на »сообщение 1118« (Geniepro)
___________________________
Не в обиду вам будет сказано, но вы слишком увлекающаяся натура :)
Согласитесь, несколько странно смотрится, когда на основании одного простенького опыта кто-то радостно кричит, что ФЯ быстрее ИЯ ! :-) Как вам такое?. Тем более, что действия в сравниваемом коде не совсем эквивалентены. :)

Вам лучше задать этот вопрос вот здесь: http://groups.google.com/group/fa.haskell
У нас вы вряд ли найдете спеца по хаскелю, который сказал бы вам что там хаскелю в вашем коде не понравилось.

Насколько я понял (в том числе и из тамошних тредов), в Хаскеле есть большая разница между хвостовой рекурсией

testtail1 k v = if k==1 then v else testtail1 (k-1) (v+1)

и хвостовым вызовом функции

testtail2 k v = if k==1 then v else testtail2 (k-1) v

В первом случае производится отложенное вычисление (v+1), и при каждом вызове информация об откладывании на потом этого вычисления помещается в стек (и частично также и в кучу), в результате стек может переполниться. Это следствие ленивости Хаскеля...
Это, кстати, обьясняет, почему в таком тесте даже компилятор Хаскеля выдаёт код, который на два порядка медленее, чем код на F#...

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

ЗЫ. Возможно, этот тест слишком прост, что бы почувствовать преимущества ленивых вычислений...

Ответ на »сообщение 1117« (Артем)
___________________________

Во-вторых, мы уже неоднократно обсуждали, что использование рекурсии обычно медленнее, чем использование эквивалентной итерации, соответственно чистые ФЯ по идее должны быть медленнее, чем ИЯ.

Не совсем так. Хвостовая рекурсия в исполнении F# оказалась на 20% быстрее, чем аналогичный по действию цикл на C# (.NET 2.0) (правда, тест довольно простой, и, наверное, вряд ли частоиспользуемый...)


Вообще, ко всем  бенчмаркам надо относиться с изрядной долей скепсиса.

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


ЗЫ. Кстати, о серьёзности реализаций. Не помню, проскакивала тут эта ссылка или нет, но посмотрите, интересно:

"Почему никто не использует функциональные языки" Филип Вадлер
http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

Там как раз анализируются причины незатребованности ФЯ...

Конечно, http://shootout.alioth.debian.org/ - интересный ресурс, но в нем приведены бенчмарки только по линуксовским реализациям. Delphi там, например, нет. Да и C#  там mono-вский, а не  .net-вский. Мне кажется, что такие попытки доказать преимущество в скорости той или иной парадигмы малосодержательны.  Во-первых, вызывает некоторые подозрения узкий круг тестируемых алгоритмов, а также принцип, по которому они были отобраны. Но даже по этим тестам при сравнении Clean и C gcc  второй явно выигрывает. В сравнении Clean с C++ и Free Pascal также все далеко не столь однозначно. Во-вторых, мы уже неоднократно обсуждали, что использование рекурсии обычно медленнее, чем использование эквивалентной итерации, соответственно чистые ФЯ по идее должны быть медленнее, чем ИЯ. Повторяю, я не вижу здесь ничего плохого. Если разница в скорости не является  критичной для выполнения программы, то лучше использовать рекурсию, т.к. она обычно более выразительна. То, что Clean показывает такие хорошие результаты говорит о качестве его реализации. И в нем, я уверен, та же хвостовая рекурсия неявно преобразовывается в итерацию. Но, давайте вспомним, что не все рекурсии сводятся к хвостовым. Мало того, использование в тестах некоторых библиотечных функций часто может лишь говорить о качестве этих библиотек. Причем даже для чистых ФЯ эти библиотеки могут быть написаны на C.
Вообще, ко всем  бенчмаркам надо относиться с изрядной долей скепсиса. Те же, например, бенчмарки от Sun, в которых утверждается, что скорость выполнения на JVM несильно отличается от .Net, моим собственным опытом не подтверждаются. Во всяком случае на Windows.  :) Подбор тестов может быть тенденциозным (в зависимости от того, что вы хотите доказать) и совершенно не отражать общее положение дел.
Не хочу, чтобы сказанное выше было воспринято как очередная ода ООП и отрицание ФП. В сравнении C# и F# скорость для меня не имеет никакого значения. Я вижу, что F#  - это не игрушечная реализация (в отличие, пардон, от многих реализаций Haskell) и я обязательно буду пробовать серьезно использовать его в своих проектах наряду с C#. Слава Богу, что у меня есть право решать на чем писать. :)
И еще одно маленькое лирическое отступление. То, что кто-то может быть предпенсионного возраста, совершенно не обязательно говорит о его заскорузлости. Это я из своего личного опыта. Я лично младше, чем JOS, но это не мешает мне объективно оценивать ситуацию. Мне на работе гораздо легче общаться с 50-летними профессионалами, чем с современными выпускниками институтов. :)  Мало того, я мог бы даже привести опыт профессионального общения с 75-летней женщиной, которой ничего не надо  объяснять второй раз, и ясность ума которой поражает, особенно в сравнении с безалаберностью некоторых (не всех, конечно :) ) представителей молодежи.

Ответ на »сообщение 1084« (Сергей Перовский)
___________________________

Ответ на »сообщение 1083« (Max Belugin)
___________________________
А если говорить о транзакциях, то тут играет роль состояние базы и тут уже не место для функционального подхода.


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

В-общем, мне кажется, что основная проблема, что в ООП есть состояние и identity - и это разные вещи, а в ФП одно и то же.

По поводу, haskelldb - насколько я понял, там испольжзуются монады, jnrjhst являются способом нписания имеративной программы внутри функциональной + способом при помощи пространных размышлений, доказать, что эт императивная программа тоже формально функциональная (или я не прав. монады для мена не особо понятны - надо почитать про них)

Ответ на »сообщение 1112« (Jack Of Shadows)
___________________________


Что может проверять тест, обращающийся в цикле к трем внешним модулям, из которых два -- ввод-вывод?

Это один из многих тестов, проверяющих один из многих аспектов языка программирования.


И какой же?

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

"Чтобы попробовать борщ, не обязательно съедать всю кастрюлю" (с) Не-помню-кто.
В сущности то же самое вам сказал bb в »сообщение 1106«.

Ответ на »сообщение 1112« (Jack Of Shadows)
___________________________

Ну, народ в основном читать все-таки умеет.