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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 642—633 | 632—623 | 622—613 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 488


    № 632   10-08-2006 11:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 625« (Денис Зайцев)
    ___________________________
    Ну что ж. Видимо я был неправ, когда посчитал что цифр слишком много.
    Наверное их никогда много не бывает. :))
    Так что приведенные замеры на работе фиббоначи все таки оказались полезными.


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


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

    Опять таки, я не буду говорить что ФЯ так же быстры как и ИЯ. Просто скажу что разница идет на проценты а не в разы.
    Другой вопрос - скриптовые языки, которые не компилируются. Там да, разница в скорости может достигать от 10 до 100 раз. Но скриптовые языки не обязательно функциональные. PHP, Perl, Python, Ruby - все это полноценные императивные языки. И отставание в скорости тут не из за императивности или функциональности, а из за отсутствия компилятора. Об этом говорит и наличие скажем компилятора для Python, который доводит скорость работы python программ до нормальной. Правда это экзотика. Им практически никто не пользуется.
    Просто потому что задачи, которые решаются на python в подавляющем большинстве случаев достаточно быстро работают.

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

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

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


    № 631   10-08-2006 11:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 630« (SJ)
    ___________________________


    Хоть бы в скобочках 2-3 таких языка привели. Только те, в которых вычисление 100-разрядного числа можно выполнить с помощью встроенных средств языка (без дополнительно написанных программных "костылей"


    assembler

    - их, ясное дело, можно к любому языку "привинтить" :))

    А чем не нравится "привинчивание"? Встроенных возможностей на всех не напасешься. Между прочим, операции с большими числами, как правило характерезуются тем, что их нужно выполнять максимально быстро, поэтому все реальные проэкты, работающие с большими числами до сих пор пишут на Си и assembler


    № 630   10-08-2006 11:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>>Почему компилятор языка не может вывести меня за эти жалкие рамки в
    >>>64 бита?

    >>>Может

    Хороший ответ, а главное - полный :)
    Хоть бы в скобочках 2-3 таких языка привели. Только те, в которых вычисление 100-разрядного числа можно выполнить с помощью встроенных средств языка (без дополнительно написанных программных "костылей" - их, ясное дело, можно к любому языку "привинтить" :))



    № 629   10-08-2006 10:55 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 628« (SJ)
    ___________________________

    Почему компилятор языка не может вывести меня за эти жалкие рамки в 64 бита?

    Может


    № 628   10-08-2006 10:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Добавлю еще пару слов для ясности :)
    Меня всегда удивляло, почему при наличии такой большой памяти я не могу в какой-нибудь паскалевской или сишной программе взять и без всяких заморочек посчитать число, в котором 100 десятичных разрядов. Почему компилятор языка не может вывести меня за эти жалкие рамки в 64 бита? И это мне представлялось почти какой-то "родовой" убогостью традиционных языков программирования. И тут появляются языки, в которых эти вопросы решены. И все! Я уже заинтригован :) - в полку любителей поработать с ФЯ прибыло.


    № 627   10-08-2006 10:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>>Да, но хватит перемывать одни и те же косточки :)) От цирф прогона этого
    >>>чортовго фибоначи уже в глазах рябит. We get the messge :)) Let's move on.

    1) Я так понимаю, что Фибоначчи - это просто для примера. Он же не виноват, что представляет собой блестящий пример нелинейной рекурсии :)
    А насчет цифр я с Вами не согласен. Если бы я, допустим, был бы противником всяких ФЯ и горячим сторонником работы исключительно только в С++, Java или С#, то признаюсь - один только пример с вычислением числа из 100 или более разрядов с помощью одних только встроенных средств языка программирования смог бы заставить меня более уважительно смотреть в сторону Haskell или Lisp. Тут "агитация" работает сразу, на уровне "подсознания" - а ну-ка назовите языки, на которых я могу "с ходу" посчитать факториал 100 и программа это дело "проглотит" и при этом никаких библиотек, кроме встроенных, мне не потребуется.


    2) После последних постов боюсь не "вписаться в тему", но все-таки...
    Может кто из знатоков не сочтет за труд помочь :)
    Меня интересуют "физические" основы представления структур данных в различных языках и, в связи с этим, возник один вопрос.
    В Haskell, Lisp и, я так понимаю, в большинстве других ФЯ "базисной" структурой являются списки. С другой стороны, в Haskell имеется модуль Array, который позволяет импортировать базовые возможности для представления и работы с массивами. Нигде не смог найти точного описания, что из себя представляет такой массив на "физическом" уровне: связанный список с указателями, для которого используется механизм индексации или это "настоящий" массив, в котором все элементы занимают смежные поля памяти и индексация выполняется путем вычисления адреса как в "обычных" массивах в императивных языках? Если это связанный список кортежей, то интересно, как же обеспечивается быстрота доступа по индексу? Может кто в курсе дела, подскажите или дайте ссылочку. Заранее спасибо.


    № 626   10-08-2006 06:40 Ответить на это сообщение Ответить на это сообщение с цитированием
    Многопоточность интересует нас лишь постольку, поскольку позволяет увеличить производительность программы. Иначе она не нужна, я так думаю

    Вы не совсем правы. Многопоточность упрощает проектирование систем параллельного обслуживания, при этом вся сложность распределения процессорного времени на каждого клиента, реализуется планировщиком операционной системы. Грамотно спроектированная вертушка на одном процессоре всегда быстрее многопоточности, иногда занчительно, поскольку содержит в себе встроенный планировщик, который может более эффективно обслуживать и меньше грузить процессор сам по себе. Кстати, в Windows для этого есть фиберы, которые также как и потоки призваны упростить труд программиста.


    № 625   10-08-2006 06:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 624« (Jack Of Shadows)
    ___________________________
    Меня давно интересует один вопрос, связанный с отношением ФП и многопоточности:

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

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

    Таким образом получается, что выигрывая не более чем в N раз, гда N - число процессоров (а ведь не каждую задачу вообще можно распараллелить), мы, с другой стороны проигрываем в M раз, где M >= 10. Выигрыш теоретически возможен, только если N > 10.

    В свете вышесказанного, может быть несколько преждевременно говорить о производительности как о сильной стороне ФП?


    № 624   09-08-2006 14:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 623« (Geniepro)
    ___________________________

    Разве эта ветка не должна всячески пропагандировать ФП и ФЯ?


    Да, но хватит перемывать одни и те же косточки :)) От цирф прогона этого чортовго фибоначи уже в глазах рябит. We get the messge :)) Let's move on.


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


    Я думаю разработчикам скриптовых языков далеко н так смешно как кам.
    Может потому что они "в теме" так сказать ? :))
    Если бы бы ло легко сделать многопроцессорную многопоточность, что наверное уже давно бы сделали, особоенно PHP, который имеет нехилую коммерческую поддержку и до сих пор является платформой номер 1 в интернете.

    Вот разберетесь, потом расскажете нам, что ж там такого смешного.


    Не многоядерность же. Каким боком она относится к принципам ФП?


    Не к принципам, а к востребованности. Когда надо нагрузить все 16 ядер, то у вас вобщем то всего 2 выхода.
    Либо по старинке в ручную управлять многопоточностью (невероятно трудно и доступно 1% от числа всех программистов), либо переходить на язык, берущий распараллеливание на себя, то есть на ФЯ.


    Вы ведь основатель темЫ, на Вас основная ответственность за её развитие... ;-)

    Я один из интересующихся функциональным программированием. Мне также как всем остальным есть много чему поучиться.
    Мне вот интересно, почему не высказываются хаскелисты или другие ФП-программисты ?
    Среди дельфистов их что, нет ?
    Миграция дельфистов происходит только в сторону java, сишарп, оберон ?


    Всё-таки сомнительно, что все программеры срочно перейдут на Хаскель и ему подобные языки, инерция мышления не позволит...


    Инерция мышления не помешала перейти от си к си++, не помешала перейти от компилируемых языков к языкам с виртуальной машиной.
    Дело не инерции, а в востребованности большим бизнесом и соответственно вложением большого капитала.

    До сих пор необходимости вкладываться в ФП не было. 100% персональных компьютеров были однопроцессорными с малюсенькой памятью и полудохлыми процессорами.
    Какой смысл вкладываться в Гулливера если этот Гулливер засунут в узкую трубу где он может только ползти ?
    Его в этой трубе любой лилипут обгонит.

    А сейчас ситуация меняется. 2 гигабайта оперативки уже не мечта. Это уже норма.
    Многоядерные процессоры к концу этого года полностью вытеснят из производства обычные. То есть однопроцессорных систем просто не останется!!

    Это уже совершенно другая ситуация. И классические, десятилетиями использовавшиеся языки к этой ситуации приспособлены плохо.
    Они экономят память которую уже давно не нужно экономить.
    Они не могут работать на многопроцессорных системах без того чтобы программист не водил их как ребенка за ручку. Вот здесь новый поток создай, вот здесь данные синхронизируй, вот здесь выставь флажок, вот здесь проверь не выставил ли его кто нибудь до тебя. Вот здесь сиди и жди пока другой поток отработает.
    И это на машине на которой 2 гига памяти стоят дешевле чем два часа работы программиста, а двухядерный процессор стоит дешевле чем 1 день работы программиста.

    Бизнес не потерпит такого расточительства.
    Поэтому программисты сейчас ищут разнообразные способы либо облегчить создание многопоточных приложений (erlang, active objects в обероне) либо вообще его автоматизировать (parallell haskell)

    То есть это именно то направление в которое будут вкладывать большие деньги.
    Это необходимо позарез Интелу. Иначе обосновать покупку новых процессоров не получится. На них старые приложения не только не дают никакого выигрыша, но зачастую и работают медленнее чем на обчных процессорах.
    Это необходимо Microsoft. Потому что нужно обосновать покупку новых версий прогамм. И если новые версии не дадут существенного выигрыша в производительности, то смысла переходить на них нет.
    Ну а дальше это станет необходимым всем кто учавствует в конкурентной борьбе, либо как средство сокрушить конкурентов, либо как ответ на выпад конкурентов, представивших новые, более эффективные  версии своих программ.

    Я уже тут писал, что скорее всего первой ареной такого вот столкновения станет индустрия игр.
    Почитайте отчет разработчика Unreal, ccakre я здесь приводил.


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

    Господа, эта ветка превратилась в соревнование по скачиванию различных экзотических компиляторов и прогону на них 2-х строчек наивного алгоритма фибоначи.
    Мне это не нравится.

    Хм, странный наезд... Разве эта ветка не должна всячески пропагандировать ФП и ФЯ?
    Информация о разных компиляторах ФЯ не может помешать...

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


    Это обсуждение началось с отличной новости о переходе Интела на многоядерную архитектуру.
    Как вы думаете, что это означает для языков, которые не могут задействовать все ядра, а работают только на одном ядре ?
    Что случится с такими языками когда количество ядер достигнет 8 или 16 (через 3-4 года) ?
    ТО есть программы написанные на таких языках будут задействовать 1/8 или 1/16 процессора.

    Видимо, произойдёт переход к таким языкам, которые поддерживают многозадачность.
    Может быть, снова вспомнят Ada95 и Occam (коль скоро процессоры становятся похожими на сеть из транспьютеров)...
    Да и на улице виртовского семейства наступит праздник - начнут реально использоваться активные обьекты из Active Oberon/Zonnon...

    Всё-таки сомнительно, что все программеры срочно перейдут на Хаскель и ему подобные языки, инерция мышления не позволит... :-(


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

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


    Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.

    Тогда что обсуждать-то тут??? Не многоядерность же. Каким боком она относится к принципам ФП?
    К практике применения - да, как и компиляторы...


    Мы топчемся на месте.

    Согласен. Куда пойдём? Вы ведь основатель темЫ, на Вас основная ответственность за её развитие... ;-)


    <<<... | 642—633 | 632—623 | 622—613 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 488


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

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

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

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

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

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