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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2372—2363 | 2362—2353 | 2352—2343 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 315


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

    Возможно, что Вы просто ошибаетесь, считая императив естественным для Ваших задач. Вот если бы Вы всерьёз попробовали - тогда можно было бы говорить о естественности императива для Вас.
    А причин для использования ФП Вы не видите по той простой причине (пардон за тавталогию), что не хотите их увидеть, вот и всё...


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

    Идеал - понятие субъективное.
    Есть преподаватели, считающие ФЯ гораздо идеальнее других языков подходящими для начального обучения программированию. И таких преподователей существенно больше, чем преподователей Оберонов...


    А потом, где-нибудь главе к третьей, они вдруг сообщают, что все-таки приходится использовать присваивание...
     AVC


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

    Для моих текущих задач императив естественен, а для использования ФП нет никаких причин.

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

    Правильно, на прикладных, в бизнесе - кто спорит-то? Поле широчайшее. Я и описал это поле - очень условно, но все же - как задачи "на вычисление".

    Что такое - задачи не "на вычисление"? Непонятно... Разве есть хоть одна сколько-нибудь серьёзная задача, обходящаяся без вычислений? Я о таких никогда не слышал... Даже в жрайвере мышки и то есть какие-то вычисления...

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

    Идеал - понятие субъективное.
    Есть преподователи, считающие ФЯ гораздо идеальнее других языков подходящими для начального обучения программированию. И таких преподователей существенно больше, чем преподователей Оберонов...

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

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


    № 2360   31-03-2007 11:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2356« (VPrin)
    ___________________________

    Спасибо, нашел задачу. Не нашел двухкратно уменьшения кода при использовании Хаскеля по странению с ИЯ о котором говорил Jack Of Shadows.

    Да, Вы правы, конечно же. Если считать строки чистого кода, то программа на Хаскелле почти в четыре раза короче программы на КП (63 строки против 230). Собственно, это и имелось в виду. А программа Трурля (на J, кажется) ещё в три раза короче (22 строки) :о)) Что любопытно, Ваша программа на Дельфях имеет около ста строк (среднее между Хаскеллем и КП).


    Ну все равно это больше академическая задача. Есть более земные задачи, например поиск пути волновым методом на квадратной карте. Лучше б хаскелисты на них показывали крутость хаскеля, к ним бы вопросов о надуманости задач не возникало. Может кто нить из хаскелистов, как Вы там писали "найти на неё время, показать всю мощь их языков" с волновым алгоритмом на хаскеле? :) А интересно стало, а гугл ответа не дал.

    А что это за задача, и насколько она полезна?
    И разве нет её решений на других языках? Стоит ли изобретать велосипед? ;о))


    № 2359   31-03-2007 11:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2357« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2354« (Илья Ермаков)
    ___________________________
    ФП/ДП "чахло" в диапазоне 80-х не от того, что "еще не было гигабайт дешевой памяти", а из-за упадка своей сферы.
    Отвергаются очевидные вещи, лишь бы успокоить себя что ФЯ это химера, а императив не мелкая идея, привязанная к состоянию техники 60-х годов, а нечто на тысячелетия.

    Почему химера? Гиперболы навроде "императив - мелкая идея..." как раз с Вашей стороны постоянно слышно. Для меня это всего лишь параллельные подходы. У меня сложилось четкое представление о том, где бы я стал применять ФП. Т.е. ту границу, за которой я уверенно возьму в руки LISP али Haskell, я знаю. Например, из своего, хоть и небольшого, опыта работы над системами комп. лингвистики, я извлек урок, что императив для этого подходит слабо. ФП там не пробовал (ибо корпоративный стандарт и огромный code-base у них был на Ц++), но при возможности, если еще придется работать в подобной сфере, очень хотелось бы попробовать.

    Для моих текущих задач императив естественен, а для использования ФП нет никаких причин.


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

    Правильно, на прикладных, в бизнесе - кто спорит-то? Поле широчайшее. Я и описал это поле - очень условно, но все же - как задачи "на вычисление".


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

    Практика не сама по себе, практику делают люди. Наши ветки претендуют на роль "массового просветительства". Так давайте не на практику кивать, а разбираться уже сейчас, что да как...
    А то наплодим оговорок, а потом еще MS (как Вы говорите) подключится - и получим еще раз вовсе не то, что ожидалось - как это произошло с мейнстримовским ООП. И будете на старости лет, подобно Алану Кею, говорить: "Когда я продвигал в массы ФП - то, я вам скажу, я отнюдь не имел в виду Microsoft Visual Some_Functional_Language".
    Сфера применения Оберона достаточно ясна - и никто не выдает его давно за "серебрянную пулю" в целом. Это нечто близкое к "серебрянной пуле" для системных задач, идеал для начального обучения программированию, удачный выбор для образования в целом, неплохой инструмент и в типовых задачах. Вот так, по убыванию от "эксклюзива" к уровню "не хуже, чем другие".
    Сфера применения ФП, по Вашим словам, выходит неограниченной и безграничной. А упорное доказывание, что "ФП и в системном программировании лучше, и операционные системы на нем будем писать" - это уж вообще, извините, ни в какие ворота...


    № 2358   31-03-2007 11:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2356« (VPrin)
    ___________________________
    Спасибо, нашел задачу. Не нашел двухкратно уменьшения кода при использовании Хаскеля по странению с ИЯ о котором говорил Jack Of Shadows.

    Да вы правы. Я ошибся...в пользу оберона :))
    Там более чем 3-х кратное уменьшение кода
    Хаскель: 63 строчки.
    Оберон: 227 строчек.

    Коментарии и пустые строчки убраны.


    № 2357   31-03-2007 10:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2354« (Илья Ермаков)
    ___________________________
    ФП/ДП "чахло" в диапазоне 80-х не от того, что "еще не было гигабайт дешевой памяти", а из-за упадка своей сферы.
    Бездоказательное утверждение. Почему это так ? Непонятно. Почему игнорируется факт проигрывания ФЯ на тогдашнем железе - непонятно. Почему игнорируется факт того что mainstream языки двигались исключительно бизнесом а не наукой, и каково положение языков в научной сфере не имело тут ВООБЩЕ никакого значения ? Непонятно.
    Отвергаются очевидные вещи, лишь бы успокоить себя что ФЯ это химера, а императив не мелкая идея, привязанная к состоянию техники 60-х годов, а нечто на тысячелетия.

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

    Кто определает это чувство меры - непонятно. Казалось бы практика должна определять. Она расставит все по своим местам. Те кто потеряют чувство меры - проиграют, провалят задачу, сгинут со сцены программирования.
    Вот практика и показывает что чем дальше ширитя потенциальное поле применения ФЯ (те самые гигабайты памяти и гигагерцы, да ядра процессоров) тем больше и больше ФЯ применяются в различных сферах бизнеса. То есть самых что ни на есть прикладных, приземленных задачах. Вот пусть они и поплатятся за свою "чрезмерную" и "непрактичную" абстракцию. Ан нет. Впролне успешны эти применения, вполне конкурентноспособны. Настолько конкурентноспособны что вышибают из некогда традиционных сфер императивные языки. Настолько конкурентноспособны, что сами идеи ФП начинают потихоньку просачиваться в mainstream языки, такие как сишарп и java. Настолько жизнеспособны, что все три главные ведущие силы индустрии программирования (не научные а именно бизнес силы), MS, Sun, IBM держат у себя за пазухой команды функциональщиков. Оплачивают их работу.
    Хаскель по существу развивается исключительно на деньги MS.
    Но, о чем это я. Стенания оберонщиков по этому поводу мы уже слышали. Ведь вся эта огромная масса народу, либо тупицы, либо вредители, которые специально все это делают чтобы нас всех обмануть, лапшу повесить, и побольше денег с нас содрать.


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


    Опять, голое и ничем не обоснованное утверждение. ЧЕм выделение памяти ПРИНЦИПИАЛЬНО отличается от ее освобождения ? Почему одно можно запросто автоматизировать а второе - НИ НИ ?
    Может потому что это невозможно физически ? Нет, возможно и уже давно осуществляется.
    Может потому что у Ильи негативный опыт с этим ?
    Нет. Илья, как и все остальные императивщики упорно отказывается иметь вообще какой бы то ни было опыт в этой области, одни суеверия.
    Может потому что есть документированный негативный опят внедрения такого подхода другими людьми, компаниями ?
    Нет, подход относительно новый. И те единичные случаи которые пока есть, только положительны.

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



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

    Ответ на »сообщение 2299« (VPrin)
    ___________________________

    А я кажется пропустил эту задачу. А где на нее можно посмотреть?

    Решение на Хаскелле с ссылками на решение на Компонентном Паскале и собственно условиями задачи .
    Так же в этой теме ранее было показано решение на Дельфах.

    Спасибо, нашел задачу. Не нашел двухкратно уменьшения кода при использовании Хаскеля по странению с ИЯ о котором говорил Jack Of Shadows. Ну все равно это больше академическая задача. Есть более земные задачи, например поиск пути волновым методом на квадратной карте. Лучше б хаскелисты на них показывали крутость хаскеля, к ним бы вопросов о надуманости задач не возникало. Может кто нить из хаскелистов, как Вы там писали "найти на неё время, показать всю мощь их языков" с волновым алгоритмом на хаскеле? :) А интересно стало, а гугл ответа не дал.


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

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

    Эх, непонятно всё-таки, где Вы откопали этот миф, что ФП якобы пригодно только для решения высшематематических задач, но никак не для прикладного программирования. Разве у Вас есть такой негативный опыт? Если есть, так поделитесь им! ;о)
    Ведь есть множество примеров решения и прикладных, и системных задач с помощью различных ФЯ - почему Вы их упорно игнорируете? Выглядит так, как будто у Вас обероновские шоры на глазах... :о))


    № 2354   31-03-2007 04:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2351« (Jack Of Shadows)
    ___________________________
    Ответ на »сообщение 2348« (Илья Ермаков)
    Впереди большие изменения. А вы почему то считаете что мы уже достигли вершины в программировании, и надо останавливаться и оттачивать то что уже есть.
    Как японцы, которые тысячу лет оттачивали искусство боя холодным оружием и довели его до совершенства, в то время как европейцы перешли на огнестрельное.
    Оберон вполне может быть и жемчужина императивного программирования, так же как и катана - жемчужина холодного оружия. Но поезд уехал :) вы господа опоздали лет на 20 с признанием оберона.

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

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

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

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

    Я уже как-то условно делил задачи на вычислительные (нацеленные на получение результата, безотносительно к тому, каким путем к нему пришли) и управляющие (когда ценность имеет именно процесс работы системы, ее "жизнедеятельность"). Если я решаю управляющие задачи, то глупо абстрагироваться от того, от чего предлагаете вы - от синхронного выполнения (понятие "оператор"), от разделяемых данных, распределенного по системе - по модулям, по объектам - состояния (понятие классической, многократно используемой переменной). Глупо - потому что эти аспекты устройства системы как раз-таки в данном случае существенны. Конечно, абстрагироватьс можно - но потом все равно придется эмулировать те же самые понятия, "поверх", чем и занимаются подходы аля "функциональное реактивное программирование". Ну вот просто обязательно нужно абстрагироваться от синхронной дискретной машины, построить чистую функциональную модель, а затем поверх нее смоделировать ту же самую машину - и плевать, что непонятно - зачем, зато можно теорий понастроить и диссертаций понаписать :-)

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


    № 2353   31-03-2007 00:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Про олимпиады

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

    Ибо главная задача олимпиад - выявление светлых голов. Громкими буквами: СВЕТЛЫХ ГОЛОВ, и уж никак не лучших инструментов. И поэтому важно тщательно подобрать задачи и инструменты, чтобы ни один из разрешённых инструментов ни в одной задаче не давал бы преимуществ относительно другого.

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

    И если даже разрешить использование ФЯ на олимпиадах, то боюсь, придётся проводить даже не отдельную олимпиаду по ФЯ, а одну по Лиспу, другую по Схеме, третью по Хаскелю и т.п.


    <<<... | 2372—2363 | 2362—2353 | 2352—2343 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 315


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

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

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

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

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

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