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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2392—2383 | 2382—2373 | 2372—2363 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 313


    № 2382   31-03-2007 17:28 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2374« (Илья Ермаков)
    ___________________________
    Область систем промышленной автоматики - это отнюдь не узенькая, а очень широкая область, актуальная для любого современного промышленного предприятия.
    Yeah, right! Особенно актуальная на сайте delphikingdom.com, cайте прикладников компонентокидателей, основная задача которых - виндовые морды к базам данных клепать. For crying out loud...


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

    Однако Россияне как обычно легких путей не ищут. :))

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


    № 2380   31-03-2007 17:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2374« (Илья Ермаков)
    ___________________________
    Киньте ссылочку, плиз. Это что-то из ряда вон, даже интересно стало :-) Если учитывать известное качество мат. подготовки в американской школе, то я просто не представляю, как им удалось втиснуть туда ФП...


    Ссылка на известный проект http://www.teach-scheme.org/ для школьных учреждений здесь уже не раз приводилась
    Материалом является тоже не раз упоминавшаяся книга http://www.htdp.org/
    Средой является тоже не раз упоминавшаяся http://drscheme.org/

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


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

    Казалось бы практика должна определять. Она расставит все по своим местам.

    Она уже нарасставляла. За такой практикой разгребать авгиевы конюшни предстоит еще не одному поколению программистов.


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

    (Кстати, а куда Руслан Богатырёв пропал? Читал ли он ту мою мессагу?)

    Он, наконец, появился :) Но тут столько всего уже успели наобсуждать, что дай Бог понять, что к чему.


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

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

    У кого-то еще остались вопросы относительно технологического совершенства в отношении ФП? Типичный экстенсивный путь развития. ФЯ как пожиратель ресурсов выгоден мировым производителям железа и монополии Microsoft, чтобы удерживать свои завоеванные высоты и грести деньги.

    Позабавил подсчет строк. Честное слово. В Обероне формально говоря любой модуль записывается в одну строку (с разделителем операторов). Остальное -- на усмотрение программиста. Уж тогда бы операторы считали и пришли бы к выводу, что в Обероне мелкозернистые операторы, а в ФЯ -- крупнозернистые. А это было кому-то неочевидно раньше? И какой из этого вывод?


    № 2376   31-03-2007 16:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2370« (AVC)
    ___________________________

    Я-то полагал, что специфика ФП -- в отсутствии переменных, как они понимаются в ИЯ.
    ...
    Спрашивается: это уже ФП?

    Нет. Требование к отсутствие изменения состояния переменных - это следствие ФП, но никак не его сущность.

    Сущность же функционального программирования - в манипулировании функциями, это-то и отражено в названии этой парадигмы.
    Те самые "навороты" (по мнению Ильи Ермакова) - это и есть сущность ФП. Ну а что бы ФП работало без сбоев, приходится ограничивать изменения состояния, локализовать их в карантинных зонах...
    (Кстати, а куда Руслан Богатырёв пропал? Читал ли он ту мою мессагу?)


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

    Абсолютно непонятно, где Вы видите противоречие с инкапсуляцией - она-то тут причём? С инкапсуляцией (абстрактизацией типов данных: данные + операции над ними) тут всё в порядке.
    Вы имеете в виду сокрытие (hiding) данных? А какие именно замечательные свойства у этого сокрытия есть с точки зрения ФП? ООП и ФП - всё-таки разные вещи. Что для ФП - хорошо, то для ООП - смерть! :о))

    Нет, ну скажите, что такого хорошего в сокрытии данных, не укладывающегося в сокрытие лишних деталей внутри модуля?

    С точки зрения ООП - безопасность, меньше вероятность ошибок от бесконтрольного изменения этих данных.

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

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


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

    Недавно вышедшая книга Романа Душкина на такой учебник тянет?
    Читал, разбирался - после этого, кстати, разочаровался в Хацкеле. Не нравится. Язык с чисто математическим стилем...

    К сожалению, мне эта книга в руки пока ещё не попала...
    На РСДНе была %url[тема об этой книге] http://www.rsdn.ru/Forum/Message.aspx?mid=2235031&all=1 - противоречивые мнения там были. Кто-то жаловался, что она не для средних умов, кто-то был ею вполне доволен. Однако общее мнение было таким - книга для профессиональных функциональщиков, решивших узнать, что такое Хаскелл.
    Возможно поэтому она Вам и не подощла...

    Поищите другие учебники по Хаскеллу (правда они все на инглише), например,
    "Write Yourself a Scheme in 48 Hours. A Haskell Tutorial" By Jonathan Tang
    "Haskell Tutorial for C Programmers" by Eric Etheridge
    Там другой подход - как раз для императивщиков...

    Роман сейчас пишет вторую книгу, которая должна по идее как раз быть в таком духе - с ориентацией на С++-программеров. Обещает описать, в частности, создание GUI-приложений на Хаскелле.
    К сожалению, это больная мозоль у Хаскелла по Виндовсом. Нет дизайнеров форм, вручную приходится делать. Хотя, если пользоваться библиотеками GTK+ и Gtk2hs, то можно использовать дизайнер Glade, правда потом все связи между контроллами и функциями на Хаскелле всй равно вручную прописывать придётся..
    Ну так это же и к лучшему - разделение бизнес-логики и GUI-части!


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

    Что за такие средства, которых почему-то нет в Хаскелле?
    Пресловутая динамическая загрузка-выгрузка модулей с экспортом задом-наперёд, к которым Вы привыкли?
    Другая парадигма, другие решения...

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


    № 2374   31-03-2007 16:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2371« (Geniepro)
    ___________________________

    Ответ на »сообщение 2366« (Илья Ермаков)
    ___________________________
    Ну что ж, тут уже вопрос привычек и приоритетов.
    Вы, похоже, предпочитаете размазывать состояние программы и затем мучиться с багами из-за его бесконтрольного изменения вместо того, что бы мучиться с изменением своего мышления на пути ограничения состояния программы... Если Вас устраивает текущее положение дел - тем лучше для Вас...

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


    Зачем школьникам все эти низкоуровневые сложности профессионального программирования?

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


    У меня лично такого опыта нет, но тут уже неоднократно приводился успешный пример американских учебных заведений, в которых первыми языками были Хаскелл и Scheme.
    Их опыт секретом не является - наоборот, эти преподаватели с восторгом делятся своим опытом... Лично я вполне склонен доверять им.

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



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

    "Не хуже" - была утешительная фраза для Джека. На самом деле все гораздо лучше, уж поверьте моему трехлетнему опыту преподавания спецкурсов в школе и ВУЗе. На первый курс ребята приходят уже с полностью сформировавшимися понятиями в голове, с навыками решения задач и владением инструментом. При этом инструмент на 100% доступен для понимания и не имеет темных углов.


    Жёсткое РВ - это лишь мизерная доля всего ПО.
    Причём, как Вы сами же и признаёте, даже в Оберонах приходится отказываться от сборщика мусора - а значит и терять преимущества Оберонов перед теми же Адой и Модулой-2.

    Уважаемые, что хоть за манера в этой ветке гиперболизировать? Где конкретно я это говорил?
    Перечитайте внимательно - было сказано о трех промышленных ОС ЖРВ на Обероне, в КАЖДОЙ из которых реализован удовлетворяющий требованиям сборщик мусора. Однако я все же заметил, что для некоторых особенно критичных модулей системы можно использовать ручное управление.
    Аду с Модулой противопоставлять Оберонам не надо. Это языки одного семейства и одной идеологии, с немного разным "прицелом", но прекрасно работающие в связке.


    Повторю вопрос, который задал тут на днях Jack Of Shadows, - стоит ли ориентировать язык общего назначения на узенькую облась систем реального времени, в которых даже Оберон не слишком пригоден?

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


    Да ещё заставлять бедных школьников перенапрягать свой бедный моск всеми хитростями и премудростями "грамотного проектирования фабрик объектов на Обероне"?

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


    № 2373   31-03-2007 16:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2372« (Geniepro)
    ___________________________

    Эх, пожалуй, скажу всё, что я об этой книге думаю! :о))

    Это отличная книга - классика! НО! Эта книга не есть истина в последней инстанции!
    Время не стоит на месте, технологии развиваются, меняются и представления об ограничения на применимость ФП...


    Хм... и это... все? ;)
     AVC


    <<<... | 2392—2383 | 2382—2373 | 2372—2363 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 313


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

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

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

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

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

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