Про неуклюжесть функционального программирования - Декларативное программирование

Вот в этой статье рассматривается сабж. Безусловно эта "неуклюжесть" появляется часто в репликах оппонентов ФП, только вот большей частью она является сдествием исходного императивного мышления, когда уже есть наработанные привычки рассмотрения алгоритмики и довольно трудо "разорвать шаблон" и посмотреть на проблему несколько иначе. Другой момент против ФП — чистые функции, порой работающие с большимини или бесконечными структурами, причём передавая их из вызова в вызов, тогда как в императивном программировании легко и привычно воспользоваться деструктивными изменениями. Говорится, что Gerard Huet предлагает структуру данных Zipper для решения данных проблем. Работа эта у меня одна из первых в списке для прочтения и загодя есть вопрос — а насколько общим является данный подход?

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

К>Работа эта у меня одна из первых в списке для прочтения и загодя есть вопрос — а насколько общим является данный подход?

В Haskell намного

Другой выход — писать структуру на IO, т.е. тот же императивный подход, а это коробит.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

К>>Работа эта у меня одна из первых в списке для прочтения и загодя есть вопрос — а насколько общим является данный подход?

L>В Haskell намного

Другой выход — писать структуру на IO, т.е. тот же императивный подход, а это коробит.

Тот же императивный как на ИЯ? Зиппер, он как я понимаю функциональный?
Не, точно надо прочитать про него

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

L>>В Haskell намного

Другой выход — писать структуру на IO, т.е. тот же императивный подход, а это коробит.

К>Тот же императивный как на ИЯ? Зиппер, он как я понимаю функциональный?
К>Не, точно надо прочитать про него

Ага, на оба вопроса

Почитай, после него становится видно, чем функциональные структуры отличаются.
У Кирпичева судя по слайдам замечательный доклад, можно полистать их, ну и Хуета тоже, разумеется, надо

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>У Кирпичева судя по слайдам замечательный доклад, можно полистать их, ну и Хуета тоже, разумеется, надо

L>Потом можно и Окасаки, хотя у меня он раньше был почему то.

Поглядим обязательно, а окасаки, помнится, меня напугал в своё время, правда это было пару лет назад если не больше, может уже пойдёт гораздо проще

P.S. оффтопочный вопрос — а ты в каком редакторе хаскель юзаешь? А то я емакс добороть до полной юзабилити не могу

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

К>Поглядим обязательно, а окасаки, помнится, меня напугал в своё время, правда это было пару лет назад если не больше, может уже пойдёт гораздо проще

К>P.S. оффтопочный вопрос — а ты в каком редакторе хаскель юзаешь? А то я емакс добороть до полной юзабилити не могу

Пока на виндах сидел в емакс, иногда FAR+Colorer, сейчас больше vim.
А с емаксом что не получилось? Там haskell-mode ставишь и можно ещё HaRe, если рефакторить будешь.
В haskell-mode есть связка с GHCi (C-c C-s, C-c C-b, C-c C-r). Подрубаешь что надо, вот мой кусок:

(load "~/lib/emacs/haskell-mode/haskell-site-file")

(add-hook 'haskell-mode-hook 'turn-on-haskell-doc-mode)
(add-hook 'haskell-mode-hook 'turn-on-haskell-indent)
(add-hook 'haskell-mode-hook 'font-lock-mode)
(add-hook 'haskell-mode-hook 'turn-on-haskell-ghci)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>... ну и Хуета тоже, разумеется, надо

Напомнило мне рассказ директора этнографического музея в Велье, в Псковской области. Окрестные речки испокон веков имеют простые русские названия — Гавнюха, Сучья. Но картографы — народ подневольно политкорректный, поэтому на картах они называются Гавьюха и, кажется, Сучня.

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

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

К>>Поглядим обязательно, а окасаки, помнится, меня напугал в своё время, правда это было пару лет назад если не больше, может уже пойдёт гораздо проще

К>>P.S. оффтопочный вопрос — а ты в каком редакторе хаскель юзаешь? А то я емакс добороть до полной юзабилити не могу

L>Пока на виндах сидел в емакс, иногда FAR+Colorer, сейчас больше vim.
L>А с емаксом что не получилось? Там haskell-mode ставишь и можно ещё HaRe, если рефакторить будешь.
L>В haskell-mode есть связка с GHCi (C-c C-s, C-c C-b, C-c C-r). Подрубаешь что надо, вот мой кусок:
[cut]
Есть, только она как-то "сбоку ставится" и комбинации клавиш и меню стандартные в хагс лезть пытаются (C-c C-z вроде точно), что как минимум раздражает.
Дома попробую ещё раз посмотреть, может всёж я что-то недопёр когда разбирался с ним.
А чем тебя вим купил?
И среди хаскелистов что популярней он или емакс?
Ещё есть ну совсем левый вопрос — а ты вроде тоже по работе явист, на ней ты хаскель юзаешь?

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

К>А чем тебя вим купил?

Да ничем, мне как то емакс больше по душе, просто настроить всё недосуг.
vim отторжения не вызывает, вот и работаю пока на нём.

К>И среди хаскелистов что популярней он или емакс?

ХЗ Я как то делал опрос на ру_лямбде, так там поровну вроде как.

К>Ещё есть ну совсем левый вопрос — а ты вроде тоже по работе явист, на ней ты хаскель юзаешь?

на ней = на работе? Хаскель, увы, только для прототипирования, например, алгоритмов. Получается быстро.
Правда, удаётся применять схему.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Правда, удаётся применять схему.

Которую?
Удобно?
Может пост напишешь хоть короткий?

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

L>>Правда, удаётся применять схему.

К>Которую?

Которая Лисп. Поскольку для Явы, то я брал каву.

К>Удобно?

Ну да

К>Может пост напишешь хоть короткий?

Да нечего писать в общем, был у нас переход с одной нашей системы версии на другую, я писал миграцию данных. В обоих версиях структура данных очень отличалась и не просто там дополнительные поля, а другие более близкие к предметной области виды связей, сущности были представлены группой или наоборот и т.д. Так вот на схеме я описал DSL для описания подобных вещей, он у меня занял вроде как сотню-другую строчек, может меньше, не считал. И на нём уже очень удобно описывались эти переходы. Это было самым значимым (может потому что первым) применением. В других случаях я использую схему как генератор кода/ресурсных всяких файлов, либо маленький скриптовый язык, но в качестве последнего, мне кажется он не очень удобен, мне жаваскрипт больше по душе в этом смысле.

А про пост ты прав, давно я ничего не писал

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Да нечего писать в общем, был у нас переход с одной нашей системы версии на другую, я писал миграцию данных. В обоих версиях структура данных очень отличалась и не просто там дополнительные поля, а другие более близкие к предметной области виды связей, сущности были представлены группой или наоборот и т.д. Так вот на схеме я описал DSL для описания подобных вещей, он у меня занял вроде как сотню-другую строчек, может меньше, не считал. И на нём уже очень удобно описывались эти переходы. Это было самым значимым (может потому что первым) применением. В других случаях я использую схему как генератор кода/ресурсных всяких файлов, либо маленький скриптовый язык, но в качестве последнего, мне кажется он не очень удобен, мне жаваскрипт больше по душе в этом смысле.

А статически типизированные функциональные не нашли применения? Какие-нибудь CAL, Scala, Jaskell?
Я вот всё думаю куда здесь можно было бы приткнуть что-либо подобное с пользой, пока чтот идей нема

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

К>А статически типизированные функциональные не нашли применения? Какие-нибудь CAL, Scala, Jaskell?
К>Я вот всё думаю куда здесь можно было бы приткнуть что-либо подобное с пользой, пока чтот идей нема

CAL я только смотрел, не применял, надо попробовать, джаскель находил только какой то сырой.
Очень сильно пробовал скалу, когда писал прототип одного приложения, не пошло — там были завязки на некий фреймворк, для которого скаловские классы ну совсем не подходили, нужны были тупые бины, листы/мапы и т.д.
Ещё по мелочи были какие то проблемы, к сожалению, сейчас не вспомню, но отказался именно из-за того, что интерфейсы не срастались, проще было писать на Яве. Отказался с огорчением, язык очень хороший и для чего нибудь другого вполне бы подошёл.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Хуета тоже, разумеется, надо

Я даже не знаю что делать. Вроде и банить за мат нельзя и мат в общем то. Хочу только напомнить анегдот в котором Петька переводил фамилию Блюхера

. Так вот такие фамилии точно лучше не склонять.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Так вот такие фамилии точно лучше не склонять.

Ой, я надеюсь, что таких фамилий больше не будет

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

L>>Хуета тоже, разумеется, надо

VD>Я даже не знаю что делать. Вроде и банить за мат нельзя и мат в общем то. Хочу только напомнить анегдот в котором Петька переводил фамилию Блюхера

. Так вот такие фамилии точно лучше не склонять.

Могу предположить, что в русский этот автор попал бы как Гует. Во избежание

К>Поглядим обязательно, а окасаки, помнится, меня напугал в своё время, правда это было пару лет назад если не больше, может уже пойдёт гораздо проще

Если уж использовать этот реликт, то лучше хемакс, чем емакс. С помощью настроек, которые я нашел на каком-то сайте (не помню каком, но могу посмотреть если нужно) я смог довести этот осколок эпохи до более-менее человеческого состояния. Стандартная win-раскладка (вырезка ctrl x, вставка ctrl v, копирование ctrl c, отмена ctrl z, удаление выделенного по del, открытие файла по ctrl o, поиск по ctrl f и т д). Также там есть история открытия файлов и пр.

Вот мои конфиги если интересно.

;; init.el — the XEmacs configuration file. This will load some other files
;; from the .xemacs directory. Starting with version XEmacs 21.4, one
;; can use the file .xemacs/init.el as a start-up file instead of init.el

; Saves a history of files opened previously (including other times XEmacs was used — very useful)
(require `savehist)
(setq savehist-file "~/.xemacs/history")
(setq savehist-length 1000)
(savehist-load)

; Saves the position the cursor was in a file before the file was closed.
(load-library "saveplace")
(setq save-place-file "~/.xemacs/places")
(setq shadow-todo-file "~/.xemacs/shadow-todo")

(load-file "~/.xemacs/cua-mode.el") ; load cua-mode every time XEmacs is started
(CUA-mode 1) ; run cua-mode (a package to enable MS Windows type keyboard shortcuts)

(load-library "pc-select") ; a package which enables text selection ...
(pc-select-mode) ; ... with the shift and arrow keys

(load-file "~/.xemacs/my-shortcuts.el") ; will load this file every time XEmacs is started

(load-file "~/.xemacs/my-toolbar.el"); load the toolbar

(require 'font-lock) ; enable syntax highlighting

Чтобы это работало, нужно устанвоить пакеты cua-mode и mas-file-history — там всего два файла надо скопировать в директорию хемакса
c:\.xemacs\cua-mode.el
c:\.xemacs\mas-file-history.el.

Также советую установить ecb — emacs code browser, там удобно список функций отображается если установлен haskell-mode

Ссылки на пакеты могу привести, если интересно.

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

К>>Поглядим обязательно, а окасаки, помнится, меня напугал в своё время, правда это было пару лет назад если не больше, может уже пойдёт гораздо проще

LP>Если уж использовать этот реликт, то лучше хемакс, чем емакс. С помощью настроек, которые я нашел на каком-то сайте (не помню каком, но могу посмотреть если нужно) я смог довести этот осколок эпохи до более-менее человеческого состояния. Стандартная win-раскладка (вырезка ctrl x, вставка ctrl v, копирование ctrl c, отмена ctrl z, удаление выделенного по del, открытие файла по ctrl o, поиск по ctrl f и т д). Также там есть история открытия файлов и пр.

Не знаю, меня стандартные комбинации удовлетворяют, а чем xemacs интереснее?

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

LP>Если уж использовать этот реликт, то лучше хемакс, чем емакс.

Чем лучше?

LP>С помощью настроек, которые я нашел на каком-то сайте (не помню каком, но могу посмотреть если нужно) я смог довести этот осколок эпохи до более-менее человеческого состояния. Стандартная win-раскладка (вырезка ctrl x, вставка ctrl v, копирование ctrl c, отмена ctrl z, удаление выделенного по del, открытие файла по ctrl o, поиск по ctrl f и т д). Также там есть история открытия файлов и пр.

Зачем??? Зачем ты испоганил emacs???

LP>Также советую установить ecb — emacs code browser, там удобно список функций отображается если установлен haskell-mode

+1

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

К>>>Поглядим обязательно, а окасаки, помнится, меня напугал в своё время, правда это было пару лет назад если не больше, может уже пойдёт гораздо проще

К>>>P.S. оффтопочный вопрос — а ты в каком редакторе хаскель юзаешь? А то я емакс добороть до полной юзабилити не могу

LP>>Если уж использовать этот реликт, то лучше хемакс, чем емакс. С помощью настроек, которые я нашел на каком-то сайте (не помню каком, но могу посмотреть если нужно) я смог довести этот осколок эпохи до более-менее человеческого состояния. Стандартная win-раскладка (вырезка ctrl x, вставка ctrl v, копирование ctrl c, отмена ctrl z, удаление выделенного по del, открытие файла по ctrl o, поиск по ctrl f и т д). Также там есть история открытия файлов и пр.

К>Не знаю, меня стандартные комбинации удовлетворяют, а чем xemacs интереснее?

Тем, что дефолтные настрофки ближе к виндовым манерам редактирования текста. Например, там есть выделение слова по ctrl+shift+стрелка (для меня это крайне важно). К тому же, в нем гарантированно возможно настроить таким образом, как я описал (наверное, в емаксе тоже, но я не проверял, потому не факт).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

LP>>Если уж использовать этот реликт, то лучше хемакс, чем емакс.

L>Чем лучше?

LP>>С помощью настроек, которые я нашел на каком-то сайте (не помню каком, но могу посмотреть если нужно) я смог довести этот осколок эпохи до более-менее человеческого состояния. Стандартная win-раскладка (вырезка ctrl x, вставка ctrl v, копирование ctrl c, отмена ctrl z, удаление выделенного по del, открытие файла по ctrl o, поиск по ctrl f и т д). Также там есть история открытия файлов и пр.

L>Зачем??? Зачем ты испоганил emacs???

Как можно испоганить софтину, в которой для операции undo нужно последователньо нажать ctrl+x, u? А если мне нужно отменить 10 действий? А так я просто нажимаю один раз на Ctrl+Z и держу, нетотпуская, пока процесс отмены не дойдет до нужной точки.

Все эти модификаторы ввиде ctrl+X были нужны лишь в силу ограниченности клавиатур (особенно терминальных) той эпохи. Лично я не вижу в этом никакой необходимости. если установлена современная 105-клавишная клавиатура.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Как можно испоганить софтину, в которой для операции undo нужно последователньо нажать ctrl+x, u? А если мне нужно отменить 10 действий? А так я просто нажимаю один раз на Ctrl+Z и держу, нетотпуская, пока процесс отмены не дойдет до нужной точки.

Во-первых есть C-_
Во-вторых есть M-10

Может дело не в emacs-е?

LP>Все эти модификаторы ввиде ctrl+X были нужны лишь в силу ограниченности клавиатур (особенно терминальных) той эпохи. Лично я не вижу в этом никакой необходимости. если установлена современная 105-клавишная клавиатура.

Выделил ключевое.
Ты просто ещё не получал удовольствие от того, что не надо мотать руками над клавиатурой, и всё под рукой.
C-p, C-n, C-b, C-f мне удобнее курсорных клавиш, не надо отводить руку. Тебе — не удобнее, но дело не в емаксе, а в нас

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Как можно испоганить софтину, в которой для операции undo нужно последователньо нажать ctrl+x, u? А если мне нужно отменить 10 действий? А так я просто нажимаю один раз на Ctrl+Z и держу, нетотпуская, пока процесс отмены не дойдет до нужной точки.

Да! И в третьих можно переопределить на Ctrl-Z как ты сделал, но зачем тогда вообще Emacs?
Не проще взять хороший редактор с уже настроенной удобной тебе раскладкой?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

LP>>Как можно испоганить софтину, в которой для операции undo нужно последователньо нажать ctrl+x, u? А если мне нужно отменить 10 действий? А так я просто нажимаю один раз на Ctrl+Z и держу, нетотпуская, пока процесс отмены не дойдет до нужной точки.

L>Да! И в третьих можно переопределить на Ctrl-Z как ты сделал, но зачем тогда вообще Emacs?
L>Не проще взять хороший редактор с уже настроенной удобной тебе раскладкой?

Как только я увижу такой редактор, сразу же на него перейду. Проблема в том, что пока не знаю такого редактора, который поддерживал бы хаскель, был и под windows, и в nix-ах. Банальная расцветка кода не устраивает, нужно, чтобы был оутлайн, как в haskell-mode. Или go to definition (что даже лучше). Вот Visual Haskell (плагин к студии) по возможностям как нельзя более устроил бы.

Может быть. Но не могу понять при всем желании, как это может быть удобно нажимать ctrl x по каждому поводу.

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

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

LP>>Как можно испоганить софтину, в которой для операции undo нужно последователньо нажать ctrl+x, u? А если мне нужно отменить 10 действий? А так я просто нажимаю один раз на Ctrl+Z и держу, нетотпуская, пока процесс отмены не дойдет до нужной точки.

L>Во-первых есть C-_
L>Во-вторых есть M-10

По поводу м 10 — я не знаю заранее сколько действий нужно отменять. Может 10, а может, 9. Удерживая ctrl z, z быстро попадаю в нужное место, а потом позиционирую более точно с тем же ctrl z и ctrl y. Или просто несколько раз быстро нажимаю на сtrl z.

Другой выход — писать структуру на IO, т.е. тот же императивный подход, а это коробит.

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

Например, если структура данных такова

module Some where

data Some = Some {id :: Int, childs :: [Some]}

setId some i = Some i (setIdForChilds (childs some))
where setIdForChilds (x:xs) = (setId x (i+1))

setIdForChilds xs)

Проблемы у ФП заключены в другом месте.

Вот пример

public static ArrayList buildObjects()
{
    Common commonObj = new Common("общий елемент");
    Element element1 = new Element(commonObj);
    Element element2 = new Element(commonObj);
    
    process(commonObj);
    
    ArrayList list = new ArrayList();
    list.add(element1);
    list.add(element2);
    return list;
}

element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

module Some where

data Some = Some {id :: Int, childs :: [Some]}

setId some i = Some i (setIdForChilds (childs some))
where setIdForChilds (x:xs) = (setId x (i+1))

setIdForChilds xs)

data Common = Common {name :: String}

data Element = Element {n :: Int, commonObject :: Common}

buildObject = let commonObj = Common "общий объект"
element1 = Element 1 commonObj
element2 = Element 2 commonObj
in
(Element (n element1) (process commonObj), (Element (n element2) (process commonObj))
where process commonO = Common (name commonO ++ " — изменен")

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

[cut]

LP>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

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

LP>Проблемы у ФП заключены в другом месте.

LP>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

Зачем думать? Декларируй зависимость, компилятор разберется

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

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

К>[cut]

LP>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

К>А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом. Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти. Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

LP>>Проблемы у ФП заключены в другом месте.

LP>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

D>Зачем думать? Декларируй зависимость, компилятор разберется

Как это так?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

К>>[cut]

LP>>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

К>>А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

LP>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом. Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти. Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

Только вот вопрос — на базе чего сделаны такие заявления? Есть опубликованные исследования? Конкретные цифры?
Функциональное программирование раньше вообще в "корпоративке" не воспринимали ибо "ересь".
Думаю тут имеем примерно то же самое — демонстрацию пресловутового "блаба".
Хотя моё мнение является тоже "лишь мнением"

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

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

Не понял. Нам какая разница ходит она или обновляется — это проблемы компилятора.

LP>setId some i = Some i (setIdForChilds (childs some))
LP> where setIdForChilds (x:xs) = (setId x (i+1))

setIdForChilds xs)

setIdForChilds = map (flip setId (i + 1))

Ну и именно из-за flip-а (точнее карринга) в Haskell принято то, на что действует функция делать последним параметром.

LP>Проблемы у ФП заключены в другом месте.
LP>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад).

Ну, так о чём и речь — прозрачность по ссылкам побуждает использование других структур данных/алгоритмов нежели в императивном языке.

LP> Приходится самому думать о зависимостях.

А всё потому что в Хаскеле нет ни объектов, ни тем более обновления объектов, так что рассуждения не верны в самой основе. Попробуй по другому представить свою структуру.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, <Аноним>, Вы писали:

А>Как только я увижу такой редактор, сразу же на него перейду. Проблема в том, что пока не знаю такого редактора, который поддерживал бы хаскель, был и под windows, и в nix-ах. Банальная расцветка кода не устраивает, нужно, чтобы был оутлайн, как в haskell-mode. Или go to definition (что даже лучше). Вот Visual Haskell (плагин к студии) по возможностям как нельзя более устроил бы.

Сходу приходит в голову
Эклипс + eclipsefp

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

К>>А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

LP>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом. Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти. Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

Это вывод на основании ОО опыта?

ОО — всего лишь POV. ФП подразумевает другой взгляд.
Тут уже несколько раз приводили ссылку Composing contracts: an adventure in financial engineering.

И ещё есть тут же тред с ФП-дизайном (Решение Problem K на Эрланг: дизайн), а ещё есть самое первое сообщение этого треда.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

L>Не понял. Нам какая разница ходит она или обновляется — это проблемы компилятора.

LP>>setId some i = Some i (setIdForChilds (childs some))
LP>> where setIdForChilds (x:xs) = (setId x (i+1))

setIdForChilds xs)

L>setIdForChilds = map (flip setId (i + 1))
L>

L>Ну и именно из-за flip-а (точнее карринга) в Haskell принято то, на что действует функция делать последним параметром.

LP>>Проблемы у ФП заключены в другом месте.
LP>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад).

L>Ну, так о чём и речь — прозрачность по ссылкам побуждает использование других структур данных/алгоритмов нежели в императивном языке.

LP>> Приходится самому думать о зависимостях.

L>А всё потому что в Хаскеле нет ни объектов, ни тем более обновления объектов, так что рассуждения не верны в самой основе. Попробуй по другому представить свою структуру.

Тут уж был спор по этому поводу. Меня тогда не убедили — если предметная область связана с реальными физ. объектами, то ОО-дизайн приводит к лучшим результатам. Вот скажем, возвращаясь к теме того спора, есть у нас объект — линия электрических сетей. Начинается она с подстанции. Проблема в том, что с этой же подстанции могут начинаться много других линий. И много линий могут на ней заканчиваться. В этом случае естественно воспользоваться ОО-декомпозицией. И без ссылок тут не обойтись.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

К>>>[cut]

LP>>>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

К>>>А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

LP>>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом. Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти. Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

К>Только вот вопрос — на базе чего сделаны такие заявления? Есть опубликованные исследования? Конкретные цифры?
К>Функциональное программирование раньше вообще в "корпоративке" не воспринимали ибо "ересь".
К>Думаю тут имеем примерно то же самое — демонстрацию пресловутового "блаба".
К>Хотя моё мнение является тоже "лишь мнением"

ООП показал в корпоративном секторе хорошие результаты. Будете спорить?

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

Haskell мне кажется очень интересным языком. Но вот облегчит ли он решение задач, в которых традиционно силен "быдлоООП", мне совсем не очевидно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>ФП может и тестировали в этой стезе, но про результаты мне ничего не известно. Так что не мне тут нужно что-либо доказывать, а сторонникам ФП. Может, фп покажет тут потрясающие результаты, а может, будет плохо применим. Только практика масштабного использования сможет ответить на этот вопрос.

LP>Haskell мне кажется очень интересным языком. Но вот облегчит ли он решение задач, в которых традиционно силен "быдлоООП", мне совсем не очевидно.

Ну вот уже более конструктивный разговор

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

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

LP>ООП показал в корпоративном секторе хорошие результаты. Будете спорить?

Я буду!

Масса проваленных проектов, куча дизайн-заплаток типа паттернов — это хороший результат?

LP>ФП может и тестировали в этой стезе, но про результаты мне ничего не известно. Так что не мне тут нужно что-либо доказывать, а сторонникам ФП. Может, фп покажет тут потрясающие результаты, а может, будет плохо применим. Только практика масштабного использования сможет ответить на этот вопрос.

+1. Может быть ФП будет хуже, я до сих пор не разобрался.

LP>Haskell мне кажется очень интересным языком. Но вот облегчит ли он решение задач, в которых традиционно силен "быдлоООП", мне совсем не очевидно.

тоже +1. Нужен опыт.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Тут уж был спор по этому поводу. Меня тогда не убедили — если предметная область связана с реальными физ. объектами, то ОО-дизайн приводит к лучшим результатам.

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

LP>Вот скажем, возвращаясь к теме того спора, есть у нас объект — линия электрических сетей. Начинается она с подстанции. Проблема в том, что с этой же подстанции могут начинаться много других линий. И много линий могут на ней заканчиваться. В этом случае естественно воспользоваться ОО-декомпозицией. И без ссылок тут не обойтись.

Естественно для кого? Возьми тот же зиппер.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

LP>>ООП показал в корпоративном секторе хорошие результаты. Будете спорить?

L>Я буду!

Масса проваленных проектов, куча дизайн-заплаток типа паттернов — это хороший результат?

Проваленные проекты всегда будут. Паттерны — а ты думаешь, что в ФП их не будет? Это вещь, отвязанная от конкретной идеологии и существует вне ее. К тому же никак не понятно, каким образом существование паттернов может судить о пригодности/непригодности.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

LP>>Тут уж был спор по этому поводу. Меня тогда не убедили — если предметная область связана с реальными физ. объектами, то ОО-дизайн приводит к лучшим результатам.

L>Ты тогда описал структуру, вместо того, чтобы описать функциональность системы. Давай я тебе тоже опишу какую нибудь функциональную структуру и скажу — вот эта структура очень плохо ложится на ОО. Ты задачу то опиши.

Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

LP>>Вот скажем, возвращаясь к теме того спора, есть у нас объект — линия электрических сетей. Начинается она с подстанции. Проблема в том, что с этой же подстанции могут начинаться много других линий. И много линий могут на ней заканчиваться. В этом случае естественно воспользоваться ОО-декомпозицией. И без ссылок тут не обойтись.

L>Естественно для кого? Возьми тот же зиппер.

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

В общем, что мне нравится в ООП вообще и ОО-декомпозиции в часности? Это возможность быстро смоделировать предметную область стой степенью детализации. которая необходима в конкретном случае. Вот если б ФП позволил мне это сделать, да еще и декларативно, то цены б ему не было. Может ли оно это или нет — вопрос для меня.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>В общем, что мне нравится в ООП вообще и ОО-декомпозиции в часности? Это возможность быстро смоделировать предметную область стой степенью детализации. которая необходима в конкретном случае. Вот если б ФП позволил мне это сделать, да еще и декларативно, то цены б ему не было. Может ли оно это или нет — вопрос для меня.

Какая-то у тебя странная позиция, будто все тебя убеждают, что ООП — это страшное зло и ни в коем случае нельзя использовать эту каку

Скажем, вот мы с lomeo на яве пишем на своих работах и ничего — нормально

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

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

LP>Проваленные проекты всегда будут.

Я даже не знаю, что на это ответить. Т.е. этот аргумент мы отметаем, как неорганизованный так что ли?
Если ФП позволит снизить (или наоборот приведёт к повышению) количество провальных проектов — разве это совсем-совсем неважно?

LP>Паттерны — а ты думаешь, что в ФП их не будет? Это вещь, отвязанная от конкретной идеологии и существует вне ее. К тому же никак не понятно, каким образом существование паттернов может судить о пригодности/непригодности.

Элементарно! Паттерны разрешают какие-то недостатки, а значит самим своим существованием высвечивают проблемы. И в ФП тоже есть паттерны, но пока не могу сказать, какие недостатки хуже "в корпоративном секторе".

А ты уже можешь?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Во-вторых (и это важно) — ФП не поможет тебе сделать ОО-декомпозицию. Никак. Вот ФП-декомпозицию — запросто!

LP>В общем, что мне нравится в ООП вообще и ОО-декомпозиции в часности? Это возможность быстро смоделировать предметную область стой степенью детализации. которая необходима в конкретном случае. Вот если б ФП позволил мне это сделать, да еще и декларативно, то цены б ему не было. Может ли оно это или нет — вопрос для меня.

ФП ничего не может. Могут программисты. Как ФП моделирует предметную область — я тебе уже давал несколько ссылок, если ты задаёшь вопросы — может ли оно, значит ты их не читал, нес па?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Тут уж был спор по этому поводу. Меня тогда не убедили — если предметная область связана с реальными физ. объектами, то ОО-дизайн приводит к лучшим результатам. Вот скажем, возвращаясь к теме того спора, есть у нас объект — линия электрических сетей. Начинается она с подстанции. Проблема в том, что с этой же подстанции могут начинаться много других линий. И много линий могут на ней заканчиваться. В этом случае естественно воспользоваться ОО-декомпозицией. И без ссылок тут не обойтись.

здесь как раз обсуждается задача К. когда её решают ООП-minded люди, они представляют решение как систему объектов (таблица, ячейка, выражение), взаиможействующих некоторым образом. когда эту задачу решают fp-minded people, задача предсатвляется как набор преобразований входного формата данных в выходной, используя механизмы композиции функций, итерации коллекции, выявления циклов в графе и т.д.

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

насколько я понимаю, единственная твоя загвоздка — ты привык описывать алгоритмы на эти структурах данных императивно, опираясь на понятие текущего состояния, и не умеешь их представлять как отображение входной структуры в выходную целиком. но это противоречие между императвиным и pure fp программированием, а не fp vs oop

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

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

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

К>>[cut]

LP>>>element1 и element2 имеют ссылку на один объект и обновление этого объекта приведет к актуальному обновлению зависимых объектов. В Хаскеле, не имеющим побобочных эффектов, такое невозможно (без монад). Приходится самому думать о зависимостях.

К>>А вот тут вопрос — а нужно ли такое? Чтоб были неявные зависимости, усложняющие логику нехило?

LP>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом.

Любые объекты (не только "бизнес") всегда имеют сложные зависимости по identity. В этом суть объектов — они скрывают изменяемое состояние и доступны по identity. Означает ли это, что бизнес-процессы могут быть описаны только в терминах объектов с изменяемым состоянием? Разумеется, нет. Более того, значительная часть артефактов бизнес-процесса в реальной жизни не являются мутабельными — например, все первичные документы и бухгалетрские проводки. Они делаются один раз, их провка — нештатная ситуация.

LP>Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти.

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

Вопрос другой — а так ли необходимо представлять полноценную реляционную модель в объектном виде?

Что кроме вашей привычки (не канает) и тупости оппонентов (не советую) вы можете назвать в качестве аргумента?

LP>Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

Пример.

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

LP>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

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

во-вторых, я вижу здесь пару небольших, но всё же преимуществ ФП языков типа хаскела — возможность описать каждое ред-ние чистой функцией (их проще описывать и проще проверять чем update state процедуры); второе — "бесплатный undo" за счёт хранения предыдущих версий структуры данных (это дёшево, поскольку её не надо целиком копировать; кол-во копируемых при каждом ред-нии элементов — O(log N))

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

кстати, вспаомгнилось, что есть такая универсадбная система ред-ния графов — Graphviz. по идее вещей, нужно просто написать преобразование данных туда/сюда и правила ред-ния и перевадлить эту заботу на её плечи. как видишь, я свёл даже твою задачу к сложному алгоритму обработки данных

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

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

LP>>Проваленные проекты всегда будут.

L>Я даже не знаю, что на это ответить. Т.е. этот аргумент мы отметаем, как неорганизованный так что ли?
L>Если ФП позволит снизить (или наоборот приведёт к повышению) количество провальных проектов — разве это совсем-совсем неважно?

LP>>Паттерны — а ты думаешь, что в ФП их не будет? Это вещь, отвязанная от конкретной идеологии и существует вне ее. К тому же никак не понятно, каким образом существование паттернов может судить о пригодности/непригодности.

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

L>Элементарно! Паттерны разрешают какие-то недостатки, а значит самим своим существованием высвечивают проблемы. И в ФП тоже есть паттерны, но пока не могу сказать, какие недостатки хуже "в корпоративном секторе".

L>А ты уже можешь?

Я же уже писал об этом. Только практика может все прояснить.

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

К>Какая-то у тебя странная позиция, будто все тебя убеждают, что ООП — это страшное зло и ни в коем случае нельзя использовать эту каку

К>Скажем, вот мы с lomeo на яве пишем на своих работах и ничего — нормально

К>Никто же не пытается обратить тебя в Великую Веру Лямбды, если будет желание, то сам разберёшься по-моему. А если не хочешь — пользуйся ООП, если оно тебе нравится. По сути это всё лишь инструмент для решения конкретных задач и определяется выбор не абстрактной крутостью, а удобностью и выгодностью в свете конкретной ситуации.

С чего ты решил, что я так думаю? Мне вообще не нравится, что ООП как парадигма основана на объектах, имеющих состояние. Вот если бы можно разложить предметную область на объекты без состояния, т е избавиться от императивности, которая вытекают от играний с состоянием, я был бы только рад. Проблема в том, что не знаю, возможно ли такое — провести четкую декомпозицию задачи на объекты без ООП. Если вы заметили, все мои сообщения как раз сводятся к этому.

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

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

LP>>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

L>Ну и? Действия то какие ты будешь проводить с линиями и подстанциями, потому что просто информация — это тупая декларация, которую ты уже писал. Ты же натыкался на referential transparency, значит, решал какую то конкретную задачу, отличную от просто информации. Расскажи.

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

L>ФП ничего не может. Могут программисты. Как ФП моделирует предметную область — я тебе уже давал несколько ссылок, если ты задаёшь вопросы — может ли оно, значит ты их не читал, нес па?

Не читал. Времени не было. Но прочитаю при возможности.

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

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

LP>>Паспортная система — т е информация об энергетических объектах, в виде таблиц, диаграмм и графиеских схем (редактируемых интерактивно). Т е в качестве простейшего случая — это информация об объектах, о которых я уже говорил — взаймосвязанных линиях и подстанциях.

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

Сложных алгоритмов нет. Но задача совсем не так проста, как кажется.

BZ>во-вторых, я вижу здесь пару небольших, но всё же преимуществ ФП языков типа хаскела — возможность описать каждое ред-ние чистой функцией (их проще описывать и проще проверять чем update state процедуры); второе — "бесплатный undo" за счёт хранения предыдущих версий структуры данных (это дёшево, поскольку её не надо целиком копировать; кол-во копируемых при каждом ред-нии элементов — O(log N))

Т е каждое редактирование — это функция, которая просто пишет напрямую в б д без всякой промежуточной модели?

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

LP>Паттерны не разрешают недостатки. Паттерны представляют собой наработанные шаблоны и схемы проектирования, позволяющие с минимальными издержками реализовать необходимую функциональность/поведение. Да, существование некоторых из них можно объяснить отсутствием соотвествующих возможностей в языке (сопоставление с образцом. двойная диспетчеризация). Но ведь не это главное?

Главное — понятие относительное

Если в ФП та же задача решается естественно безо всяких паттернов, не говорит ли это о том, что в ОО это недостаток?

LP>Я же уже писал об этом. Только практика может все прояснить.

О том и речь! Поэтому не стоит так категорично

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Какие действия? Но ведь я уже все описал. Вот есть б д. В ней — информация об энергетических объектах в сети. Нужно тупо прочитать и тупо отобразить. Способы отображения — разные — от простейшей таблицы, до сложной схемы, редактируемой в специальном редакторе. Какого-бы то не было состояния иметь не планируется — ни на клиенте, ни на сервере (не считая, само-собой, граф. объектов в редакторе). ООП здесь нужен не столько для обеспечения долгоживущих объектов, сериализуемых время от времени, а для создания именно объектной декомпозиции.

А в чём там проблема с алгебраическими типами данных?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>>Нужны. Бизнес-объекты имеют сложные зависимости by design. В корпоративке это сплошь и рядом.

G>Любые объекты (не только "бизнес") всегда имеют сложные зависимости по identity. В этом суть объектов — они скрывают изменяемое состояние и доступны по identity. Означает ли это, что бизнес-процессы могут быть описаны только в терминах объектов с изменяемым состоянием? Разумеется, нет.

Это вопрос меня сильно интересует. Я его уже задал в соседней теме про задачу К. Если бы кто-нибудь подсказал способ разрабатывать в терминах объектов, но без осточертевшего состояния, мне бы этого хватило. Сейчас читаю по ссылками lomeo, может, ситуация прояснится.

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

Мотивов для использования ООП может быть в этом случае 2
1. Наличие мутабельных объектов. которые интенсивно меняются/взаймодействуют с пользователем-средой-внешним миром.
2. Проведение декомпозиции с целью представления исходных физических объектов в виде объектной модели.

В случае с документами первое вроде бы как отпадает (хотя тоже не факт). Но вот со вторым что будем делать?

LP>>Для представления любой более-менее полноценной реляционной модели в объектном виде нужны такие зависимсоти.

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

G>Вопрос другой — а так ли необходимо представлять полноценную реляционную модель в объектном виде?

Что кроме вашей привычки (не канает) и тупости оппонентов (не советую) вы можете назвать в качестве аргумента?

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

Если бы я еще получил способ отправить на свалку сопутствующую этому императивность, жить стало бы легче

А при виде процедуры, которая колбасит черт-знает-что в хрен-знает-что мне тошно становится. Объекты нужны.

LP>>Конечно, если в качестве persistence layer выступает база данных, то без этого можно вроде бы как обойтись, но дизайн все равно хорошим не получится.

G>Пример.

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

PS проект — J2EE.

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

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

LP>>Какие действия? Но ведь я уже все описал. Вот есть б д. В ней — информация об энергетических объектах в сети. Нужно тупо прочитать и тупо отобразить. Способы отображения — разные — от простейшей таблицы, до сложной схемы, редактируемой в специальном редакторе. Какого-бы то не было состояния иметь не планируется — ни на клиенте, ни на сервере (не считая, само-собой, граф. объектов в редакторе). ООП здесь нужен не столько для обеспечения долгоживущих объектов, сериализуемых время от времени, а для создания именно объектной декомпозиции.

L>А в чём там проблема с алгебраическими типами данных?

Да вроде бы оно самое то. Только вот невозможность иметь на один и тот же объект ссылки из разных мест объектов мешает. Неужто, если бы эти ссылки разрешили, но сделали немутабельными, это привело бы к императивности? По-моему, нет. Могу примеры привести. как я это себе представляю.

PS За ссылки спасибо, сейчас читаю.

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

LP>Сложных алгоритмов нет. Но задача совсем не так проста, как кажется.

и что в этой задаче сложного?

BZ>>во-вторых, я вижу здесь пару небольших, но всё же преимуществ ФП языков типа хаскела — возможность описать каждое ред-ние чистой функцией (их проще описывать и проще проверять чем update state процедуры); второе — "бесплатный undo" за счёт хранения предыдущих версий структуры данных (это дёшево, поскольку её не надо целиком копировать; кол-во копируемых при каждом ред-нии элементов — O(log N))

LP>Т е каждое редактирование — это функция, которая просто пишет напрямую в б д без всякой промежуточной модели?

ага. бд. реляционка? действительно, без ООП лекомпозиции здесь никак не обойтись

в таком варианте, каждое ред-ние отображается в sql-операцию

кстати, вспомнил, как я в 90-х годах принимал участие в разработке очередной бух.системы. её дизайн был просто верхом искусства — каждый реестр представлялся sql-запросом, которые могли включать и десяток таблиц, и все операции сводились либо к добавлению данных в эти (обновляемые) запросы, либо к показу выборок из них. вся система была чётко структурирована на три уровня — системный, которым я занимался, обеспечивал открытие нужных запросов/формочек. прикладной, которые делали люди, разбирающиеся в бухучёте — описание соответствующих sql-запросов. и "украшательский" — рисование формочек и отчётов на базе готовых запросов.

единственным недостатком этой системы, написанной на access, была её чудовищная медлительность. проводка (перевод денег со счёта на счёт) вносилась в базу 2 минуты!

думаю, это как раз отличный пример того, как работа с состояниями была отображена в высокоуровневый sql-based подход, а сама система разделена на независимые уровни, разработчикам которых не требуется ни лишней квалификации, ни зависимости от разработчиков других уровней

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

L>Здравствуйте, <Аноним>, Вы писали:

А>>Как только я увижу такой редактор, сразу же на него перейду. Проблема в том, что пока не знаю такого редактора, который поддерживал бы хаскель, был и под windows, и в nix-ах. Банальная расцветка кода не устраивает, нужно, чтобы был оутлайн, как в haskell-mode. Или go to definition (что даже лучше). Вот Visual Haskell (плагин к студии) по возможностям как нельзя более устроил бы.

L>Сходу приходит в голову
L>Эклипс + eclipsefp

Я видел эту штуку, но не понравилась. Еклипс — слишком неповортливая среда для того, чтобы терпеть тормоза при столь низкой функциональности плагина — это раз. Там есть глюки в синтаксическом анализаторе (antlr) — это два. И поскольку функциональность этого тула не выше, чем у haskell-mode, а удобство работы с последним удалось довести до приемлего состояния, то дергаться в его сторону пока не стоит.

Кстати, в новой версии haskell-mode тоже нет пo to definition? А то я использую старую версию плагина, где этой возможности нет, очень неудобно.

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

G>Вопрос другой — а так ли необходимо представлять полноценную реляционную модель в объектном виде?

Что кроме вашей привычки (не канает) и тупости оппонентов (не советую) вы можете назвать в качестве аргумента?

Кроме того, при условии осуществления декомпозиции на некотором уровне детализации, нам становятся с помощью полученного фреймворка доступны вариации в поведениях объектов. Давайте рассмотрим предельный случай — нам удалось реализовать модель подстанции с с точностью до элементарных частиц, ее образующих. Само собой, что такая наша модель в случае чего и споет, и спляшет. Она абсолютно устойчива к изменяющимся условиям — до той поры, разумеется, пока эти условия не вступают в противоречие с самой природой объекта. Осуществление детализации на таком уровне невозможно, а самое главное, не нужно. Достаточно подобрать какой-то определенный уровень детализации представления объекта, и нам становятся доступен определенный диапазон возмущений, которые наша модель выдержит без тотального рефакторинга. Это напоминает работу супергетеродинного приемника — чем выше селективность, тем ниже мощность приема.
В случае же ваших процедур — когда одна непонятная хрень преобразуется по черт-те знает каким правилам в другую непонятную хрень — о какой устойчивости к возмущениям вообще может идти речь? Стоит только измениться, скажем, способу питания катушек трансформаторов — как придется разгребать кучу говнокода, причем еще непонятно, изменение какой функции приведет к требуемому результату. А в случае модели я просто дергаю нужное оборудование и делаю примерно тоже самое, что делает в жизни электромонтер. Наивный ООП, скажете? Но черт возьми, это реально работает. Проверено на практике.

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

LP>В случае же ваших процедур — когда одна непонятная хрень преобразуется по черт-те знает каким правилам в другую непонятную хрень — о какой устойчивости к возмущениям вообще может идти речь? Стоит только измениться, скажем, способу питания катушек трансформаторов — как придется разгребать кучу говнокода

а теперь ты путаешь ООП и энкапсуляцию. исторически же как раз функциональный подход был одним из первых способов изолирования частей программы и разбиения её на соабо-связанные куски кода. ООП — частный случай ФП, когда некий набор функций и данных объявляется объектом, и все остальные способы декомпозиции эмулируются через объекты — модульность через синглетоны, higher-order funcs — через функторы, фабрики, делегаты, акторы и т.д.

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

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

LP>>В случае же ваших процедур — когда одна непонятная хрень преобразуется по черт-те знает каким правилам в другую непонятную хрень — о какой устойчивости к возмущениям вообще может идти речь? Стоит только измениться, скажем, способу питания катушек трансформаторов — как придется разгребать кучу говнокода

BZ>а теперь ты путаешь ООП и энкапсуляцию. исторически же как раз функциональный подход был одним из первых способов изолирования частей программы и разбиения её на соабо-связанные куски кода. ООП — частный случай ФП, когда некий набор функций и данных объявляется объектом, и все остальные способы декомпозиции эмулируются через объекты — модульность через синглетоны, higher-order funcs — через функторы, фабрики, делегаты, акторы и т.д.

Ничего я не путаю. Вообще, я возражаю Gaperton'u, который говорит, что введение объектов и определение бизнес-пророцедур на изх основе ничего особенного не привносит.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Ничего я не путаю. Вообще, я возражаю Gaperton'u, который говорит, что введение объектов и определение бизнес-пророцедур на изх основе ничего особенного не привносит.

Не привносит куда? Одно дело если сравнивать с ассемблером или процедурным программированием, а другое с полноценным ФП. Кстати можешь показать, где он говорит такое? Он лишь писал про то, что ООП не является единственным возможным способом представления моделируемой системы. То, что ООП скорее всего выгодней процедурного программирования, думаю, понятно (но не факт, т.к. всё определяется конкретной задачей, которые и для бизнеса бывают разными), а вот то, что оно обязательно "перекрывает" возможности ФП (по мощности с учётом простоты и удобства) — спорное утверждение.

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

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

LP>>Ничего я не путаю. Вообще, я возражаю Gaperton'u, который говорит, что введение объектов и определение бизнес-пророцедур на изх основе ничего особенного не привносит.

К>Не привносит куда? Одно дело если сравнивать с ассемблером или процедурным программированием, а другое с полноценным ФП. Кстати можешь показать, где он говорит такое? Он лишь писал про то, что ООП не является единственным возможным способом представления моделируемой системы. То, что ООП скорее всего выгодней процедурного программирования, думаю, понятно (но не факт, т.к. всё определяется конкретной задачей, которые и для бизнеса бывают разными), а вот то, что оно обязательно "перекрывает" возможности ФП (по мощности с учётом простоты и удобства) — спорное утверждение.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

А чем ООП отличается от процедурного? Небось видел ООП на C?
Или чем процедурное отличается от ассемблера, а тот от машинных кодов?
Каждый уровень по сути добавляет некий функциональный (не от ФП, а выполняюищй свою функцию

) сахар, который при возможности можно заоптимизировать ещё в добавок (заинлайнить функции, убрать лишнюю синхронизацию по synchronized из Java и т.п.)
Или ещё пример — чем языки со сборкой мусора отличаются от тех, где её нет? Да почти ничем, если брать в расчёт то, что можно ведь и самому написать сборщик и принудительно гарантировать его использование.
Ну а по сути ФП позволяет заметно поднять уровень абстракции (как и ООП, только несколько в другую сторону), скажем ты в C не сможешь гарантировать чистоту функций, как это можно сделать для Хаскеля, ну и заоптимизировать сможешь заметно меньше мест программы.

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

L>>А в чём там проблема с алгебраическими типами данных?

LP>Да вроде бы оно самое то. Только вот невозможность иметь на один и тот же объект ссылки из разных мест объектов мешает. Неужто, если бы эти ссылки разрешили, но сделали немутабельными, это привело бы к императивности? По-моему, нет. Могу примеры привести. как я это себе представляю.

Не понял. Алгебраические типы — не объекты. Пример приведи, ага.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Кстати, в новой версии haskell-mode тоже нет пo to definition? А то я использую старую версию плагина, где этой возможности нет, очень неудобно.

Не знаю

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

К>А чем ООП отличается от процедурного? Небось видел ООП на C?
К>Или чем процедурное отличается от ассемблера, а тот от машинных кодов?
К>Каждый уровень по сути добавляет некий функциональный (не от ФП, а выполняюищй свою функцию

) сахар, который при возможности можно заоптимизировать ещё в добавок (заинлайнить функции, убрать лишнюю синхронизацию по synchronized из Java и т.п.)
К>Или ещё пример — чем языки со сборкой мусора отличаются от тех, где её нет? Да почти ничем, если брать в расчёт то, что можно ведь и самому написать сборщик и принудительно гарантировать его использование.
К>Ну а по сути ФП позволяет заметно поднять уровень абстракции (как и ООП, только несколько в другую сторону), скажем ты в C не сможешь гарантировать чистоту функций, как это можно сделать для Хаскеля, ну и заоптимизировать сможешь заметно меньше мест программы.

Да не пытаюсь я наехать на ваше любое ФП, мне оно самому очень интересно, сейчас вот Хаскель изучаю. Просто непонятно мне, сможет ли оно мне помочь в моих задачах. Хотел заранее это понять, но, видимо, пока полностью не изучу Хаскель, сие будет от меня скрыто.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LP>Да не пытаюсь я наехать на ваше любое ФП, мне оно самому очень интересно, сейчас вот Хаскель изучаю. Просто непонятно мне, сможет ли оно мне помочь в моих задачах. Хотел заранее это понять, но, видимо, пока полностью не изучу Хаскель, сие будет от меня скрыто.

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

От:	Курилка	http://kirya.narod.ru/
Дата:	17.11.07 10:57
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	18.11.07 08:54
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	18.11.07 09:07
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	19.11.07 09:21
Оценка:	7 (1)

От:	Курилка	http://kirya.narod.ru/
Дата:	19.11.07 09:26
Оценка:

От:	VladD2	www.nemerle.org
Дата:	20.11.07 15:18
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	21.11.07 13:42
Оценка:

	От:	BulatZiganshin
	Дата:	22.11.07 13:21
	Оценка:	2 (1)

От:	Gaperton	http://gaperton.livejournal.com
Дата:	22.11.07 13:41
Оценка: