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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 632—623 | 622—613 | 612—603 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 489


    № 622   09-08-2006 10:34 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 620« (Geniepro)
    ___________________________
    Господа, эта ветка превратилась в соревнование по скачиванию различных экзотических компиляторов и прогону на них 2-х строчек наивного алгоритма фибоначи.
    Мне это не нравится.
    Такие замеры бессмысленны. Мы топчемся на месте.
    Для подавляющего большинства прикладных задач скорости современных компиляторов более чем в 10 раз превышают необходимую скорость для решения этих задач.

    Именно поэтому разработка web приложений практически полностью завоевана скриптовыми динамическими языками.
    Это несмотря на то что они от 10 до 100 (!!!) раз медленнее компилируемых.

    Я хочу обратить внимание на кое что другое.
    Это обсуждение началось с отличной новости о переходе Интела на многоядерную архитектуру.
    Как вы думаете, что это означает для языков, которые не могут задействовать все ядра, а работают только на одном ядре ?
    Что случится с такими языками когда количество ядер достигнет 8 или 16 (через 3-4 года) ?
    ТО есть программы написанные на таких языках будут задействовать 1/8 или 1/16 процессора.

    Если вы еще не поняли, я говорю о скриптовых языках. Php, Python, Ruby, Perl - все эти фавориты современного web development имеют один общий недостаток. Нет полной поддержки настоящей многопоточности (multithreading)

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



    № 621   09-08-2006 10:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 619« (Max Belugin)
    ___________________________
    В лиспе и в хаскеле во время вычислений происходит автоматическое преобразование типов если число не помещается в отведенную ему ячейку. То есть грубо говоря integer привращается в BigInt а тот еще далье в HugeInt итд итп.
    ФЯ могут позволить себе такую неэффективную трату памяти, поскольку никогда не создавались с целью экономии памяти.
    Императивные языки до сих пор ведут себя так как будто им доступно всего 640 кб. :))


    № 620   09-08-2006 09:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 618« (SJ)
    ___________________________

    Маленький вопрос к знатокам ФЯ - функциональные языки действительно имеют встроенные возможности по "склеиванию" сверхбольших чисел, которые выходят за рамки возможностей стандартных числовых форматов? Если это так, то это несомненный плюс этих языков. Значит в "математике сверхбольших числовых диапазонов" этим языкам нет альтернативы. Или я что-то тут не понимаю?

    Я, правда, не знаток ФЯ, но как я понял, это зависит от конкретного языка и конкретной его реализации. Например, на Лиспе в системе CLisp проблем вроде нет:

    (defun fact (n)
      (cond ((eq n 1) 1)
            (t      (* n (fact (1- n))))
      )
    )

    (fact 100)
    93326215443944152681699238856266700490715968264381621
    46859296389521759999322991560894146397615651828625369
    7920827223758251185210916864000000000000000000000000


    Также и в Хаскелле в WinHUGS:

    fact 0 = 1
    fact n = n * fact (n - 1)

    fact 100
    93326215443944152681699238856266700490715968264381621
    46859296389521759999322991560894146397615651828625369
    7920827223758251185210916864000000000000000000000000


    А вот SML.NET в Visual Studio 2005 лажанул:

    fun fact (0) = 1
    |  fact (n) = n * fact (n - 1)

    fact (100)
    0


    Может, я что-то ему не указал, не знаю... Но вот такой вот результат... :-( С наскока не получилось...


    № 619   09-08-2006 07:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 618« (SJ)
    ___________________________
    http://www.python.org/dev/peps/pep-0237/


    № 618   09-08-2006 06:07 Ответить на это сообщение Ответить на это сообщение с цитированием
    Когда в Haskell вычисляется число Фибоначчи с 1000-м номером или факториал 100, то это производит впечатление.
    Маленький вопрос к знатокам ФЯ - функциональные языки действительно имеют встроенные возможности по "склеиванию" сверхбольших чисел, которые выходят за рамки возможностей стандартных числовых форматов? Если это так, то это несомненный плюс этих языков. Значит в "математике сверхбольших числовых диапазонов" этим языкам нет альтернативы. Или я что-то тут не понимаю?

    >>>Почитаю, что такое этот Mercury, может, тоже скачаю, посмотрю...
    >>>Что-то типа Хаскелля, что ли?..
    Нет.
    Haskell - это язык функционального программирования, он скорее родственник таких языков, как Lisp, Caml, Miranda и т.д.
    Mercury - язык логического программирования. Он из той же группы, что и язык Prolog. Хотя я не знаю, какие еще языки, кроме Mercury и Prolog входят в эту группу.


    № 617   09-08-2006 04:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 616« (Geniepro)
    ___________________________
    Какой смысл тут секунды мерять? Надо сгенеренный MSIL сравнивать.


    № 616   09-08-2006 03:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 615« (Jack Of Shadows)
    ___________________________




    Окей, оставим эту сомнительную сингулярность, вернёмся к нашим баранам... :-)

    Таки вставил я в Visual Studio хоть один ФП!

    SML.NET - http://www.cl.cam.ac.uk/Research/TSG/SMLNET/dist/vssmlnet.tar.gz
    Всего 3.6 мегабайта!

    Хотя в описании упомянуты VS2002 и VS2003, но и в VS2005 она тоже интегрируется.
    Компилятор не очень шустрый, особенно заметны тормоза при вводе текста программы - проверка синтаксиса существенно тормозит...

    Не могу пока сравнить точно быстродействие программ на SML.NET с С#, но на глаз - примерно одинаково:

    fun fib (1) = 1
    | fib (2) = 1
    | fib (n) = fib (n - 1) + fib (n - 2)

    static int Fib(int n)
    {
        return n < 3 ? 1 : Fib(n - 1) + Fib(n - 2);
    }


    при n=40 время выполнение на С# составило 2.8 сек, и практически столько же на SML.NET (не знаю пока, как время замерить, поэтому замерял на раз-два-три... :-) ).
    Вариант на С# с типом long уже заметно медленнее, чем на SML.NET без указания типа.
    Ну что ж, неплохо. Оптимизации нет, к сожалению, но хотя бы сопоставимо с С#...

    Я пока не знаю ML, но всё равно доволен! :-)


    № 615   08-08-2006 15:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 614« (Geniepro)
    ___________________________
    Офтопик. Откройте отдельную ветку про технологическую сингулярность.
    Все одно лучше чем "информационные поля" :))
    Там и поговорим.


    № 614   08-08-2006 15:13 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 607« (Jack Of Shadows)
    ___________________________

    Ну а что там возможно будт через 50 лет, у меня на этот счет совя теория, и боюсь она вам не понравится. :))

    Я ожидаю конца света к году эдак 2045-2050.

    http://en.wikipedia.org/wiki/Technological_singularity

    Хм. имхо, довольно сомнительно всё это. Псевдонаучные спекуляции.
    Графики, конечно, интересны, но сколько уже было подобных прогнозов? И сколько из них сбылись?
    Все эти страшилки а-ля Армагеддон, Терминатор-Х...
    Поживём, увидим, и, скорее всего, через полвека будем только смеяться над этой "сингулярностью"...
    Да, ещё дожить надо до того времени... :-) Вот как рухнет Луна на Землю, так и настанет конец света, а все эти сингулярности - только красные словца... Футуристы, блин...
    А что Римский клуб на этот счёт говорит?


    № 613   08-08-2006 13:39 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 612« (Geniepro)
    ___________________________
    А почему, кстати, такие сомнения по поводу автоматической мемоизации?
    Сомнений нет. Есть желание увидеть цифры :))

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


    Кстати, по-моему, так можно преобразовать далеко не каждую функцию.
    И для чего, это, кстати, нужно? Какие выгоды даёт?


    Любую чистую (то есть без побочных эффектов) функцию.
    А нужно как раз для автоматического преобразования алгоритмов. Этим может заняться компилятор.

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


    <<<... | 632—623 | 622—613 | 612—603 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 489


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

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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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