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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 3122—3113 | 3112—3103 | 3102—3093 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 240


    № 3112   04-10-2007 01:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Хочу задать практический вопрос.

    В книге горячих финских парней "Мир лиспа", том 1  в качестве упражнения предлагается решить на Common Lisp-е следующую задачку:

    "Определите функцию (НАЗОВИ x y), которая определяет функцию с именем, заданным аргументом x, и лямбда-выражением y. Определите с помощью этой функции функцию, вычисляющую сумму квадратов двух чисел, и саму функцию НАЗОВИ"

    Поскольку с русским в clisp-е вроде проблемы, то "(НАЗОВИ x y)" я для простоты заменил на "(create_fn n la)" и определил эту функцию так:

    (defun create_fn (n la) (eval (cons 'defun (cons n (cdr la)))))

    пример использования:
    (create_fn 'sum_sqr '(lambda (x y) (+ (* x x) (* y y))))
    SUM_SQR

    (sum_sqr 2 3)
    13

    Но как-то не нравится мне мое решение "составить список и вычислить его через eval" с эстетической точки зрения. Может ли решить эту задачу поэлегантней?


    № 3111   03-10-2007 20:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3110« (Илья Ермаков)
    ___________________________
    Ну это все равно что императивщики сейчас стали бы сравнивать варианты кода с for, while, repeat, foreach. Причем с ходу и невозможно удет сказать какой вариант лучше :))
    Только у вас вариативность в операторах а у нас (за неимением операторов) в функциях и их декларациях.
    А так - тоже самое.
    Далее разница приведенного хаскелевского кода на оберон скажем будет переводиться так:


    if x > 0 then
      y := true
    else
      y := false;



    Супротив


    y := (x > 0)



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


    № 3110   03-10-2007 19:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3105« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 3098« (Илья Ермаков)
    ___________________________
    Хаскель это практически псевдо-язык. Настолько легок что запонимается намертво. Уступает в этом разве что только лиспу.

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


    № 3109   03-10-2007 18:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3107« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 3105« (Jack Of Shadows)
    ___________________________
    запонимается намертво Приколистая опечатка :))

    Читаю электронную книжку Непейводы, Скопина "Основания программирования".
    Слово "англо-американский". Внизу страницы восторженная сноска от авторов:
    "Это слово система проверки правописания предложила заменить на "нагло-американский".


    № 3108   03-10-2007 18:55 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3106« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 3104« (Илья Ермаков)
    ___________________________
    через годик практики рефала конечно

    Побачим, насколько легко реализуется рантайм рефала :-) На КП в ББ...


    № 3107   03-10-2007 18:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3105« (Jack Of Shadows)
    ___________________________
    запонимается намертво Приколистая опечатка :))


    № 3106   03-10-2007 18:18 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3104« (Илья Ермаков)
    ___________________________
    Знаете, я код на Рефале и основы программирования на нём стал разбирать первый раз сегодня утром. У меня уже есть полное представление о том, КАК писать программы на этом языке и ДЛЯ ЧЕГО его можно эффектно применить.
    Вот и отлично. Рефал, хаскель, erlang, лисп, ocaml - какая разница. Принципы везде одинаковые. Отличаются мелочами да синтаксисом. Раз освоив приемы ФП на рефале вам на остальные языки (через годик практики рефала конечно) будет гораздо легче смотреть. И на хаскель тоже :))


    № 3105   03-10-2007 18:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3098« (Илья Ермаков)
    ___________________________
    Кстати, интересно, а присутствует ли у Хаскелла типичный, например, для С++ эффект, когда после долгой паузы в работе с языком (полгода-год) начинаешь местами путаться в коде и долго спотыкаешься о подзабытые детали?

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


    № 3104   03-10-2007 18:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3101« (Geniepro)
    ___________________________

    Ответ на »сообщение 3097« (Илья Ермаков)
    ___________________________
    Так и что же тут чудовищно сложного и непонятного, а потому и не запоминаемого? Ваш код на Рефале немногим лучше регэкспов Перла...

    Знаете, я код на Рефале и основы программирования на нём стал разбирать первый раз сегодня утром. У меня уже есть полное представление о том, КАК писать программы на этом языке и ДЛЯ ЧЕГО его можно эффектно применить.
    Относительно Хаскелла я у себя в голове так и не смог утрясти эти вопросы. Нет, я прекрасно понимаю, что есть самый надёжный путь, по Маяковскому - "сядь на собственные ягодицы и катись". Вот именно таким и только таким путём осваивается С++.
    Однако, кроме отсутсвия времени на эксперименты из любопытства, у меня есть сложившееся предпочтение к тем идеям, которые доступны для понимания без погружения в процесс их использования... В конце концов, мы же с формальными системами работаем, а не ботинки примеряем.
    Вы знаете, до того, как я написал на практике первую программу на Обероне, я месяца полтора проделывал это в уме, "в параллель" с кодом на С++, и мне для этого хватило двух просмотров описания языка.


    № 3103   03-10-2007 18:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3099« (Geniepro)
    ___________________________
    Вроде какой то мужик написал ListLike интерфейсы ко многим типам списков, включая стандартные List и ByteString, PackedString итд
    http://software.complete.org/listlike

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

    А подобные pattern match-и народ делает сам. Например HSP (Haskel Server Pages) включает в себя библиотеку HaRP (Haskell Regular Patterns). Который как раз позволяет сопоставлять используя regexp. То есть практически как душе угодно.
    Скажем наш палиндром при их помощи можно записать точно также как и на рефале:


    palindrom [ ]      = True
    palindrom [_]      = True
    palindrom [x, m@:_*, x] = palindrom m
    palindrom _ = False



    <<<... | 3122—3113 | 3112—3103 | 3102—3093 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 240


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

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

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

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

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

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