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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2862—2853 | 2852—2843 | 2842—2833 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 266


    № 2852   13-04-2007 21:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2850« (AVC)
    ___________________________

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


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

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

    Давайте возьмем другой пример - пианист.
    Он может пройти прекрасную школу, иметь более десяти лет опыта.
    Но он не может основываясь на все свои знания и весь свой опыт, просто взять новую незнакомую партитуру, выйти на сцену и сходу ее забацать.
    Ему требуется тренировка.
    Да, он сможет разобрать эту партитуру за неделю. В тысячи раз быстрее чем любой неподготовленный человек.
    Именно из за своих знаний и опыта по переносу этих знаний на новые ситуации.
    Но никакие знания и никакой опыт не освобождают от необходимости каждую ситуацию изучать заново.
    И у шахматистов то же самое.
    Каким бы чемпионом вы не были, вы не будете выходить на турнир с новым противником полагаясь на "способность ума к обобщению и переносу опыта на новые ситуации."
    Вы соберете все партии этого соперника, будете их изучать, искать его любимые приемы и его слабые места, сотни раз проигрывать партии в том направлении которое обычно он выбирает.
    То есть вы будете ТРЕНИРОВАТЬСЯ, изучать новую ситуацию.
    Да, может быть в тысячи раз быстрее и эффективнее нешахматиста.
    Но тем не менее, изучать новую ситуацию вам придется. Чтобы потом по настоящему сыграть всего один лишь раз.

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

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

    Представьте себе пусть даже самого гениального пианиста, которого заставили открыть ноты незнакомого ему произведения и сразу сыграть на сцене.
    После улюлюканий, ему дадут ту же вешь, играть еще раз завтра и тоже на сцене.
    После 10 провалов, на 11 концерте (за который между прочим как и за все предыдущие денежки уплачены) в конце концов он более менее сыграет вам "версию 10 с сервис паком"

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


    № 2851   13-04-2007 19:55 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2849« (Geniepro)
    ___________________________

    >>>Неужели бильярд труднее реализовать, чем игру типа Квейка?

    Будем считать, что одинаково трудно (в принципе, это задачи примерно одного класса). :)
    Вместо того, чтобы отсылать спрашивающего к 345KB очередного чуда криптографии, вполне можно, IMHO, объяснить принцип на словах.
    Например (это, конечно, мои глупые фантазии) так: основной цикл программы моделирования реализован в виде хвостовой рекурсии, а (измененное) состояние передается между итерациями в качестве аргумента этой рекурсивной функции основного цикла.
    Или, что вероятнее, используется какой-то другой способ.
    Главное, что это вполне можно выразить обычным языком.
     AVC


    № 2850   13-04-2007 19:18 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2845« (Jack Of Shadows)
    ___________________________

    Чемпионы мира это те кто прошел один и тот же путь десятки тысяч раз.
    <...>
    Невозможно грамотно проектировать на незнакомой местности.


    Где-то здесь у нас расхождение.
    Как мне кажется, Вы упускаете из виду способность ума к обобщению и переносу опыта на новые ситуации.
    У Вас же получается, что каждая ситуация абсолютно уникальна, перенос опыта невозможен.
    Но Вы же не станете утверждать, что чемпион мира стал таковым, потому что заранее выучил наизусть все возможные шахматные позиции? (Ведь иначе, по вашей логике, он должен был бы играть не сильнее, чем новичок; ведь каждая ситуация уникальна.)
     AVC


    № 2849   13-04-2007 16:42 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2844« (Илья Ермаков)
    ___________________________

    Представьте себе, что вас не особо заботит, как реализовать ту или иную функцию, а вам приходится решать задачи, как обеспечить их взаимодействие, обмен сообщениями, синхронное управление и т.п. Здесь модульные ИЯ дают мощные конструкции и паттерны. Что дает ФЯ? Вместо модулей - просто пакеты. Вместо взаимодействия и явного управления состоянием технической системы - исключительно композицию функций. Тоска, господа :-)

    Тоска, абсолютнейшая тоска... :о(

    Ну хорошо, возьмём такую программу как игра-3D шутер Quake 3. Скажите, в этой игре есть манипуляции с состояниями? Есть взаимодействия между объектами? Есть события типа столкновений шаров друг с другом или пуль и тел? Синхронное управление?
    Очевидно, что есть. Хорошо.

    Неужели бильярд труднее реализовать, чем игру типа Квейка?

    Теперь в который раз вспомним про игру Frag ...
    Frag - это игра, очень таки походая на Quake 3, причём написана она на Хаскелле с использованием библиотеки Функционально-Реактивного Программирования Yampa .
    Как Вы думаете, Хаскелл всё ещё ничего не может предложить для подобных задач?
    Исходники доступны, и занимают всего 345 кБт...

    Ну ладно, чёрт с ними с Квейками/Фрагами. Всем известный Тетрис, реализованный на Хаскелле

    Библиотеки для генетического программирования на Хаскелле - подойдут для демонстрации изменяемого состояния?

    Тоска, господа :-)


    № 2848   13-04-2007 15:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2847« (Илья Ермаков)
    ___________________________
    Класс - это всего лишь тип данных. Но ни в коем случае не несущий элемент архитектуры.
    Золотые слова!!
    Уже много раз об этом здесь говорилось.
    Бессмысленно ориентировать программирование вокруг какого то конкретного то типа данных.

    Но поднята другая тема.
    Поднята тема проектирования архитектуры, и средств, необходимых для успешного проектирования.
    Я уже говорил что исходя из натуры человеческой мы гарантированно ошибаемся.
    Мы обязанны просто пробовать каждый шаг, вместо того чтобы планировать сделать сразу несколько.
    ФЯ дает нам такую возможность. В ФЯ пробовать легко и быстро.
    А вот как пробовать в ООП ?
    ФЯ дает вам возможность строить кирпичик за кирпичиком снизу вверх, проверяя на прочность и практичность каждый уровень, и строя следующий только после проверки предыдущих.

    ООП требует сначал полностью возвести каркас (иерархию классов, арматуру) а затем уже строить.
    Но строить каркас дорого, трудно, долго. Цена ошибки высока.
    Денег на столь дорогостоящие пробы ни у кого нет.
    Я в программировании с 1992 года. До сих пор ни разу не видел, чтобы построенные ОО каркасы отбрасывались.

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





    № 2847   13-04-2007 15:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2846« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2844« (Илья Ермаков)
    ___________________________
    Большая беда в том, что архитектура и анализ ПрО смешиваются воедино. 

    Этому способствует, да нет, даже поддталкивает к этому, парадигма ООП.

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


    № 2846   13-04-2007 14:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2844« (Илья Ермаков)
    ___________________________

    Большая беда в том, что архитектура и анализ ПрО смешиваются воедино. 

    Этому способствует, да нет, даже поддталкивает к этому, парадигма ООП.

    Проектируя систему, я строю инфраструктуру, на которой смогу
    Вот так прям с ходу строите ? Без экспериментов ? Без проб и ошибок ? Да вы первый человек, который может строить сложную инфраструктуру без проб, сразу с идеи в голове, в воплощение в коде :))
    Я больше таких не видал.

    где ФЯ не предоставляет практически ничего... 
    Говорит человек, пробовавший ФЯ в реальной задаче. Или вы повторяете то что гле то слышали ?

    Здесь модульные ИЯ дают мощные конструкции и паттерны.
    Я понимаю что вам дает ИЯ. Я просто не вижу, где ваша песочница в которой вы можете легко и быстро поиграться с множеством разных идей чтобы отбросить ошибочные и найту ту саму правильную.
    Более того, я даже не вижу что вы ВООБЩЕ это делаете.
    Я знаю что нет человека который бы не ошибался. И чем длиннее цепочка рассуждений без проб, тем дороже цена ошибки, тем больше девиация от правильно подхода.


    № 2845   13-04-2007 14:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2843« (AVC)
    ___________________________
    Вы ссылаетесь на шахматы. Хорошо. Вам известно, что бывают слабые шахматисты, а бывают чемпионы мира. Несовершенны все, но в разной степени. :)


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

    ФЯ позволяет вам проваливать проекты в песочнице, быстро и помногу, в считанные дни и выкатить в production сразу версию 100

    В то время как в ООП, повсеместно проекты выходят в версии 1.0 и потом уже на живых пользователях "доводятся". Долго, мучительно, годами, с огромными затратами. С фантомными багами, кочующими из версии в версию.
    С необходимым "полным переписыванием" каждые несколько лет. Поскольку количество и нагромождение ошибок проектирования становится уже невыносимым.
    Это и есть тот самы метод проб и ошибок. Другого у нас нет.
    Вопрос только в том где вы пробуете и ошибаетесь. Как быстро и легко и дешево, или наоборот медленно, трудно и дорого вы это делаете. Но и в том и в другом случае это один и тот же метод.
    Грамотного проектирования не существует. Есть только нарабатывание опыта и его применение.
    Как программистами так и чемпионами мира по шахматам.


    № 2844   13-04-2007 14:44 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2842« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2841« (Сергей Перовский)
    ___________________________
    А что предлагают апологеты "грамотного проектирования" ?
    Они предполагают что существует набор методик, которые позволят даже не пройдясь по незнакомой территории, только лишь сбором первичной информации, сразу построить весь план пути от начала до конца.

    Джек, Вы немножко не правы...

    Большая беда в том, что архитектура и анализ ПрО смешиваются воедино. Это две ортогональные задачи при разработке ПО. Они решаются в терминах различных конструкций, различных абстракций. Сколь бы ни была замутнена постановка задачи - можно начать выстраивать систему так, чтобы при флуктуациях ее постановки систему перестраивать было гораздо легче. Анализ/решение ПрО и проектирование системы - это связанные, но ортогональные и часто (конструктивно) противоречивые задачи.
    Проектируя систему, я строю инфраструктуру, на которой смогу (или смогут другие) эффективно и быстро построить решение конкретных задач. Но я не завязываюсь на эти конкретные задачи.
    Реализация функционального языка в совокупности со средой - одна из возможных инфраструктур, которую кто-то уже реализовал для вас, господа прикладники.
    Императивные языки позволяют реализовывать и другие инфраструктуры...

    ФЯ - это прекрасно. Если бы я писал алгоритмы и решал прикладные задачи, то я нашел бы там много интересного... Но, увы, в моих задачах мне приходится мыслить в других категориях, где ФЯ не предоставляет практически ничего... Представьте себе, что вас не особо заботит, как реализовать ту или иную функцию, а вам приходится решать задачи, как обеспечить их взаимодействие, обмен сообщениями, синхронное управление и т.п. Здесь модульные ИЯ дают мощные конструкции и паттерны. Что дает ФЯ? Вместо модулей - просто пакеты. Вместо взаимодействия и явного управления состоянием технической системы - исключительно композицию функций. Тоска, господа :-)

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




    № 2843   13-04-2007 14:32 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2840« (Jack Of Shadows)
    ___________________________

    "Грамотное проектирование" это миф, живущий в рекламных слоганах оберонщиков.
    <...>
    Когда люди показывают на примеры "грамотного проектирования"<...>


    Так все-таки грамотное проектирование есть? :)

    >>>Пусть он все это усвоит (ни разу не сев за доску), а потом применит свои недюжинные познания в "грамотном проектировании" игры, и выиграет свою первую в жизни партию сходу.

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


    <<<... | 2862—2853 | 2852—2843 | 2842—2833 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 266


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

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

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

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

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

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