Здравствуйте, faulx, Вы писали:

F>В статье был простейший пример. Если сформулировать в общих чертах: ленивые вычисления являются средством повышения модульности. В схеме вроде "producer — consumer" модуль-producer становится более изолированным от модуля-consumer'а, соотвественно, повышается возможность его повторного использования.

Что-то в упор не вижу повышения модульности от этих линивых вычислений.

Здравствуйте, faulx, Вы писали:

F>Я же говорю, в статье есть пример, очень простой, правда. Producer-у не нужно знать, когда прекращать producing данных. Соотвественну, consumer-у не нужно ничего знать о producer-е. В качестве средства коммуникации между ними служит (потенциально) бесконечный список (иногда его называют stream). Откуда он взялся, consumer-у все равно, он возьмет из него только то, что нужно. Producer-у это списка тоже неинтересно, сколько данных генерировать и когда останавливаться.

Ну, и чем это ушучшает модульность по сравнению с тем же энумератором, стримом, системой передачи сообщений и т.п.?

F>Если я не ошибаюсь, в Unix подобным образом работает кострукция program1 | program2.

А в виндовс program1 > program2 и что?

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

Здравствуйте, VladD2, Вы писали:

F>>Если я не ошибаюсь, в Unix подобным образом работает кострукция program1 | program2.

VD>А в виндовс program1 > program2 и что?

И где у тебя тут хотя бы намёк на типизацию?

Здравствуйте, VladD2, Вы писали:

VD>Ну, и чем это ушучшает модульность по сравнению с тем же энумератором, стримом, системой передачи сообщений и т.п.?

Тем, что для абстракции нужны паттерны. У ФЯ паттерны "родные". А ИЯ паттерны пережевывает с большим напрягом. Поэтому простейшее решение задачи в ФЯ будет, как правило, менее завязанным на частности, чем простейшее решение той же задачи на ИЯ.

Здравствуйте, Gaperton, Вы писали:

G>Сильные стороны функционального программирования
Красивая, простая и понятная статья. После ее прочтения у меня остался только один вопрос: А как это применить в жизни?
Дело в том, что автор неявно сужает все программирование к отображению некоторого входа на некоторый выход (http://msdn.microsoft.com/library/en-us/iissdk/iis/ref_prog_iaorefiwi.asp

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:

G>>Сильные стороны функционального программирования
S>Красивая, простая и понятная статья. После ее прочтения у меня остался только один вопрос: А как это применить в жизни?
S>Дело в том, что автор неявно сужает все программирование к отображению некоторого входа на некоторый выход (http://msdn.microsoft.com/library/en-us/iissdk/iis/ref_prog_iaorefiwi.asp

А причём тут IIsWebInfo (ADSI) ???

Здравствуйте, Sinclair, Вы писали:

S>... А как это применить в жизни?
S>Дело в том, что автор неявно сужает все программирование к отображению некоторого входа на некоторый выход (http://msdn.microsoft.com/library/en-us/iissdk/iis/ref_prog_iaorefiwi.asp

Компонентные технологии,создание объектных моделей повышает уровень абстракции в одном аспекте. Но алгоритмическая часть остается довольно низкоуровневой. ФЯ повышает уровень абстракции для алгоритмического аспекта. Программирование это не только построение удобных объектных моделей, но и алгоритмы тоже. Да конфигурирование IIS через ActiveDirectory непростая задача, но алгоритмически она для детей дошкольного возраста.

Вот чтобы легче это все применялось в реальной жизни. Нужно что то наподобии F#. Т.е. пусть бы был для начала какой нибудь даже примитивный функциональный язык, но чтобы очень хорошо интегрировался с программами на других языках. Чтобы алгоритмические куски можно было переносить на него. И хороший оптимизатор. F# вроде двигается в правильном направлении, из любого .NET языка можно обратиться к функциям на F#. И сам F# может дергать функции других языков через делегаты. Только все его никак не доделают этот F#.

Здравствуйте, Курилка, Вы писали:

Ой, прошу прощения. Это у меня Janus взглюкнул. Блин, вся мессага потерялась!

Здравствуйте, Silver_s, Вы писали:

S_> Ну хорошо, возьмем конкретную вычислительную задачу, если ФЯ в них сильны.
S_>Нужно написать функцию. На вход ей подается:
S_>1) координаты прямой на плоскости в виде двух точек (X,Y)
S_>2) флажок указывающий на то что прямую рассматривать как бесконечную, или как отрезок по этим точкам.
S_>3) Координаты прямоугольника.
S_> Нужно подрезать эту прямую (или отрезок если флажок стоит) по границам прямоугольника(все что снаружи него обрезается), и вернуть координаты нового отрезка.

S_>Несмотря на кажущуюся простоту, довольно муторная задача. На ИЯ напишется около 150 строк не очень читабельного кода. Уйдет на это несколько часов.

Да ладно тебе! Есть алгоритм решения этой задачи для одного отрезка/луча/прямой. Сам реализовывал — порядка 30 строчек на С++ (зависит от форматирования, конечно ). Причем количество измерений задается длиной входного вектора координат — читаем Шикина и Борескова по части алгоритмов 3D-графики .

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, faulx, Вы писали:

F>>В статье был простейший пример. Если сформулировать в общих чертах: ленивые вычисления являются средством повышения модульности. В схеме вроде "producer — consumer" модуль-producer становится более изолированным от модуля-consumer'а, соотвественно, повышается возможность его повторного использования.

VD>Что-то в упор не вижу повышения модульности от этих линивых вычислений.

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

Аналогия (все аналогии ущербны, а эту я придумал только что, но все равно приведу ее). Из крана льет вода, если его открыть и не льет, если закрыть. Тебе все равно, откуда в этом кране вода, с какой именно водонапорной башни (или что там у них) она подведена к крану. А теперь представь, что для того, чтобы принять душ, тебе надо набирать телефон водонапорной башни (это аналог итератора) и звонить туда, заказывая нужное количество воды. Ну и в какой схеме выше модульность?

Здравствуйте, Gaperton, Вы писали:
Корявый Janus таки отправил мессагу до того, как я ее написал. Особенно приятно, что он убивает окончательный вариант при следующей синхронизации.
Попробую вкратце написать основную претензию по материалу статьи.
Дело в том, что "Функциональное программирование называется так, потому что программа полностью состоит из функций. Сама программа тоже является функцией, которая получает исходные данные в качестве аргумента, а выходные данные выдаёт как результат."
Замечательно. Когда вы в последний раз видели такую программу? Подсказка: попробуйте перебутиться из linux в современную ОС.
Что является входом Notepad.exe? Что является ее выходом?
В статье рассмотрен пример с игрой. Увы, программа для игры должна не только вычислять оптимальный ход. За кадром осталась собственно программа — то, как она инициализирует позицию, запрашивает ход у игрока, и изменяет текущее состояние позиции. Все верно — ведь это не укладывается в рамки выбранной трактовки термина "программа".
А если мы говорим о Windows приложении? Боюсь, ограничиться только функциями не удастся.

Итого: FP подходит только для небольших частей современных программ. Пока что не видно возможности построения языка общего назначения на основе FP.
Таким образом, FP — вовсе не альтернатива IP. Некоторые черты FP можно и нужно встраивать в языки общего назначения, но они вынуждены оставаться императивными.

Здравствуйте, Sinclair, Вы писали:

S>Что является входом Notepad.exe? Что является ее выходом?
Входом является _состояние_ и _событие_. Состояние — текст в редакторе до события, положение курсора etc. Событие — нажатие кнопки, клик мышки. Результат — следующее _состояние_ — с изменившися текстом, положением курсора и т.д.
В pure функцтональных языках так и делается.
Любой итеративный процесс можно преобразовать... Нет, даже не преобразовать, осмыслить как рекурсивный. И каждое состояние объекта — как значение. В pure функцтональных языках так и делается.

S>Итого: FP подходит только для небольших частей современных программ. Пока что не видно возможности построения языка общего назначения на основе FP.
S>Таким образом, FP — вовсе не альтернатива IP. Некоторые черты FP можно и нужно встраивать в языки общего назначения, но они вынуждены оставаться императивными.

В Ocaml (который является языком общего назначения на основе FP) можно использовать элементы императивности. И можно свести их к минимуму, минимизируя свойственные им проблемы. Конкретно применение императивности (т.е. изменяемых состояний) необходимо... нет, полезно, в двух случаях: интерфейсы и низкоуровневая оптимизация. Не необходио, потому что и интерфейсы можно реализовать функционально (как описано выше), а низкоуровневую оптимизацию выпихнуть в С или ассемблер. Не так уж много ее и надо.

Кстати, императивные фичи в OCaml себя чувствуют гораздо лучше, чем функциональные в ИЯ.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Тем, что для абстракции нужны паттерны. У ФЯ паттерны "родные". А ИЯ паттерны пережевывает с большим напрягом. Поэтому простейшее решение задачи в ФЯ будет, как правило, менее завязанным на частности, чем простейшее решение той же задачи на ИЯ.
Это пока типы данных простые и отношения между ними — тоже. Постройте не расчётную или коммутационную систему — а бухгалтерскую, к примеру — в ФЯ так же патерны потребуются и работать будут с таким же скрипом. Это вам не сортировку крестиком делать.

Здравствуйте, AndreyFedotov, Вы писали:

AF> Это пока типы данных простые и отношения между ними — тоже. Постройте не расчётную или коммутационную систему — а бухгалтерскую, к примеру — в ФЯ так же патерны потребуются и работать будут с таким же скрипом. Это вам не сортировку крестиком делать.

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

Здравствуйте, Larm, Вы писали:

L>Да ладно тебе! Есть алгоритм решения этой задачи для одного отрезка/луча/прямой. Сам реализовывал — порядка 30 строчек на С++ (зависит от форматирования, конечно ). Причем количество измерений задается длиной входного вектора координат — читаем Шикина и Борескова по части алгоритмов 3D-графики .

Ну закинь тогда, если на C++ реализация есть оптимальная, посмотрим, сравним достоинства и недостатки.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Входом является _состояние_ и _событие_. Состояние — текст в редакторе до события, положение курсора etc. Событие — нажатие кнопки, клик мышки. Результат — следующее _состояние_ — с изменившися текстом, положением курсора и т.д.
INT>В pure функцтональных языках так и делается.
Очень интересно. Было бы некисло пронаблюдать хотя бы calc.exe, написанный на FL. К сожалению, реальные приложения гораздо больше похожи на calc.exe, чем на численное интегрирование.

Здравствуйте, Sinclair, Вы писали:

INT>>Входом является _состояние_ и _событие_. Состояние — текст в редакторе до события, положение курсора etc. Событие — нажатие кнопки, клик мышки. Результат — следующее _состояние_ — с изменившися текстом, положением курсора и т.д.
INT>>В pure функцтональных языках так и делается.
S>Очень интересно. Было бы некисло пронаблюдать хотя бы calc.exe, написанный на FL. К сожалению, реальные приложения гораздо больше похожи на calc.exe, чем на численное интегрирование.

sigh... Я ж уже кидал сюда пример кола, написанного на Ocaml с Tcl. Обыкновенный ООП пополам с ФП. На родном верблюжьем сайте caml.inria.org есть файл с примерами. Ну, вот еще примеры оттуда же, если от этого кому-нибудь будет счастье здесь

Главный список либ и программ на камле есть здесь
Списочек, кстати, нехилый весьма и весьма. Вот только бухгальтерских програм, разве что, я там и не нашел

Здравствуйте, INTP_mihoshi, Вы писали:

INT>sigh... Я ж уже кидал сюда пример кола, написанного на Ocaml с Tcl. Обыкновенный ООП пополам с ФП. На родном верблюжьем сайте caml.inria.org есть файл с примерами. Ну, вот еще примеры оттуда же, если от этого кому-нибудь будет счастье здесь
Отлично. Возьмем, например, http://caml.inria.fr/Examples/oc/camltk/addition.ml. Что-то мне подсказывает, что вариант C# будет все-таки попрощще. Что, в общем-то, неудивительно.

Здравствуйте, Sinclair, Вы писали:

S>Отлично. Возьмем, например, http://caml.inria.fr/Examples/oc/camltk/addition.ml. Что-то мне подсказывает, что вариант C# будет все-таки попрощще. Что, в общем-то, неудивительно.

Можешь набросать для сравнения? А то я уже его основательно забыл... Сомневаюсь, что C# выиграет больше нескольких процентов даже на своем родном поле... Даже не уверен, что выиграет вообще.

Счет в целых числах, вывод error, если обе строчки — не целые числа или пустая строка, кнопка Quit, закрывающая приложение.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Здравствуйте, Sinclair, Вы писали:

S>>Отлично. Возьмем, например, http://caml.inria.fr/Examples/oc/camltk/addition.ml. Что-то мне подсказывает, что вариант C# будет все-таки попрощще. Что, в общем-то, неудивительно.

INT>Можешь набросать для сравнения? А то я уже его основательно забыл... Сомневаюсь, что C# выиграет больше нескольких процентов даже на своем родном поле... Даже не уверен, что выиграет вообще.

INT>Счет в целых числах, вывод error, если обе строчки — не целые числа или пустая строка, кнопка Quit, закрывающая приложение.

+ недеюсь разницу между WinForms и Tk тут выяснять не будем