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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 52—43 | 42—33 | 32—23 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 547


    № 42   08-06-2006 11:18 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>>Лисп набирает популярность семимильными шагами, в то время как оберон
    >>>наоборот, борется с тем чтобы хотя бы удержать позиции.

    Я еще раз перечитал название этой ветки :)
    "Функциональное программирование"!
    А не что-то вроде "Лисп против Оберона".

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






    № 41   08-06-2006 11:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 31« (Q. Werty)
    ___________________________
    Не обижайтесь, но я думаю, что число сторонников и активных пользователей Лиспа не намного превосходит число сторонников и активных пользователей Оберона.

    ПО моим оценкам в несколько раз. Не удивлюсь если более чем в 10 (!!!) раз.
    Причем разрыв растет с каждым днем и очень быстро. Лисп набирает популярность семимильными шагами, в то время как оберон наоборот, борется с тем чтобы хотя бы удержать позиции.

    Хорошим мерилом является портирование популярных библиотек. Это как обживание нового дома. Он пуст, но приняв решение жить в нем, люди тащат в него свои старые вещи или покупают новые точно такие же и ставят мебель в тех же местах, как им было удобно в старом доме. Это показатель того что в язык приходят люди, решающие в нем остаться. И обживают пустое пространство переписывая полюбившиеся им библиотеки в других языках.

    Скажем junit портирован уже наверно в десятки языков. Люди тащат его за собой. Конечно же он портирован и в лисп. Или например Lucene - библиотека полнотекстового поиска в java. Куда только ее не портировали. И конечно в лисп тоже.
    Попробуйте поискать что либо портированное на Оберон. Вы будете удивлены. Практически ничего нет.
    Дом остается пустым. Никто в нем надолго не задерживается.

    То же самое кстати характерно и для других быстро набирающих популярность ФЯ, таких как Haskell и Ocaml.
    Идет активный процесс наращивания мускулов, т.е. написания всякого рода библиотек, доказавших свою нужность в mainsteram языках.


    № 40   08-06-2006 10:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 31« (Q. Werty)
    ___________________________
    Проблема в другом. Функциональный подход не сможет полностью вытеснить императивный до тех пор, пока сама архитектура компьютера будет оставаться "императивной", т.е. фон-неймановской
    Проблемы нет абсолютно. Более того никто никогда не ставил такой задачи.
    Речь идет о том, что если раньше функциональный подход был экзотикой, которую использовали считанные единицы, то теперь эта техника станет такой же обязательной для успешного программиста как и императивная.
    Речь идет о выходе функционального программирования из подполья универститетов, и специфических проектов, в mainstream, в повсеместное использование, в повсеместное обучение.
    Ну а что там будет еще через 50 лет, это слишком далеко чтобы загадывать.


    № 39   08-06-2006 10:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 38« (Jack Of Shadows)
    ___________________________


    Механизм потоков появился в си, java, дельфи не вчера.
    Если бы я преувеличивал, то сейчас мы наблюдали гораздо больше многопоточного кода чем жалкая доля процента от всего написанного за эти годы кода.


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


    Я уже приводил цитаты ведущих специалистов о сложности написания многопоточного кода.


    Ну, не знаю.
    Бринч Хансен, Хоар, Бирелл не оставили у меня впечатления, что многопоточный код настолько неподъемен.
    Просто есть адекватные средства (мониторы, активные объекты) и неадекватные (критические секции, рассыпанные по коду там и сям).
    Активный Оберон дает пример потоко-безопасного языка.


    Однако дальше делать вид что все хорошо - не получится. Мы уже сегодня вступили в эру повсеместного многопроцессорного железа.


    Согласен -- это, конечно, стимулирует создание многопоточных приложений.
     AVC


    № 38   08-06-2006 10:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 33« (AVC)
    ___________________________
    Мне кажется, эти трудности несколько преувеличены.
    Надо только пользоваться подходящими концепциями и механизмами.
    Например, мониторами -- для реализации взаимного исключения.


    Механизм потоков появился в си, java, дельфи не вчера.
    Если бы я преувеличивал, то сейчас мы наблюдали гораздо больше многопоточного кода чем жалкая доля процента от всего написанного за эти годы кода.

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

    Однако дальше делать вид что все хорошо - не получится. Мы уже сегодня вступили в эру повсеместного многопроцессорного железа.


    № 37   08-06-2006 10:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 36« (Сергей Перовский)
    ___________________________
    А помните FORT?
    Расширять синтаксис можно по разному, например через препроцессор. Каждый подход имеет свои недостатки.
    Подход лиспа в корне отличается от того как это делается в форте или скажем в aspectj или sqlj.
    Поэтому в нем нет таки проблем как в форте с одним единственным сообщением об ошибке :))

    Лисп по моему единственный язык программирования в котором исходный код программы одновременно является корректной записью основного формата данных - списка. Поправьте мня если ошибаюсь, но по моему другого такого языка нет.
    Таким образом лисп может легко читать и разбирать код на лиспе, для чего в других языках нужно писать громоздкие и сложные парсеры.

    Так мы о чем? Я могу использовать функциональный подход в любом языке, почему нет.
    Скоро сможете. Функциональные возможности сейчас вовсю просачиваются в сишарп (linq, type inference). А за ним я думаю и java подтянется, если не хочет проиграть в конкурентной борьбе.

    Тут проблема в другом. Простое наличие в языке функциональных фозможностей не означает что ваши программы автоматически станут распараллеливаться. Вот скажем Хаскель это вам гарантирует. Поскольку там вы вынуждены просто отделять функциональный код от императивного специальной констуркцией do, которой вы обрамляете императивный код. Т.е. программа представляет из себя море функционального кода с маленькими островками императивного. А в программе где состояние (state) размазано как масло на хлеб, по всей поверхности программы, компилятор просто не в состоянии как либо распараллелить ее.
    Так что если перед вами будет стоять задача уведичения производительности программы в многопроцессорной среде. То придется таки выбирать.


    № 36   08-06-2006 08:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 12« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 10« (Сергей Перовский)
    ___________________________
    Насколько я понимаю, он состоит в том, чтобы принципиально отказатся от понятия состояния

    Ошибаетесь. Вы говорите о чистых функциональных языках (Haskell, Clean) в которых исключен императивный подход. Но это не означает что функциональный и императивный подходы взаимно исключаемы.
    Такие языки как лисп или оcaml полностью поддерживают как функциональную так и императивную и обьектную парадигму программирования.
    Т.е. используя лисп вы не теряете ни присваивания ни циклов, ни состояния ни классов.
    Это значит что для каждой задачи вы можете выбирать наиболее оптимальный подход.
    По моему это наиболее правильный подход для прикладных задач.

    Так мы о чем? Я могу использовать функциональный подход в любом языке, почему нет. Мы же говорим о функциональном программировании, об определенной парадигме. Вот про нее и спрос - где полезна, а где вредна?


    Лисп это макросы. А это уже не имеет никакого отношения к функциональному программировнаию. Это уже мета-программирование.

    А с мета-программированием в другую ветку :)


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

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


    Поэтому несмотря на появление мощных функциональных языков нового поколения (Haskell, Erland) я думаю будущее за лиспом.

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


    № 35   08-06-2006 08:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 34« (Q. Werty)
    ___________________________

    И где критерий "приземленности"?

    Ну уж не технологическое совершенство, не элегантная математическая основа, не изящество форм и не надежность программирования. "Приземленность" -- это то, что активно используют в ремесленном программировании. Изо дня в день. Лица все те же: Си, C++, Delphi, Фортран. В последние годы -- Java, C#. А "приземленный" некогда ассемблер (для самых разных платформ) стал уже экзотической птицей, парящей высоко в поднебесье.


    № 34   08-06-2006 08:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>>Но "мировая революция" -- это замечательно. Однако у людей другие,
    >>>куда как более приземленные проблемы...

    А какие языки программирования Вы считаете достаточно приземленными?
    И где критерий "приземленности"? Объем продаж?
    Просто интересно.


    № 33   08-06-2006 07:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 18« (Jack Of Shadows)
    ___________________________


    В чем дело ? Разве на императивных языках нельзя писать распараллеленные, многопоточные  (multithread) программы ?
    Можно конечно. Но написание многопоточных программ на императивных языках, дело невероятно трудное.


    Мне кажется, эти трудности несколько преувеличены.
    Надо только пользоваться подходящими концепциями и механизмами.
    Например, мониторами -- для реализации взаимного исключения.
     AVC


    <<<... | 52—43 | 42—33 | 32—23 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 547


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

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

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

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

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

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