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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

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


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

    Ну извините, это уж от Вас зависит, как Вы это всё проделаете, как построите программу.
    Будете использовать абстрактные типы данных - будет проще, не будете использовать их - сложнее... Будете максимально абстрагировать задачу или не будете...


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


    № 2391   31-03-2007 18:48 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2384« (Руслан Богатырев)
    ___________________________

    Для школ идеальны языки с минимумом синтаксиса и маскимумом приближения к школьной математике.

    Например?

    Ну, для меня пример очевиден - Хаскелл с его рафинированным синтаксисом и незаставлянием думать о лишних деталях, неважных на уроках информатики. :о))
    Впрочем, гибридные языки, такие как Питон и Scheme - тоже весьма подойдут...

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


    Так вот, Оберон -- это упрощенный Паскаль.

    Да, с точки зрения имеющихся в наличии учителей - Оберон, пожалуй, лучший выбор, потому что знаком по Паскалю.
    А вот с ФЯ наши учителя практически незнакомы, увы... Их самих учить надо... :о(


    Друзья-товарищи-господа-коллеги! Давайте определимся, что мы обсуждаем: ФП или конкретно Хаскель? Если ФП, то давайте остановимся на конкретной эталонной книге (ее кстати уже рекомендовали) и относительно нее будем плясать. Так можно ее уже изучать или погодить из-за того, что "просроченная"?

    Эх, не устану повторять, что Хаскелл - эталонный ФЯ... :о))
    Впрочем, эталон, как и идеал, понятие субъективное...

    А что насчёт книги - боюсь, ни одна книга не сможет охватить полностью всё многообразие как ИП, так и ФП...
    Но мне кажется, что книга Филда и Харрисона очень неплоха. Ну а по новым течениям в ФП придётся изучать дополнительную литературу...


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

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

    Почему?


    Функции как объекты первого класса - функции можно не только вызывать, принимать как значения (по имени/ссылке), но и создавать и возвращать в качестве результата.
    В Оберонах процедуры не являются объектами первого класса, поскольку в нём нет лямбд, нельзя возвращать локальные процедуры в качестве результата.


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

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

    Причем здесь ФЯ?
    Например, паттерн-матчинг применяется как в генераторе лексических сканеров lex (строящем конечный автомат), так и в скриптовом языке AWK.


    Определители/генераторы списков/массивов (list/array comprehensions) - позволяет в очень удобной декларативной манере задавать содержимое списков или массивов.
    В Оберонах для этого придётся создавать отдельные процедуры или циклы (что уже противоречит духу ФП).


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

    Не стану сейчас разбирать все пункты.


    Кортежи (tuples) - чертовски удобны в использовании, так как освобождают от необходимости создавать лишние типы данных.
    В Оберонах есть зачатки кортежей - это списки параметров процедур. То есть каждая процедура с параметрами в Оберонах фактически имеют один-единственный параметр - кортёж.
    Так почему же нельзя сделать кортежи в Оберонах объектами первого класса? Почему нельзя возвращать кортежи в качестве результата? Вместо этого приходится плодить ненужные обёртки (записи новых типов) или вообще переходить к императиву - глобальным изменяемым объектам или к VAR-OUT-параметрам...


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


    Оптимизация хвостовой рекурсии в Оберонах отсутствует, но это является недостатком не языка, а его имеющихся трансляторов. Тем не менее, учитывая запрет на использование циклов, этот недостаток сильно ограничивает создание циклических расчётов, поскольку приводит к быстрой перегрузке стека.


    Виноваты, просто руки не дошли. :)
    Ведь в Обероне используются циклы, поэтому до оптимизации хвостовой рекурсии не дошло.
    Но можно и "докрутить". :)
    Собственно и в ФЯ этого не было до Схемы.

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


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

    Ну а почему бы не Хаскелл, раз уж он является "квинтэссенцией" ФП, как Оберон - ФЯ...

    Упс! Имелось в виду, конечно же, что Оберон - квинтэссенция ИП... :о))


    № 2388   31-03-2007 18:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2383« (AVC)
    ___________________________

    IMHO, не все, чего нет в Обероне, относится к ФП.

    Уточните, что куда по-Вашему относится.

    (а список явно напирает на то, чего в Обероне нет).

    Список был составлен исходя из вопроса Руслана Богатырёва, захотевшего узнать, чего нет в Обероне, что должно быть для полного функционального "щастья".

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

    Ну, вообще-то такой уж принципиальной разницы, пожалуй нет. Если и есть, то скорее для динамических языков.
    Просто вопрос удобства. Зачем нужно имя временному объекту с минимальной областью видимости?

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

    Ну извините, это уж от Вас зависит, как Вы это всё проделаете, как построите программу.
    Будете использовать абстрактные типы данных - будет проще, не будете использовать их - сложнее... Будете максимально абстрагировать задачу или не будете...

    А в чем разница для остальной части программы?
    Какая ей разница, поместили Вы датчик внутрь монады или просто используете локальную переменную?

    Особой разницы, пожалуй и нет, просто вопрос принципа - в чистых ФЯ приходится делать так, что бы сохранить чистоту... Монады ввода-вывода, уникальные типы... Одним словом, запрет на доступ снаружи и на переходы назад в цепочке операторов...
    Если использовать изменяемые локальные переменные и при этом запретить операторы циклов и условных/безусловных переходов - то Вы получите фактически имитацию монады ввода-вывода, в некотором роде... Конечно, имитация монад будет частичной, далеко не полной.

    Вообще, складывается впечатление, что до Хаскеля ФП не существовало, т.к. Вы все время переводите разговор на Хаскель.

    Ну а почему бы не Хаскелл, раз уж он является "квинтэссенцией" ФП, как Оберон - ФЯ...
    (Просто другие ФЯ я знаю ещё хуже, чем Хаскелл :о)))


    № 2387   31-03-2007 17:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2374« (Илья Ермаков)
    ___________________________

    И чем больше работаю, тем больше "душа поет".

    Рад за Вас! :о) Честно говоря, не понимаю, как от Оберона может "душа петь", но Вы, надеюсь, поймёте, что и от Хаскелла "душа может петь" не меньше! :о))

    Киньте ссылочку, плиз. Это что-то из ряда вон, даже интересно стало :-) Если учитывать известное качество мат. подготовки в американской школе, то я просто не представляю, как им удалось втиснуть туда ФП...

    И я, и Jack Of Shadows уже приводили такие ссылки. Правда, не совсем про американские школы... Вообще, я не в курсе американских школьных программ, есть ли там уроки по информатике...

    Самый известный пример: проект "TeachScheme!"
    Правда, не смогли удержаться от коммерциализации - в конце обучения переходят на Java...
    (Эх, Джек опять опередил! :о))

    Менее известная работа, которую я тут недавно приводил:
    "The Pros and Cons of Teaching Purely Functional Programming in First Year"
    Manuel M. T. Chakravarty & Gabriele Keller

    Пример Оксфорда и MIT Вас, похоже, не впечатляет, а жаль...


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

    Вообще-то Вы сказали - "приходится"...

    А в чём, собственно говоря, проблема у ФП в жёстком РВ? Только в том, что Вам об этом не так много известно, как об Оберонах в жёстком РВ?

    Пример ОС РВ, написанной на языке Timber, основанном на Хаскелле.

    M. Wallace "Functional Programming and Embedded Systems"

    Учитывая, что тут описываются встраиваемые системы - это такое же ЖРВ, что и в случае с Оберонами...


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

    Да я понимаю. Я бы и сам с радостью использовал Оберон или Модулу-2 в своих микроконтроллерных разработках, да только нет трансляторов, вот и приходится на Сях работать...


    А я бы не стал перенапрягать их моск нюансами каррирования функций...

    А какие там есть непонятные нюансы? Я кроме удобства в этом ничего больше не вижу...


    № 2386   31-03-2007 17:46 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2372« (Geniepro)
    ___________________________

    Это отличная книга - классика! НО! Эта книга не есть истина в последней инстанции!

    Друзья-товарищи-господа-коллеги! Давайте определимся, что мы обсуждаем: ФП или конкретно Хаскель? Если ФП, то давайте остановимся на конкретной эталонной книге (ее кстати уже рекомендовали) и относительно нее будем плясать. Так можно ее уже изучать или погодить из-за того, что "просроченная"?


    № 2385   31-03-2007 17:42 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2371« (Geniepro)
    ___________________________

    Да ещё заставлять бедных школьников перенапрягать свой бедный моск всеми хитростями и премудростями "грамотного проектирования фабрик объектов на Обероне"?

    Странное какое-то передергивание. Оберон -- это упрощенный Паскаль (если брать то, что разумеют под этим словом в школах -- это не классический Паскаль 1970 г., не Паскаль 1972 г., не ISO Pascal -- это детище компании Borland). Так вот, Оберон -- это упрощенный Паскаль. А то, что он при этом могет быть языком системного программирования и заниматься всякой там коммутацией-композицией модулей и процедур -- просто полезный "довесок".


    № 2384   31-03-2007 17:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2371« (Geniepro)
    ___________________________

    Для школ идеальны языки с минимумом синтаксиса и маскимумом приближения к школьной математике.
    Например?


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

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


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

    >>>(Кстати, а куда Руслан Богатырёв пропал? Читал ли он ту мою мессагу?)

    Руслан, скорее всего, занят подготовкой очередного номера "Мира ПК".
    Вернется... :)

    Вы имеете в виду сокрытие (hiding) данных? А какие именно замечательные свойства у этого сокрытия есть с точки зрения ФП? ООП и ФП - всё-таки разные вещи. Что для ФП - хорошо, то для ООП - смерть! :о))

    Или наоборот... :)

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

    Та проблема с датчиком случайных чисел актуальна для Scheme, но это не значит, что она актуальна для чистого ФП. В Хаскелле этот датчик помещается внутрь монады ввода-вывода, и тем самым скрывается от остальной части программы...

    А в чем разница для остальной части программы?
    Какая ей разница, поместили Вы датчик внутрь монады или просто используете локальную переменную?
    Вообще, складывается впечатление, что до Хаскеля ФП не существовало, т.к. Вы все время переводите разговор на Хаскель.
     AVC


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


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

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

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

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

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

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