Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  09:32[Войти] | [Зарегистрироваться]
Обсуждение темы:
Функциональное программирование

Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5502 сообщения

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 1132—1123 | 1122—1113 | 1112—1103 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 439


    № 1122   04-09-2006 06:11 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1118« (Geniepro)
    ___________________________
    Спасибо за ссылку, очень толковая статья.
    Кстати, многие аргументы могут быть перенесены и в ветку по Оберонам.


    № 1121   04-09-2006 06:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1120« (Артем)
    ___________________________

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

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


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

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


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


    № 1119   04-09-2006 03:22 Ответить на это сообщение Ответить на это сообщение с цитированием

    Вам лучше задать этот вопрос вот здесь: 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#...

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

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


    № 1118   04-09-2006 03:05 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1117« (Артем)
    ___________________________

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

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


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

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


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

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

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


    № 1117   04-09-2006 02:22 Ответить на это сообщение Ответить на это сообщение с цитированием
    Конечно, 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-летней женщиной, которой ничего не надо  объяснять второй раз, и ясность ума которой поражает, особенно в сравнении с безалаберностью некоторых (не всех, конечно :) ) представителей молодежи.


    № 1116   04-09-2006 01:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1084« (Сергей Перовский)
    ___________________________

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


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

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

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


    № 1115   04-09-2006 01:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    сообщение от модератора

    Jack Of Shadows позволил себе несколько очень грубых выпадов по отношению к своим оппонентам несмотря на то, что на этот раз его никто не провоцировал. Так как это уже далеко не первый подобный случай, Jack Of Shadows лишается возможности писать что-либо в эту тему с момента опубликования этого объявления и до 24:00 мск 10.09.06. Все его сообщения, независимо от содержания, будут удаляться. Также будут удаляться все сообщения других пользователей, которые станут отвечать на сообщения Jack Of Shadows.


    № 1114   04-09-2006 00:29 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1112« (Jack Of Shadows)
    ___________________________


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

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


    И какой же?

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

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


    № 1113   04-09-2006 00:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1112« (Jack Of Shadows)
    ___________________________

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


    <<<... | 1132—1123 | 1122—1113 | 1112—1103 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 439


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования