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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 3042—3033 | 3032—3023 | 3022—3013 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 248


    № 3032   02-10-2007 15:48 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3030« (Илья Ермаков)
    ___________________________
    Простите но именно "кукольный театр" вы и получаете. В реальном мире у самолета нет метода "гравитация". Гравитация есть сила внешная по отношению к обьекту самолет. Сила глобальная. Функция, преобразующая данные. Весь мир состоит из громадного количества таких вот ВНЕШНИХ и ВЗАИМОПРОНИКАЮЩИХ связей, а не обьектов у которых все методы обработки акуратно так "пришпилены" к данным.
    Парадигма на которой построена ООП - это игрушечная и неработающая "модель" в которую несчастные программисты вынуждены впихивать реальный мир. Да еще и без права на ошибку. Ведь даже поиграться с несколькими построенными моделями нельзя. На одну (самую первую и по определению неверную) уходит слишком много усилий и времени.
    Короче мы уже об этом говорили.

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


    № 3031   02-10-2007 15:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3030« (Илья Ермаков)
    ___________________________

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

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


    № 3030   02-10-2007 15:27 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3028« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 3027« (Руслан Богатырев)
    ___________________________
    АТД - это декларация типов данных и операций над ними (что есть хорошо). ООП - это упаковка типов данных, методов их обработки, и хранилища состояния в единый обьект (что есть плохо).

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


    № 3029   02-10-2007 15:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3027« (Руслан Богатырев)
    ___________________________
    >>> При всей верности критики излишнего восхваления ООП во имя извлечения прибыли (маркетинговая сторона медали) трудно согласиться с технологическими оценками Армстронга.
    Как будто все дело именно в ООП (маркетинговая сторона)... Можно ООП заменить на ФП - статья совершенно не про это. Так как всегда были, есть и будут люди, готовые создать трудности, чтобы потом героически их решить (за определенное вознаграждение)... И проблема эта общесоциальная, а не только ИТ...



    № 3028   02-10-2007 14:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3027« (Руслан Богатырев)
    ___________________________
    Инкапсуляция суть идея абстрактных типов данных (АТД). До сего дня не утихают споры, что считать типом данных: только набор (однородных) сущностей или еще и набор операций над ними. АТД не стоит путать с ООП.
    А он и не путает.
    АТД - это декларация типов данных и операций над ними (что есть хорошо). ООП - это упаковка типов данных, методов их обработки, и хранилища состояния в единый обьект (что есть плохо). Уберите из этого контейнера состояние - и получите нормальный хаскелевский type classes или эрланговский process.
    О том и речь Руслан. ФП пытается автоматизровать работу с состоянием в то время как ООП считает что достаточно состояние инкапсулировать в обьекты, и программирование станет легче. Практика показывает - не стало легче. Ручная работа она и есть ручная работа, в какую оболочку ее не упаковывай.



    № 3027   02-10-2007 14:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3026« (Jack Of Shadows)
    ___________________________

    Наверное надо именно так нелюбить ОО чтобы создать такой язык как Erlang :))

    При всей верности критики излишнего восхваления ООП во имя извлечения прибыли (маркетинговая сторона медали) трудно согласиться с технологическими оценками Армстронга.

    Особенно занятна фраза: Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.

    Вообще говоря, это и есть инкапсуляция (которую многие смешивают с информационным сокрытием). Инкапсуляция суть идея абстрактных типов данных (АТД). До сего дня не утихают споры, что считать типом данных: только набор (однородных) сущностей или еще и набор операций над ними. АТД не стоит путать с ООП.

    Логика утверждения Армстронга ведет к тому, что объединять можно только представителей одного муравейника. Что является средством объединения сущностей в языках программирования? Структуры (записи), процедуры (функции), классы, модули (кластеры)... В общем-то вся их ценность в том и состоит, что они объединяют именно неоднородные вещи.

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

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


    № 3026   02-10-2007 11:46 Ответить на это сообщение Ответить на это сообщение с цитированием
    Наткнулся на короткую статью от создателя Erlang, Джо Армстронга
    Why OO Sucks: http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
    Наверное надо именно так нелюбить ОО чтобы создать такой язык как Erlang :))


    № 3025   01-10-2007 18:29 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3024« (Сергей Осколков)
    ___________________________
    Это было к тому, что свои собственные предметные области (или область) есть и у программистов, а не только в сферах, внешних по отношению к программированию. Списки м.б. пример неудачный, но взамен могу назвать сетевое программирование, работу с БД, и т.д. и т.д.
    Работа с БД - отличный пример. Никак не могу найти СУБД, строго реализующую реляционное исчисление. Такое впечатление, что разработчики теорию не изучали. Нет, нормальные формы они, конечно, проходили. А вот к чему может привести разрешение незаполненного поля никто не разбирался. Стараясь перещеголять друг друга, вводят все новые механизмы, способные разрушить целостность реляционной модели. И перекладывают ответственность на разработчиков конкретных баз данных и конкретных запросов.
    То же самое с сетями - почитайте вопросы на круглом столе: "никогда раньше с сетями не работал, посоветуйте компоненты...". А советовать нужно книжки по сетям :(
    Имеет предметная область отношение к программированию или не имеет - ее нужно знать.
    Дилетантизм собственно в программировании менее опасен, чем дилетантизм в понимании решаемой задачи.
    Можно сделать коряво, неэффективно, но нельзя сделать НЕ ТО.

    Что касается системного анализа, мне кажется, что здесь важно скорей умение, чем формальные знания, причем умение может быть без наличия формальных знаний о системном анализе.
    Конечно, системный анализ не только наука но и исскуство. В любом исскустве можно найти примеры высоких достижений у самородков. Но в любом исскустве больше возможностей добится хороших результатов у тех, кто изучил соответствующие науки. В Академии Художеств не только пишут картины, вырабатывая навык, но и изучают перспективу, анатомию, свойства красок и т.д. Очень способствует...


    № 3024   01-10-2007 11:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3022« (Сергей Перовский)
    ___________________________
    А это тоже предметные области :)
    Только специфические.

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

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


    № 3023   01-10-2007 10:43 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3021« (torvic)
    ___________________________

    утверждён новый стандарт Scheme R6RS
    http://www.r6rs.org/

    Что-то многие разработчики трансляторов Scheme недовольны новым стандартом - считают его слишком сложным... Некоторые даже предложили альтернативный стандарт ERR5RS
    Основная страница SchemePunks - Панки Схемы... :о))
    Говорят, поддержка R6RS будет у PLT (DrScheme/MzScheme), Scheme 48 и Chez.
    А вот отказались поддерживать: Bigloo, Gambit, Chicken, Stalin, SCM. Stalin, Bigloo, Gambit-C вроде как самые оптимизирующие трансляторы Схемы, MzScheme уступает им...
    Но наверное, пройдёт какое-то время, и им придётся тоже обеспечить совместимость с R6RS?..


    <<<... | 3042—3033 | 3032—3023 | 3022—3013 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 248


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

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

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

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

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

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