Ответ на »сообщение 1997« (Сергей Перовский)
___________________________

Почему "Дискретные" и “непрерывные”? С этими терминами у меня совсем другие ассоциации. Чем функция непрерывнее алгоритма?

"Дискретные", поскольку они опираются на понятие состояния и на трансформацию состояний. В этом-то и "дискретность". Надо сделать шаг, постоять, подумать, потом еще шаг... А для ФП и ЛП - не тормози, сникерсни!

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

А в чем, собственно проблемы? Зачем же решать задачу в лоб? Если состояние присуще задаче, то можно построить для нее модель-"прослойку", которую реализовать через любой ЯП, функциональный или какой иной.

ООП можно реализовать на не объектных языках

Оберон-1, с Вашей точки зрения, объектный язык и почему?

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

А не трудно ли будет привести примеры "фанатичных языков" из тех, что обсуждались в этой ветке в последнюю неделю?

Ответ на »сообщение 1995« (Сергей Перовский)
___________________________

Я привел мнение Вирта в ответ на реплику, что он не включил функциональные возможности в Оберон по недосмотру. Я хотел только сказать, что он сделал это сознательно.

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

Элементы ФП в Обероне смотрелись бы чуждо.
Ориентированность на изменение состояния глобальных переменных (пусть даже и локализованных в модулях) - side-effects - делает бессмысленными попытки совместить ФП и Оберон...
___________________________

Хотя, такой важный элемент ФП, как функции высшего порядка, всё таки можно реализовать.
Но функции в нём не являются полноценными объектами первого класса (first-class).
Та же самая функция map, например, может выглядеть так:

MODULE MapTest;
IMPORT S:=StdLog, Strings;

TYPE
  Element    = INTEGER;
  Element2  = POINTER TO ARRAY OF CHAR;
  Container  = POINTER TO ARRAY OF Element;
  Container2 = POINTER TO ARRAY OF Element2;
  Func      = PROCEDURE (el : Element) : Element;
  Func2      = PROCEDURE (el : Element) : Element2;

PROCEDURE map (f : Func; c : Container) : Container;
  VAR
    i : INTEGER;
    res : Container;
BEGIN
  NEW (res, LEN (c));
  FOR i := 0 TO LEN (res) - 1 DO
    res [i] := f (c[i]);
  END;
  RETURN res;
END map;

PROCEDURE map2 (f : Func2; c : Container) : Container2;
  VAR
    i : INTEGER;
    res : Container2;
BEGIN
  NEW (res, LEN (c));
  FOR i := 0 TO LEN (res) - 1 DO
    res [i] := f (c[i]);
  END;
  RETURN res;
END map2;

PROCEDURE inc (x : Element) : Element;
BEGIN
  RETURN x + 1;
END inc;

PROCEDURE show (x : Element) : Element2;
  VAR
    res : Element2;
BEGIN
  NEW (res, 10);
  Strings.IntToString (x, res);
  RETURN res;
END show;

PROCEDURE Do*;
  VAR
    arr, arr1 : Container;
    arr2 : Container2;
    i : INTEGER;

  PROCEDURE dec (x : Element) : Element;
  BEGIN
    RETURN x - 1;
  END dec;
BEGIN
  NEW(arr, 10);
  FOR i := 1 TO LEN (arr) - 1 DO arr [i] := i; END;

  FOR i := 1 TO LEN (arr) - 1 DO S.Int (arr [i]); END; S.Ln;

  arr1 := map (inc, arr);

  FOR i := 1 TO LEN (arr1) - 1 DO S.Int (arr1 [i]); END; S.Ln;

  arr2 := map2 (show, arr);

  FOR i := 1 TO LEN (arr2) - 1 DO S.String (arr2 [i]); END; S.Ln;
END Do;

END MapTest.

Но мы тут сталкиваемся с такой кучей ограничений, что смысла в таком неуниверсальном варианте функции map не видно...

Мы тут ограничены жёстким типом контейнера - вот пример неполноценного ООП в Обероне!
Разные экземпляры типа Container не могут иметь элементы разных типов, и даже метапрограммирование (имейся оно в Обероне) нам не помогло бы...

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

Да и функция, передаваемая в map, почему-то должна иметь уровень 0 (procedure must have level 0, т.е. должна быть глобальной?), так что inc мы можем передать ей, а dec - уже нельзя...

В данном примере map2 почти полностью дублирует map - копипастингом заниматься приходится. Несерьёзно как-то...

Есть ли какие-то способы преодолеть эти ограничения и как-то повысить уровень программ на Обероне?

Ответ на »сообщение 2001« (Jack Of Shadows)
___________________________

На чистом функциональном языке Erlang (повторяю ЧИСТОМ) написаны огромные ОС реального времени с надежностью недостижимой ни для одного императивного языка.

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

На Ерланге написана великолепная СУБД Mnesia на которой работают огромные просто приложения с сотнями миллионов пользователей (телефоны, телефоны).

Любой подобный пример демонстрирует потенциальную возможность использования ФП в данной области, но не эффективность ее применения в конкретных условиях и, тем более, не выигрыш по отношению к другим подходам. Думаю, success stories надо оставить маркетологам.

Ответ на »сообщение 2001« (Jack Of Shadows)
___________________________

ОС говорите ? На чистом функциональном языке Erlang (повторяю ЧИСТОМ) написаны огромные ОС реального времени с надежностью недостижимой ни для одного императивного языка.

100% на Эрланге?

Ответ на »сообщение 1978« (Илья Ермаков)
___________________________
Однако вот ведь какое дело - постоянно поглядывая на ФП и почитывая что-либо по этой теме, применения этим языкам в моей практике не находится и вряд ли найдется.
Да совершенно забыл. Для тех  императивщиков кто не понимает каким боком прикрутить ФП к задачам с манипулированием состояния - предалагаю вашему вниманию прекрасную книгу.
Purely Functional Data Structures. Chris Okasaki http://www.amazon.com/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504/ref=pd_rhf_p_2/102-3245296-8540908

В emule находится с полпинка.
Требует знания английского и какого нибудь ФЯ (желательно хаскель или языков семейства ML)

Ответ на »сообщение 1978« (Илья Ермаков)
___________________________
И задач на управление - огромное количество - любое системное ПО - ОС, СУБД etc. - это задачи на управление, и решать их с помощью ФП по меньшей мере глупо.
ОС говорите ? На чистом функциональном языке Erlang (повторяю ЧИСТОМ) написаны огромные ОС реального времени с надежностью недостижимой ни для одного императивного языка.
На хаскеле тоже написана игрушечная ос для писюков. С графикой, GUI, мышкой. Написна одним человеком.
То есть посади туда армию из MS и дай им 6-7 лет (солько они писали Vista) и от вашей "по меньшей мере глупо" не останется и следа.

СУБД говорите ? На Ерланге написана великолепная СУБД Mnesia на которой работают огромные просто приложения с сотнями миллионов пользователей (телефоны, телефоны) Все это в реальном времени.

То что вы просто НЕ ПРЕДСТАВЛЯЕТЕ СЕБЕ каким боком использовать ФП в этих задачах, говорит лишь о школе программирование забитой за долгие годы в вашу голову. Так же как и старикан всю жизнь проработавший на коболе, не понимает на кой черт все эти обьекты и как они взаимодействуют.

Кстати общаетесь с СУБД вы тоже на ФЯ (SQL) :))

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

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

Просто я не смог понять, для чего сейчас, в современное время нужна эта эзотерика?

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

Вы хотя бы можете сравнить...
А для меня это пока просто абсурд какой-то. :(

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

Просто я не смог понять, для чего сейчас, в современное время нужна эта эзотерика?

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

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

Для системщика абстрагироваться от состояния и алгоритма как перехода состояний - это абстрагироваться от основных элементов своего мышления.

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

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

Снегурочка очень красиво расписала четыре парадигмы, у меня вопрос только по терминологии. Почему "Дискретные" и “непрерывные”? С этими терминами у меня совсем другие ассоциации. Чем функция непрерывнее алгоритма?

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

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

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

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