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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2192—2183 | 2182—2173 | 2172—2163 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 333


    № 2182   23-03-2007 19:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2176« (Jack Of Shadows)
    ___________________________


    Вот тогда императивщикам придется туго. Надо будет переучиваться :))

    у "императивщиков" для решения проблем, в частности, параллельного программирования и свой арсенал есть. Увы, мейнстрим не поднимается в абстрагировании выше уровня семафоров/критических секций/потоков - но это уже проблемы мейнстрима...
    В паскалевском семействе та же Ada еще в 80-м предоставила превосходные, встроенные в язык средства параллельного программирования, и большинству языков в этом аспекте до нее семь верст сами знаете чем еще плыть :-)

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


    № 2181   23-03-2007 19:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2179« (Булат Зиганшин)
    ___________________________

    >>>ну пусть не все языки, но многие :)

    Точнее сказать -- некоторые.
    Такие языки называются модульными. :)
     AVC


    № 2180   23-03-2007 19:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2176« (Jack Of Shadows)
    ___________________________

    IBM делает процессоры cells для Playstation 3, в которых работают несколько асинхронных ядер.
    Это в корне отличается от обычной SMP архитектуры.


    асинхронные - это как? может, асимметричные? в xbox 3-ядерный powerPC. в ps3 1нормальное ppc ядро, и ещё 8 упрощённых, чисто вычислительных, с 128к локальной памяти каждое. какие-нибуль научные расчёты на них пускать - самое милое дело. помните, как ps2 щапретили ввозить в россию, поскольку его мозность, 5.6 гфлопс, попала в диапазон, описывающий суперкмопьюетры? :)


    № 2179   23-03-2007 19:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2178« (AVC)
    ___________________________

    Вы говорите о независимой (independent) компиляции, а Руслан Богатырев -- о раздельной (separate).
    Основное (но не единственное) различие -- в межмодульном контроле типов.
    Кроме того, раздельная компиляция позволяет избегать перекомпиляции клиентов модуля (при условии сохранения или даже расширения интерфейса).
    А отсюда один шаг до компонентного подхода.


    ну пусть не все языки, но многие :)  с тех пор, как наткнулись на проблемы с нею, придумали отделение интерфейса от реализации, что и позволяет реализовать контроль типов. что касается избегания перекомпиляции - с этим в ghc как-то не очень, хотя я подозреваю, что делов в том, что я экспортирую всё и сигнатур не пишу, в результате чего у меня интерфейсы меняются за милую душу. но при этом я хамечаю, что при включенной оптимизации перекомпиляция случается чаще - видимо, из-за кросс-модульного инлайнинга функций


    № 2178   23-03-2007 18:52 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2175« (Булат Зиганшин)
    ___________________________

    Ответ на »сообщение 144« (Руслан Богатырев)
    ___________________________

    Какие языки ФП имеют концепцию модуля как средства для инкапсуляции программных сущностей и инструмента поддержки раздельной компиляции (separate compilation) -- отчуждение интерфейса модуля от его реализации и автономную компиляцию модуля на основе одних интерфейсов при отсутствии доступа к реализации импортируемых им модулей?

    по-моему, все практические компилируемые языки, начиная с фортрана, поддерживают раздельную компиляцию - иначе далеко не уедешь. в ml какое-то особо мощное модулльное программирование - модули образуют так называемые функторы. что это такое, я так и удосужился разобраться, но судя по тому, что их сравнивают с type classes...


    Вы говорите о независимой (independent) компиляции, а Руслан Богатырев -- о раздельной (separate).
    Основное (но не единственное) различие -- в межмодульном контроле типов.
    Кроме того, раздельная компиляция позволяет избегать перекомпиляции клиентов модуля (при условии сохранения или даже расширения интерфейса).
    А отсюда один шаг до компонентного подхода.
     AVC


    № 2177   23-03-2007 18:52 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 156« (info21)
    ___________________________
    А возращать локальные функции -- в гробу хочется видеть такие штуки. Жизнь-то одна, и хочется че-нить реальное совершать, а не примеры для конкурса Obfuscated Lisp генерить.

    а ведь объект - это как раз и есть данные вместе с привязанными к ним функциями :)

    я на http://haskell.org/haskellwiki/IO_inside приводил несколько примеров возрастающей сложности, как вместо класса, реализующего ту или иную функциональность в ООП-овской парадигме, в хаскеле возвращаются просто те самые несколько функций, которые составляют функционал этого класса. чем это лучше? меньше писанины. чем хуже? нет наследования. т.е. фактически это АТД, а не ООП

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


    № 2176   23-03-2007 18:40 Ответить на это сообщение Ответить на это сообщение с цитированием
    Булат переключился на начало списка :))
    Если он продолжит в том же духе, нас ждет масса интересных коментариев.

    Кстати по поводу нестандартной архитектуры компьютеров.
    IBM делает процессоры cells для Playstation 3, в которых работают несколько асинхронных ядер.
    Это в корне отличается от обычной SMP архитектуры.
    И эти машины уже у нас дома. PS3 по моему продан уже в обьеме нескольких миллионов экземпляров.
    Я думаю не за горами тот день когда мы увидми персоналки с асинхронными ядрами.
    Вот тогда императивщикам придется туго. Надо будет переучиваться :))


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

    Какие языки ФП имеют концепцию модуля как средства для инкапсуляции программных сущностей и инструмента поддержки раздельной компиляции (separate compilation) -- отчуждение интерфейса модуля от его реализации и автономную компиляцию модуля на основе одних интерфейсов при отсутствии доступа к реализации импортируемых им модулей?

    по-моему, все практические компилируемые языки, начиная с фортрана, поддерживают раздельную компиляцию - иначе далеко не уедешь. в ml какое-то особо мощное модулльное программирование - модули образуют так называемые функторы. что это такое, я так и удосужился разобраться, но судя по тому, что их сравнивают с type classes...


    № 2174   23-03-2007 18:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 31« (Q. Werty)
    ___________________________

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

    в свою очередь фон-неймановская архитектура была придумана отгадайте для чего?... для того, чтобы упростить программирование! :)  один из первых компьютеров, созданный под руководстовм Тьюринга, имел возможность программировать все исполнительные устройства параллельно и независимо, а данными управлять так, чтобы они приходили на исполнительные устройства just-in-time. в результате чего он работал в 6 раз быстрее (по сравнению с самим собой, работающим в "фон-неймановском" режиме), но его программирование превращалось в настоящий вызов для программистов :))

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

    современные же компьютеры имеют отнюдь не фон-неймановскую микро-архитектуру. они *супер-скалярны* и только из-за проблем совместимости вынуждены эмулировать фон-неймановскую архитектуру, которая тянется как минимум со времён 8080. была подвижка с vliw-процессором itanium, но её благополучно закатала под асфальт amd :))

    тем не менее, экспериментальные процессоры, управляемые данными, существовали. представь себе - есть куча исполнительных блоков. есть очередь заданий на вычисление - скажем вычислить x+y и поместить результат в z, затем a+b->c и z*c->t. задания из этой очереди расхватываются исполняемыми устройствами и выполняются в порядке, опредлеляемом их зависимостями *по данным*. в остальном же выполнение порграммы идёт асинхронно. фактически именно так сейчас и исполняются МОПыб в которые превращаются внутри процессора старые добрые x86 инструкции

    добавь к эому параллелизм на уровне ядер (число которых intel обещает к концу десятилетия довести до 80 и вообще говорит, что теперь закон Мура будет работать в отношении числа ядер). не забудь ещё hyperthreading, хотя он наверно останется в основном для серверных процов; кстати уже продающийся sun t1 имеет не то 8 ядер по 4 треда, не то наоборот

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

    или - слышали про google mapReduce? идея из функционального программирования, которая используется google для построения из тысяч компьютеров кластера, "суперкомпьютера", просеивающего гигабайты информации в секунду. между прочим, отсутствие состояния здесь существенно используется - оно позволяет перезапустиь любую часть вычисления заново, если её результаты были потеряны из-за сбоев в компьютерах

    так что функциональный подход хорош для обработки данных, и современные комптютерные архитектуры вынуждены рещать проблему прямо противоположную имевшейся 60 лет назад - не как извратить *аппаратные* средства, чтобы программисту было проще программировать в машинном коде, а какие дать средства *программисту*, чтобы пришлось как можно меньше извращать аппаратуру от уровня естественного схемного параллелизма


    № 2173   23-03-2007 17:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2172« (Jack Of Shadows)
    _________________________
    Кстати, почему delphikingdom ? Насколько я понял ты к дельфям никакого отношения не имеешь.


    geniepro в жж ссылку кинул на задачку ACM. а к дельфи я действительно отношения никакого не имею, кроме того, что с 98-го его на хлеб намазываю :)))


    <<<... | 2192—2183 | 2182—2173 | 2172—2163 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 333


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

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

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

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

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

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