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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2412—2403 | 2402—2393 | 2392—2383 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 311


    № 2402   01-04-2007 04:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2391« (Geniepro)
    ___________________________

    Ответ на »сообщение 2384« (Руслан Богатырев)
    ___________________________
    Неужели Вы действительно думаете, что решать типичные школьные задачки на Обероне легче, проще и быстрее, чем на этих трёх языках?

    Знаете, я как-то не помню никаких проблем с решением "типичных школьных задачек" на Паскале, когда был в школе... В 11 классе реализовывал даже распознавание образов на Дельфе - и вполне успешно (программа заняла 1 место на всеройссийском конкурсе Intel-Авангард).
    Так вот, о чем я - освоить паскалеский инструмент школьнику вполне по силам самостоятельно, как по силам и делать на нем что-то реальное. А если говорить о ББ - то вообще, более или менее способный школьник унесет с собой не только основы алгоритмизации, но и отличный "карманный" инструмент для решения каких-либо несложных задачек или "любительского" программирования в дальнейшем.
    А вот с ФП-то, господа, вы как раз ставите школьнику жесткий "потолок": вроде бы и все легко сначала, и функции вы рекурсивные попишете, но дальше для самостоятельной работы дорога закрыта - для окончившего школу и не ставшего проф. программистом два выбора: либо так ничего никогда и не написать за пределами школьного курса, либо лезть в дебри сверхвысоких для среднего ума абстракций...


    № 2401   01-04-2007 03:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Если сформулировать предварительное впечатление от обсуждения, то функциональщики несколько увлекаются деталями языка Хаскель, как будто ФП и Хаскель одно и то же (на мой взгляд, Хаскель -- частный случай), а оберонщики склонны не замечать механизмы, отсутствующие в "чисто" императивных языках (например -- лямбды; каюсь).
     AVC


    № 2400   01-04-2007 03:39 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2395« (AVC)
    ___________________________

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

    Просто потому, что это главная единица лямбда-исчисления - основы ФП.
    По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.


    Насколько я понял, необходимости в лямбдах нет, как и прямой связи между лямбдами (как безымянными функциями) и функциональностью (в смысле ФП).


    Я подумал и решил, что вчера был неправ. :)
    Действительно, λ нужна для анонимного и динамического создания функций.
    Это как раз та специфика ФП, которая выходит за рамки отсутствия побочных эффектов и относится к функциям как "объектам первого порядка".
    Короче, возражение по этому пункту снимаю.
     AVC


    № 2399   01-04-2007 02:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2398« (slava)
    ___________________________
    Синтаксический сахар, как анонимные классы в Java.
    Верно. Однако 2 замечания.
    Во первых анонимные классы в java - это провальный эксперимент. Слишком громоздкий синтаксис. Синтаксический сахар должен быть коротким и удобным. Иначе его смысл теряется.

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

    То есть функция в ФП записывается так:

    f = lamdba x y -> bla bla x y

    и привычное вам обьявление функций
    f(x,y) = bla bla - это с точки зрения ФП и есть синтаксический сахар к лямбде.



    № 2398   01-04-2007 02:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Здесь (<10) является анонимной функцией. Не будь этой фозможности вам пришлось бы писать так:

    Синтаксический сахар, как анонимные классы в Java.


    № 2397   31-03-2007 23:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2396« (AVC)
    ___________________________
    Я просто никак не могу себе хорошо представить эту глобальную структуру, в которой все хранится. :)

    Попробуйте написать сами.

    Короче, один пример (даже схематичный) стоит тысячи слов.
    Вам уже этот пример приводили. В целых 63 строчки. Требовать от кого либо чтобы он тратил на вас свое свободное время, мягко говоря некорректно. Хотите посмотреть код побольше и посложнее - есть такие известные open source проекты на хаскеле как darcs, pugs, HaskellDB, и еще много много других библиотек.
    Есть также и большие программы типа Quake на хаскеле. Тоже с исходным кодом.

    Ну какая принципиальная разница, именована функция или нет, если ее имени не видно за пределами модуля?
    Почему, собственно, без анонимных функций нет ФП?


    Во первых динамическое создание функций. Там названия так просто не дашь.

    Во вторых я уже приводил примеры как раз показывающие преимущество использования анонимных функций.
    Приведу еще раз

    less_than_10 = filter (< 10) mylist



    Здесь (<10) является анонимной функцией. Не будь этой фозможности вам пришлось бы писать так:


    is_less_than_10 x = x < 10
    less_than_10 = filter is_less_than_10 mylist




    № 2396   31-03-2007 20:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2394« (Geniepro)
    ___________________________

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


    Я просто никак не могу себе хорошо представить эту глобальную структуру, в которой все хранится. :)
    Как она соединяется в одно целое?
    Как с ее помощью получить доступ к отдельным объектам?
    И т.д.
    Конечно, причиной может быть моя неопытность в ФП.
    Мое представление о соединении структур данных в ФП ограничено использованием пар в Схеме (car, cdr etc).

    Короче, один пример (даже схематичный) стоит тысячи слов.
     AVC


    № 2395   31-03-2007 20:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2393« (Geniepro)
    ___________________________

    Просто потому, что это главная единица лямбда-исчисления - основы ФП.
    По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.


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


    Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?
    Конечно же не должны, на то они и не функциональные языки.


    Переформулирую. :)
    Разве все ФЯ реализуют ФП одинаково?
    Я просто хочу подчеркнуть, что Вы сводите разговор на уровень реализации (не ФП, а Хаскель; лямбды есть во всех ФЯ, а в Обероне нет и т.д.) вместо уровня концепций.


    Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).
    Это уже ООП...


    Разве?
    Хочу напомнить, что в функторы (объекты-функции) в STL никакого отношения к ООП не имеют.
    А то, если так рассуждать, то почти все ИЯ являются еще и ФЯ: ведь практически в каждом есть функции. :)


    Языки, в которых функции не являются объектами первого класса, по определению не являются функциональными языками. Всё-таки главное в ФП - функции, всё остально вертится вокруг них, а не они вокруг всего остального.


    Здесь у меня есть некоторое сомнение.
    Ведь функция есть некое отображение.
    Может ли она логически быть первой ("главной"), если само ее определение предполагает существование других объектов (не функций)?


    Конечно же, аскеты не нуждаются в новомодных штучках, но зачем отказываться от удобств-то?


    Так же говорили и сторонники PL/I. :)
    "Мы слишком любили удобства."


    Конечно, очень большого труда не составит, но труд будет всё-таки больше.
    Это опять же из раздела автоматизации труда программиста. Сборщик мусора необязателен, но очень желателен. Так же и list comprehensions необязательны, но очень желательны...


    Пардон?
    Я правильно понял, что в ФП сборщик мусора -- необязательный элемент, кусок синтаксического сахара?
    Например, в Обероне его необходимость считается математически доказанной...

    >>>Э-э, это не ко мне. Не я постановщик этого вопроса ("Может ли Оберон использоваться как ФЯ?")

    Повторю вопрос: все ФЯ реализуют ФП одинаково?


    Между кортежами и записями есть небольшая разница. Кортежи можно рассматривать как безымянные записи. Т.е. при использовании записей приходится создавать специальные новые типы, при использовании кортежей от этой ненужной работы можно избавиться.


    Кому ненужная работа, а кому спасение.
    Илья Ермаков уже много раз говорил о том, какую роль играет т.н. "избыточность".
    Не верите нам, так хотя бы возьмите в руки учебник по теории кодирования (раздел дискретной математики).

    >>>Так и язык ведь он не функциональный, а императивный. Потому и по-другому устроен...

    Вместе с тем, он позволяет писать в функциональном стиле.
    Естественно, это не слишком удобно, но возможно (а речь и шла именно о принципе).
     AVC


    № 2394   31-03-2007 19:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2392« (AVC)
    ___________________________

    Вот создал я АТД, а он должен торчать "кишками наружу", чтобы выдержать принципы ФП.
    Допустим, от многих неприятностей меня функциональность как раз и защитит (не даст модифицировать мои структуры данных).
    Но что будет, если мне потребуется изменить эти структуры?
    В модульном и объектно-ориентированном программировании здесь нет никаких проблем (да-да, то самое сокрытие информации), но там структура данных не всплывает наверх, в отличие от ФП.

    Ну так меняйте, в чём проблема-то?
    Если этот тип - абстрактный, то вся работа с ним будет вестись через набор операций, с ним связанных, а кишки его будут спрятаны в каком-нибудь отдельном модуле. Сама структура-то собственно и не всплывёт наружу - это ведь абстрактный тип данных.
    А если Вы вдруг поменяете интерфейс этого типа - то тут Вас не спасёт и ООП...
    Если же "кишки наружу" будут, то какой же это АТД? :о))

    Эти данные будут у Вас проходить через главный поток управления - но они же не будут размазаны по всей программе! Доступ к ним будет жёстко ограничен, а интерфейс - абстрактным! В чём проблема-то? Главный поток (называйте как хотите - монада ввода-вывода или как-нибудь по другому...), так вот, главный поток программы и будет тем самым модулем, который скрывает свои данные от чужих рук и глаз...

    Ссылка в тему: D. Obradovic "Structuring functional programs by using monads"


    № 2393   31-03-2007 19:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2390« (AVC)
    ___________________________

    Лямбда-абстракции (безымянные/анонимные функции) - это очень важный элемент ФП, который напрочь отсутствует в Оберонах. Без этого элемента язык не может считаться функциональным.

    Почему?

    Просто потому, что это главная единица лямбда-исчисления - основы ФП.
    По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.

    Главное отличие поименованных функций от безымянных в том, что безымянные создаются динамически, а поименованные - статически.


    Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?

    Конечно же не должны, на то они и не функциональные языки.

    Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).

    Это уже ООП...

    Языки, в которых функции не являются объектами первого класса, по определению не являются функциональными языками. Всё-таки главное в ФП - функции, всё остально вертится вокруг них, а не они вокруг всего остального.


    Сопоставление по образцу (pattern matching) - очень модный аттрибут современных ФЯ и некоторых гибридных языков.

    Причем здесь ФЯ?

    Да ни при чём, просто это сейчас очень модно в ФЯ. Мода, ничего больше.
    Конечно же, аскеты не нуждаются в новомодных штучках, но зачем отказываться от удобств-то?

    Вообще, pattern matching - аттрибут декларативного программирования, а так как ФП часто относят к разделу ДП, то в ФЯ этот элемент очень желателен - повышает уровень декларативности программ.


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

    Конечно, очень большого труда не составит, но труд будет всё-таки больше.
    Это опять же из раздела автоматизации труда программиста. Сборщик мусора необязателен, но очень желателен. Так же и list comprehensions необязательны, но очень желательны...


    Опять же, предрассудок, что Оберон должен делать все так же, как ФЯ.

    Э-э, это не ко мне. Не я постановщик этого вопроса ("Может ли Оберон использоваться как ФЯ?")

    Между тем, кортежи в Обероне есть -- это записи-параметры.
    На их использовании основана работа часто упоминаемой в обероновской ветке software bus.
    Запись можно передать в качестве аргумента, можно вернуть в качестве результата.

    Между кортежами и записями есть небольшая разница. Кортежи можно рассматривать как безымянные записи. Т.е. при использовании записей приходится создавать специальные новые типы, при использовании кортежей от этой ненужной работы можно избавиться.


    Могу выделить два пункта.
    1) Большая любовь к синтаксическому сахару (что для ФЯ, возможно, необходимость).

    Синтаксический сахар не только приводит к раку точки с запятой, но иногда просто делает язык вкуснее... :о))

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

    Так и язык ведь он не функциональный, а императивный. Потому и по-другому устроен...


    <<<... | 2412—2403 | 2402—2393 | 2392—2383 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 311


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

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

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

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

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

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