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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1142—1133 | 1132—1123 | 1122—1113 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 438


    № 1132   04-09-2006 11:13 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1118« (Geniepro)
    ___________________________

    Ответ на »сообщение 1117« (Артем)
    ___________________________
    "Почему никто не использует функциональные языки" Филип Вадлер
    http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

    Там как раз анализируются причины незатребованности ФЯ...


    Не устаю восхищаться Игорем Анатольевичем: хорошо выбрал ("умение выделять главное -- главный показатель ума") и перевел пару текстов -- вот кого бы ведущим этой ветки.

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


    № 1131   04-09-2006 11:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1130« (Артем)
    ___________________________

    Не могли бы вы привести исходник вашего 64-битного кода на F# ? :)

    let dec32 n =
        let f32 x y z =
            let rec f232 x y z = if (y+1)=x then z else f232 x (y+1) (z+1)
            in if x=1 then 0 else f232 x y z
        in f32 n 0 0

    let dec64 n =
        let f64 x y z =
            let rec f264 x y z = if (y+1L)=x then z else f264 x (y+1L) (z+1L)
            in if x=1L then 0L else f264 x y z
        in f64 n 0L 0L

    let rec testtail k v = if k=1 then v else testtail (k-1) (v+1)
    let test n = testtail n 1

    let Nd32 = 1000000000
    let Nd64 = 1000000000L

    let st = System.DateTime.Now
    let r  = dec32 Nd32
    let ft = System.DateTime.Now
    let t  = time ft - time st

    do  System.Console.WriteLine("dec32 {0} == {1}, time == {2}", Nd32, r, t)

    let st2 = System.DateTime.Now
    let r2  = dec64 Nd64
    let ft2 = System.DateTime.Now
    let t2  = time ft2 - time st2

    do  System.Console.WriteLine("dec64 {0} == {1}, time == {2}", Nd64, r2, t2)


    PS. Ну про Release-то я знаю... :-))

    ЗЗЫ. Кстати, понять не могу, выделил в C#-проге эти циклы в отдельные функции - 64битная стала выполняться за те же 6 сек.. Что за дела? почему в теле main она работала 7.3 сек?


    № 1130   04-09-2006 09:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1129« (Geniepro)
    ___________________________
    Действительно, на С# 32-битный расчёт в полтора раза быстрее, чем на F#, но 64-битный - на 20% медленнее!
    Не могли бы вы привести исходник вашего 64-битного кода на F# ? :)

    Кстати, а как Вы включаете оптимизацию в .NET? А то я, признаюсь, не в курсе... - Кнопкой включаю :)
    Если быть точным, то это не оптимизация .Net, а оптимизация компилятора C#. (VS:Project/MyProject properties/Build/Optimize code)


    № 1129   04-09-2006 09:32 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1124« (Артем)
    ___________________________

    Так почему же тогда в следующем примере на C#, вы выбрали 64-битный?

    Да, я так и думал, что Вы мне именно ЭТО припомните... :-))
    Но дело в том, что этот тест я проводил и с 32-битными числами, и с 64-битными. Да, я недоглядел, и выложил куски кода с разными разрядностями. В этом виноват!

    НО! Те значения времени выполнения я привёл для 64-битных тестов!
    Ну хорошо, я немного приукрасил результаты, реально должно выглядеть так:

    bits  C#    F#    Haskell(GHC)
    32    1.21.85.8s
    64    7.36.0s  ??? (не знаю, как указать int64 в Хаскеле)


    Действительно, на С# 32-битный расчёт в полтора раза быстрее, чем на F#, но 64-битный - на 20% медленнее!

    Кстати, я, оказывается, зря наезжал на компилятор GHC - нужно просто уметь им пользоваться! :)
    Скомпилировал им (с ключём оптимизации -O ) ту же самую функцию Клини


    dec:: Int -> Int
    dec n = f n 0 0 where
          f x y z  = if x==1 then 0 else f2 x y z where
                  f2 x y z = if (y+1)==x then z else f2 x (y+1) (z+1)

    и она тут же перестала нагружать стек и выполнилась более-менее быстро, хотя и в три раза медленнее, чем та же функция на F#.

    В-общем, всё-таки не стоит считать Хаскель просто игрушкой. ;-)


    Как видите, миллиард влазит и в 32-битный целый. :)

    Спасибо, вижу! :))

    ЗЫ. Кстати, а как Вы включаете оптимизацию в .NET? А то я, признаюсь, не в курсе... :-))


    № 1128   04-09-2006 07:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1127« (Артем)
    ___________________________
    Сложность все больше становится неконтролируемой.
    Боюсь, что и ФП с этой проблемой не покончит :)


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

    Программисты IMHO упорно хотят облегчать себе жизнь, требуя по максимуму самых невероятных наворотов в языках и инструментах (даешь скрещивание ФП с ООП, а заодно уж и с генетическим программированием!), часто не понимая, что одно из самых важных, бесценных и утраченных качеств - чувство меры. Часто нужно идти на сильные ограничения и самоограничения, чтобы плод твоего творчества/труда поддавался последующему разумному контролю по сложности и через 3-5 лет не шел в корзину, а мог находить свое развитие и применение.

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


    № 1127   04-09-2006 07:27 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1123« (bb)
    ___________________________
    Сложность все больше становится неконтролируемой.
    Боюсь, что и ФП с этой проблемой не покончит :)


    № 1126   04-09-2006 07:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1124« (Артем)
    ___________________________
    Пардон, я вместо F#-вского Haskell-вский тектст запхал в прошлом сообщении. Но суть от этого не меняется.


    let rec f2 x y z = if (y+1) = x then z else f2 x (y+1) (z+1)
    let f x y z = if x = 1 then 0 else f2 x y z
    let dec n = f n 0 0
    let Nd = 1000000000
    do  Printf.printf "dec %d = %d\n" Nd (dec Nd)



    № 1125   04-09-2006 07:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1118« (Geniepro)
    "Почему никто не использует функциональные языки" Филип Вадлер
    http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

    Понятно теперь, откуда Jack черпает лозунги:
    Функциональное программирование прекрасно, оно - радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
     hugi


    № 1124   04-09-2006 06:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1121« (Geniepro)
    ___________________________
    Ув. Geniepro! Как вы думаете, какой тип для x,y,z выбирается в результате type inference?


    dec n = f n 0 0
    f x y z  = if x == 1 then 0 else f2 x y z
    f2 x y z = if (y+1) == x then z else f2 x (y+1) (z+1)
    main = print (dec 1000000)



    Так почему же тогда в следующем примере на C#, вы выбрали 64-битный?


    long x, y, z;
    const long N = 1000000000L;
    x = N; y = 0; z = 0;
    while ((y+1) != x)
    {
        y++; z++;
    }


    Здесь (если у вас, конечно, не 64-битная Винда) идет эмуляция 64-битной арифметики. Для корректного сравнения надо было написать так:


    int x, y, z;
    const int N = 1000000000;
    x = N; y = 0; z = 0;
    while ((y + 1) != x)
    {
      y++; z++;
    }


    Как видите, миллиард влазит и в 32-битный целый. :)
    Даже без включения оптимизации (надеюсь, вы знаете, что и в .Net можно включить оптимизацию) код выполнился гораздо быстрее.

    Вывод. Вот такие горе-тесты, как в сообщении 1088, и дают искаженную картину производительности.

    P.S. Gienpro! Не обижайтесь. Просто тесты должны быть более продуманы...


    № 1123   04-09-2006 06:29 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1122« (Сергей Перовский)
    ___________________________

    Кстати, многие аргументы могут быть перенесены и в ветку по Оберонам.

    Внешне - да, а по сути - вряд ли. ФП - это практически другой мир в сравнении с привычным императивным и ООП. Кризис программирования с начала 70-х не только не преодолен, но все больше усугубляется. Сложность все больше становится неконтролируемой. В этой ситуации что-то кардинально иное (как было в свое время с ООП) будет с большей легкостью подхвачено софтверной индустрией. Так что у функционального программирования через n-е число лет все шансы занять трон, вытеснив оттуда ООП. Со сложностью можно бороться по-разному. Упрощения а-ля Оберон рынку не выгодны. Давно пора бы это всем нам понять. А другая парадигма - вполне. Это деньги и новый рынок.


    <<<... | 1142—1133 | 1132—1123 | 1122—1113 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 438


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

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

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

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

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

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