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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1972—1963 | 1962—1953 | 1952—1943 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 355


    № 1962   22-02-2007 17:16 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1961« (Илья Ермаков)
    ___________________________
    В статье Info21 перечилил те моменты ФП, которые он считает значимыми, и как именно эти моменты применяются в программировании на Обероне.

    Все это отмазки, да еще и в виде мнения кого то там, кто к ФП сбоку припека.
    Где размашисто функциональное программирование на обероне ? Код в студию.
    Сказать то много чего можно :))

    Ах да попытались уже. Вместо map получился раскоряченный в интерфейсном приседе непойми что.
    Если это функциональное программирование то тогда я папа римский :))




    № 1961   22-02-2007 16:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1959« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 1958« (Илья Ермаков)
    ___________________________
    http://www.inr.ac.ru/~info21/qna.htm#functional

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

    В статье Info21 перечилил те моменты ФП, которые он считает значимыми, и как именно эти моменты применяются в программировании на Обероне.


    № 1960   22-02-2007 16:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1956« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 1952« (AVC)
    ___________________________
    О том и речь шла когда я говорил об ортогональности.
    Нет ее в ИЯ, приходится извращаться и создавать такие вот СПЕЦИАЛЬНЫЕ функции Double вместо того чтобы пользоваться той что есть. И так в кажом конкретном случае.
    Библиотека всевозможных функций "на все случаи жизни" растет как на дрожжах.

    И чем закончился пример ?
    Вместо одной строчки использующей СТАНДАРТНЫЙ один раз написанный map со стандартными один раз написанными ЛЮБЫМИ функциями, работающими с ЛЮЫМИ типами, при этом и сохраняющий СТРОГУЮ ТИПИЗАЦИЮ, имеем зоопарк разных НЕСТАНДАРТНЫХ функций, которые надо написать потому что стандартные функции, эта - в дырку не лезут :))

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

    По поводу второй проблемы - да, такая проблема есть. Решается введением обобобщенки Однако опять же - все зависит от решаемых задач. Я знаю об этой проблеме и прекрасно понимаю, в каких задачах прикладник может ее ощутить. Однако сам почти не ощущал нехватки дженериков. Просто в силу работы над системными задачами. Ну, не нужен для них общий Map. Обобщенности, даваемой расширением типов и метапрограммированием хватает. Зато ясность и простота языка в выражении архитектуры, разъемов между модулями системы, выходит на первый план по сравнению со средствами записи алгоритмов.


    № 1959   22-02-2007 16:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1958« (Илья Ермаков)
    ___________________________
    http://www.inr.ac.ru/~info21/qna.htm#functional

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


    № 1958   22-02-2007 16:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1946« (pepper)
    ___________________________

    Ответ на »сообщение 1942« (info21)
    ___________________________


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


    Размашисто по-функциональному? На обероне? Это даже не смешно. Более неприспособленного для написания в функциональном стиле ЯВУ придумать сложно. Даже дельфя даст фору.

    http://www.inr.ac.ru/~info21/qna.htm#functional


    № 1957   22-02-2007 15:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1952« (AVC)
    ___________________________

    Насколько я понимаю, в Scheme динамическая типизация (верно ли?).
    Динамическую проверку типа можно применить и в Обероне.
    ...
    А процедуру Double напишем примерно так:
    ...

    То есть Вы предлагаете идти от обратного?

    Если в Scheme Вам достаточно определить функцию double в очень простом виде:

    (define (double x)
      (* 2 x))


    а map - так как Вы предлагаете:

    (define (map f list)
      (if (null? list) ()
          (cons (f (car list)) (map f (cdr list)))))


    то потом можно задавать такие запросы, как:

    (map double '(1 2 3 4))
    (map double '(1.0 2.0 3.0 4.0))
    (map double '(1/2 2/3 3/4 4/5))


    и не нужен никакой оператор WITH... Результат будет нужным:

    (2 4 6 8)
    (2.0 4.0 6.0 8.0)
        1  1  3
    (1 1- 1- 1-)
        3  2  5


    Аналогично и в Хаскелле...


    № 1956   22-02-2007 14:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1952« (AVC)
    ___________________________
    Не получится :))
    Именно строгая типизация вам не позволит. Ну лист ладно вы мапу передадите по интерфейсу.
    А функция Double то требует КОНКРЕТНЫЙ ТИП numeric.
    Именно поэтому вам пришлось переписать Double как принимающий тоже интерфес List :))
    Получается что вы не можете ВООБЩЕ никакую функцию мапу передать а только те которые специально перепишете.
    А это грабли :))

    О том и речь шла когда я говорил об ортогональности.
    Нет ее в ИЯ, приходится извращаться и создавать такие вот СПЕЦИАЛЬНЫЕ функции Double вместо того чтобы пользоваться той что есть. И так в кажом конкретном случае.
    Библиотека всевозможных функций "на все случаи жизни" растет как на дрожжах.

    И чем закончился пример ?
    Вместо одной строчки использующей СТАНДАРТНЫЙ один раз написанный map со стандартными один раз написанными ЛЮБЫМИ функциями, работающими с ЛЮЫМИ типами, при этом и сохраняющий СТРОГУЮ ТИПИЗАЦИЮ, имеем зоопарк разных НЕСТАНДАРТНЫХ функций, которые надо написать потому что стандартные функции, эта - в дырку не лезут :))
    При этом все прелести строгой типизации ТЕРЯЮТСЯ, потому что никто вам не запрещает такому вот мап передать вместо списка числе - спискок строк. Вы не получите никакой ошибки при компиляции.
    А в хаскеле - получите.





    № 1955   22-02-2007 14:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Разница между конкурирующими ветками составляет ровно 1000 сообщений. :)
     AVC


    № 1954   22-02-2007 14:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1953« (Geniepro)
    ___________________________


    PROCEDURE Map* (f: PROCEDURE(p: IntList); p: IntList);
    Если я правильно понимаю, такая декларация процедуры map гарантирует отсутствие изменения содержимого переменной p, не так ли?
    <...>
    ЗЫ. Поправьте меня, если я вдруг сполусонья ашипся... :о))


    В данном конкретном случае Вы понимаете неправильно. :)
    List и IntList -- указатели.

    TYPE
      List* = POINTER TO EXTENSIBLE RECORD next: List END;
      IntList* = POINTER TO RECORD (List) x*: INTEGER END;


    Перед тем, как привести пример кода, я сделал набросок в ББ, откомпилировал его и исполнил, получив 2 4 6 8.
     AVC


    № 1953   22-02-2007 14:44 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1951« (AVC)
    ___________________________

    Похоже, что после вызова первоначальный список уходит в корм сборщику мусора.
    Зачем же мне брать пример с не самой лучшей стороны ФП?

    Ну хорошо, допустим, что для Вас не имеет особого значения такое важное для ФП понятие, как прозрачность по ссылкам, связанная с отсутствием изменения каких-либо объектов...

    PROCEDURE Map* (f: PROCEDURE(p: IntList); p: IntList);


    Если я правильно понимаю, такая декларация процедуры map гарантирует отсутствие изменения содержимого переменной p, не так ли? Тогда эта процедура может производить очень ограниченный набор действий над списком - например вывести его на печать, но никак не удвоить значения его элементов... :о))
    Разве не следует объявить её вот так:

    PROCEDURE Map* (f: PROCEDURE(VAR p: IntList); VAR p: IntList);


    Казалось бы, такая простая задача, а так чревата ошибками в императивных языках... То ли ещё будет, ой-ё-ёй! ;о)

    ЗЫ. Поправьте меня, если я вдруг сполусонья ашипся... :о))


    <<<... | 1972—1963 | 1962—1953 | 1952—1943 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 355


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

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

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

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

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

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