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

Лисп лучше называть метаязыком, языком метапрограммирования - вот главная фишка Лиспа, позволяющая реализовать в нём не только функциональную парадигму, но и любые другие...

Лисп - это наше всё! Как справедливо заметил Джон Маккарти, отец-основатель Лиспа, в ближайшие полвека станут важны программы, которые расширяют самих себя. Оберон тоже за расширение, и не одними только ручонками программистов. Но супротив Лиспа он пигмей: не может взять в толк, что самомодификация кода - это благо, а не мифическая опасность.

В мае 1961 г. Маккарти писал ("A Basis for a Mathematical Theory of Computation") относительно главного направления - разработки универсального языка программирования: We believe that this goal has been written off prematurely by a number of people. Our opinion of the present situation is that ALGOL is on the right track but mainly lacks the ability to describe different kinds of data, that COBOL is a step up a blind alley on account of its orientation towards English which is not well suited to the formal description of procedures, and that UNCOL is an exercise in group wishful thinking. Т.е. Алгол (читай, Оберон) - то, что надо.

Причем это спустя год после публикации в Communications of the ACM своей главной работы по Лиспу: Recursive Functions of Symbolic Expressions and Their Computation by Machine. Part 1 (часть 2 так и не была написана) и два года спустя после первой реализации Лиспа. Видать, недооценил перспектив своего детища. А зря. Язык науниверсальнейший и наинепобедимейший!

P.S. Где хранится "смерть Кащея", Маккарти сознался еще в 1978 г. (History of LISP): LISP will become obsolete when someone makes a more comprehensive language that dominates LISP practically and also gives a clear mathematical semantics to a more comprehensive set of features.

Ответ на »сообщение 1961« (Jack Of Shadows)
___________________________
>>>Who the hell is Wirth ? Истина в последней инстанции ?
Jack? не надо кидаться в эту свару :)
Я привел мнение Вирта в ответ на реплику, что он не включил функциональные возможности в Оберон по недосмотру. Я хотел только сказать, что он сделал это сознательно.
Каждый имеет право не разделять его мнение.

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

Ответ на »сообщение 1978« (Илья Ермаков)
___________________________

Извините, но я не понимаю, почему Вы считаете, что подобные задачи нельзя эффективно решать с помощью функциональных языков?

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

Операционные системы? Ну по крайней мере одна ОС на Хаскелле таки существует - House.
Хотя, конечно, она является всего лишь демонстрацией того, что это возможно. С ОС Oberon или BlueBottle её не сравнить...
Речь не о библиотеках доступа к БД, а о самой реализации СУБД. Язык запросов к СУБД как раз-таки имеет смысл делать декларативным. Реализовывать СУБД... Не знаю, не знаю, системное программирование на ФЯ как-то противоестественно. "Можно" это еще не значит "нужно". Выражать логику состояний и архитектурные решения на языке математических "чистых" функций для моего мышления неприемлемо.

Опять же, при взгляде на примеры "как это красиво смотрится на ФЯ" иногда не покидает мысль: да, но пойди ты пойми, что в этой строчке записано... Тут pepper пытался все приводить какой-то пример с map, но, извините, эта строчка настолько связана со своим контекстом - стандартными определениями, механизмами интерпретации, - что для непосвященного совершенно не понятна.
Кроме того, чтобы выразить требуемое соотношение функционально и в "одну строчку" нужно иногда так вывернуть мозги, что не проще ли написать обычный алгоритм, пусть он и будет на десяток строк длиннее?

Вон в соседней ветке Jack Of Shadows утверждал, что "надо учить школьников ФЯ". Не надо. Чтобы понять ФЯ, нужна не слабая предварительная (в частности, математическая) база. Покажите хоть одну книжку по ФЯ, которая не начиналась бы с элементов теории вычислений, лямбда-исчисления и т.п. И правильно - с этого и надо начинать, потому что это основа ФЯ. Но только вот не для школьников это явно...

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

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

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

А если подняться по ступенькам абстрагирования еще выше и убрать из ФП функции, то это будет почти то же, что Оберон на фоне C++. И как на таком "инвалиде" программировать? :)

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

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

Первые две парадигмы опираются на понятие состояния (state). Исполнение программного кода (включая квазипараллельные, параллельные и асинхронные ветви) рассматривается как последовательность преобразований состояний (state transformations). Централизация состояний и/или преобразований состояний (ИП) и их децентрализация/локализация (ООП) есть линия водораздела между этими парадигмами. Их можно назвать “дискретными” парадигмами. Вирт идет дальше и утверждает, что ООП принципиально от ИП не отличается. Т.е. это не что-то новое, а просто старое, облаченное в новые идеологические одежды. Сам по себе проект Oberon и есть демонстрация этого смелого, революционного тезиса.

Последующие две парадигмы (ФП и ЛП) в явном виде понятие состояния не отражают. Поскольку языки, воплощающие эти парадигмы, работают на фон-неймановской архитектуре, то так или иначе им приходится устанавливать соответствие между языком (где нет состояний) и железом (где на них все построено). В этом смысле по уровню абстракции они приподнимаются над “дискретными” парадигмами, превращаясь в “непрерывные”. За такую высокоуровневость приходится платить: как эффективностью реализации, так и опосредованным (“трюковым”) введением понятия состояния. Вирт называет это странной (odd) и даже плохой (bad) идеей.

Нет, каков этот Вирт “наглец”! Мало того, что унизил красивое и перспективное ФП, так еще и поднял руку на великое и могучее ООП. :)

Причем в первоначальном варианте статьи Вирт еще больше опустил ФП. А еще он называл его “земляным червяком”. :)  Между авторской и опубликованной версией есть интересное расхождение в разделе, посвященном ФП: в результате усушки/утруски пропал небольшой абзац:
Are functional languages thus a category of their own merely due to terminology? Are their functions functions by form only, but not by substance? Or is the substance of the functional paradigm expressed by simply saying: “No side-effects”? Если по-простому, без затей: Так функции в ФП функции только по форме, но не по содержанию? Или содержание ФП просто формулируется словами “без побочных эффектов”?

Если почитать соседнюю ветку по функциональным языкам, то проникаешься следующей мыслью: Прошли те дремучие времена, когда функциональные языки были “тормозом” из-за недоразвитости железа. Но грядут иные времена, когда железо дозреет (и даже уже кое-где дозрело!) до ФП. Работая на ФП, вы идете к светлым горизонтам будущего. Занимаясь ИП и ООП, вы погружаетесь в мрачную пучину прошлого. Неужели вы еще стоите перед выбором? Да? Тогда мы летим к вам! :)

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

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

Наверное, они просто не читают Вирта?.. 8-о

Статья Вирта была опубликована в IEEE Computer. Для справки: это центральное издание ассоциации IEEE, которое получают все члены IEEE и которое для ИТ-специалистов почти столь же обязательное к прочтению, как когда-то газета "Правда". :)

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

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

Понимаю.
Я недавно пытался осилить Рефал - не смог. Не потому что он сложен, вовсе нет.
Просто я не смог понять, для чего сейчас, в современное время нужна эта эзотерика?

Конечно, для тех времён - 60-е годы прошлого века (подумать только, мои родители ещё в школу ходили) Рефал был очень хорошей попыткой, которая, как и функциональные языки, упёрлась в ограничения тех давнишних компьютеров...

Из функциональных языков Вы, как я понимаю, пользовались Лиспом?
Лисп лучше называть метаязыком, языком метапрограммирования - вот главная фишка Лиспа, позволяющая реализовать в нём не только функциональную парадигму, но и любые другие...
Лисп не более ФЯ, чем ООЯ...

Современные ФЯ всё таки далеко ушли от тех времён, когда на счету был каждый байт и каждый герц...

Ответ на »сообщение 1978« (Илья Ермаков)
___________________________

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

Вообще-то, если хорошенько подумать, то функциональная парадигма вовсе не отрицает состояние и его смены.

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

Это можно рассматривать как развитие идеи модульного программирования.


любое системное ПО - ОС, СУБД etc. - это задачи на управление

Извините, но я не понимаю, почему Вы считаете, что подобные задачи нельзя эффективно решать с помощью функциональных языков?

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

Операционные системы? Ну по крайней мере одна ОС на Хаскелле таки существует - House.
Хотя, конечно, она является всего лишь демонстрацией того, что это возможно. С ОС Oberon или BlueBottle её не сравнить...

Ответ на »сообщение 1978« (Илья Ермаков)
___________________________

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

В ФП есть ответвление - FRP, Функциональное Реактивное Программирование (ФРП).
Развивается оно в том числе и в рамках таких чистых ФЯ, как Haskell, Clean, т.е. без оговорок на то, что мир императивен и нужно включать для этого императвное программирование.

Позвольте маленькие выдержки из статьи о FRP:

"Arrows, Robots, and Functional Reactive Programming"
Paul Hudak, Antony Courtney, Henrik Nilsson, and John Peterson

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

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

(извиняюсь за кривой перевод, вот оригинальный текст:

Functional reactive programming, or FRP, is a paradigm for programming hybrid systems -- i.e., systems containing a combination of both continuous and discrete components -- in a high-level, declarative way. The key ideas in FRP are its notions of continuous, time-varying values, and time-ordered sequences of discrete events.
)

Авторы этой статьи отвечают на такие вопросы:

Могут ли функциональные языки использоваться в реальном мире, а конкретно в системах реального времени? Говоря точнее, может ли выгодно использована в таких системах выразительность функциональных языков, и могут ли вопросы производительности преодолены хотя бы в самых общих приложениях?

Can functional languages be used in the real world, and in particular for real-time systems? More specifically, can the expressiveness of functional languages be used advantageously in such systems, and can performance issues be overcome at least for the most common applications?

В качестве идеального примера гибридных систем они приводят мобильные роботы, реально использующиеся в промышленности. Мобильные роботы имеют такие непрерывные компоненты, как электродвигатели, батареи, дальномеры, и такие дискретные компоненты, как микропроцессоры, бамперные переключатели (bumper switches) и цифровую связь.


"Functional Reactive Programming from First Principles"
Zhanyong Wan, Paul Hudak

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

Статьи эти, правда, довольно специфические и требуют знания языка Хаскелл.
Впрочем, FRP реализуется и в других языках - Clean, Scheme...

ЗЫ. Может быть FRP и не даёт больших преимуществ по сравнению с низкоуровневыми языками, традиционно использующимися в системах управления (С, С++, ассемблер...), но тем не менее вполне возможно создавать такие системы с использованием функционального программирования и глупостью это никак не является...

Ответ на »сообщение 1986« (Антон Григорьев)
___________________________

Господа оберонщики, тут для вас вопрос: http://www.delphikingdom.com/asp/answer.asp?IDAnswer=48559

Не должно компилироваться.
У меня, например, не компилируется.
WinApi.SendMessageA есть процедура-функция, возвращающая WinApi.LRESULT.

И еще.
Я видел в сети фото Клеменса Шиперски (Clemens Szyperski),
одного из "идеологов" компонентного программирования и "отцов" Компонентного Паскаля.
http://research.microsoft.com/~cszypers/
Может, конечно, старая фотография, но есть подозрение, что это еще не старый человек. Во всяком случае не старше Эрвина Шредингера и Вернера Гейзенберга в соответствующее время :)