Re: Так в чем же принципиальные отличия ФП от ИП?
От: Кодт Россия  
Дата: 23.04.07 09:12
Оценка: 24 (3) +1 :))) :))) :))) :))) :))) :))
Здравствуйте, <Аноним>, Вы писали:

А>Игрался неделю со scala, до этого читал статьи всяких проповедников ФП(один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете). В результате пребываю в довольно странном состоянии — "И ЭТО ВСЕ? И ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ ИП?".


http://mr-aleph.livejournal.com/51409.html

Как-то однажды знаменитый учитель Кх Ан вышел на прогулку со учеником Антоном. Надеясь разговорить учителя, Антон спросил: "Учитель, слыхал я, что объекты — очень хорошая штука — правда ли это?" Кх Ан посмотрел на ученика с жалостью в глазах и ответил: "Глупый ученик! Объекты — всего лишь замыкания для бедных."

Пристыженный Антон простился с учителем и вернулся в свою комнату, горя желанием как можно скорее изучить замыкания. Он внимательно прочитал все статьи из серии "Lambda: The Ultimate", и родственные им статьи, и написал небольшой интерпретатор Scheme с объектно-ориентированной системой, основанной на замыканиях. Он многому научился, и с нетерпением ждал случая сообщить учителю о своих успехах.

Во время следующей прогулки с Кх Аном, Антон, пытаясь произвести хорошее впечатление, сказал: "Учитель, я прилежно изучил этот вопрос, и понимаю теперь, что объекты — воистину замыкания для бедных." Кх Ан в ответ ударил Антона палкой и воскликнул: "Когда же ты чему-то научишься? Замыкания — это объекты для бедных!" В эту секунду Антон обрел просветление.

... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: граммофон  
Дата: 03.05.07 00:58
Оценка: 26 (4) -3 :))) :)
Здравствуйте, VGn, Вы писали:


VGn>В общем-то, конечно, да, если плясать от IDEF. Но чем больше система, тем менее понятной становится её функциональная модель и сложнее выделять уровни абстракции.

VGn>В этом отношении ООП намного проще и удобнее.

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

Я вот вижу ООП так, что ему есть место и есть применения для ряда случаев, как у сущности сопутствующей данным — внешние устройства там представлять, генераторы там всякие. Но уж точно не фабрики и команды.

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

VGn>Хотя знавал я одного айтишника в возрасте, который ооп/а так и не понял и держался зубами за IDEF. Правда всё это служило оправданием макаронному структурному подходу.


Я вот понимал ООП раз 8. Каждый раз по-настоящему. Как-то даже наследование понимал и любил. Неловко признаться.
прежде чем понять рекурсию, необходимо понять рекурсию.
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 04.05.07 11:54
Оценка: 16 (2) +7 :)
Здравствуйте, Аноним, Вы писали:

А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?

А зачем объект-то? Что вам мешает вам вообще без объектов на чистом С писать — будете структурками пользоваться, в чем проблема? Да что там С — на ассемблере можно вообще что хочешь изобразить. Неудобно? Вот так и мне не нравится на каждый писк класс заводить — с туплами любой (в том числе и императивный) код на порядок выигрывает в читабельности. Чем конкретно вам не нравятся туплы?

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

А глядя на С++ — в начале девяностых у меня тогда сложилось впечатление, что это самый обыкновенный С с синтаксическим сахаром — например, можно где угодно переменные объявлять. Удобно . Еще помню, бесило, что компилятор автоматически void* к MyType* не приводит — приходится руками приведение писать. Ну не все же сахар, есть и недостатки у языка, да.

А>В процессе прочтения статей я видел кучу примеров (в основном всякие математические вычисления или сортировка). Но я нигде не видел РЕАЛЬНЫХ примеров (из тех областей для которых пишется большинство программ).


Веб-сервер подойдет?
http://yaws.hyber.org/

Jabber-сервер подойдет?
http://ejabberd.jabber.ru/

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


GoF решает проблемы микродизайна, характерные для ОО систем. Там динамический полиморфизм слабенький — по одному аргументу, и частенько приходится городить черт знает что в простейших случаях. В языках с паттерн-матчингом и функциями высшего порядка все гораздо проще — очевидное решение чаще оказывается правильным. Паттерны какие-то наверное есть (foldr, foldl, и прочее к ним можно отнести), но на книгу их точно не хватит .

Пример хотите? Расскажите, как вы будете делать конечный автомат, реагирующий на сообщения разных типов. (У вас там появится две иерархии классов + дабл диспатч на них вылезет — хрен поймешь по коду потом что за нафиг). А я вам покажу, как это делается в языках с паттерн-матчингом.

Другой эффектный пример — алгоритмы на деревьях. Они примерно раз в 5 компактнее, чем в классическом ОО языке.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.07 11:33
Оценка: 9 (1) :))) :))) :))
Здравствуйте, Кодт, Вы писали:

К>Если на сладкое подсесть, то попа слипнется


Ну, на это в каждой уважающей себя конторе имеется проффесиональный массажист (ПМ).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 16:02
Оценка: -5 :))
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:


КЛ>>По-моему, чистый фп подход продьюсит спагетти-код


D>Эээ, залезем в Вики


D>

D>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.


1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
2. слабо структурированная. Туда же.
3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси
4. трудная для понимания программа. см. пункт 3.
5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

Кроме того, спагетти-код был в рифму к "подход"

D>И? Причём тут чистый ФП?
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: Трурль  
Дата: 04.05.07 13:11
Оценка: 72 (6)
Здравствуйте, Gaperton, Вы писали:

G Паттерны какие-то наверное есть (foldr, foldl, и прочее к ним можно отнести), но на книгу их точно не хватит .

Собрать несколько таких статей и хватит .
Re[18]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 03.05.07 08:31
Оценка: 24 (3) +3
Здравствуйте, VGn, Вы писали:
VGn>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.
Не торопитесь. Функционально-реактивные графические интерфейсы — очень активная область исследований в последнее время. Пролистайте туториал по flapjax, например, и убедитесь, что функциональное описание поведения интерфейса в терминах зависимостей между контролами может быть значительно проще привычных Form1.Button1_OnClick().
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 10.05.07 13:57
Оценка: :))) :)))
КЛ>>один хрен лоб до затылка расшибет.

Я долго медитировал над этой фразой

Что он куда расшибет?


dmitriid.comGitHubLinkedIn
Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 21.04.07 09:35
Оценка: 9 (1) +2 :))
Добрый день, товарищи!

Игрался неделю со scala, до этого читал статьи всяких проповедников ФП(один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете). В результате пребываю в довольно странном состоянии — "И ЭТО ВСЕ? И ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ ИП?".

Начнем по порядку:

1) Функции высшего порядка (название то какое!) — принимают функции в качестве аргментов
и возвращают другме функции.
Вопрос: А чем это отличается от метода который принимает в качестве аргумента объект и возвращает другой, у которых есть не только свои методы и переменные члены, но и которые соответствуют определенной сущности предметной область.
2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)
Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
И.т.д.

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

В процессе прочтения статей я видел кучу примеров (в основном всякие математические вычисления или сортировка). Но я нигде не видел РЕАЛЬНЫХ примеров (из тех областей для которых пишется большинство программ). Читал кусок сататью VladD2 (тот что лежит на сайте). Там описывается во введении описывается замечательный язык LISP, который является самым мощным, потому всю остальное сукс (во всяком случае посыл такой...), жду когда
появится полная версия статьи... Хотя лично я в реальной задачи скорее предпочту простой и понятный инструмент (возможно даже аскетичный) чем
супер хренорезку с функциями карьерного самосвала.

Вот мне, например, нужно написать универсальный траснпорт между подразделениями, по которму может ездить что угодно куда угодно а код менять не надо, сейчас играюся с диким гибридом Jetty+Axis2+Quarts+Xalan+JDBC (как я понимаю к ФЯ с натяжкой можно отнести только XSLT) и мнея абсолютно неважно кто, где и как считает факториал.

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

P.S, Я еще не растерял интуазизм и планирую еше посидеть на скалой.... а заодно попробую найти что-то конкретное.
P.P.S. Надеюсь на вменяемую дискуссию..
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: Кодт Россия  
Дата: 27.04.07 10:26
Оценка: :))) :))
Здравствуйте, Mamut, Вы писали:

M>Все хуже На сладкое и подсесть можно


Если на сладкое подсесть, то попа слипнется
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.07 16:47
Оценка: 56 (2) +2
Здравствуйте, Курилка, Вы писали:

К>Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода.


Это миф который насаждают фанатики ФП пользующиеся языками и компиляторамии не имеющими полноценных средств отлакди (например, Хаскелисты).

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

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

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

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

И не надо рассказывать, что каждую фукнцию можно отлаживать отельно. Вам в начале нужно найти проблему. А без отладчика это сделать куда сложнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Не в тему, но про J :)
От: Gaperton http://gaperton.livejournal.com
Дата: 02.05.07 09:02
Оценка: 8 (2) :))
Здравствуйте, Mirrorer, Вы писали:

K>>Ну как это кому? Я вот на Хаскеле обсчитываю задания по матстатистике. Там есть вещи, которые не под силу Excel. Люди говорят, что для этих целей лучше подходит J, а мне вот лень его изучать, тем более синтаксис у него жуткий.


M>Синтаксис как раз не жуткий. А вот лексемы в нем .. непривычные это да.

M>Поченму-то мне кажется что основные понятия в J можно выучить в течении дня-двух. А вот научиться эффективно им пользоваться это займет некоторое время.

M>Лично я считаю J чем-то сродни математическому ассемблеру. Очень узкоспециализированный. Хотя теоретически на нем можно написать все что угодно.


На случай, если кто не сышал — удивительно то, что создатели J и К занимались, кажется, в Mitsubishi автоматизацией бизнес-процессов на APL (нет ничего более далекого от математики). И пришли к выводу, что APL для этих дел немерянно крут.

Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.
Re: Так в чем же принципиальные отличия ФП от ИП?
От: geniepro http://geniepro.livejournal.com/
Дата: 21.04.07 16:44
Оценка: :))) :)
Здравствуйте, mini_root_2, Вы писали:

MR2> Читал кусок сататью VladD2 (тот что лежит на сайте). Там описывается во введении описывается замечательный язык LISP, который является самым мощным, потому всю остальное сукс (во всяком случае посыл такой...),


Это когда же VladD2 успел разлюбить Nemerle и полюбить Лисп с жутким по его мнению синтаксисом? 8-о
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 24.04.07 03:23
Оценка: 7 (2) :)
VladD2,

LCR>>К сожалению, крупные примеры в функциональном стиле будут вряд ли интересны читателю, поэтому и ограничиваются примерами типа =take k . quicksort=.


VD>А можно с этого места по подробнее. Мне почему-то все больше и больше кажется, что дело тут не в неинтересности "читателю", а в банальном отсуствии чего показать.




Ну например известный бенчмарк chameneos
public class chameneos {

    private MeetingPlace mp;

    public static final Colour[] COLOURS = { Colour.BLUE, Colour.RED, Colour.YELLOW, Colour.BLUE };

    private Creature[] creatures = new Creature[COLOURS.length];

    public enum Colour {
        RED, BLUE, YELLOW, FADED
    }

    public class Creature extends Thread {

        private MeetingPlace mp;
        private Colour colour;
        private int met = 0;
        private Colour other;

        public Creature(Colour c, MeetingPlace mp) {
            this.colour = c;
            this.mp = mp;
        }

        public void run() {
            try {
                while (colour != Colour.FADED) {
                    mp.meet(this);
                    if (other == Colour.FADED)
                        colour = Colour.FADED;
                    else {
                        met++;
                        colour = complement(other);
                    }
                }
            } catch (InterruptedException e) {
                // Let the thread exit.
            }
        }

        private Colour complement(Colour other) {
            if (colour == other)
                return colour;
            switch (colour) {
            case BLUE:
                return other == Colour.RED ? Colour.YELLOW : Colour.RED;
            case RED:
                return other == Colour.BLUE ? Colour.YELLOW : Colour.BLUE;
            case YELLOW:
                return other == Colour.BLUE ? Colour.RED : Colour.BLUE;
            default:
                return colour;
            }
        }

        public int getCreaturesMet() {
            return met;
        }

        public Colour getColour() {
            return colour;
        }

        public void setOther(Colour other) throws InterruptedException {
            this.other = other;
        }
    }

    public class MeetingPlace {

        int n;

        public MeetingPlace(int n) {
            this.n = n;
        }

        Creature other = null;
        public void meet(Creature c) throws InterruptedException {

            synchronized (this) {
                if (n > 0) {
                    if (other == null) {
                        other = c;
                        this.wait();
                    } else {
                        other.setOther(c.getColour());
                        c.setOther(other.getColour());
                        other = null;
                        n--;
                        this.notify();
                    }
                } else {
                    c.setOther(Colour.FADED);
                }
            }
        }
    }

    public chameneos(int n) throws InterruptedException {
        int meetings = 0;
        mp = new MeetingPlace(n);

        for (int i = 0; i < COLOURS.length; i++) {
            creatures[i] = new Creature(COLOURS[i], mp);
            creatures[i].start();
        }

        // wait for all threads to complete
        for (int i = 0; i < COLOURS.length; i++)
            creatures[i].join();

        // sum all the meetings
        for (int i = 0; i < COLOURS.length; i++) {
            meetings += creatures[i].getCreaturesMet();
        }

        System.out.println(meetings);
    }

    public static void main(String[] args) throws Exception {
        if (args.length < 1)
            throw new IllegalArgumentException();
        new chameneos(Integer.parseInt(args[0]));
    }
}


{- Written by Tom Pledger, 13 Nov 2006. modified by Don Stewart -}

import Control.Concurrent
import Control.Monad
import System

data Colour = Blue | Red | Yellow

complement a b = case (a,b) of
    (Red,Yellow)    -> Blue
    (Red,Blue)      -> Yellow
    (Red,Red)       -> Red
    (Yellow,Blue)   -> Red
    (Yellow,Red)    -> Blue
    (Yellow,Yellow) -> Yellow
    (Blue,Red)      -> Yellow
    (Blue,Yellow)   -> Red
    (Blue,Blue)     -> Blue

colors = [Blue, Red, Yellow]

data MP = MP !Int !(Maybe Colour) ![Int]

main = do n   <- getArgs >>= readIO . head
        waker <- newEmptyMVar
        mpv   <- newMVar $ MP n Nothing []

        let arrive c t = do
              MP q w d <- takeMVar mpv
              case w of
                  _ | q == 0 -> if length d /= 3 then putMVar mpv $ MP 0 w (t:d)
                                                 else print $ t + sum d

                  Nothing    -> do putMVar mpv $ MP q (Just c) d
                                   c' <- takeMVar waker
                                   arrive c' $! t+1

                  Just k     -> do let c' = complement k c
                                   putMVar waker $! c'
                                   putMVar mpv $ MP (q-1) Nothing d
                                   arrive c' $! t+1

        mapM_ (forkIO . flip arrive 0) colors
        arrive Blue 0
        replicateM_ 3 yield

Если бы не погоня за скоростью, то код на Хаскеле был бы ещё короче и чище.

VD>Стается мне, что эта отмазка (которую я слушу постоянно) такое же мошейничество как присловутый quicksort который может и красив, но никак не хочет работать с той же скоростью (даже близко), что императивный.


В Хаскелл-комьюнити распространено выражение "sufficiently smart compiler", который принципиально может делать очень сильные оптимизации (и эти оптимизации описаны в научных работах и о них знают много людей), но пока практически такого компилятора нет. Поэтому на самом низком уровне (для выжимания битов из байтов) не вижу ничего криминального в том, чтобы для достижения необходимого перфоманса сделать "грязные дела".

VD>Другими словами — ФП отлично на макроуровне, когда нужно написать некий алгоритм, но вот средств композиции вепрхнего уровне у него нет. Модули не канают по сравненению с классами.


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

VD>Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.


Этот баззворд фактически является синонимом термина "coding discipline", если абстракцию невозможно оформить в библиотеку. Что скорее говорит о слабости языка, а не о величии термина "паттерн".
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 28.04.07 08:43
Оценка: 1 (1) +2
mini_root_2,

__>P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных

__>функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения,
__>но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие
__>поддержки со стороны netbeans.

Посмотри вот этот proposal от Bob Lee, Doug Lea и Josh Bloch (если ты джавист, а похоже что так и есть, то эти имена должны быть для тебя небезызвестными). Всё, что я вижу, это что в Скале этот proposal уже реализован, причём решение куда более общее, чем те частности, которые предлагают эти товарищи. Какой можно сделать вывод? Функции как первоклассные значения и замыкания лучше иметь прямо в языке, чем уметь их эмулировать с помощью ООП. Это касается и остальных элементов ФП.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 21.04.07 13:21
Оценка: +3
Здравствуйте, Аноним, Вы писали:

А>Вообщето это все можо сделать и вто так:


А>
А> Код поскипан...
А>


А>Пишется несколько длиннее но результат тот же самый.


Дык всё можно сэмулировать: языки-то Тьюринг-полные. У тебя здесь порядка 60 идентификаторов, а у Mamut'а меньше 15. А на Хаскелле та же мелодия угадывается с пяти нот:
fun = (+)
myvar = fun 2


Тестируем:
Hugs> myvar 1
3
Hugs> myvar 4
6
Hugs> myvar 47
49


Мораль: чем более "функционален" язык, тем лучше он заточен под работу с функциями (в.т.ч. высшего порядка).
Re: Так в чем же принципиальные отличия ФП от ИП?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 21.04.07 13:27
Оценка: +2 -1
Здравствуйте, <Аноним>, Вы писали:

А>один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете


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

Касательно второго подхода — это не обязательно удел ФЯ. В том же С++ есть средства метапрораммирования. Просто в C++ эта фича реализована малость извртано. Вообще, метапрограммирование "дружит" с ФЯ, т.к. ФЯ содержит кучу сахара для облегчения написания макросов.

А>Начнем по порядку:


А>1) Функции высшего порядка (название то какое!) — принимают функции в качестве аргментов

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

Да, можно. Но написать функцию — быстрее и лаконичнее, чем каждый раз создавать объект. Ещё в ФЯ есть вложенные функции, лямбды и замыкания — неслабый такой сахар. Конечно, это всё эмулируется на классах. Но попробуй сам попиши с использованием перечисленных фич и без их использования (эмуляцией), и сам поймёшь в чём прелесть. Правда, стоит оговориться, что выбор того или иного подхода часто диктуется самой задачей. Иногда проще и понятнее добавить лишний класс. Но порой глаза начинает рябить от многочисленных XXXView, XXXHandle, XXXInfo, XXXDescriptor, которые имеют примитувную внутреннюю структуру и используются в двух-трёх случаях.

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

А>2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)

А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
А>И.т.д.

Опять же, вопрос удобства.

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


По сути, так оно есть. Большинство ФЯ (начиная с Лиспа) — это ИЯ с сахаром, в том числе поддерживающим и упрощающим функциональное программирование.


PS: продолжаю заниматься наглым самопиаром. А потому даю ссылочку сюда
Автор: konsoletyper
Дата: 13.04.07
, как пример использования ФЯ. Советую особенно посмотреть на вещи, связанные с генерацией ДКА и LALR-таблицы (src\Common\Bnf, src\Common\Finite, scr\Common\Grammar) и с распарсиванием BNF (src\BnfParser).
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 22.04.07 21:24
Оценка: -2 :)
Здравствуйте, Аноним, Вы писали:

А>1) Функции высшего порядка (название то какое!)


А математики особой фантазией на названия никогда не отличались. Традиционалисты-с.

А>Вопрос: А чем это отличается от метода который


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

А>2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)

А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?

Мешает то, что для этих ваших объектов нет такой простой и понятной модели, как банальное декартово произведение множеств.

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

А> Читал кусок сататью VladD2 (тот что лежит на сайте). Там описывается во введении описывается замечательный язык LISP,


Lisp вообще никогда не был языком ФП. Лисп — это императивный язык, ориентированный преимущественно на метапрограммирование. Совсем другая область, гораздо более практичная и приземлённая.

А>Вот мне, например, нужно написать универсальный траснпорт между подразделениями, по которму может ездить что угодно куда угодно а код менять не надо, сейчас играюся с диким гибридом Jetty+Axis2+Quarts+Xalan+JDBC (как я понимаю к ФЯ с натяжкой можно отнести только XSLT) и мнея абсолютно неважно кто, где и как считает факториал.


А я бы с дикими гибридами из всяких разных уродцев не игрался, и построил бы тупейшую агентную модель, взяв за основу для протокола SXML и какую либо легковесную реализацию языка Scheme. Уложился бы строк в 100 кода и часа в два работы.

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


Шаблоны нужны там, где язык настолько убог, что заставляет одну и ту же абстракцию реализовывать многократно. Функциональщик же любую конструкцию, аналогичную встречающимся в GoF реализует ровно один раз, и забудет про неё навсегда. Кстати, самый часто употребимый функциональщиками pattern — "interpreter pattern". Но для постижения этого факта вам надо постичь дзен.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.04.07 08:54
Оценка: :)))
Здравствуйте, Gaperton, Вы писали:

VD>>Не смотря на то, что объяснить приемущества невозможно, все же можно продемонстрировать их результат. Вот здесь
Автор: VladD2
Дата: 30.12.06
приведено два исходника идентичные с точки зрения решаемой задачи, но исходник написанный на языке поддерживающем ФП (аналог Скалы — язык Немерле) примерно в четверо короче и в 10 раз выразительнее. И это не маги, подтасовки или спецэффекты. Это просто грамотное применение того самого "сахара".


G>Гхм... Ты на сахар-то эта, особо не налегай... Чему людей учишь? Али не наешь, что от сладкого зубы портятся?


Ну, можно было это назвать солью языка, но ведь от соли тоже разные органы страдают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 02.05.07 02:23
Оценка: +1 -2
VladD2, Вы писали:

M>>Хм. Что есть "проектирование на макро-уровне"?


VD>Этому вопросу посвящено не мало умных книг. Есть масса методик и подходов.


Всё что нужно на макро-уровне — это поименовать сущности, и формализовать (хотя бы как-нибудь) зависимости между ними и расположить в иерархию. Об этом ещё Гради Буч писал. А способы формализации конечно же зависят от языка, главное что средства выражения абстракций есть
Автор: lomeo
Дата: 27.04.07
.

M>>Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки.


VD>Это механизмы абстрации С и Паскаля.


Модули нормально подходят для построения больших систем. Причём невозможность создавать "экземпляры модулей" ничуть не уменьшает возможность абстрагирования, и вопрос о создании экземпляров — это чисто вопрос спецификации контрактов.
handle_call(current_snapshot, _From, State) ->
    {reply, {ok, internal_current_snapshot(State)}, State};

Можно создавать высоко-реюзабельные кусочки, из которых потом будет состоять три четверти всего функционала. Примеры: gen_server, gen_event, gen_fsm, библиотеки комбинаторов, модули, функторы (в ocaml).

Да, кстати, покажи мне хотя бы одну библиотеку комбинаторов на Паскале.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[8]: Мой ник
От: deniok Россия  
Дата: 08.05.07 13:10
Оценка: :)))
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Здравствуйте, konsoletyper, Вы писали:


K>>Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!


ДГ>Заведи себе лучше GUID, как все нормальные люди.


Их уникальность гарантированна вроде всего на 700 лет вперёд. Может он собирается прожить дольше?
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 08.05.07 16:28
Оценка: +3
Здравствуйте, Константин Л., Вы писали:

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


D>>Здравствуйте, Константин Л., Вы писали:


КЛ>>>По-моему, чистый фп подход продьюсит спагетти-код



КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.

КЛ>2. слабо структурированная. Туда же.

Извини, но это уже неприкрытый флейм. Реч шла про код.

КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси


Лямбды не порождают спагетти — они замкнуты на себя и никуда не ссылаются.

КЛ>4. трудная для понимания программа. см. пункт 3.

КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

А с ними то что не так? Лаконичнейшее средство абстрагирования
map унарная_функция список


fold бинарная_функция инициализатор список

Где тут спагетти?

Что касается претензий к читабельности, то, извини, любой язык надо сначало изучить, пописать на нём какое-то время, а уж потом рассуждать об этой самой читабельности. А то вот я по-финнски ничего не понимаю, нечитабельный, блин, язык.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 08.05.07 20:30
Оценка: +3
Здравствуйте, Константин Л., Вы писали:


КЛ>>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.


K>>Кто сказал такую глупость. ...


КЛ>здесь сказали такую глупость и я с ней согласен
Автор: VladD2
Дата: 23.04.07


Я так и не понял, что там имелось ввиду.

В Хаскелле инкапсуляция достигается с помощью системы модулей, которые помимо этого играют роль пространств имён.
А наследование и полиморфизм (специальный) реализованы с помощью классов типов (аналог обобщённых интерфейсов) и возможности для типов данных эти интерфейсы воплощать.

Так что весь ООП-шный инструментарий в наличии.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: WolfHound  
Дата: 10.05.07 09:21
Оценка: +2 -1
Здравствуйте, deniok, Вы писали:

D>Да, чистая лямбда — это, конечно, то ещё спагетти. Но, в отличие от goto, немножко лямбды кода не испортит.

Тут как посмотреть... правильно поставленные goto тоже код не портят...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 18:25
Оценка: +1 :))
Здравствуйте, Константин Л., Вы писали:

КЛ>Ладно, мой поинт в том, что оо+фя гораздо привлекательнее и "живучее" чем чистые фя.


Так это вполне нормальный пойнт . У меня пойнт оф вью, что характерно, зе сэйм. Однако с остальным содержимым твоих постов я при этом не согласен . Прикольно, однако .
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 21.04.07 14:19
Оценка: 35 (2)
Аноним,

А>Игрался неделю со scala, до этого читал статьи всяких проповедников ФП(один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете). В результате пребываю в довольно странном состоянии — "И ЭТО ВСЕ? И ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ ИП?".


Отличия ФП от ИП очень много обсуждалось здесь (с переменным успехом)

А>1) Функции высшего порядка (название то какое!) — принимают функции в качестве аргментов

А>и возвращают другме функции.
А>Вопрос: А чем это отличается от метода который принимает в качестве аргумента объект и возвращает другой, у которых есть не только свои методы и переменные члены, но и которые соответствуют определенной сущности предметной область.
Если интерфейс соответствует сущности — отлично. Это должна быть крупная сущность, иначе мы упрёмся в создании миллиона интерфейсов на каждый писк, типа IFile, IFileArchived, IFileArchivedWithRAR, IFileArchivedWith7z и т.п. И созданием объектов типа
interface IFromIAndI {
   Integer call(Integer a, Integer b);
}

IFromIAndI add_two_integers = new IFromIAndI() {
   public Integer call(final Integer a, final Integer b) {
      return a + b;
   }
};

Намано?

Ещё пример. Дан регексп, нужно узнать, матчится ли он с текстом:
Pattern pattern = new Pattern(regexp);
Matcher matcher = pattern.matcher(text);
if (matcher.matches()) ...

Это и есть исполнение в Королевстве Существительных. Ты должен сначала создать нужных исполнителей, а потом сказать им: "Ду!" вместо непосредственного исполнения =matches regexp text=. Кроме замутнения самого Действия мы вдобавок получаем кучу побочных эффектов на пустом месте, там где можно было вполне обойтись без них.

К сожалению, крупные примеры в функциональном стиле будут вряд ли интересны читателю, поэтому и ограничиваются примерами типа =take k . quicksort=.


А>2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)

А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
А>И.т.д.

Тебе нужно заводить тип (то есть плодить сущности без надобности), ты не можешь отождествлять объекты в соответствии со структурой, и ты не можешь делать паттерн-матчинг по содержимому объектов (обычно так, хотя в Scala есть unapply) и работа с объектами (обычно) более громоздка по сравнению с работой с кортежами.


А>Я прекрасно понимаю что ФП в чистом виде мало применимо



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


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

А>В процессе прочтения статей я видел кучу примеров (в основном всякие математические вычисления или сортировка). Но я нигде не видел РЕАЛЬНЫХ примеров (из тех областей для которых пишется большинство программ).


Очень скользкая фраза... По причине выше, скорее всего на Скале будет мало чистых функциональных программ и всё ФП там представляет собой просто "сахарницу" средних размеров.

Реальное применение вообще ФП? Ну можно начать отсюда
http://rsdn.ru/Forum/Message.aspx?mid=2182617&amp;only=1
Автор: Didro
Дата: 26.10.06


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


В ФП паттерны часто являются просто ФВП. Ну вот fold — чем не паттерн? Или map-reduce? Или класс типов Monad?
Reusable — безусловно. General — тоже (в рамках применимости конечно ).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[24]: А за что же минус-то? :) [-]
От: Mirrorer  
Дата: 07.05.07 09:39
Оценка: 30 (2)
Здравствуйте, Mamut, Вы писали:

M>Помнится, в Германии надо было гос. портал по поиску работы переделать. Сделать его более удобным в использовании и быстрым. 2 или 3 года, 40 миллионов долларов. Портал так и не сделали.

Почему-то напомнило эту историю
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 10.05.07 17:54
Оценка: 18 (2)
Здравствуйте, Gaperton, Вы писали:

G>б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

G>Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.

module OO where

import Control.Monad
import Data.IORef

type Mutable = IORef 

data MyObject = MyObject { state :: Mutable Int, 
                           otherObject :: Mutable (Maybe MyObject) }
              deriving Eq

nullObject = newIORef Nothing

createMyObject :: Int -> IO MyObject
createMyObject init = do 
  x <- newIORef init
  other <- nullObject
  return (MyObject {state=x, otherObject=other})

setOther obj other = writeIORef (otherObject obj) (Just other)
readOther obj = readIORef (otherObject obj)
modifyState obj = modifyIORef (state obj)
readState obj = readIORef (state obj)

makeObjLoop = do 
  o1 <- createMyObject 1
  o2 <- createMyObject 2
  o3 <- createMyObject 3
  setOther o1 o2
  setOther o2 o3
  setOther o3 o1
  return o1

printLoop o = printLoop' o []
  where printLoop' obj visited = when (not (obj `elem` visited)) $ do          
                                  n       <- readState obj
                                  nextRef <- readOther obj
                                  putStrLn (show n)
                                  case nextRef of
                                    Just next -> printLoop' next (obj:visited)
                                    Nothing   -> putStrLn "You lied, this is not loop"


main = do
  loop <- makeObjLoop
  printLoop loop
  modifyState loop (+1)
  printLoop loop
  modifyState loop (+100)
  printLoop loop

Оно? Или ты что-то более сложное имел в виду? Прошу обратить внимание на 'deriving Eq' и 'obj `elem` visited' — это обещанная Identity. Полиморфизму сверху добавить тоже можно.
з.ы. Я не говорю, что так нужно делать, но можно — факт
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: R.K. Украина  
Дата: 10.05.07 21:05
Оценка: 18 (2)
Здравствуйте, palm mute, Вы писали:

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


G>>б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

G>>Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.

[skip]
PM>з.ы. Я не говорю, что так нужно делать, но можно — факт

Можно сделать и попроще. Вот так:
import Data.IORef
import Control.Monad
import Control.Monad.Fix

data Loop a = Loop a (IORef (Loop a))

seed n = mfix $ liftM (Loop n) . newIORef

(Loop _ ref) `intro` n = do
    a <- readIORef ref
    c <- liftM (Loop n) $ newIORef a
    writeIORef ref c

readLoop (Loop n init) = cons n init
    where
    cons n ref = liftM (n:) $ readIORef ref >>= intern
    intern (Loop n ref) = if ref==init then return [] else cons n ref

main = do
    oo <- seed 5
    mapM_ (oo `intro`) [8,6,7,9,4,2,0,1,3]
    readLoop oo >>= print

Получается односвязный список с возможной простой модификацией в двусвязный (просто добавить в тип еще один IORef и слегка подправить seed и intro).
You aren't expected to absorb this
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.05.07 20:43
Оценка: 1 (1) +1
Здравствуйте, Константин Л., Вы писали:

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


K>>И что же, по твоему clisp — чисто функциональный?


КЛ>а вот тут то я и попался


КЛ>насколько помню с ооп там было бедненько


Ммм, CLOS — это бедненько?
Re: Так в чем же принципиальные отличия ФП от ИП?
От: IT Россия linq2db.com
Дата: 22.04.07 01:24
Оценка: +2
Здравствуйте, <Аноним>, Вы писали:

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


Не парься. Не стоит рассматривать ФП как альтернатива ИП или ООП. ФП надо рассматривать как дополнение к ним, тогда всё будет очень хорошо
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.07 14:50
Оценка: +2
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>К сожалению, крупные примеры в функциональном стиле будут вряд ли интересны читателю, поэтому и ограничиваются примерами типа =take k . quicksort=.


А можно с этого места по подробнее. Мне почему-то все больше и больше кажется, что дело тут не в неинтересности "читателю", а в банальном отсуствии чего показать.

Стается мне, что эта отмазка (которую я слушу постоянно) такое же мошейничество как присловутый quicksort который может и красив, но никак не хочет работать с той же скоростью (даже близко), что императивный.

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

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


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

LCR>Очень скользкая фраза... По причине выше, скорее всего на Скале будет мало чистых функциональных программ и всё ФП там представляет собой просто "сахарницу" средних размеров.


А кому нужны чистые фунциональные? Людям нужно писать программы проще, быстрее и удобнее.

LCR>В ФП паттерны часто являются просто ФВП. Ну вот fold — чем не паттерн? Или map-reduce? Или класс типов Monad?


Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 23.04.07 19:08
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Не смотря на то, что объяснить приемущества невозможно, все же можно продемонстрировать их результат. Вот здесь
Автор: VladD2
Дата: 30.12.06
приведено два исходника идентичные с точки зрения решаемой задачи, но исходник написанный на языке поддерживающем ФП (аналог Скалы — язык Немерле) примерно в четверо короче и в 10 раз выразительнее. И это не маги, подтасовки или спецэффекты. Это просто грамотное применение того самого "сахара".


Гхм... Ты на сахар-то эта, особо не налегай... Чему людей учишь? Али не наешь, что от сладкого зубы портятся?
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.04.07 20:26
Оценка: +2
Здравствуйте, VladD2, Вы писали:

L>>Мда.. Паттерн — это типичное решение типичной проблемы (в типичном языке ).

L>>Нет проблемы — нет необходимости в решении.

VD>Нет проблем только у тех кто ничего не делает. Паттерны есть в любом языке. Это просто общие решения общих проблем. Все в язык не впихнешь. Так что Косолетайпер верно говорит, без макросредств паттерны один фиг нужны. Ну, есть правда один путь. Писать настолько тупо и не о чем не думать. Правда даже не очень большие программки будут рассыпаться, но зато будет чем гордиться.


Зачем ты мне это написал? Те паттерны, о которых, как я понял, шла речь, это не общие решения общих проблем. Это решения типичных проблем объектно-ориентированного проектирования.

L>>В ФП свои проблемы и свои паттерны.


VD>Чем это противоречит словам Косолетайпера?


А должно? Моя мысль была в том, что некоторые паттерны из GoF (о которых шла речь, "остальные кроме посетителя") просто не нужны в FP. В FP свои задачи и свои решения.

L>> В языках без поддержки императивности


VD>А что такие есть в природе?


Есть.

L>> — CPS/монады,


VD>А что монады уже не императивны?


Нет.

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


VD>Ага. Причем иногда так приходится извращаться, чтобы сэмулировать примитивен действия, что паттерны ООП, которые работают в основном на уровне проектирования, просто кажутся огромными абстракциями.


Бывает. А бывает и наоборот

VD>ЗЫ


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


На провакационные вопросы отвечать не хочется Интересно — посмотри для начала Why FP matters Хьюза. Дальше — катаморфизм, полиморфизм, генерики. Это то, что работает на уменьшение сложности программы. Есть паттерны и для композиции, low coupling и high cohension, но они обычно языко-зависимые, как например, умные конструкторы.
Кстати, насчёт терминов, я всегда думал, что макро-уровень — это когда ворочаешь большими блоками, а микро — когда работешь пинцетом под микроскопом.
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.07 10:52
Оценка: +2
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Ну например известный бенчмарк chameneos

...
LCR>Если бы не погоня за скоростью, то код на Хаскеле был бы ещё короче и чище.

Демонстрации средств проектирования снова нет. Снова использование синтаксического сахара позволяющего уменьшить объем реализации. Другими словами, снова демонстрация приемуществ на микроуровне при полном игнорировании макроуровня.

Что и требовалось доказать! ФП просто не имеет средств абстрагирвоания уровня большого проекта. В нем есть исключительно средства оптимизации уровня отдельных алгоритмов.

Вот, собственно, по этому и имеет смысл использовать гибридные языки позвляющие использовать ООП для проектирования "в большом" и ФП для согращения кодирования и создания более понятного кода.

LCR>В Хаскелл-комьюнити распространено выражение "sufficiently smart compiler", который принципиально может делать очень сильные оптимизации (и эти оптимизации описаны в научных работах и о них знают много людей), но пока практически такого компилятора нет.


Сочувствую.

LCR> Поэтому на самом низком уровне (для выжимания битов из байтов) не вижу ничего криминального в том, чтобы для достижения необходимого перфоманса сделать "грязные дела".


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

VD>>Другими словами — ФП отлично на микроуровне, когда нужно написать некий алгоритм, но вот средств композиции вепрхнего уровне у него нет. Модули не канают по сравненению с классами.


LCR>И в каком же аспекте они не канают?


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

VD>>Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.


LCR>Этот баззворд фактически является синонимом термина "coding discipline", если абстракцию невозможно оформить в библиотеку. Что скорее говорит о слабости языка, а не о величии термина "паттерн".


Треп это пустопорожний. Нет в природе языков включающих все и вся. И нельзя паттерны впихнуть в функции или классы. ФП тут вообще ничего не решает. Единственное универсальное средство превращения паттернов в декларативные конструкции — это макросы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Мой ник
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.04.07 06:54
Оценка: :))
Здравствуйте, VladD2, Вы писали:

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


K>>Вообще-то, ник я придумывал не для того, чтобы его пытались зачитать вслух или перевести на русский. Может, специально для этих целей мне поменять ник на фамилию/имя?


K>>PS: напоминает случай с Cyberax'ом


VD>Так, а что тебя не устраивает? Мне просто влом переключаться на англицкий.


Ну, тогда не Косолетайпер, а Консолетайпер. Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 27.04.07 07:46
Оценка: +2
Здравствуйте, lomeo, Вы писали:

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


VD>>В грануляности. Нет экземлпяров.


L>Увы! Модули — это не аналог классов, это аналог пакетов.


VD>>Спроектировать большую систему в терминах модулей просто невозможно. В терминах функций можно, но очень сложно.


L>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.



Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров:
1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных.
2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур, которые вызывают другие процедуры
(я намеренно не использую слово "функция"), использование глоабальных переменных не приветствуется. Сразу возникает вопрос как передавать
эти переменные при вызове, единственный разумный вариант — в виде структуры. Но структуры — это первый шаг к ООП. При построение
большого приложения, возможно потребуется подменить что-то не исправляя кода, а заодно привязать те или иные процедуры к строго определенному
контексту.
3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.

VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например:
public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем
же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат
методы для управления подсистемой в целом (start/shutdown).
А вот при описании этого же в термених ФП мы вернемся к пункту 2, отчего несколько десятилетий назад наооборот пытались уйти.

Глупый вопрос к VladD2: а что дают макросы? Они позволяет встроить кодогенерацю внутрь программы и управлять ей из нее же?
Вещь конечно заманчивая, но не возникнет ли бардака?

P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных
функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения,
но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие
поддержки со стороны netbeans.
Re[7]: Мой ник
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.07 08:07
Оценка: :))
Здравствуйте, konsoletyper, Вы писали:

K>Ну, тогда не Косолетайпер, а Консолетайпер.


Ну, это просто очепятка. Извини. Я с тем же успехом мог бы написать kosoletyper.

K> Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!


Э... тогда могут начать писать "этот !@#$%^" .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.07 10:55
Оценка: +2
Здравствуйте, Mamut, Вы писали:

M>Ну и чем это отличается от объекта?


"Это" ничем, так как является эмуляцией ООП на не поддерживающем на прямую эту парадигму языке. То есть то же ООП, только слишком многословно и сложно.

M> Состояние этот модуль тоже может хранить (см. gen_server в документации по Эрлангу ну или здесь).


Это, как я понимаю, эмуляция глобальных переменных.

Модуль же отличается от объекта, тем что не позволяет создать свои экземляры.

ЗЫ

Никто не спорит, что любой процедурный язык позволяет эмулировать ООП.

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

Если все что оно дает — это возможность эмулировать ООП так же как это делали 30 лет назад на С, да еще и ченит препятствия, то в пору задуматся, а на хрена козе баян?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.07 11:26
Оценка: +1 :)
Здравствуйте, Курилка, Вы писали:

К>В свете этого сразу вспоминается идея параметризуемых модулей в Эрланге, которые фактически и являются экземплярами.

К>Т.е. опять же эмуляция.

Изобретение велосипеда самое увлекательное занятие из придуманных человечеством.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 03.05.07 09:10
Оценка: +1 -1
VGn>Не сократит.
VGn>Замена дешёвых кодеров на Разработчиков сократит раза в 2 от силы.
VGn>Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.
VGn>А значит + ещё 1000 кодеров.

Это из разряда "87.34569712% всех приводимых цифр взяты с потолка"?

VGn>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.


А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"

Телекоммуникации, data mining — это вполне такие системы. А ФП там применяются.

VGn>В моём нынешнем проекте из 15 сборок ФП напрашивается толко в 5.

VGn>И то — ещё только потому, что на него завязано меньше бизнес-логики и больше системных задач.

Ну а в моем нынешнем проекте вообще нет ФП Потому что Coldfusion И о чем это говорит? Ни о чем


dmitriid.comGitHubLinkedIn
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 15:11
Оценка: -2
Здравствуйте, Аноним, Вы писали:

[]

По-моему, чистый фп подход продьюсит спагетти-код
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Дм.Григорьев  
Дата: 08.05.07 15:38
Оценка: -2
Здравствуйте, граммофон, Вы писали:

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


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

Г>Какие глобальные проблемы с декомпозицией решает ООП я не понимаю. По-моему он только проблемы создает на ровном месте увеличением сущностей и созданием дополнительной связности между частями с помощью своих иерархий.


Нутром чую, что про выделенное тоже басня была, и не одна, да вот вспомнить не могу... Ну так предложи более эффективную методологию, чем ООП. Чтобы решать сложные задачи, да по щучьему велению. Джин-мартини "Фаулер" в бутылке.

Г>модулями, неймспейсами, пакетами и тп. То есть чисто функционально.


Гы. Модули, неймспейсы и пакеты — ЭТО ДААААА, это без базару, это главные атрибуты функционального программирования. Можно сказать, характеристические. Не удивительно, что тебе никто даже ответить не удосужился. (Я не в счёт, я развлекаюсь.)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: Gajdalager Украина  
Дата: 09.05.07 10:40
Оценка: +2
Здравствуйте, Константин Л., Вы писали:

КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

Это ж где? Посмотри на Яву и на ГоФ.. Паттерн Command, интерфейсы Comparator, Runnable и иже с ними — как раз следствие отсутсвия ФВП, точнее, что-то типа эмуляции ФВП через объекты..
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Чур — Карна
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: Трурль  
Дата: 10.05.07 05:33
Оценка: :))
Здравствуйте, Константин Л., Вы писали:

КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему.

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

Меньшевики-комбинаторщики любят ссылаться на откровения преп. Дж.Бэкуса:

The lambda expression (with its substitution rules) is capable of defining all possible computable functions of all possible types and of any number of arguments. This freedom and power has its disadvantages as well as its obvious advantages. It is analogous to the power of unrestricted control statements in conventional languages: with unrestricted freedom comes chaos.

Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 10.05.07 14:06
Оценка: +2
КЛ>Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

arr = [1, 2, 3, 4];

for(i = 0; i < arr.length; i++)
{
    some_func(arr[i]);
}


versus

arr = [1, 2, 3, 4];

map(arr, some_func);


Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )


dmitriid.comGitHubLinkedIn
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: Mirrorer  
Дата: 11.05.07 05:54
Оценка: :))
Здравствуйте, lomeo, Вы писали:

L>поэтому сохраняется чистота, но одновременно можем менять состояние (такое вот противоречие).


Угу. Из той же серии что и звук хлопка одной ладонью.
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: Трурль  
Дата: 11.05.07 13:13
Оценка: :))
Здравствуйте, palm mute, Вы писали:

PM>Даруйте, пане, я щирий українець.

Для нас, чукчей, вы все на одно лицо.

PM>>>Но ты же не будешь утверждать, что C++, например, не подерживает присваивания на том основании, что нельзя реализовать на C++ оператор присваивания для встроенных типов.

Т>>Не буду. А если бы стал, то меня ткнули бы носом в п. 5.17.
PM>Ничего опровергающего мои слова я там не нашел. Или это было согласие?
Упс, п. 5.17. ISO 14882. Ну да, согласие. Присваивания C++ подерживает и я не буду утверждать обратного.
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 14.05.07 10:38
Оценка: :))
M>>Будем считать особенностями реализации В С++ вон map — это вообще тип данных, и ничего

VD>Там мы сравниваем разные вещи имеющие одинаковые названия, или все же в нас еще осталась чистичка разума?


Все, сдаюсь, сдаюсь


dmitriid.comGitHubLinkedIn
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 25.05.07 11:26
Оценка: +1 :)
G>1) Ромбик мне из объектов не изобразите? Чтобы два иорефа в структуре данных на один объект указывали. Зело хоцца на идентити в действии поглядеть.

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

main = do x <- newIORef 1
          a <- readIORef x
          writeIORef x (a+1)


эвивалетно следующему:

main()
{
    int* const x = new int(1);
    const int a = *x;
    *x = a+1;
}


можно также написать эквивалентный с++ код с использованием references, но они синтаксически-невидимо разыменовываются

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

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


с другой стороны, в хаскеле низкоуровневый имеративный код я писал только в двух случаях — для general-purpose библиотек, где нужна максимальная эффектвиность, и как часть кода, работающего с низкоуровневыми императивными библиотеками (написанные на C++). писать же императивные алгоритмы обработки данных на хаскеле — это в большинстве случаев нонсенс
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: z00n  
Дата: 23.04.07 14:56
Оценка: 26 (1)
Здравствуйте, Кодт, Вы писали:

К>Как-то однажды знаменитый учитель Кх Ан вышел на прогулку со учеником Антоном ...


Кстати, если кто не знает, этого Антона целиком зовут — Anton van Straaten
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html

Там же, Guy Steele предложил сл. формулировку — "замыкания — это объекты с единственным методом — apply"
Топик целиком:
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03215.html
Re[23]: А за что же минус-то? :) [-]
От: Mamut Швеция http://dmitriid.com
Дата: 07.05.07 07:45
Оценка: 12 (1)
M>>Просто +1000 кодеров — это совсем необязательно.
VGn>Рост сложности прямо пропорционален росту трудозатрат.

Почему? И откуда это следует?

Помнится, в Германии надо было гос. портал по поиску работы переделать. Сделать его более удобным в использовании и быстрым. 2 или 3 года, 40 миллионов долларов. Портал так и не сделали.

С другой стороны Flickr, YouTube и даже Google начинались чуть ли не на коленке.

M>>Я честно не понимаю, как бизнес-логика связана с формочками.

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

VGn>Если говорить о реализации, то ты прав на все 100%.

VGn>Но разговор изначально был о целях. Любой встречный ПМ скажет тебе, что важнее чтобы "Эта иконка была василькового цвета" (с)FightClub,
VGn>чем твой способ доступа к БД или протокол передачи данных.

Что важнее в системе? Иконка василькового цвета или протокол передачи данных? Пусть иконка будет хоть фотореалистично нарисована, но если протокол передачи данных глючит, то иконка положение не спасет.

Мне интерфейс доступа к данным все равно на чем писать. Хоть на Coldfusion. Мы же не только о формочках говорим. Мы говорим о

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


Пример

If you want to do a simple round-trip from BOS to LAX in two weeks, coming back in three, willing to entertain a 24 hour departure window for both parts, then limiting to "reasonable" routes (at most 3 flights and at most 10 hours or so) you have about 5,000 ways to get there and 5,000 ways to get back. Listing them is a mostly trivial graph-search (there are a few minor complications, but not many), that anybody could do in a fraction of a second.

The real challenge is that a single fixed itinerary (a fixed set of flights from BOS to LAX and a fixed set back) with only two flights in each direction may have more than 10,000 possible combinations of applicable "fares", each fare with complex restrictions that must be checked against the flights and the other fares. That means that the search space for this simple trip is of the order 5000 x 5000 x 10000, and a naive program would need to do a _lot_ of computation just to validate each of these possibilities.




Если вы хотите слетать из BOS в LAX и обратно через две недели с возвратом через три, так, чтобы было окно в 24 часа перед вылетом в обе стороны, то ограничение возможных полетов (максимум 3 вылета в течение 10 часов) состоит в выборке из примерно 5000 вариантов полета туда и 5000 вариантов полета оттуда. Список этих полетов достигается простым поиском по графу, которые кто угодно может сделать в долб секунды.

Сама проблема состоит в том, что один фиксированный план полета с только двумя вылетами туда/обратно может содерждать более 10 000 комбинаций стоимости, каждая из которых содержит строгие ограничения, которые должны быть сопоставлены с другими стоимостями и полетами. Таким образом область поиска на одно путешествие — 5000 x 5000 x 10000, и наивной программе придется совершать множество вычислений для тго, чтобы проверить все возможности


Ну и причем в описанной проблеме формочки?

Вот эти формочки: http://www.orbitz.com/ (вверху было описание именно этого сервиса). Эти формочки вполне декларативно описываются в HTML. А вот бизнес логика — это та самая скрытая часть айсберга. И написана она может быть на чем угодно.

Orbitz — это Lisp + C
Ядро Амазона — это Lisp + C

M>>Ну а в Эрикссоне и Нортеле применяется. И это тоже факт

VGn>Это по большей части системный софт.

И? Выдержка из описания AXD 301 switch

Call handling

The following connection types are supported in the AXD 301:
• Permanent connections set up by operator order.
— Point-to-point virtual-path and virtual-channel connections.
— Point-to-multipoint virtual-path and virtual-channel connections.
• On-demand, end-to-end connections set up from subscribers via signaling.
— Point-to-point, virtual-channel connections.
— Point-to-multipoint, virtual-channelconnections.
• Soft permanent, edge-to-edge connections across a PNNI routing domain set up by operator demand.
— Point-to-point, virtual-channel connections.
— Point-to-multipoint, virtual-channelconnections.

For on-demand control of connections, three different signaling protocols are presently supported:
• UNI and Q.2931—for users and private networks; this interface may also be used between public networks when BICI is not supported.
• PNNI—for use between nodes in the same network.
• BICI (B-ISUP)—for use between public networks, between nodes where PNNI is not supported, or between PNNI routing domains within a network.


Ключевые моменты выделены. У операторов/подписчиков вполне могут быть себе формочки для управления/настройки этого самого свитча. Но они не составляют и десятой части всей логики системы. А система вполне себе благополучно написана на функциональном Эрланге.

M>>Я просто не понимаю, почему

M>>

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


M>>Может, их просто надо правильно готовить?


VGn>Есть рецепты?


Наверняка есть Народ ведь пишет (см. примеры выше). И более того, радуются, когда пишут


dmitriid.comGitHubLinkedIn
Re[25]: А за что же минус-то? :) [-]
От: Mamut Швеция http://dmitriid.com
Дата: 08.05.07 06:56
Оценка: 8 (1)
M>>Помнится, в Германии надо было гос. портал по поиску работы переделать. Сделать его более удобным в использовании и быстрым. 2 или 3 года, 40 миллионов долларов. Портал так и не сделали.
M>Почему-то напомнило эту историю

В Германии все похуже: http://europa.eu.int/idabc/en/document/2210/353

Я цифры подзабыл однако. Оценка стоимости была 65 миллионов евро. В итоге оценка показала, что он будет стоить около 165 миллионов к 2008 году. Портал в итоге так и не запустили.


dmitriid.comGitHubLinkedIn
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.07 14:50
Оценка: 6 (1)
Здравствуйте, lomeo, Вы писали:

L>Мда.. Паттерн — это типичное решение типичной проблемы (в типичном языке ).

L>Нет проблемы — нет необходимости в решении.

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

L>В ФП свои проблемы и свои паттерны.


Чем это противоречит словам Косолетайпера?

L> В языках без поддержки императивности


А что такие есть в природе?

L> — CPS/монады,


А что монады уже не императивны?

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


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

ЗЫ

Кстати, хочется задать один провакационный вопрос. Вот паттерны проектирвоания в ООП появились для облегчения проектирвоания больших и комплексных приложений. А что в этом плане придумано в ФП? Я вот сколько не гляжу, а все фишки ФП так или иначе крутятся вокруг микро-уровня. Собственно никто не спорит, что паттерн-матчинг вещь отличная, и красивая работа с фукнциями и замыканиями тоже очень удобно, но это все дает эффект только на довольно низктом (микро) уровне. А как насчет уровня приложения (и большого)?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.07 08:41
Оценка: 3 (1)
Здравствуйте, mini_root_2, Вы писали:

__>Глупый вопрос к VladD2: а что дают макросы? Они позволяет встроить кодогенерацю внутрь программы и управлять ей из нее же?

__>Вещь конечно заманчивая, но не возникнет ли бардака?


Макрос позволяют оформлять свои мысли максимально близко к идеалу. Простой пример — сплайс-строки. Со времен С (да, пожалуй по раньше) люди хотели записать код формирования строк максимально близко к внешнему виду этой строки при выоде. Но ни ООП, ни ФП не дает возможности получить действительно желаемый результат. Точнее иногда удается приблизиться к идеалу, но постоянно что-то получается не так. В С printf был захардкожен в язык (как тип вызова процедуры) и при этом был очень небезопасным. В Яве и Шарпе пошли ОО-путем, но получилось довольно не эффективно и все проверки типов переехали в рантайм. Почти замечательно все получилось только в нитерпретаторах, но опять же все проверки в рантайме.

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

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

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

Панацей небывает. Любое средство имеет свой набор ТТХ. И только сочетакние передовых срредств в купе с хорошей подготовкой специалистов и созедательной фантазией позволит нам выйти на новый, более продуктивный уровень разработки ПО.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Так в чем же принципиальные отличия ФП от ИП?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 03.05.07 09:07
Оценка: 2 (1)
palm mute,

VGn>>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.

PM>Не торопитесь. Функционально-реактивные графические интерфейсы — очень активная область исследований в последнее время. Пролистайте туториал по flapjax, например, и убедитесь, что функциональное описание поведения интерфейса в терминах зависимостей между контролами может быть значительно проще привычных Form1.Button1_OnClick().

Обожаю калькулятор!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.07 16:44
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>Просто суть в том, что функциональная композиция она выражает другую точку зрения на проблему, отличную от ООП, которая в GoF преподносится. Собственно об этом мамут уже написал


Скажи, а верующие в эту религию могут продемонстриовать отличия этого великого учения от проектировния с использованием структурной декомпозиции применявшейся в С и Паскале?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 08.05.07 20:41
Оценка: 1 (1)
Здравствуйте, Константин Л., Вы писали:

КЛ>ладно, я имелл ввиду, что мог привести пример понавороченее.


Легко


-- стандартный оператор композиции
-- (.) :: (a -> b) -> (c -> a) -> (c -> b)

-- добавляет спереди единицу арности ко второму аргументу и возвращаемому значению 
-- переданной бинарной функции
addArity :: (a -> b -> c) -> (a -> (d -> b) -> (d -> c))
addArity =  (.) (.)

-- композитор унарной и бинарной функций
-- f(g(x y))
(.##) :: (a -> b) -> (c -> d -> a) -> (c -> d -> b)
(.##) = addArity (.)

-- композитор унарной и тернарной функций
-- f(g(x y z))
(.###) :: (a -> b) -> (c -> d -> e -> a) -> (c -> d -> e -> b)
(.###) = addArity (.##)

-- и.т.д. рекурсивно
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 11.05.07 07:34
Оценка: 1 (1)
Здравствуйте, Трурль, Вы писали:

PM>>Оно?

Т>Наглое жульничество . Вот напиши ка определение writeIORef на хаскеле.
Да ну, Трурль, уж ты то должен знать, где искать .
http://darcs.haskell.org/ghc-6.6/packages/base/GHC/IOBase.lhs
-- |Write a new value into an 'IORef'
writeIORef  :: IORef a -> a -> IO ()
writeIORef (IORef var) v = stToIO (writeSTRef var v)


Следующей просьбой будет, полагаю, реализовать stToIO и writeSTRef. И, естественно, в конце концов мы дойдем до примитивов, реализованных на C и C-- в рантайме. Но ты же не будешь утверждать, что C++, например, не поддерживает присваивания на том основании, что нельзя реализовать на C++ оператор присваивания для встроенных типов.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.04.07 13:43
Оценка: :)
Здравствуйте, konsoletyper, Вы писали:

K>Кто это такое говорил? Чтобы обойтись без паттернов проектирования, они либо должны быть зашиты в сам язык, либо язык должен иметь средства расширения, чтобы можно было реализовать паттерны в виде макробиблиотеки. Что касается первого, то тут есть маленький нюанс: многие современные ФЯ поддерживают паттерн-матчинг, который позволяет выкинуть паттерн посетитель. Остальные же паттерны приходится по-прежнему реализовывать ручками.


Мда.. Паттерн — это типичное решение типичной проблемы (в типичном языке ;-)).
Нет проблемы — нет необходимости в решении.

В ФП свои проблемы и свои паттерны. В языках без поддержки императивности — CPS/монады, без глобальных переменных — мемоизация, в ленивых — форсирование, с иммутабельными данными — Окасаки :-) куча паттернов для работы с функциями и т.д.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.04.07 09:46
Оценка: +1
Здравствуйте, mini_root_2, Вы писали:

__>Это тот же паскаль (или дельфи), там тоже есть unit(module),interface(типа export),implementation.

__>А нахрена козе баян? А как реализовать наследование — создать еще один модуль в котором протащить
__>все публичные методы первого и добавить что-то еще?.

Вот этого я долго ждал — когда же кто нибудь скажет о subtyping. Это имхо единственное отличие. Наследования, действительно, нет.
Правда, можно поговорить о двухуровневом наследовании (варианты); HOF + полиморфизм как решение задач, которые решает наследование, или даже polymorphic variants; недостатках наследования, но это уже скорее в философию ;-)

Важно другое — средства есть.

Ещё какие отличия ООП от ФП в плане проектирования?
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 27.04.07 11:31
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Изобретение велосипеда самое увлекательное занятие из придуманных человечеством.


С последущими попытками выдать его за очередную волшебную пулю...
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 27.04.07 11:53
Оценка: +1
Здравствуйте, mini_root_2, Вы писали:

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


VD>>Изобретение велосипеда самое увлекательное занятие из придуманных человечеством.


__>С последущими попытками выдать его за очередную волшебную пулю...


Только вот попыток чтот не видать, вспоминают иногда правда, что была бы полезна такая фича, но, видимо, нынешним пользователям языка это не очень актуально.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Zuka Россия  
Дата: 27.04.07 16:50
Оценка: +1
Здравствуйте, mini_root_2, Вы писали:




__>Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров:

__>1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных.
__>2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур, которые вызывают другие процедуры
__>(я намеренно не использую слово "функция"), использование глоабальных переменных не приветствуется. Сразу возникает вопрос как передавать
__>эти переменные при вызове, единственный разумный вариант — в виде структуры. Но структуры — это первый шаг к ООП. При построение
__>большого приложения, возможно потребуется подменить что-то не исправляя кода, а заодно привязать те или иные процедуры к строго определенному
__>контексту.
__>3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.

__>VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например:

__>public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем
__>же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат
__>методы для управления подсистемой в целом (start/shutdown).
__>А вот при описании этого же в термених ФП мы вернемся к пункту 2, отчего несколько десятилетий назад наооборот пытались уйти.

А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.07 21:08
Оценка: +1
Здравствуйте, aka50, Вы писали:

Не оверквоть, плиз.

Z>>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1


A>а если мы это сделаем через конфигурационные файлы как в IoC контейнерах, т.е. декларативно соберем систему?


То получишь еще один убогий и страшный язык, который к тому же будет динамическим. Фрэймворки вроде Струтса ни что иное как костыли.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 28.04.07 06:25
Оценка: +1
Здравствуйте, Zuka, Вы писали:

Z>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1


Неее, мне кажется что ты меня не правильно понял. Я рассматривал не передачу параметров, от нее никуда не денешься, а
место где хранится состояние, в пункте два оно хранится в виде локальных переменных процедур. Глобальные не привиетствуются,
потому что глобальное пространство одно и если им активно пользоваться возникнет бардак.
Если же мы получаем это значение (JobSystem) через синглтон, то это отнюдь не пункт 1, т.к. в этом случае она располагается
не глобально а в контексте определенного класса...
Фишка ООП в том что оно по сути предоставляет контейнер для контекста или на уровне классов или на уровне их экземпляров+
набор ассоциированных с ним методов+определенные правила их расширения(наследования)..
Проправьте если я ошибаюсь.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Zuka Россия  
Дата: 28.04.07 08:20
Оценка: +1
Здравствуйте, mini_root_2, Вы писали:

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


Z>>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1


__>Неее, мне кажется что ты меня не правильно понял. Я рассматривал не передачу параметров, от нее никуда не денешься, а

__>место где хранится состояние, в пункте два оно хранится в виде локальных переменных процедур. Глобальные не привиетствуются,
__>потому что глобальное пространство одно и если им активно пользоваться возникнет бардак.
__>Если же мы получаем это значение (JobSystem) через синглтон, то это отнюдь не пункт 1, т.к. в этом случае она располагается
__>не глобально а в контексте определенного класса...
__>Фишка ООП в том что оно по сути предоставляет контейнер для контекста или на уровне классов или на уровне их экземпляров+
__>набор ассоциированных с ним методов+определенные правила их расширения(наследования)..
__>Проправьте если я ошибаюсь.

Разница между пунктом 1-м и 2-м — техническая. Т.е. глобальные и локальные переменные по сути своей различные. А вот предлагаемый тобой "контекст" по сути является неявным параметром методов класса. Т.е. классы предлагают иной (и весьма продуктивный) взгляд на задачу, но разница между 3-м пунктом и первыми двумя носит скорее синтактический характер.

Что касается синглтонов. Проблема глобальных переменных не в том, что они засоряют пространство имен, а в том, что передача состояния через глобальные переменные приводит к весьма неочевидным (для читающего код) side-effect'ам. И синглтоны тут не исключения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.05.07 15:25
Оценка: +1
Здравствуйте, aka50, Вы писали:

A>Эти проблемы есть у любой компонентной архитектуры с возможностью гибкой настройки (JobSystemJBOSS, JobSystemJMS и проблему отсутсвия какого-то компонента компилятор решить не сможет, максимум проверит корректность типов, что могут делать и аннотации + annotation processor как часть компилятора)


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

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

A>А в целом я считаю что ценен именно FP + OOP.


+1

A>[off]

A>И scala мне все больше нравиться
A>[/off]

Ей бы еще метапрограммирование добавить, и было бы просто замечательно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 21:33
Оценка: +1
VD>Кстати, хочет задать один провакационный вопрос. Вот паттерны проектирвоания в ООП появились для облегчения проектирвоания больших и комплексных приложений. А что в этом плане придумано в ФП? Я вот сколько не гляжу, а все фишки ФП так или иначе крутятся вокруг макро-уровня. Собственно никто не спорит, что паттерн-матчинг ведь отличная, и красивая работа с фукнциями и замыканиями тоже очень удобно, но это все дает эффект только на довольно низктом (макро) уровне. А как насчет уровня приложения (и большого)?

Перепутал макро и микро. После реплейса всё становится понятно, а главное правильно. Полностью согласен.
Задолбался уже в сишарпе в тысячный раз команду писать вокруг одной строчки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.05.07 23:07
Оценка: -1
Здравствуйте, VGn, Вы писали:

VGn>Хотя как вариант:

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

Решаются, но еденицами. Тот же Пол Грэхем делал Интернет-магазины.

VGn>А задачи бизнес-уровня замечательно решаются при нынешнем подходе и в ФП на макро уровне необходимости нет.

VGn>Опять же: методологии переписывать, UML новой версии — много работы.
VGn>Замкнутый круг.

Мне кажется все еще банальнее. Все упирается в три фактора:
1. Человеческая лень.
2. Человеческая глупость.
3. Человеческая трусость.

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

Например, я сталкнулся с нешуточным сопротивлением просто потому, что язык не поддерживается мега-корпорацией вроде МС или Сана. И этих людей можно понять.
Так же я сто раз нарывался на высассанные из пальца утверждения.
С ФП все усложняется практически полным отсуствие учебных материалов приемлемого качества. То что есть нассчитано или на людей с серьезным мат. образованием, или вообще никуда не годятся. Вещей класса "The C programming language" я не видел во все.

В общем, есть два лагера представители которых практически ничего не знают о другом лагере. Есть много фанатизма и откровенной некомпетенции. Причем ни у кого нет даже малейшего желания устранять эти проблемы.
Те не многие кто хорошо разбирается в особенностях обоих лагерей и достаточно адекватен, чтобы не вподать в религиозные оргии одного из лагерей просрто не могут ничего исправить, так как нарываются на серьезное сопротивление по перечисленным причинам. Потыркавшись мноие из них просто бросают это знятие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.05.07 23:39
Оценка: +1
Здравствуйте, deniok, Вы писали:

D>Угу. Между коммуникабельностью и знакомстовом с Excell.


А ты думаешь, что это не важно? По-твоему, важно только кнопки нажимать уметь?

Кому ты нужен в большом проекте если не умешь в Ёкселе табличку слабать с отчеом и не в силах договриться с товарищами и начальством о том, что и как ты будешь делать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: граммофон  
Дата: 03.05.07 02:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:



VD>Так что нет проблем в создании гибридных языков. И таких языков уже не мало.

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


Ну по-моему вопрос императивен или нет ввод-вывод сродни вопросу: вращается ли солнце вокруг земли или наоборот. Правильного ответа не существует — все зависит от системы отсчета и начала координат.
Что же до фанатизма — я бы не называл то, что имеет под собой аргументы фанатизмом. Все же ссылочная прозрачность несет в себе немало выгод. Я даже в последнее время за собой заметил, что для всех задач, где мне реально требуется делать что-то императивное, я делаю на Си, потому что в той же Java от этих всех присваиваний смысл без указателей, их арифметики и goto какой-то не очень большой. 99% этих присваиваний — локальные переменные и подергивание полей в конструкторах и сеттерах. Чудовищно бессмысленная работа, которая выводится за видимость нормальным компилятором. А оставшийся 1% случаев вполне оборачивается во что-нибудь безопасное. Оборачивают же они сейчас работу с буферами в памяти и тому подобное.
прежде чем понять рекурсию, необходимо понять рекурсию.
Re[20]: А за что же минус-то? :) [-]
От: deniok Россия  
Дата: 04.05.07 07:24
Оценка: :)
Здравствуйте, Mamut, Вы писали:

M>Сабж.


Может человеку Coldfusion и отсутствие ФП в проекте говорит о многом?
Re[7]: Мой ник
От: Дм.Григорьев  
Дата: 08.05.07 12:19
Оценка: :)
Здравствуйте, konsoletyper, Вы писали:

K>Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!


Заведи себе лучше GUID, как все нормальные люди.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 20:32
Оценка: :)
Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Константин Л., Вы писали:


КЛ>>здесь сказали такую глупость и я с ней согласен
Автор: VladD2
Дата: 23.04.07


K>Да, я тоже согласен. Вот только вопрос: если ФП никак не мешает использовать ООП, то зачем ругать ФП?


да ну не хотелось его ругать Как бы недостатки хотел показать

КЛ>>чувствуешь разницу м/у лямбдами и спагетти из лямбд? Ну ладно, тут почти можно отступить.


K>Ну так если руки кривые, то спагетти можно нагородить на ровном месте любыми средствами.


КЛ>>>>4. трудная для понимания программа. см. пункт 3.


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


КЛ>>Проблема — структурированность. Сам писал на clisp, поэтому есть представление.


K>И что же, по твоему clisp — чисто функциональный?


а вот тут то я и попался

насколько помню с ооп там было бедненько
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 13:52
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ>>>По-моему, чистый фп подход продьюсит спагетти-код


И много ты ФП кода видал? Можно на примерах?

D>>Эээ, залезем в Вики


D>>

D>>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.


КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.

Да лана. Есть модули, есть стримы. Есть злые монады. Этого вполне достаточно для построения макроархитектуры.

КЛ>2. слабо структурированная. Туда же.

Куда же туда же. Это неправда. Как система будет структурирована — зависит от того, как у человека мысли в голове структурированы. И только. А дурака хоть молиться заставь — один хрен лоб до затылка расшибет.

КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси

Саппорт легаси усложняет работа с явням разделяемым состоянием. Которое из-за спагетти-кода может поменяться откуда угодно (в этом и суть спагетти), в результате поведение кода трудно предсказать и сложно выделить границы подсистем.

В чистом ФП нет разделяемого состояния. Не будет и связанных с этим проблем, например спагетти. Это хорошо. Проблем в целом будет меньше.

КЛ>4. трудная для понимания программа. см. пункт 3.

Субъекивно. Что трудно для вашего понимания, может быть легко для моего, и наоборот.

КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

Да что угодно. GOTO, паттерн "визитор", дабл диспатч, а также наследование, примененное не по назначению.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 14:04
Оценка: +1
Здравствуйте, deniok, Вы писали:

КЛ>>>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.


K>>>Кто сказал такую глупость. ...


КЛ>>здесь сказали такую глупость и я с ней согласен
Автор: VladD2
Дата: 23.04.07


D>Я так и не понял, что там имелось ввиду.


D>В Хаскелле инкапсуляция достигается с помощью системы модулей, которые помимо этого играют роль пространств имён.

D>А наследование и полиморфизм (специальный) реализованы с помощью классов типов (аналог обобщённых интерфейсов) и возможности для типов данных эти интерфейсы воплощать.

D>Так что весь ООП-шный инструментарий в наличии.


Ты почти прав. Только ты упустил главное из ООП-шного инструментария. Что такое "объект"?
Объект = АДТ (абстрактный тип данных) + состояние
АДТ = тип данных, определяющийся набором операций над ним. С этим у ФЯ все в порядке.

Объект же не просто АДТ — он имеет состояние и "идентити" — т.е. в системе могут существовать два одинаковых по состоянию объекта с разным идентити. В ОО языках роль "идентити" играет указатель. Идентити — непременный атрибут изменяемого состояния и ООП.

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

В чистых языках состояние можно моделировать стримами (ленивыми списками) — это альтернативный ОО-декомпозиции подход.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 10.05.07 14:41
Оценка: :)
Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Константин Л., Вы писали:


КЛ>>А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил

PM>Во-первых, таки да, map возвращает функцию (т.к. у map 2 аргумента, см. карринг). Во-вторых, функция высшего порядка может не только возвращать функции, но и принимать их как аргументы. Какой у map первый аргумент?

1. какую функцию возвращает map?
2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию
3. Я уже в курсе, что такое фвп и этот пример был для меня понятен
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 17:26
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


M>>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )


VD>Жаль, правда, что код не идентичный.


А мы его немного не то чтобы изменим, а слегка дополним...
         inline template< class F, class A >
         A& map( A &arr, F some_func )
         {
for(i = 0; i < arr.length; i++)
{
  some_func(arr[i]);
}
          return arr;
         }

versus //?!

arr = [1, 2, 3, 4];

map(arr, some_func);


Теперь вроде как идентичен
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 18:37
Оценка: :)
Здравствуйте, palm mute, Вы писали:

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


G>>б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

G>>Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.

PM>Оно? Или ты что-то более сложное имел в виду? Прошу обратить внимание на 'deriving Eq' и 'obj `elem` visited' — это обещанная Identity. Полиморфизму сверху добавить тоже можно.


Похоже. Прикольная штука этот ваш IORef. Надо разобраться, я пока не до конца фкуриваю, как оно работает.

PM>з.ы. Я не говорю, что так нужно делать, но можно — факт
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.05.07 21:39
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Похоже. Прикольная штука этот ваш IORef. Надо разобраться, я пока не до конца фкуриваю, как оно работает.


Да ссылка обычная, только завернутая в IO. В смысле, работать с ней можно только там (это не совсем так, но в данном случае непринципиально).
Погляди на типы функций:

newIORef :: IO (IORef a)
readIORef :: IORef a -> IO a
writeIORef :: IORef a -> a -> IO a


Должно стать понятно. Т.е. там в любом случае приходится работать в IO, поэтому сохраняется чистота, но одновременно можем менять состояние (такое вот противоречие).

Вообще, для практического использования Хаскеля обязательная к прочтению вещь:
Tackling the awkward squad
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.05.07 00:38
Оценка: :)
Здравствуйте, palm mute, Вы писали:

PM>з.ы. Я не говорю, что так нужно делать, но можно — факт


А тут девочке еще советовали тему для лабы "Метапрограммирование на шаблонах С++ как средсво шифрования кода". С++ морально устраел для этих целй. ООП на Хаскеле явно его победит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 11.05.07 07:45
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>А тут девочке еще советовали тему для лабы "Метапрограммирование на шаблонах С++ как средсво шифрования кода". С++ морально устраел для этих целй. ООП на Хаскеле явно его победит.


Я вот по-португальски тоже ничего не понимаю. Странный язык, непонятный. Как на нем люди разговаривают, да еще и песни пишут, загадка.
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 12.05.07 07:41
Оценка: :)
M>> Чтобы голову не заморачивать

VD>map должен возвращать другой массив/список, а не менять имеющися. А проблемы ява-скрипов пусть так и остаются их проблемами.


Будем считать особенностями реализации В С++ вон map — это вообще тип данных, и ничего


dmitriid.comGitHubLinkedIn
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 21.04.07 09:43
Оценка:
rsdn.ru, работает как то чудесато, войти так и не удалось(IE схлопывается)..., так что знайте первое сообщение написаль mini_root_2.
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 21.04.07 10:51
Оценка:
А>По поводу шаблонов проектирования: я понимаю что GoF мало соответствует функциональному подходу, но не слышал чтобы кто-нибудь из функциональщиков приводил свой аналог, позволяющий стандартным образом провести декомпозицю задачи...

По поводу паттернов: http://norvig.com/design-patterns/

16 из 23 шаблонов из книги "Шаблоны проектирования" легче имплементировать в Лиспе или Дилане. Эти шаблоны проще или вообще незаметны (поддерживаются на уровне языка)



dmitriid.comGitHubLinkedIn
Re: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.04.07 10:54
Оценка:
Здравствуйте, Аноним, Вы писали:

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


Ты считаешь, что есть единственный The Right Way?
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 21.04.07 11:40
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Ты считаешь, что есть единственный The Right Way?


Разумеется нет, но в более или менее крупном проекте лучше предерживаться чего-нибудь
одного — меньше будет проблем...
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.04.07 11:42
Оценка:
Здравствуйте, Аноним, Вы писали:

К>>Ты считаешь, что есть единственный The Right Way?


А>Разумеется нет, но в более или менее крупном проекте лучше предерживаться чего-нибудь

А>одного — меньше будет проблем...

Просто суть в том, что функциональная композиция она выражает другую точку зрения на проблему, отличную от ООП, которая в GoF преподносится. Собственно об этом мамут уже написал
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 21.04.07 11:47
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Просто суть в том, что функциональная композиция она выражает другую точку зрения на проблему, отличную от ООП, которая в GoF преподносится. Собственно об этом мамут уже написал


Возможно, но как насчет приведенных примеров (пункты 1 и 2)... и так ли эта точка зрения
сильно отличается?
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 21.04.07 12:07
Оценка:
А>Возможно, но как насчет приведенных примеров (пункты 1 и 2)... и так ли эта точка зрения
А>сильно отличается?

Функции высшего порядка (или все же function as first-class values?) (на примере яваскрипта):

function fun(a, b)
{
    return a + b;
}


myvar = function(i) { return fun(2, i); }

//получаем значения

myvar(1);  // получим 3
myvar(5);  // получим 7
myvar(47);  // получим 49


или пример.

В библиотеке Ext есть так называемый mixedcollection. В котором есть функция filterBy. На вход она принимает функцию об одном/двух параметрах. Если передаваемая функция возвращает true, то элемент остается в возвращаемой коллекции. Если false, элемент игнорируется

// Предположим, у нас в коллекции есть 
// var numbers = [1, 2, 3, 4, 5, 6, 7]

var numbers;

// найдем все нечетные

var odds = numbers.filterBy(
    function(n) {
        return n % 2 == 0;
    }
)

// или даже так:

function isOdd(n) { return n % 2 == 0; }
function isEven(n) { return !isOdd(n); }

function conditional(cond) { 
    // в зависимости от переданного значения возвращаем одну функцию или другую
    return cond == 'odd' ? isOdd : isEven;
}

// находим четные

var evens = numbers.filterBy(
    conditional('even')
);


Что хорошо в function as first class values и языках, их поддерживающих (а это в основном функциональные) — это возможность создания функций на лету (anonymous/lambda functions) и замыкания (closures). Эти две вещи через объекты эмулируются кривовато


dmitriid.comGitHubLinkedIn
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.04.07 12:08
Оценка:
Здравствуйте, Аноним, Вы писали:

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


К>>Просто суть в том, что функциональная композиция она выражает другую точку зрения на проблему, отличную от ООП, которая в GoF преподносится. Собственно об этом мамут уже написал


А>Возможно, но как насчет приведенных примеров (пункты 1 и 2)... и так ли эта точка зрения

А>сильно отличается?

Вот тут как раз и очень отличается
Ты смотришь на всё как на объекты.
Как в поговорке про молоток.
А функция — она лишь только функция. И кортежи лишь только кортежи.
Наличие же классов может вылиться хотябы в отстутствии неизменяемости объектов. Никто же не мешает тебе в функтор (в плюсовой терминологии) добавить переменную (скажем, счётчик вызовов), только вот это уменьшает прозрачность, увеличивает число зависимостей и т.п.
Т.е. ты пытаешься функциональны подход "замапить" на ООПшный. Эт хорошо для понимания. Но для использования функционального подхода плохо.
Знаешь это напоминает изучение иностранного языка. В начале ты всё время переводишь иностранные слова на родной язык. Поэтому процесси идёт медленно. Потом в ходе практики получается что ты думать научиваешься на том языке, поэтому понимание идёт много проще. Хотя может у других это иначе, но вот с аглицким у меня так ситуация обстояла.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 21.04.07 12:45
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Функции высшего порядка (или все же function as first-class values?) (на примере яваскрипта):


Вообщето это все можо сделать и вто так:


 public interface MyInterface
  {
   public Integer function(Integer _a, Integer _b);
  }

 public interface MySecondInterface
  {
   public void setFristFunction(MyInterface _mi);   
   public Integer function(Integer _i);
  }

 ...
 MyInterface firstFunction=new MyInterface() 
  {
   public Integer function(Integer _a, Integer _b) {return _a+_b;}
  };

 MySecondInterface secondFunction=new MySecondInterface()
  {
   protected MyInterface mi=null;
   public void setFirstFunction(MyInterface _mi) {mi=_mi;}
   public Integer function(Integer _i) {return mi.function(2,_i);}
  }
 Integer myVar=secondFunction.function(1); //получим 3
 ...


Пишется несколько длиннее но результат тот же самый.
Или на scala:
def function(i:int):int = 
 {
  def internalFunction(_a:int, _b:int):int =
   {
    return _a+_b;
   }
  return internalFunction(2,_i);
 };

Одно и тоже, только во втором варианте сахара побольше (кроме того в случае с явой можно
было не определять первый интерфейс а захардкодить все внутрь анаонимного класса).
И никакой кривизны здесь нет! Вы удивитесь, но лично я выберу ПЕРВЫЙ вариант.
Я склоняюсь к мнению что рассматривать преимущества ФП "в малом" занятие бессмысленное,
единственное _возможное_ преимущество возможно только в одном случае если ФП позволит
как-то по-другому разбить проект и получившееся архитектура будет более понятной и простой...
Но вто этого я пока нигде и не увидел(и не уверен что оно вообще есть...): в основном сортировка или вышка...
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.04.07 12:51
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Одно и тоже, только во втором варианте сахара побольше (кроме того в случае с явой можно

А>было не определять первый интерфейс а захардкодить все внутрь анаонимного класса).
А>И никакой кривизны здесь нет! Вы удивитесь, но лично я выберу ПЕРВЫЙ вариант.
Первый — с интерфейсами? Ну дак яж уже писал — ты тут смотришь на всё через призму ООП, тебе привычно, поэтому для тебя это логично
А>Я склоняюсь к мнению что рассматривать преимущества ФП "в малом" занятие бессмысленное,
А>единственное _возможное_ преимущество возможно только в одном случае если ФП позволит
А>как-то по-другому разбить проект и получившееся архитектура будет более понятной и простой...
А>Но вто этого я пока нигде и не увидел(и не уверен что оно вообще есть...): в основном сортировка или вышка...

А вышка — это что имеется в виду?
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 21.04.07 16:28
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Это и есть исполнение в Королевстве Существительных.


Отличная фэнтези
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 22.04.07 06:28
Оценка:
Здравствуйте, geniepro, Вы писали:

G>Это когда же VladD2 успел разлюбить Nemerle и полюбить Лисп с жутким по его мнению синтаксисом? 8-о


А он и не разлюбил, там просто во введении была большая цитата какого-то господина.

mini_root_2
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 23.04.07 04:24
Оценка:
deniok,

D>Отличная фэнтези


Ага, ещё и с любопытным сатирическим оттенком.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 23.04.07 09:45
Оценка:
Все поскипано.

Дальше про Веб (который 2.0, ага )
У меня есть так называемый TabPanel. То есть это табы, которые открывают ту или иную панельку. Откпывается панелька, в ней записывается слово "Loading..." и выполняется AJAX запрос к серверу. Когда ответ с сервера приходит, вызывается callback функция,которая что-то там записывает в эту самую панельку.

Ключевое слова в AJAX — асинхронный. То есть, когда вызовется callback, эта панелька уже может не быть активной. Как же узнать, куда что писать?


/****************************************************
 * callback функция выглядит так:                   *
 *     function callback(response) {                *
 *         response - это пришедший с сервера ответ *
 *     }                                            *
 ****************************************************/

function createCallback(panel)
{
    return function(response)
    {
        panel.innerHTML(response); // записываем ответ, пришедший с сервера
    }
}

function createPanel(condition)
{
    panel = new TabPanel //... и т.д. и т.п. создаем панель


    $.ajax(
        '/get/data',          // запрос куда
        {cond: condition},    // параметры
        createCallback(panel) // callback
    )
}


Таким образом callback будет всегда сам знать, в какую панель что писать. closures рулят Если честно, я же не представляю, как такое же сделать чисто ОО подходом.


dmitriid.comGitHubLinkedIn
Re: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.07 14:50
Оценка:
Здравствуйте, <Аноним>, Вы писали:

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

Объяснять это тому кто не освоил этот подход совершенно бесполезно. Почему? Тут как раз упоминали цитату главного проповедника Лиспа Пола Грэхема которую я приводил. Так вот она отлично объясняет этот феномен. Если интересно, ищи ее здесь
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
.

Не смотря на то, что объяснить приемущества невозможно, все же можно продемонстрировать их результат. Вот здесь
Автор: VladD2
Дата: 30.12.06
приведено два исходника идентичные с точки зрения решаемой задачи, но исходник написанный на языке поддерживающем ФП (аналог Скалы — язык Немерле) примерно в четверо короче и в 10 раз выразительнее. И это не маги, подтасовки или спецэффекты. Это просто грамотное применение того самого "сахара".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Мой ник
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 23.04.07 18:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Косолетайпер верно говорит


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

PS: напоминает случай с Cyberax'ом
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 23.04.07 18:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А кому нужны чистые фунциональные? Людям нужно писать программы проще, быстрее и удобнее.


Ну как это кому? Я вот на Хаскеле обсчитываю задания по матстатистике. Там есть вещи, которые не под силу Excel. Люди говорят, что для этих целей лучше подходит J, а мне вот лень его изучать, тем более синтаксис у него жуткий.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.04.07 20:32
Оценка:
Здравствуйте, VladD2, Вы писали:

LCR>>В ФП паттерны часто являются просто ФВП. Ну вот fold — чем не паттерн? Или map-reduce? Или класс типов Monad?


VD>Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.


Это не библиотечные функции.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 24.04.07 10:43
Оценка:
G>Гхм... Ты на сахар-то эта, особо не налегай... Чему людей учишь? Али не наешь, что от сладкого зубы портятся?

Все хуже На сладкое и подсесть можно


dmitriid.comGitHubLinkedIn
Не в тему, но про J :)
От: Mirrorer  
Дата: 25.04.07 16:13
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Ну как это кому? Я вот на Хаскеле обсчитываю задания по матстатистике. Там есть вещи, которые не под силу Excel. Люди говорят, что для этих целей лучше подходит J, а мне вот лень его изучать, тем более синтаксис у него жуткий.


Синтаксис как раз не жуткий. А вот лексемы в нем .. непривычные это да.
Поченму-то мне кажется что основные понятия в J можно выучить в течении дня-двух. А вот научиться эффективно им пользоваться это займет некоторое время.

Лично я считаю J чем-то сродни математическому ассемблеру. Очень узкоспециализированный. Хотя теоретически на нем можно написать все что угодно.
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.07 10:52
Оценка:
Здравствуйте, lomeo, Вы писали:

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


За тем что надоелу слушать ничем не подкдепленную пропаганду.

L> Те паттерны, о которых, как я понял, шла речь, это не общие решения общих проблем. Это решения типичных проблем объектно-ориентированного проектирования.


Паттерны есть в любых языках в независимости от применяемой парадигмы.

L>А должно?


А зачем тогда было ему возражать?

L> Моя мысль была в том, что некоторые паттерны из GoF (о которых шла речь, "остальные кроме посетителя") просто не нужны в FP. В FP свои задачи и свои решения.


В ФП есть свои паттерны. А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем. В качетсве средств проектирования используются дедовские сдерства структурной декомпозиции, а подается все это с понтом новеших технологий.

L>>> В языках без поддержки императивности


VD>>А что такие есть в природе?


L>Есть.


Да, ну? Ну, как привиди пример хоть одного.

L>>> — CPS/монады,


VD>>А что монады уже не императивны?


L>Нет.


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

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


L>На провакационные вопросы отвечать не хочется


Это потому что честный ответ банально тебя не устроит.

L> Интересно — посмотри для начала Why FP matters Хьюза.


Не интересно. Интересно получить прямой ответ, на прямо поставленный вопрос.

L> Дальше — катаморфизм, полиморфизм, генерики. Это то, что работает на уменьшение сложности программы.


Да, да. По больше базвородов. Это помогает уйти от ответа.

L>Есть паттерны и для композиции, low coupling и high cohension, но они обычно языко-зависимые, как например, умные конструкторы.


О, значит на счет наличия паттернов мы все же договорились. Уже сдвиг. Жаль, правда, что нет средств проектирвоать сложные системы.

L>Кстати, насчёт терминов, я всегда думал, что макро-уровень — это когда ворочаешь большими блоками, а микро — когда работешь пинцетом под микроскопом.


Я оговорился. Имелось в виду микро-уровенть, конечно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.04.07 14:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>За тем что надоелу слушать ничем не подкдепленную пропаганду.


Я тут при чём?

L>> Те паттерны, о которых, как я понял, шла речь, это не общие решения общих проблем. Это решения типичных проблем объектно-ориентированного проектирования.


VD>Паттерны есть в любых языках в независимости от применяемой парадигмы.


Ежу ясно. Речь о GoF.

L>>А должно?


VD>А зачем тогда было ему возражать?


Я возражал не этому. Так что не в кассу.

L>> Моя мысль была в том, что некоторые паттерны из GoF (о которых шла речь, "остальные кроме посетителя") просто не нужны в FP. В FP свои задачи и свои решения.


VD>В ФП есть свои паттерны. А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем. В качетсве средств проектирования используются дедовские сдерства структурной декомпозиции, а подается все это с понтом новеших технологий.


-1

VD>Да, ну? Ну, как привиди пример хоть одного.


Не хочу. Ты до слов пытаешься докопаться, а мысль, которую я пытался донести, тебя не интересует. Спор мы начинаем вести совсем о другом. Мне это надо?

VD>Во как? А темнеменее состояния держат и императивно программировать позволяют. Только раком.


Мало ли что что-то там позволяет. Насквозь императивное железо позволяет нам программировать функционально. Так что? Оно функционально?

L>>На провакационные вопросы отвечать не хочется :-)


VD>Это потому что честный ответ банально тебя не устроит. ;)


Не угадал. Подумай ещё раз.

VD>Не интересно. Интересно получить прямой ответ, на прямо поставленный вопрос.

VD>Да, да. По больше базвородов. Это помогает уйти от ответа. :)
VD>О, значит на счет наличия паттернов мы все же договорились. Уже сдвиг. :) Жаль, правда, что нет средств проектирвоать сложные системы.

Так. Ты что хочешь узнать? Средства проектирования в ФП аналогичные по мощи паттернам GoF?
Ещё раз — задачи, решаемые этими паттернами или решаются так же, или по другому или не решаются, потому что такие задачи не встают.

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

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

Если хочешь, давай перейдём к конкретике. Скажи что нибудь из области императива "проблема-решение на верхнем уровне", я попытаюсь найти аналогию в мире ФП. Возможно, я ошибаюсь, возможно, есть такие вещи, которые не решаются/гораздо тяжелее решаются в ФП. Но пока я таких вещей не видел. С другой стороны, у меня небольшой опыт, а некоторые уважаемые (и опытные) люди, например, Gaperton, считают, что декомпозицию на верхнем уровне надо делать в объектах.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.04.07 15:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В грануляности. Нет экземлпяров.


Увы! Модули — это не аналог классов, это аналог пакетов.

VD>Спроектировать большую систему в терминах модулей просто невозможно. В терминах функций можно, но очень сложно.


А в терминах групп функций? Разумеется поименованных. Экземпляры есть.
Re[5]: Мой ник
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.07 16:51
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Вообще-то, ник я придумывал не для того, чтобы его пытались зачитать вслух или перевести на русский. Может, специально для этих целей мне поменять ник на фамилию/имя?


K>PS: напоминает случай с Cyberax'ом


Так, а что тебя не устраивает? Мне просто влом переключаться на англицкий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.07 16:51
Оценка:
Здравствуйте, lomeo, Вы писали:

L>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.


Вот это и называется структурной декомпозицей. ООП как раз и придумывали потому как при некотором объеме задачи она становится мало пригодной.

Собщственно сейчас даже при разработке на ЯП не поддерживающих ООП напрямую все равно проектирование ведется обычно именно в ООП. Достаточно взглянуть на API Линукса и Виндовс.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.07 16:51
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Паттерны есть в любых языках в независимости от применяемой парадигмы.


L>Ежу ясно. Речь о GoF.


Я незнаю о каком еже речь, но GoF тут ты произнес первым. До этого речь шала о паттернах вообще.

VD>>А зачем тогда было ему возражать?


L>Я возражал не этому. Так что не в кассу.


Хм... А это что?
Автор: lomeo
Дата: 23.04.07


VD>>В ФП есть свои паттерны. А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем. В качетсве средств проектирования используются дедовские сдерства структурной декомпозиции, а подается все это с понтом новеших технологий.


L>-1


Да что толку с твоих "-1"? Не согласен? Тогда продемонстрируй обратное. Покажи нам что за средства декомпозиции предоставляет ФП? Как их применять для проектирования больших систем? Чем они отличаются от приемов проектирования исползовавшихся в С 20 лет назад и от которых люди убежали в ООП?

VD>>Да, ну? Ну, как привиди пример хоть одного.


L>Не хочу. Ты до слов пытаешься докопаться,


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

L>Мало ли что что-то там позволяет. Насквозь императивное железо позволяет нам программировать функционально. Так что? Оно функционально?


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

VD>>Это потому что честный ответ банально тебя не устроит.


L>Не угадал. Подумай ещё раз.


А я и не гадал. Я знал.

L>Так. Ты что хочешь узнать? Средства проектирования в ФП аналогичные по мощи паттернам GoF?


Мне вообще интересно послушать о хоть каких-то средствах проектирвоания ФП которые не пересекались бы со средствами структурного программирования.

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

А что предлагает ФП на этом уровне?

L>Если хочешь, давай перейдём к конкретике. Скажи что нибудь из области императива "проблема-решение на верхнем уровне", я попытаюсь найти аналогию в мире ФП.


Я уже сказал. ООП основной целью имеет проектирование на уровне абстрактных объектов и их взаимодействия. С функциями это не прокатывает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: EvilChild Ниоткуда  
Дата: 26.04.07 17:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем.

А как одно из другого следует? И какое отношение GoF имеют к размеру системы?
now playing: Phace — Krunk Time
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Трурль  
Дата: 26.04.07 18:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Спроектировать большую систему в терминах модулей просто невозможно.

А ничего, что самые большие системы именно в терминах модулей и проектировались?
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.04.07 18:30
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.


VD>Вот это и называется структурной декомпозицей. ООП как раз и придумывали потому как при некотором объеме задачи она становится мало пригодной.


Чем это отличается от классов?

VD>Собщственно сейчас даже при разработке на ЯП не поддерживающих ООП напрямую все равно проектирование ведется обычно именно в ООП. Достаточно взглянуть на API Линукса и Виндовс.


Поясни. Ты имеешь в виду работу с хендлами? Посылку сообщений? Что то ещё?
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.04.07 18:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я незнаю о каком еже речь, но GoF тут ты произнес первым. До этого речь шала о паттернах вообще.


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


Как прикажешь воспринимать "остальные"? Универсальное множество паттернов во всех возможных случаях проектирования минус посетитель?

L>>Я возражал не этому. Так что не в кассу.


VD>Хм... А это что?
Автор: lomeo
Дата: 23.04.07


Ну и? Мне в третий раз повторить, что я хотел сказать?

VD>Да что толку с твоих "-1"? Не согласен? Тогда продемонстрируй обратное. Покажи нам что за средства декомпозиции предоставляет ФП? Как их применять для проектирования больших систем? Чем они отличаются от приемов проектирования исползовавшихся в С 20 лет назад и от которых люди убежали в ООП?


Ты недостатки скажи. Или в чем преимущества ООП расскажи, я пока совершенно не понимаю, где и какого монстра ты увидал.

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


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

L>>Мало ли что что-то там позволяет. Насквозь императивное железо позволяет нам программировать функционально. Так что? Оно функционально?


VD>Не позволяет. Как только ты обращаешся к железу, то начинается императив. Просто ты работаешь в рамках концепций которые создают иллюзию "чистой функциональности". А по стути на современном железе функциональность в чистом виде невозможна. Она только в математике и есть.


Аналогично и с монадами По сути они чисто функциональны.

VD>>>Это потому что честный ответ банально тебя не устроит.


L>>Не угадал. Подумай ещё раз.


VD>А я и не гадал. Я знал.


Какое самомнение! Вынужден тебя огорчить, причины совершенно иные.

L>>Так. Ты что хочешь узнать? Средства проектирования в ФП аналогичные по мощи паттернам GoF?


VD>Мне вообще интересно послушать о хоть каких-то средствах проектирвоания ФП которые не пересекались бы со средствами структурного программирования.


Полиморфные функции? Type classes?

VD>Вот в ООП даже не поднимаясь к каким-то там паттернам я могу представить сложную систему как совокпность взаимодействующих объектов. Они абстрагируют меня от сложности системы.


VD>А что предлагает ФП на этом уровне?


Функциональную декомпозицию.

VD>Я уже сказал. ООП основной целью имеет проектирование на уровне абстрактных объектов и их взаимодействия. С функциями это не прокатывает.


Разумеется. ФП имеет своей целью проектирование на уровне функций и их взаимодействий. С объектами это не прокатывает.
Re[7]: Мой ник
От: aka50 Россия  
Дата: 27.04.07 07:04
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Ну, тогда не Косолетайпер, а Консолетайпер. Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!


Ну эт без проблем набрать можно, на русском это будет примерно так: ыряячслгоящзшстт
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 27.04.07 08:09
Оценка:
Здравствуйте, mini_root_2, Вы писали:


___>P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных

__>функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения,
__>но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие
__>поддержки со стороны netbeans.

А чем тебя смущает большое количество анонимных функций? Если одни и те же функции, то повод для рефакторинга и лишения их анонимности
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 27.04.07 08:53
Оценка:
__>3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.

__>VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например:

__>public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем
__>же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат
__>методы для управления подсистемой в целом (start/shutdown).

-module(job_system).

-export([
    public_method/1,
    public_method_two/1,
    public_method_three/2
]).


%% ------------------------------------------------------
%% Публичные методы aka интерфейс взаимодействия
%% ------------------------------------------------------

public_method(Param) ->
    ok.

%% Функция является перегруженной
%% Перегрузка на основе паттерн-матчинга

%% Эта функция принимает список и вызывает внутреннюю, приватную функцию
public_method_two([Head|Tail]) ->
    private_method(Head, Tail);

%% Эта функция принимает кортеж и вызывает внутреннюю, приватную функцию
public_method_two({A,B}) ->
    private_method(A, B).

public_method_three(Param1, Param2) ->
    {я, не, знаю, что, мне, делать, с, этою, бедой}.

%% ------------------------------------------------------
%% Приватные функции
%% ------------------------------------------------------

%% Приватная функция также прегружена на основе
%% сопоставления с образцом

private_method(A, [Head|Tail]) ->
    another_Module:do_something(A),
    private_method(Head, Tail);

private_method(A, []) ->
   another_Module:do_something(A);

private_method(A, B) ->
   another_Module:do_something(A),
   another_Module:do_something(B).


Ну и чем это отличается от объекта? Состояние этот модуль тоже может хранить (см. gen_server в документации по Эрлангу ну или здесь).


dmitriid.comGitHubLinkedIn
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 27.04.07 09:15
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ну и чем это отличается от объекта? Состояние этот модуль тоже может хранить (см. gen_server в документации по Эрлангу ну или здесь).


Это тот же паскаль (или дельфи), там тоже есть unit(module),interface(типа export),implementation.
А нахрена козе баян? А как реализовать наследование — создать еще один модуль в котором протащить
все публичные методы первого и добавить что-то еще?.

P.S. Если я не ошибаюсь ООП через модули было реализована в Perl5, откуда я в свое время благополучно
сбежал на Яву.
P.P.S. А вот по поводу кодогенерации, макросов и DSL — это уже интересно. Я с некоторых пор начал зашиваться и понял что самый реальный способ строить что-то большое это набирать функциональность
из готовых блоков, а сверху прикручивать какой-нибуль интерпретатор (хоть Groovy, хоть XSLT с расширениями), вто недавно встроил скалу в яву, щас пребываю в раздумье...
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 27.04.07 11:03
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Модуль же отличается от объекта, тем что не позволяет создать свои экземляры.


В свете этого сразу вспоминается идея параметризуемых модулей в Эрланге, которые фактически и являются экземплярами.
Т.е. опять же эмуляция.
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: aka50 Россия  
Дата: 27.04.07 18:33
Оценка:
Здравствуйте, Zuka, Вы писали:

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





__>>Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров:

__>>1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных.
__>>2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур
__>>3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.

Z>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1


а если мы это сделаем через конфигурационные файлы как в IoC контейнерах, т.е. декларативно соберем систему?
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: aka50 Россия  
Дата: 28.04.07 07:43
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Не оверквоть, плиз.

угу... что-то случайно получилось...
Z>>>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
A>>а если мы это сделаем через конфигурационные файлы как в IoC контейнерах, т.е. декларативно соберем систему?
VD>То получишь еще один убогий и страшный язык, который к тому же будет динамическим. Фрэймворки вроде Струтса ни что иное как костыли.
Ну почему сразу струтс или spring вспоминают?. Например http://code.google.com/p/google-guice/ или http://tapestry.apache.org/tapestry5/tapestry-ioc/ работают без конфигурационных файлов на аннотациях. Т.е. все в пределах одного языка. Вот собственно и интересно куда это отнести и чем это будет отличаться от поиска модулей в том же erlang на уровне самой vm.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.04.07 07:59
Оценка:
Здравствуйте, aka50, Вы писали:

A>Ну почему сразу струтс или spring вспоминают?.


Потому что это самые популярные реализации. С них все началось.

A> Например http://code.google.com/p/google-guice/ или http://tapestry.apache.org/tapestry5/tapestry-ioc/ работают без конфигурационных файлов на аннотациях. Т.е. все в пределах одного языка. Вот собственно и интересно куда это отнести и чем это будет отличаться от поиска модулей в том же erlang на уровне самой vm.


Это все равно другие языки и у них те же пролемы с интеграцией. Во время компиляции они не проверяются и имеют массу проблем с отладкой и вообще мало гарантий того что общая система основанная на них заведется и будет работать. В общем, их примененеие связанно с перекладыванием отвественности на тех кто занимается развертыванием приложений, что не может не ухудшать качество ПО.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 28.04.07 08:52
Оценка:
M>>Ну и чем это отличается от объекта?

VD>"Это" ничем, так как является эмуляцией ООП на не поддерживающем на прямую эту парадигму языке. То есть то же ООП, только слишком многословно и сложно.


Ну почему же обязательно ООП?

VD>Никто не спорит, что любой процедурный язык позволяет эмулировать ООП.


VD>Только вопрос был не в этом. Вопрос был в том, что ФП дает в области проектирования на макро-уровне.


VD>Если все что оно дает — это возможность эмулировать ООП так же как это делали 30 лет назад на С, да еще и ченит препятствия, то в пору задуматся, а на хрена козе баян?


Хм. Что есть "проектирование на макро-уровне"?

Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки. От публичных и приватных функций никуда не убежишь, но по-моему, это не указывает на попытку "эмулировать" ООП. Это просто другая реализация "черной коробки" с известным публичным интерфейсом и непонятно чем внутри (а внутре у ней — неонка, ага )

Может, это Эрлангистам стоит говорить "нафига козе баян", говоря об ООП?


dmitriid.comGitHubLinkedIn
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: aka50 Россия  
Дата: 28.04.07 09:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


A>> Например http://code.google.com/p/google-guice/ или http://tapestry.apache.org/tapestry5/tapestry-ioc/ работают без конфигурационных файлов на аннотациях. Т.е. все в пределах одного языка. Вот собственно и интересно куда это отнести и чем это будет отличаться от поиска модулей в том же erlang на уровне самой vm.

VD>Это все равно другие языки и у них те же пролемы с интеграцией. Во время компиляции они не проверяются и имеют массу проблем с отладкой и вообще мало гарантий того что общая система основанная на них заведется и будет работать. В общем, их примененеие связанно с перекладыванием отвественности на тех кто занимается развертыванием приложений, что не может не ухудшать качество ПО.

Эти проблемы есть у любой компонентной архитектуры с возможностью гибкой настройки (JobSystemJBOSS, JobSystemJMS и проблему отсутсвия какого-то компонента компилятор решить не сможет, максимум проверит корректность типов, что могут делать и аннотации + annotation processor как часть компилятора)

А в целом я считаю что ценен именно FP + OOP. Например вот Мартин рассматривает возможные реализации компонентной архитектуры на Scala. Например с использованием abstract members или self-types.
http://www-edlab.cs.umass.edu/cs530/LectureSlides07/scala-popl06-6up.pdf

По этому дальше спорить не буду, ибо чистый ООП как и чистый FP — это максимализм. Гибчее надо быть

[off]
И scala мне все больше нравиться
[/off]
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 28.04.07 10:26
Оценка:
Здравствуйте, aka50, Вы писали:

A>По этому дальше спорить не буду, ибо чистый ООП как и чистый FP — это максимализм. Гибчее надо быть


A>[off]

A>И scala мне все больше нравиться
A>[/off]

Мне тоже (хотя есть определенные моменты, когда сахара слишком много), жду нормальной литературы и поддержки со стороны netbeans, а пока продолжаю играться.
Re[14]: Так в чем же принципиальные отличия ФП от ИП?
От: aka50 Россия  
Дата: 28.04.07 10:41
Оценка:
Здравствуйте, mini_root_2, Вы писали:

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


__>Мне тоже (хотя есть определенные моменты, когда сахара слишком много), жду нормальной литературы и поддержки со стороны netbeans, а пока продолжаю играться.

В intellj уже есть, но правда для этого надо 7-ку пользовать и еще эта поддержка пока слишком alpha... По этому тоже пока играюсь
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.05.07 15:25
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ну почему же обязательно ООП?


По определению.

M>Хм. Что есть "проектирование на макро-уровне"?


Этому вопросу посвящено не мало умных книг. Есть масса методик и подходов.

M>Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки.


Это механизмы абстрации С и Паскаля.

M>Может, это Эрлангистам стоит говорить "нафига козе баян", говоря об ООП?


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

На мой взгляд напрашивается вывод — чистые ФЯ не имеют особого интереса на пракике. Нужны гибридные языки позволяющие возсопльзоваться премуществами всех подходов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Не в тему, но про J :)
От: Quintanar Россия  
Дата: 02.05.07 19:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.


С недоверием — это, типа, на сайт даже не зашли? Вообще, странно, пару-тройку лет назад здесь была дискуссия по поводу К, ты же тогда же выступил в его пользу.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 21:48
Оценка:
VD>Другими словами — ФП отлично на макроуровне, когда нужно написать некий алгоритм, но вот средств композиции вепрхнего уровне у него нет. Модули не канают по сравненению с классами. Отсюда и появление такого количества гибридов ОО/Ф-языков.

А зачем вообще противопоставление объектный-фунциональный?
Откуда оно взялось?
Объектный-императивный само собой.
Но имхо функция совершенно не канает, как макро-сущность в нематематических задачах.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 21:53
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>>>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.


VD>>Вот это и называется структурной декомпозицей. ООП как раз и придумывали потому как при некотором объеме задачи она становится мало пригодной.


L>Чем это отличается от классов?


VD>>Собщственно сейчас даже при разработке на ЯП не поддерживающих ООП напрямую все равно проектирование ведется обычно именно в ООП. Достаточно взглянуть на API Линукса и Виндовс.


L>Поясни. Ты имеешь в виду работу с хендлами? Посылку сообщений? Что то ещё?


Троллите товарищ?
Или это действительно спор о бесполезности ООП?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.05.07 22:23
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>А зачем вообще противопоставление объектный-фунциональный?


А это не ко мне вопрос.
Меня тут называют "фанатиком" натуральные маньяки от того или другого лагеря.
Один видит нечто божественное в ООП и даже представить не может, что есть задачи (или их части) которые отлично решаются в другом стиле.
Второй спрашивает зачем лябды если есть объекты.
Третий спрашивает зачем объекты если есть замыкания.
Четвертый вообще орет, что ООП — это маразм, а все кто им занимается идиоты.

VGn>Откуда оно взялось?


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

VGn>Объектный-императивный само собой.

VGn>Но имхо функция совершенно не канает, как макро-сущность в нематематических задачах.

+1

А совмещение концепций дает отличный результат. Главное научиться делать правльный выбор в конкретных ситуациях.

Но тут возникает глобальнейшая проблема!
Большинство современных языков программирования не позволяют одинаково хорошо програмировать в разных стилях. Присловутый С++ только декларирует мультипарадигмность. Большинство ФЯ ООП могут только эмулировать и то со скрипом. В Ява и Шарп ООП вмонтирован, так, что что-то другое уже и использовать то непривычно, хотя Шарп движется в правильном направлении (если говорить о 3.0).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 22:24
Оценка:
Здравствуйте, VladD2, Вы писали:

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


M>>Ну почему же обязательно ООП?


VD>По определению.


M>>Хм. Что есть "проектирование на макро-уровне"?


VD>Этому вопросу посвящено не мало умных книг. Есть масса методик и подходов.


M>>Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки.


VD>Это механизмы абстрации С и Паскаля.


M>>Может, это Эрлангистам стоит говорить "нафига козе баян", говоря об ООП?


VD>Речь о том, что ФП не предлагает никаких средств проектирвоания отличных от структурного программирования известного со времен Алгола. Причем уже давно никто не спорит, что этих средств явно недостаточно для проектирования больших ситем.


VD>На мой взгляд напрашивается вывод — чистые ФЯ не имеют особого интереса на пракике. Нужны гибридные языки позволяющие возсопльзоваться премуществами всех подходов.


Хотя как вариант:
может, просто никто не подходил профессионально к этой задаче, потому что с использованием ФП на данный момент не решаются задачи бизнес-уровня.
А задачи бизнес-уровня замечательно решаются при нынешнем подходе и в ФП на макро уровне необходимости нет.
Опять же: методологии переписывать, UML новой версии — много работы.
Замкнутый круг.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 02.05.07 22:35
Оценка:
Здравствуйте, VGn, Вы писали:


VGn>Хотя как вариант:

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

А кто такой бизнес-уровень?
Это не он?
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 22:39
Оценка:
VD>Но тут возникает глобальнейшая проблема!
VD>Большинство современных языков программирования не позволяют одинаково хорошо програмировать в разных стилях. Присловутый С++ только декларирует мультипарадигмность. Большинство ФЯ ООП могут только эмулировать и то со скрипом. В Ява и Шарп ООП вмонтирован, так, что что-то другое уже и использовать то непривычно, хотя Шарп движется в правильном направлении (если говорить о 3.0).

Интересно, есть языки, в которых функциональные блоки используются в императивном коде по примеру паскалевских асемблерных вставок?
Было бы симпатичным решением, учитывая вышесказанное о макро и микро и плачи по поводу суперотимизирующих компиляторов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 22:50
Оценка:
D>А кто такой бизнес-уровень?
D>Это не он?

Типа того.
В скилах, как и отмечалось — Good understanding of C++ and OO design.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 22:55
Оценка:
A>Эти проблемы есть у любой компонентной архитектуры с возможностью гибкой настройки (JobSystemJBOSS, JobSystemJMS и проблему отсутсвия какого-то компонента компилятор решить не сможет, максимум проверит корректность типов, что могут делать и аннотации + annotation processor как часть компилятора)

Это уже имхо проблема высоких уровней абстракции. Точнее их отсутствия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[14]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 02.05.07 23:00
Оценка:
Здравствуйте, VGn, Вы писали:

D>>А кто такой бизнес-уровень?

D>>Это не он?

VGn>Типа того.

VGn>В скилах, как и отмечалось — Good understanding of C++ and OO design.

Угу. Между коммуникабельностью и знакомстовом с Excell.
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.05.07 23:07
Оценка:
Здравствуйте, VGn, Вы писали:

Большая просба так не оврквотить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:10
Оценка:
VGn>>Типа того.
VGn>>В скилах, как и отмечалось — Good understanding of C++ and OO design.

D>Угу. Между коммуникабельностью и знакомстовом с Excell.


Ещё там кого-то чему-то надо учить и кому-то в чём-то помогать.
Очевидно задачи довольно мелкие.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:20
Оценка:
VD>В общем, есть два лагера представители которых практически ничего не знают о другом лагере. Есть много фанатизма и откровенной некомпетенции. Причем ни у кого нет даже малейшего желания устранять эти проблемы.
VD>Те не многие кто хорошо разбирается в особенностях обоих лагерей и достаточно адекватен, чтобы не вподать в религиозные оргии одного из лагерей просрто не могут ничего исправить, так как нарываются на серьезное сопротивление по перечисленным причинам. Потыркавшись мноие из них просто бросают это знятие.

Мне это видится немного подругому:
лагерь бизнеса вообще не знает о других возможностях.
лагерь науки вообще не знает о реальных бизнес-задачах (скучать они начинают раньше чем дойдут до интересного)
Поэтому эти 2 лагеря практически не пересекаются.
А религиозные войны в форумах — это имхо случайные пересечения скучающих личностей с целью просто повоевать на какую-либо тему. Или крики веб-программистов, которые не смыслят ни в том, ни в другом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:24
Оценка:
D>>>Это не он?

VGn>>Типа того.


Немного ошибся (с первого раза не очень внимательно посмотрел).
Я имел в виду системы по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: граммофон  
Дата: 02.05.07 23:31
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Но имхо функция совершенно не канает, как макро-сущность в нематематических задачах.


О как. Это почему?
Или я, видимо, не совсем верно понял что понимается под функцией.
Как вижу я, функция — это как раз-таки сущность самого верхнего уровня; любой софт характеризуется в первую очередь своей функциональностью. То есть максимально абстрактное определение будет туплом из функций (f: X -> Y, ...) между входными данными и ожидаемым результатом. Потом f = f_1 * f_2 * .. * f_n и так далее.
Структуры данных вообще ортогональны функциональной декомпозиции и прямого влияния на результат не оказывают. А непосредственно ФП подходит к проектированию не созданием универсальных структур данных, а созданием универсальных функций. И вместо того, чтобы делать расширяемые данные, делают расширяемые отображение данных в необходимую форму.
прежде чем понять рекурсию, необходимо понять рекурсию.
Re[16]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 02.05.07 23:35
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>>>Типа того.

VGn>>>В скилах, как и отмечалось — Good understanding of C++ and OO design.

D>>Угу. Между коммуникабельностью и знакомстовом с Excell.


VGn>Ещё там кого-то чему-то надо учить и кому-то в чём-то помогать.

VGn>Очевидно задачи довольно мелкие.

Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.05.07 23:39
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Интересно, есть языки, в которых функциональные блоки используются в императивном коде по примеру паскалевских асемблерных вставок?


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

По сути, писать фукнционально можно на любом ЯП.

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

Все что унжно для поддержки ИП — это изменяемые переменные.

Так что нет проблем в создании гибридных языков. И таких языков уже не мало.
Проблема только в сознании людей и догмах. Тут найдется не мало фанатиков которые будут плеваться при певрвом упоминании модификации состояния. А простой довод, что любой вод-вывод (как консольный, так и графический) — это императивное действие сразу вызвает взрыв флуда и флэйма. Тебе сразу начинают объяснять, что ты неумешь смореть на мир. Что, мол, достаточно ввести левую переменную "мир" и все проблемы проходят. Мол каждый вод-вывод создает новый мир .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:44
Оценка:
VGn>>Но имхо функция совершенно не канает, как макро-сущность в нематематических задачах.

Г>О как. Это почему?

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

В общем-то, конечно, да, если плясать от IDEF. Но чем больше система, тем менее понятной становится её функциональная модель и сложнее выделять уровни абстракции.
В этом отношении ООП намного проще и удобнее.
Хотя знавал я одного айтишника в возрасте, который ооп/а так и не понял и держался зубами за IDEF. Правда всё это служило оправданием макаронному структурному подходу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[16]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 02.05.07 23:44
Оценка:
Здравствуйте, VladD2, Вы писали:

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


D>>Угу. Между коммуникабельностью и знакомстовом с Excell.


VD>А ты думаешь, что это не важно? По-твоему, важно только кнопки нажимать уметь?


VD>Кому ты нужен в большом проекте если не умешь в Ёкселе табличку слабать с отчеом и не в силах договриться с товарищами и начальством о том, что и как ты будешь делать?


Я лишь к тому, что в этом оффере обсуждаемые скиллы — дополнительные. Никто не говорит, что они не важны.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:49
Оценка:
это если путать декларативное равенство с присвоением
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[17]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:54
Оценка:
D>Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.

В больших проектах от одного человека не требуется выполнение нескольких малозависимых ролей сразу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[17]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 02.05.07 23:54
Оценка:
D>Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.

Ты представляешь себе задачу, которую можно решать сотнями высоколобых математиков?
Я — нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[18]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 03.05.07 00:05
Оценка:
Здравствуйте, VGn, Вы писали:

D>>Ага. Мелкая задача управления финансами Credit Suisse Там сидят высоколобые математики, генерящие идеи и модели и надо эти модели уметь быстренько воплощать в код. Вот этот DSL для них, похоже, и делается.


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


Вроде сначала речь шла о "задачах бизнес-уровня".
И потом — универсальный DSL для финансового моделирования в гигантской бизнес-структуре это не "большой проект"?
Re[18]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 03.05.07 00:07
Оценка:
Здравствуйте, VGn, Вы писали:


VGn>Ты представляешь себе задачу, которую можно решать сотнями высоколобых математиков?


Теорема Ферма
Re[19]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 03.05.07 00:13
Оценка:
VGn>>Ты представляешь себе задачу, которую можно решать сотнями высоколобых математиков?
D>Теорема Ферма

И чем в данном отдельно взятом случае сотни математиков эффективнее одного?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[19]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 03.05.07 00:18
Оценка:
VGn>>В больших проектах от одного человека не требуется выполнение нескольких малозависимых ролей сразу.

D>Вроде сначала речь шла о "задачах бизнес-уровня".

D>И потом — универсальный DSL для финансового моделирования в гигантской бизнес-структуре это не "большой проект"?

В этом случае задача больше похожа на абстракто математическую.
Задачами бизнес-уровня я считаю задачи, которые решаются вширь.
Поясню:
Мы тут с Владом беседовали о противположных лагерях программистов.
Программирование — это, как известно борьба со сложностью.
Только в одних задачах — это борьба со сложностью вглубь, а в других — вширь.
Естественно, что раз задачи ортогональны, то люди их решающие могут спорить до
хрипоты, и никогда не поймут друг друга, потому что беседуя вроде об одном, думают совершенно о разном.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: граммофон  
Дата: 03.05.07 01:38
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Например, я сталкнулся с нешуточным сопротивлением просто потому, что язык не поддерживается мега-корпорацией вроде МС или Сана. И этих людей можно понять.

VD>Так же я сто раз нарывался на высассанные из пальца утверждения.
VD>С ФП все усложняется практически полным отсуствие учебных материалов приемлемого качества. То что есть нассчитано или на людей с серьезным мат. образованием, или вообще никуда не годятся. Вещей класса "The C programming language" я не видел во все.

Ну все не так уж и плохо, конечно. Для хаскеля есть the Haskell School of Expression, Programming Haskell и еще пяток приличных. Для ML/Caml полно книжек на любую тему. И все от вполне себе попсовых издательств типа O'Reilly и Addison-Wesley. Для лиспа есть те же Грэм и Сейбел. Это не считая приличного количества самиздата и и всякой вики-блогосферы.
Но дело не в этом. Все же спрос рождает предложение, а не наоборот. Если человек захочет что-то выучить, он это выучит и без кучи книжек. А если не хочет, то хоть обложи его литературой.
прежде чем понять рекурсию, необходимо понять рекурсию.
Re[16]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 03.05.07 08:04
Оценка:
Здравствуйте, VGn, Вы писали:

D>>>>Это не он?


VGn>>>Типа того.


VGn>Немного ошибся (с первого раза не очень внимательно посмотрел).

VGn>Я имел в виду системы по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой.

А может оно и не надо? Может ФП (грамотно применяемый) позволяет сократить всю эту кучу народа раз в нцать?


dmitriid.comGitHubLinkedIn
Re[17]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 03.05.07 08:24
Оценка:
VGn>>Я имел в виду системы по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой.

M>А может оно и не надо? Может ФП (грамотно применяемый) позволяет сократить всю эту кучу народа раз в нцать?


Не сократит.
Замена дешёвых кодеров на Разработчиков сократит раза в 2 от силы.
Проблемы не в сложности самих задач, а в их количестве, классификации и построении на этой базе архитектуры. ФП на верхнем уровне только усложнит и замедлит этот процесс.
А значит + ещё 1000 кодеров.
Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.
В моём нынешнем проекте из 15 сборок ФП напрашивается толко в 5.
И то — ещё только потому, что на него завязано меньше бизнес-логики и больше системных задач.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[3]: Не в тему, но про J :)
От: Gaperton http://gaperton.livejournal.com
Дата: 03.05.07 08:27
Оценка:
Здравствуйте, Quintanar, Вы писали:

G>>Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.


Q>С недоверием — это, типа, на сайт даже не зашли? Вообще, странно, пару-тройку лет назад здесь была дискуссия по поводу К, ты же тогда же выступил в его пользу.


Почему — зашли. Только было это очень давно — в районе 2001 года, кажется. До дискуссий о К.
Re[14]: Так в чем же принципиальные отличия ФП от ИП?
От: Lloyd Россия  
Дата: 03.05.07 10:07
Оценка:
Здравствуйте, граммофон, Вы писали:

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



VD>>Например, я сталкнулся с нешуточным сопротивлением просто потому, что язык не поддерживается мега-корпорацией вроде МС или Сана. И этих людей можно понять.

VD>>Так же я сто раз нарывался на высассанные из пальца утверждения.
VD>>С ФП все усложняется практически полным отсуствие учебных материалов приемлемого качества. То что есть нассчитано или на людей с серьезным мат. образованием, или вообще никуда не годятся. Вещей класса "The C programming language" я не видел во все.

Г>Ну все не так уж и плохо, конечно. Для хаскеля есть the Haskell School of Expression, Programming Haskell и еще пяток приличных.


Странно, но в осле найти их не удалось.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: граммофон  
Дата: 03.05.07 10:55
Оценка:
Здравствуйте, Lloyd, Вы писали:

Г>>Ну все не так уж и плохо, конечно. Для хаскеля есть the Haskell School of Expression, Programming Haskell и еще пяток приличных.


L>Странно, но в осле найти их не удалось.


И еще более странно то, что у меня там только что нашлись:
Haskell: The Craft of Functional Programming (2nd Edition) — Simon Thompson
The Haskell Road to Logic, Math and Programming — Kees Doets & Jan van Eijck. В хорошем состоянии
Programming in Haskell (draft, CUP, 2005)(200s) Hutton A.
Портсигар отечественный — два

THSoE нету, да. У меня она, увы, только в бумажном виде.
прежде чем понять рекурсию, необходимо понять рекурсию.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.05.07 10:58
Оценка:
Здравствуйте, VGn, Вы писали:

L>>Поясни. Ты имеешь в виду работу с хендлами? Посылку сообщений? Что то ещё?


VGn>Троллите товарищ?


Нет, просто не понимаю, что имеется в виду.

VGn>Или это действительно спор о бесполезности ООП? :???:


Как из моих слов следует бесполезность ООП?
Re[20]: Так в чем же принципиальные отличия ФП от ИП?
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.05.07 11:08
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Только в одних задачах — это борьба со сложностью вглубь, а в других — вширь.


Что такое вглубь и что такое вширь? То, что Влад называл микро и макро?
Re[21]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 03.05.07 12:00
Оценка:
VGn>>Только в одних задачах — это борьба со сложностью вглубь, а в других — вширь.

L>Что такое вглубь и что такое вширь? То, что Влад называл микро и макро?


Похоже, но не совсем.
Вглубь — это решение небольших по объёму требований, но алгоритмически сложных задач.
Вширь — решение большого количества связанных мелких задач по большому количеству динамически изменяющихся требований.
Иногда, но очень редко, сумма второго рождает первое. Но чаще всего в этих случаях нет соответствующих людей, потому что задачи второго списка им не интересны по определению.
Re[19]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.05.07 12:03
Оценка:
Здравствуйте, palm mute, Вы писали:

VGn>>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.

PM>Не торопитесь. Функционально-реактивные графические интерфейсы — очень активная область исследований в последнее время. Пролистайте туториал по flapjax, например, и убедитесь, что функциональное описание поведения интерфейса в терминах зависимостей между контролами может быть значительно проще привычных Form1.Button1_OnClick().

Что-то не вижу противоречий с предыдущим утверждением. Логика работы формы — это одно. А презентационная часть совсем другое.

К тому же для логики нужны скорее подходы вроде континюэшонов или конечных автоматов (в прочем первые можно считать плоской и понятной записью последних).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 04.05.07 06:47
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Похоже, но не совсем.

VGn>Вглубь — это решение небольших по объёму требований, но алгоритмически сложных задач.
VGn>Вширь — решение большого количества связанных мелких задач по большому количеству динамически изменяющихся требований.
VGn>Иногда, но очень редко, сумма второго рождает первое. Но чаще всего в этих случаях нет соответствующих людей, потому что задачи второго списка им не интересны по определению.

Добрый день, товарищи!
А если по диагонали?
Например: пишется что-нибудь объемное, функционал, не зависящий от задачи, можно накидать из готовых компонентов или написать на тех Java/C# а сверху прикрутить что-нибудь ДикоФункциональноЗасахареннное+сПоддержкойООП (например scala хорошо встраивается в Яву) и прикладные вещи писать уже на нем. Таким образом никаких проблем с декомпозицей не будет(ООП и там и там), можно использовать все фичи ФП и в то же время функцилнальная зараза(сахар) не распротраняется по всей программе.
Возникает два вопроса:
1)Стоит ли оно того?
2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно
обойтись и отладочными сообщениями).
Re[23]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 04.05.07 06:52
Оценка:
Здравствуйте, mini_root_2, Вы писали:

__>2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно

__>обойтись и отладочными сообщениями).

Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода.
Ну а Яву дебажить без проблем. Т.е. чистофункциональные куски "перескакиваем". Или ты хочешь дебажить "до инструкции"?
Re[19]: А за что же минус-то? :) [-]
От: Mamut Швеция http://dmitriid.com
Дата: 04.05.07 07:13
Оценка:
Сабж.


dmitriid.comGitHubLinkedIn
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 04.05.07 08:15
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода.

К>Ну а Яву дебажить без проблем. Т.е. чистофункциональные куски "перескакиваем". Или ты хочешь дебажить "до инструкции"?

1) В реальности не все так гладко...
2) Я не предлагаю использовать в надстройке чистое ФП, вместо этого можно спользовать гибрид,
где есть императив+ООП и функциональный сахар, в любом случае отладка (желательно удаленная) необходима.
Re[21]: А за что же минус-то? :) [-]
От: Mamut Швеция http://dmitriid.com
Дата: 04.05.07 08:44
Оценка:
D>Может человеку Coldfusion и отсутствие ФП в проекте говорит о многом?



Тогда перефразирую.

ФП в проекте используется только в виде использования функциональных подходов во время программирования на Яваскрипте Благо функции как first-class objects и замыкания он поддерживает на ура


dmitriid.comGitHubLinkedIn
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 04.05.07 14:08
Оценка:
Здравствуйте, Трурль, Вы писали:

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


Т>G Паттерны какие-то наверное есть (foldr, foldl, и прочее к ним можно отнести), но на книгу их точно не хватит .


Т>Собрать несколько таких статей и хватит .

Ахренеть! Посыпаю голову пеплом, ухожу в монастырь.
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 04.05.07 15:50
Оценка:
К>Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода.

Главное слово тут — "если". Императивный код тоже отлаживать не нужно, ЕСЛИ он корректен.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[20]: А за что же минус-то? :) [-]
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 04.05.07 15:59
Оценка:
>Это из разряда "87.34569712% всех приводимых цифр взяты с потолка"?
Это — придирка к словам.

VGn>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.


>А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"


А чем занимается 90% народа при разработке таких систем? Реализацией бизнес-логики.
А что такое бизнеслогика в крупных корпоративных системах? По большей части формочки.

>Телекоммуникации, data mining — это вполне такие системы. А ФП там применяются.


Я работаю в телекоммуникациях. У нас ФП не применяется. (Не скажу что это правильно. Но это — факт.)

Минус поставил, надеясь не отвечать. Потому что считаю такой разговор малосодержательным.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[23]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.07 16:47
Оценка:
Здравствуйте, mini_root_2, Вы писали:

__>2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно обойтись и отладочными сообщениями).


Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.

И вообще, Скала ничем не уступает Яве (как языку) и при использовании Скалы использовать Яву уже смысла особого нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
От: Gajdalager Украина  
Дата: 04.05.07 18:40
Оценка:
Здравствуйте, VladD2, Вы писали:

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


__>>2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно обойтись и отладочными сообщениями).


VD>Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.


VD>И вообще, Скала ничем не уступает Яве (как языку) и при использовании Скалы использовать Яву уже смысла особого нет.

Как язык — да.. Однако поддержка IDE хромает на обе ноги. Не знаю, как самая распоследняя версия Эклипс-плагина, однако в предпоследней регулярно пропадала подсветка синтаксиса. А плагин для Идеи каждый раз при запуске бросает непонятную ошибку. В общем, до полноценной интеграции как с Эклипсом, так и с Идеей, ИМХО, ещё далеко.
А чтобы можно было пользовать мощь гибридного ФП-ИП подхода в промышленном программировании, нужны ещё и библиотеки, написанные с учётом этого подхода (например DB-маппер уровня Хибернейта или враппер над оным) да тулзы разные (к примеру, визуальный редактор GUI)... Вот тогда можно будет писать проекты только на Скале.
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Within Temptation — Candles & Pears Of Light (remix)
Re[4]: Не в тему, но про J :)
От: Mikl Kurkov Россия  
Дата: 04.05.07 21:19
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>>>Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.


Q>>С недоверием — это, типа, на сайт даже не зашли? Вообще, странно, пару-тройку лет назад здесь была дискуссия по поводу К, ты же тогда же выступил в его пользу.


G>Почему — зашли. Только было это очень давно — в районе 2001 года, кажется. До дискуссий о К.


Да, интересно. А вот ваши конкуренты похоже давно и плодотворно его используют.
Кстати у них на сйте лежит мануал по KDB+, выгодно отличающийся от материалов на родном сайте презентабельностью. Некоторые места вообще выдержаны в стиле рекламных буклетов.
А вдруг кому-нибудь поможет в принятии правильного решения при выборе новой БД.

--
Mikl
Re[5]: Не в тему, но про J :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.07 23:43
Оценка:
Здравствуйте, Mikl Kurkov, Вы писали:

Большая просьба не оверквотить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 05.05.07 06:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.


Верно! Просто там при встраивании кажется дергается класс Interpreter(точно не помню, завтра прихвачу код и выложу...), то что он компилится в байт код и потом грузится в JVM это понятно.

Я имел в виду общий случай (можно встроить ведь и Groovy?). Что касается отладки то я имел ввиду
именно поддержку со стороны IDE. Проблемма в том что они обычно не могут отлаживать что попало.
Хотя в Netbeans можно подцепить отладчик к произвольному процессу(в т.ч. и удаленно) и отлаживать
при наличии исходников — вот только они, помоему, должны быть уложены в соответствующие проекты.
Поправьте, если ошибаюсь.
Re[25]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 05.05.07 07:11
Оценка:
Здравствуйте, Gajdalager, Вы писали:

G>А чтобы можно было пользовать мощь гибридного ФП-ИП подхода в промышленном программировании, нужны ещё и библиотеки, написанные с учётом этого подхода (например DB-маппер уровня Хибернейта или враппер над оным) да тулзы разные (к примеру, визуальный редактор GUI)... Вот тогда можно будет писать проекты только на Скале.


Речь не идет о том что писать проекты только на скале. Что касается hibernate, то что мешает его
использовать как есть? С другой стороны, например, для работы с БД я врядли смогу привести много
примеров того куда можно засунуть ФП-шный фишки (например RowMapper в Spring, если делать через
анонминый класс то это почти лямбда). Что касается GUI через ФП — тут моя фантазий пасует... (во всем
виноват Swing ).

По поводу того что бизнес логика это форточки — категорически не согласен! Форточки это представления
результатов каких-то операций проведенных в соответствии с БЛ, а сама БЛ может быть очнеь даже сложной и включать себя работу с несколькими БД, уадаленные вызовы и т.д.
Re[21]: А за что же минус-то? :) [-]
От: Mamut Швеция http://dmitriid.com
Дата: 05.05.07 08:28
Оценка:
>>Это из разряда "87.34569712% всех приводимых цифр взяты с потолка"?
VGn>Это — придирка к словам.

Мне просто не понравилось утверждение:

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

А значит + ещё 1000 кодеров.


Просто +1000 кодеров — это совсем необязательно.

VGn>>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.


>>А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"


VGn>А чем занимается 90% народа при разработке таких систем? Реализацией бизнес-логики.

VGn>А что такое бизнеслогика в крупных корпоративных системах? По большей части формочки.

???

Я честно не понимаю, как бизнес-логика связана с формочками.

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

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

>>Телекоммуникации, data mining — это вполне такие системы. А ФП там применяются.


VGn>Я работаю в телекоммуникациях. У нас ФП не применяется. (Не скажу что это правильно. Но это — факт.)


Ну а в Эрикссоне и Нортеле применяется. И это тоже факт

VGn>Минус поставил, надеясь не отвечать. Потому что считаю такой разговор малосодержательным.


Я просто не понимаю, почему

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




Может, их просто надо правильно готовить?


dmitriid.comGitHubLinkedIn
Re[21]: А за что же минус-то? :) [-]
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 05.05.07 10:44
Оценка:
VGn,

>>А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"


VGn>А чем занимается 90% народа при разработке таких систем? Реализацией бизнес-логики.

VGn>А что такое бизнеслогика в крупных корпоративных системах? По большей части формочки.

Что-то твои умозрительные заключения противоречат практике.
Advanced programming language design in enterprise software

Мой скромный опыт в enterprise говорит, что подавляющее количество сил и времени уходит на преобразование данных (графические рисунки <-> xml, business rules <-> java, xml1 <-> xml2, xml <-> java, xml <-> sql, string <-> binary etc). А jsp — это туфта. Нам требовалось порядка 90 форм, и мы вшестером их сделали за 2 недели. По готовым метаданным это делалось быстро и совершенно тупо. А можно вообще убрать людей, и купить генератор, например jaxfront.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[25]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 05.05.07 21:12
Оценка:
VD>Более того, ни одна серьеная программа не мыслима без состояния. Фанитики ФП могут говорить, что угодно, но состояние будет обязательно. Просто возможно вместо объектов оно будет храниться в разных монадах, хэш-таблицах процесса и т.п.

В случае ФП контроллируемым значением может быть некая промежуточная (или контрольная) функция (естественно, не без состояния)
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[26]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 05.05.07 21:12
Оценка:
__>По поводу того что бизнес логика это форточки — категорически не согласен! Форточки это представления
__>результатов каких-то операций проведенных в соответствии с БЛ, а сама БЛ может быть очнеь даже сложной и включать себя работу с несколькими БД, уадаленные вызовы и т.д.

Наверное, это — камень в мой огород.
Полностью согласен с данным утверждением. Упоминая формочки в качестве основной части бизнес-логики корпоративных систем, я имел в виду верхний уровень абстракции. То, что основные источники, условия и результаты работы находятся именно там.
Из 15 сборок в моём нынешнем проекте к GUI имеют отношение только 2 (причём не самые объёмные). При этом я считаю, что эти самые формочки у меня составляют около 70% бизнес-логики. Остальное — это API и всего-навсего реализация, со всеми БД, AD, шедалерами, ремоутингом, кофигурированием и т.п.
Безусловно, это очень обобщённое утверждение.
Но заказчик думает именно так. И, по большому счёту, он прав.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[22]: А за что же минус-то? :) [-]
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 05.05.07 21:12
Оценка:
M>Просто +1000 кодеров — это совсем необязательно.
Рост сложности прямо пропорционален росту трудозатрат.

M>Я честно не понимаю, как бизнес-логика связана с формочками.

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

Если говорить о реализации, то ты прав на все 100%.
Но разговор изначально был о целях. Любой встречный ПМ скажет тебе, что важнее чтобы "Эта иконка была василькового цвета" (с)FightClub,
чем твой способ доступа к БД или протокол передачи данных.

M>Ну а в Эрикссоне и Нортеле применяется. И это тоже факт

Это по большей части системный софт.

M>Я просто не понимаю, почему

M>

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


M>Может, их просто надо правильно готовить?


Есть рецепты?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[27]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 06.05.07 06:05
Оценка:
Здравствуйте, VGn, Вы писали:

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

VGn>Из 15 сборок в моём нынешнем проекте к GUI имеют отношение только 2 (причём не самые объёмные). При этом я считаю, что эти самые формочки у меня составляют около 70% бизнес-логики. Остальное — это API и всего-навсего реализация, со всеми БД, AD, шедалерами, ремоутингом, кофигурированием и т.п.
VGn>Безусловно, это очень обобщённое утверждение.
VGn>Но заказчик думает именно так. И, по большому счёту, он прав.

Брр... Очень странно. Что, всё-таки, ты вкладываешь в слово "бизнес-логика"? Представь, что делается система управления какой-то торговлей. Есть, скажем, код, рассчитывающий скидку клиенту по его предыдущим закупкам. Он может использоваться в формочке розничной продажи, формочке оптовой отгрузки со склада, в web-интерфейсе. Ты его будешь копипастить в три места?
Обычно всё-таки стараются отделить слой бизнес-логики от presentation layer.
Re[25]: Так в чем же принципиальные отличия ФП от ИП?
От: mini_root_2  
Дата: 06.05.07 06:32
Оценка:
Здравствуйте, mini_root_2, Вы писали:

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


VD>>Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.


__>Верно! Просто там при встраивании кажется дергается класс Interpreter(точно не помню, завтра прихвачу код и выложу...), то что он компилится в байт код и потом грузится в JVM это понятно.

Выкладываю:

 BufferedReader reader=new BufferedReader(new InputStreamReader(System.in));
 PrintWriter writer=new PrintWriter(System.out);
 Settings s=new Settings();
 ConsoleReporter r=new ConsoleReporter(s,reader,writer);   
 Interpreter i=new Interpreter(s,r,writer);
 i.interpret("Console.println(2+2)");


А по-поводу того чтобы использовать скалу вместо явы (а не скалу на яве), то пока ну будет нормальной
поддержки со стороны IDE, нормальной документации (а еще лучше книжек) и т.д — особого смысла не вижу.
Кроме того из скалы без проблем можно дергать явовские классы. Вопрос по поводу отладки, как отлаживать:
i.interpret("Console.println(2+2)");
Re[28]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 06.05.07 06:47
Оценка:
D>Брр... Очень странно. Что, всё-таки, ты вкладываешь в слово "бизнес-логика"? Представь, что делается система управления какой-то торговлей. Есть, скажем, код, рассчитывающий скидку клиенту по его предыдущим закупкам. Он может использоваться в формочке розничной продажи, формочке оптовой отгрузки со склада, в web-интерфейсе. Ты его будешь копипастить в три места?
D>Обычно всё-таки стараются отделить слой бизнес-логики от presentation layer.

Это ты с кем сейчас споришь?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[29]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 06.05.07 07:32
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Это ты с кем сейчас споришь?


При этом я считаю, что эти самые формочки у меня составляют около 70% бизнес-логики.


Я просто хочу понять, что ты понимаешь под термином бизнес-логика. Я всегда считал, что бизнес-логика — это совокупность правил, принципов и зависимостей в некоторой предметной области. Как формочки могут составлять "правила, принципы и зависимости" — мне не ясно. Ты имеешь в виду, что код, воплощающий эти "правила, принципы и зависимости" реализован в методах формочек? Тогда, ИМХО, 70% — это многовато. Хотя, конечно, от задачи зависит...
Re[28]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.05.07 06:27
Оценка:
D>Обычно всё-таки стараются отделить слой бизнес-логики от presentation layer.

Предлагаю в данном контексте от слова "бизнес-логика" (действительно употребляемого обычно в другом смысле) веруться обратно к "бизнес-уровню" или придумайте сами как это назвать.
Вот только дай людям повод к словам придраться! Блин!
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[30]: Так в чем же принципиальные отличия ФП от ИП?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.05.07 06:33
Оценка:
D>Я просто хочу понять, что ты понимаешь под термином бизнес-логика. Я всегда считал, что бизнес-логика — это совокупность правил, принципов и зависимостей в некоторой предметной области.

Значит всегда путал бизнес-логику с бизнес-правилами.
Бизнес-логика — это всего лишь логика работы программы минус системная логика.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[29]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 07.05.07 09:10
Оценка:
Здравствуйте, VGn, Вы писали:

Re[30]: Это был я :)
От: deniok Россия  
Дата: 07.05.07 09:13
Оценка:
Re[5]: Не в тему, но про J :)
От: Mirrorer  
Дата: 07.05.07 09:29
Оценка:
Здравствуйте, Mikl Kurkov, Вы писали:

MK>Кстати у них на сйте лежит мануал по KDB+, выгодно отличающийся от материалов на родном сайте презентабельностью.


Хм. А я был уверен что это от К-шников дока. Еще удивился, насколько они качественные доки начали делать
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[6]: Не в тему, но про J :)
От: Quintanar Россия  
Дата: 07.05.07 10:11
Оценка:
Здравствуйте, Mirrorer, Вы писали:

M>Здравствуйте, Mikl Kurkov, Вы писали:


MK>>Кстати у них на сйте лежит мануал по KDB+, выгодно отличающийся от материалов на родном сайте презентабельностью.


M>Хм. А я был уверен что это от К-шников дока. Еще удивился, насколько они качественные доки начали делать


Видно, вы ее не читали. Довольно отстойная дока со множеством опечаток. Хорошая книга-дока у KX есть, но, почему-то, не в открытом доступе.
Re[7]: Не в тему, но про J :)
От: Mirrorer  
Дата: 07.05.07 10:31
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Видно, вы ее не читали. Довольно отстойная дока со множеством опечаток.


Внимательно не читал. Факт. Просмотрел по диагонали.
Но мне просто не с чем было сравнивать. Единственное что до этого я видел по К это Kref 1998 года выпуска. Kref неплохой справочник по языку. Но хоть какое-то общее описание системы я первый раз увидел именно в отстойной доке.

И в ней же с удивлением открыл, что K нормально интегрируется с .NET и Java. Опять же, я не пробовал руками эту интеграцию. Вполне может быть что качество у нее неидеальное.

Q>Хорошая книга-дока у KX есть, но, почему-то, не в открытом доступе.

Жаль
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 08.05.07 09:13
Оценка:
M> Состояние этот модуль тоже может хранить

Эмм... процессы Эрланга — они конечно являются тяжеловесными объектами — но все же сколько может быть реально таких процессов вработающей программе? три тысячи? тридцать тысяч? Объектов в C++ или Java программе наверное побольше будет
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.05.07 09:40
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Эмм... процессы Эрланга — они конечно являются тяжеловесными объектами — но все же сколько может быть реально таких процессов вработающей программе? три тысячи? тридцать тысяч? Объектов в C++ или Java программе наверное побольше будет


С чего ты взял тяжеловесность? В том и смысл что они "лёгкие" (хотя и тут есть пределы ), по сравнению с потоками обычными.
Вроде как десятки тысяч процессов — это обычная ситуация. А в плюсах и жаве порой есть объекты которые практически только инкапсулируют данные (т.е. struct по сути), реализовывать их в виде процессов довольно странное занятие (хотя тоже может быть нужным )
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 08.05.07 10:02
Оценка:
Здравствуйте, Курилка, Вы писали:

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


А>>Эмм... процессы Эрланга — они конечно являются тяжеловесными объектами — но все же сколько может быть реально таких процессов вработающей программе? три тысячи? тридцать тысяч? Объектов в C++ или Java программе наверное побольше будет


К>С чего ты взял тяжеловесность? В том и смысл что они "лёгкие" (хотя и тут есть пределы ), по сравнению с потоками обычными.


Не читаешь.
Прочитай сначала — процессы Эрланга легковесны по сравнению с нитями ОС — и *тяжеловесны* по сравнению с объектами C++/Java/etc

К>Вроде как десятки тысяч процессов — это обычная ситуация. А в плюсах и жаве порой есть объекты которые практически только инкапсулируют данные (т.е. struct по сути), реализовывать их в виде процессов довольно странное занятие (хотя тоже может быть нужным )


Однако тогда не говори что процессы — замена объектам. Иногда, но только не полностью.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.05.07 10:08
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Прочитай сначала — процессы Эрланга легковесны по сравнению с нитями ОС — и *тяжеловесны* по сравнению с объектами C++/Java/etc


Поясни "тяжеловесность", фактически там есть мессаджбокс и словарь процесса.
Фактически это аналог переменных класса + таблицы методов.

К>>Вроде как десятки тысяч процессов — это обычная ситуация. А в плюсах и жаве порой есть объекты которые практически только инкапсулируют данные (т.е. struct по сути), реализовывать их в виде процессов довольно странное занятие (хотя тоже может быть нужным )


А>Однако тогда не говори что процессы — замена объектам. Иногда, но только не полностью.


Я говорил? Покажи.
Мамут говорил, что процессы могут участвовать в декомпозиции системы также как объекты, как раз на "макроуровне", а таких объектов много быть не может по определению.
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: Аноним  
Дата: 08.05.07 10:49
Оценка:
К>Поясни "тяжеловесность", фактически там есть мессаджбокс и словарь процесса.
К>Фактически это аналог переменных класса + таблицы методов.

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

VMT состоит из пар integer — ID+указатель. Тоже структура заметно попроще, чем словарь. И она одна на класс, а не одна на объект. Наконец используется она заметно менее гибко — т.е. реализация опять таки проще и ресурсов требуется меньше.


А>>Однако тогда не говори что процессы — замена объектам. Иногда, но только не полностью.


К>Я говорил? Покажи.


ДЕйствительно, Мамут. Но не суть, если ты с ним согласен.

К>Мамут говорил, что процессы могут участвовать в декомпозиции системы также как объекты, как раз на "макроуровне", а таких объектов много быть не может по определению.


Если только объекты макроуровня — то да.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 08.05.07 15:47
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>По-моему, чистый фп подход продьюсит спагетти-код


Эээ, залезем в Вики

Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.


И? Причём тут чистый ФП?
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 08.05.07 17:35
Оценка:
Здравствуйте, Константин Л., Вы писали:

D>>

D>>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.


КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.


Кто сказал такую глупость. Это утверждение неверно в первую очередь из-за того, что ФП сам по себе никак не пересекается с макроархитектурой. Тот же Common Lisp поддерживает как ОО, так и ФП. То же самое можно сказать про Nemerle (правда, это гибридный язык, но, как выяснилось, ФП и ОО в одном флаконе вполне ужились). Есть и несколько другой подход — система типов Хаскеля. Она гораздо мощнее, чем в том же .NET. Единственный минус — если в ОО можно делать "методы-омонимы", т.е. методы у совершенно несвязанных классов, обладающие различной функциональностью, но имеющие одинаковые названия, то в Хаскеле такого провернуть не удастся, потому приходится придумывать кучу префиксов для методов. Но и эта проблема разрешима, т.к. при правильном проектировании такие вещи сводятся к минимуму. Кроме того, никто не запрещает некому Васе придумать систему типов Хиндли-Милнера-Пупкина, где это будет учтено.

КЛ>2. слабо структурированная. Туда же.


Обоснуй.

КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси


Это лямбды-то спагетти? Вот когда мне нужно в C# 1.0 что-то отсортировать по сложному критерию, приходится объявлять доп. приватный метод. Так вот и начинает в глазах рябить от нагромождения мелких приватных методов. А если нужно ещё смоделировать замыкания, то приходится делать приватный класс, так что проще "выпитьйаду" и убить себя "апстену". Хорошо хоть, что в C# 2.0 проблема была решена. А в ФЯ эта проблема решена красивее и лаконичнее.

КЛ>4. трудная для понимания программа. см. пункт 3.


Конечно же. Программа на языке, содержащем крутые фичи по объёму меньше, чем на менее мощном языке. Потому средняя скорость восприятия (в строках) такой программы на мощном языке меньше. Надо заметить, что крутой язык — не обязательно ФЯ. Но вот если язык смог правильно позаимствовать из ФЯ хорошие концепции, то это только увеличивает его мощь.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 19:44
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:


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


D>>>Здравствуйте, Константин Л., Вы писали:


КЛ>>>>По-моему, чистый фп подход продьюсит спагетти-код



КЛ>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.

КЛ>>2. слабо структурированная. Туда же.

D>Извини, но это уже неприкрытый флейм. Реч шла про код.


я не про код?

КЛ>>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси


D>Лямбды не порождают спагетти — они замкнуты на себя и никуда не ссылаются.


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

КЛ>>4. трудная для понимания программа. см. пункт 3.

КЛ>>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?

D>А с ними то что не так? Лаконичнейшее средство абстрагирования

D>
D>map унарная_функция список
D>


D>
D>fold бинарная_функция инициализатор список
D>

D>Где тут спагетти?

а где тут функции высшего порядка? это fold что-ли, который принимает функцию?

D>Что касается претензий к читабельности, то, извини, любой язык надо сначало изучить, пописать на нём какое-то время, а уж потом рассуждать об этой самой читабельности. А то вот я по-финнски ничего не понимаю, нечитабельный, блин, язык.


Да ну как бы никто не возражает. На любом языке можно писать нечитабельно, просто фичеры ФЯ чуть-чуть способствуют этому.

Ладно, мой поинт в том, что оо+фя гораздо привлекательнее и "живучее" чем чистые фя.

PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 19:55
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Константин Л., Вы писали:


D>>>

D>>>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.


КЛ>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.


K>Кто сказал такую глупость. Это утверждение неверно в первую очередь из-за того, что ФП сам по себе никак не пересекается с макроархитектурой. Тот же Common Lisp поддерживает как ОО, так и ФП. То же самое можно сказать про Nemerle (правда, это гибридный язык, но, как выяснилось, ФП и ОО в одном флаконе вполне ужились). Есть и несколько другой подход — система типов Хаскеля. Она гораздо мощнее, чем в том же .NET. Единственный минус — если в ОО можно делать "методы-омонимы", т.е. методы у совершенно несвязанных классов, обладающие различной функциональностью, но имеющие одинаковые названия, то в Хаскеле такого провернуть не удастся, потому приходится придумывать кучу префиксов для методов. Но и эта проблема разрешима, т.к. при правильном проектировании такие вещи сводятся к минимуму. Кроме того, никто не запрещает некому Васе придумать систему типов Хиндли-Милнера-Пупкина, где это будет учтено.


здесь сказали такую глупость и я с ней согласен
Автор: VladD2
Дата: 23.04.07


КЛ>>2. слабо структурированная. Туда же.


K>Обоснуй.


КЛ>>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси


K>Это лямбды-то спагетти? Вот когда мне нужно в C# 1.0 что-то отсортировать по сложному критерию, приходится объявлять доп. приватный метод. Так вот и начинает в глазах рябить от нагромождения мелких приватных методов. А если нужно ещё смоделировать замыкания, то приходится делать приватный класс, так что проще "выпитьйаду" и убить себя "апстену". Хорошо хоть, что в C# 2.0 проблема была решена. А в ФЯ эта проблема решена красивее и лаконичнее.


чувствуешь разницу м/у лямбдами и спагетти из лямбд? Ну ладно, тут почти можно отступить.

КЛ>>4. трудная для понимания программа. см. пункт 3.


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


Проблема — структурированность. Сам писал на clisp, поэтому есть представление.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.05.07 19:57
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю


Ты есть замкнутая система, которая не разумеет чужих мыслей?
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 08.05.07 20:00
Оценка:
Здравствуйте, Константин Л., Вы писали:

D>>
D>>map унарная_функция список
D>>


D>>
D>>fold бинарная_функция инициализатор список
D>>

D>>Где тут спагетти?

КЛ>а где тут функции высшего порядка? это fold что-ли, который принимает функцию?


Конечно. Это, собственно, и есть канонические ФВП.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 20:02
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Константин Л., Вы писали:


КЛ>>PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю


К>Ты есть замкнутая система, которая не разумеет чужих мыслей?


с каких это пор (разумеет мысли) == (разделяет мнение)?
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 08.05.07 20:04
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:


D>>>
D>>>map унарная_функция список
D>>>


D>>>
D>>>fold бинарная_функция инициализатор список
D>>>

D>>>Где тут спагетти?

КЛ>>а где тут функции высшего порядка? это fold что-ли, который принимает функцию?


D>Конечно. Это, собственно, и есть канонические ФВП.


ладно, я имелл ввиду, что мог привести пример понавороченее.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 08.05.07 20:08
Оценка:
Здравствуйте, konsoletyper, Вы писали:


K>... Есть и несколько другой подход — система типов Хаскеля. Она гораздо мощнее, чем в том же .NET. Единственный минус — если в ОО можно делать "методы-омонимы", т.е. методы у совершенно несвязанных классов, обладающие различной функциональностью, но имеющие одинаковые названия, то в Хаскеле такого провернуть не удастся, потому приходится придумывать кучу префиксов для методов. Но и эта проблема разрешима, т.к. при правильном проектировании такие вещи сводятся к минимуму.


Она решена с помощью квалифицированных имён: [Имя_модуля].[конфликтное_имя].
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 08.05.07 20:24
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Ладно, мой поинт в том, что оо+фя гораздо привлекательнее и "живучее" чем чистые фя.


Ну и что же ты считаешь "чистым" ФЯ?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 08.05.07 20:24
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>здесь сказали такую глупость и я с ней согласен
Автор: VladD2
Дата: 23.04.07


Да, я тоже согласен. Вот только вопрос: если ФП никак не мешает использовать ООП, то зачем ругать ФП?

КЛ>чувствуешь разницу м/у лямбдами и спагетти из лямбд? Ну ладно, тут почти можно отступить.


Ну так если руки кривые, то спагетти можно нагородить на ровном месте любыми средствами.

КЛ>>>4. трудная для понимания программа. см. пункт 3.


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


КЛ>Проблема — структурированность. Сам писал на clisp, поэтому есть представление.


И что же, по твоему clisp — чисто функциональный?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.05.07 20:39
Оценка:
Здравствуйте, Константин Л., Вы писали:

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


К>>Здравствуйте, Константин Л., Вы писали:


КЛ>>>PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю


К>>Ты есть замкнутая система, которая не разумеет чужих мыслей?


КЛ>с каких это пор (разумеет мысли) == (разделяет мнение)?


откуда ты взял "разделяет мнение"?
Каждый имеет право на свою точку зрения и форум есть средство для обменя этими самыми точками зрения.
Не надо загодя собеседника принимать обязательно за противника
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.05.07 23:14
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.


Отсуствие оных средств не мешает, тем не менее писать чистый и ясный код. Многие алгоритмы записанные в функциональном стиле читаются намного лучше. А качетсво кода завист в первую очередь от программиста. Дурак и на С++ и на Хаскеле макаронный код написать сможет.

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

КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси


Спагети как раз обычно без лямбд получаются. Лямбды средство борьбы с морем грязи в коде. Правда опять таки только в хороших руках.

КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?


... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.05.07 12:52
Оценка:
Здравствуйте, Курилка, Вы писали:

Будь добр, цитируй только то что нужно для понимания твоей мысли.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 10.05.07 07:18
Оценка:
Здравствуйте, Трурль, Вы писали:

Да, чистая лямбда — это, конечно, то ещё спагетти. Но, в отличие от goto, немножко лямбды кода не испортит.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 10.05.07 12:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


D>>Да, чистая лямбда — это, конечно, то ещё спагетти. Но, в отличие от goto, немножко лямбды кода не испортит.

WH>Тут как посмотреть... правильно поставленные goto тоже код не портят...

Лямбда, в отличие от goto, локальна. Поэтому всякое goto — макаронина отсюда куда-то. А лямбда "макаронизируется" только если вкладываем одну лямбду в другую, в третью, etc, что бывает, когда мы пишем код на чистой лямбде (то есть вообще без именованных функций). Ну или когда мы поставили перед собой задачу обфускации
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 14:06
Оценка:
Здравствуйте, Mamut, Вы писали:

КЛ>>>один хрен лоб до затылка расшибет.


M>Я долго медитировал над этой фразой


M>Что он куда расшибет?


Э-э... Лоб расшибет, грю! До затылка, т.е. очень глубоко расшибет, очень сильно. "Один хрен" <=> "все равно".
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 10.05.07 14:10
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Ты почти прав. Только ты упустил главное из ООП-шного инструментария. Что такое "объект"?
G>Объект = АДТ (абстрактный тип данных) + состояние
G>АДТ = тип данных, определяющийся набором операций над ним. С этим у ФЯ все в порядке.

G>Объект же не просто АДТ — он имеет состояние и "идентити" — т.е. в системе могут существовать два одинаковых по состоянию объекта с разным идентити. В ОО языках роль "идентити" играет указатель. Идентити — непременный атрибут изменяемого состояния и ООП.


Мне кажется, ты тоже упускаешь из виду, что а) многие ОО-паттерны (типа Стратегии) сичтаются архи-важными и архинужными и при этом не используют состояния б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 10.05.07 14:14
Оценка:
Здравствуйте, Mamut, Вы писали:

КЛ>>Однако что может быть хуже для читабельности, чем "функций высшего порядка"?


M>
M>arr = [1, 2, 3, 4];

M>for(i = 0; i < arr.length; i++)
M>{
M>    some_func(arr[i]);
M>}
M>


M>versus


M>
M>arr = [1, 2, 3, 4];

M>map(arr, some_func);
M>


M>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )


угу.

А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 10.05.07 14:19
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил

Во-первых, таки да, map возвращает функцию (т.к. у map 2 аргумента, см. карринг). Во-вторых, функция высшего порядка может не только возвращать функции, но и принимать их как аргументы. Какой у map первый аргумент?
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 10.05.07 14:35
Оценка:
Здравствуйте, Константин Л., Вы писали:


КЛ>А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил


"Нелажевый" я привёл в посте выше
Автор: deniok
Дата: 09.05.07
. Наслаждайся
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 10.05.07 14:38
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Константин Л., Вы писали:



КЛ>>А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил


D>"Нелажевый" я привёл в посте выше
Автор: deniok
Дата: 09.05.07
. Наслаждайся


не получилось
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 10.05.07 14:43
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>1. какую функцию возвращает map?

КЛ>2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию
addOneToAllItems = map (+1)
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 10.05.07 14:46
Оценка:
КЛ>А разве map возвращает фукнцию?

Мне достаточно уже того, что оно принимает функцию в качестве параметра

КЛ>Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил


А про какие? Такие http://rsdn.ru/Forum/Message.aspx?mid=2458010&amp;only=1
Автор: Mamut
Дата: 23.04.07
?


dmitriid.comGitHubLinkedIn
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: Quintanar Россия  
Дата: 10.05.07 14:49
Оценка:
Здравствуйте, Константин Л., Вы писали:

Л>1. какую функцию возвращает map?

КЛ>2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию
КЛ>3. Я уже в курсе, что такое фвп и этот пример был для меня понятен

let memorize f =
  let hash = hash.create ....
  \arg ->
    try hash arg
    with hash_fail -> hash.add f arg; hash arg;

let process_data file = .....

let process_data_m = memorize process_data;


Is it clear?
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 10.05.07 15:00
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Константин Л., Вы писали:


Л>>1. какую функцию возвращает map?

КЛ>>2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию
КЛ>>3. Я уже в курсе, что такое фвп и этот пример был для меня понятен

Q>
Q>let memorize f =
Q>  let hash = hash.create ....
Q>  \arg ->
Q>    try hash arg
Q>    with hash_fail -> hash.add f arg; hash arg;

Q>let process_data file = .....

Q>let process_data_m = memorize process_data; 
Q>


Q>Is it clear?


no, it is not completely clear for me, but i've caught basic idea
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Константин Л. Франция  
Дата: 10.05.07 15:01
Оценка:
Здравствуйте, Mamut, Вы писали:

КЛ>>А разве map возвращает фукнцию?


M>Мне достаточно уже того, что оно принимает функцию в качестве параметра


КЛ>>Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил


M>А про какие? Такие http://rsdn.ru/Forum/Message.aspx?mid=2458010&amp;only=1
Автор: Mamut
Дата: 23.04.07
?


хотя-бы
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 10.05.07 15:44
Оценка:
Здравствуйте, palm mute, Вы писали:

PM> в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.


Хм... А зачем вообще писать императивный код на Хаскеле? Не прощели сделать интероп с теми языками, где императивность — родная парадигма?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 10.05.07 15:52
Оценка:
Здравствуйте, konsoletyper, Вы писали:

PM>> в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

K>Хм... А зачем вообще писать императивный код на Хаскеле? Не прощели сделать интероп с теми языками, где императивность — родная парадигма?
Во-первых, я говорил о принципиальной возможности. Т.е., как и говорил, все для реализации ООП, включая identity и изменяемое состояние, в Хаскеле есть.
Во-вторых, весь ввод-вывод через интероп и сделан. Фокус в том, что у foreign-вызовов такой тип, что императивный по сути код формально остается чисто функциональным.
Re[11]: Надо посты перечитывать перед отправкой, блин
От: palm mute  
Дата: 10.05.07 16:09
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Т.е., как и говорил deniok, все для реализации ООП,...
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.05.07 16:53
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )


Жаль, правда, что код не идентичный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
От: Gajdalager Украина  
Дата: 10.05.07 17:07
Оценка:
Здравствуйте, VladD2, Вы писали:

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


M>>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )


VD>Жаль, правда, что код не идентичный.

Почему?
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Blind Guardian — And The Story Ends
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 17:09
Оценка:
Здравствуйте, palm mute, Вы писали:

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

G>>Ты почти прав. Только ты упустил главное из ООП-шного инструментария. Что такое "объект"?
G>>Объект = АДТ (абстрактный тип данных) + состояние
G>>АДТ = тип данных, определяющийся набором операций над ним. С этим у ФЯ все в порядке.

G>>Объект же не просто АДТ — он имеет состояние и "идентити" — т.е. в системе могут существовать два одинаковых по состоянию объекта с разным идентити. В ОО языках роль "идентити" играет указатель. Идентити — непременный атрибут изменяемого состояния и ООП.


PM>Мне кажется, ты тоже упускаешь из виду, что а) многие ОО-паттерны (типа Стратегии) сичтаются архи-важными и архинужными и при этом не используют состояния


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

б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 10.05.07 17:14
Оценка:
Здравствуйте, palm mute, Вы писали:

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


PM>>> в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

K>>Хм... А зачем вообще писать императивный код на Хаскеле? Не прощели сделать интероп с теми языками, где императивность — родная парадигма?
PM>Во-первых, я говорил о принципиальной возможности. Т.е., как и говорил, все для реализации ООП, включая identity и изменяемое состояние, в Хаскеле есть.

Ты до сих пор не показал, как ты сделаешь из всего этого объект. А ты попробуй. Многие до тебя говорили, что мол ерунда, но ни у кого это сделать не получалось.

Это я так вежливо формулирую свою мысль, которая состоит в том, что ты в корне неправ, и это сделать невозможно. Объяснения я уже привел выше. Предлагаю возразить мне примером.

PM>Во-вторых, весь ввод-вывод через интероп и сделан. Фокус в том, что у foreign-вызовов такой тип, что императивный по сути код формально остается чисто функциональным.


Одно дело ввод-вывод, и совсем другое — объектная декомпозиция (не паттерны, а именно декомпозиция — подход к моделированию состояния сложной системы). Сие есть радикально разные вещи, имеющие мало общего.
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 10.05.07 18:22
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>не получилось


Ну вот тебе ещё (сегодня родилось по ходу болтовни в ЖЖ)

-- универсальный "поднимальщик" бинарных операторов на point-free уровень
upBinop :: (a -> b -> c) -> (d -> a) -> (d -> b) -> (d -> c)
upBinop binop p q x = binop (p x) (q x)

-- поднимаем логические операторы
(&&&) :: (a -> Bool) -> (a -> Bool) -> (a -> Bool)
(&&&) = upBinop (&&)

(|||) = upBinop (||)

-- пользуемся поднятыми операторами для point-free конструирования предикатов
isAlphaSpace = isAlpha ||| isSpace
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.05.07 22:40
Оценка:
Здравствуйте, Gajdalager, Вы писали:

VD>>Жаль, правда, что код не идентичный.

G>Почему?

Мог бы и сам догадаться

Потому, что мап преобразует один список в другой, а не прсото вызвает функцию для каждого элемента спска. На то он и map — отображение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: Трурль  
Дата: 11.05.07 05:29
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Оно?

Наглое жульничество . Вот напиши ка определение writeIORef на хаскеле.
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 11.05.07 07:36
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, palm mute, Вы писали:


PM>>Оно?

Т>Наглое жульничество . Вот напиши ка определение writeIORef на хаскеле.

writeIORef  :: IORef a -> a -> IO ()
writeIORef (IORef var) v = stToIO (writeSTRef var v)


Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: Mamut Швеция http://dmitriid.com
Дата: 11.05.07 08:27
Оценка:
VD>Мог бы и сам догадаться

VD>Потому, что мап преобразует один список в другой, а не прсото вызвает функцию для каждого элемента спска. На то он и map — отображение.


Ну, в JavaScript'е (который там приведен) это одно и то же

Обычно в JS map реализуется так:
function map(arr, fn)
{
    for(i = 0; i < arr.length; i++)
    {
        fn(arr[i]);
    }
}


Чтобы голову не заморачивать


dmitriid.comGitHubLinkedIn
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 11.05.07 08:27
Оценка:
Здравствуйте, palm mute, Вы писали:

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


G>>б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.

G>>Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.

PM>Оно? Или ты что-то более сложное имел в виду? Прошу обратить внимание на 'deriving Eq' и 'obj `elem` visited' — это обещанная Identity. Полиморфизму сверху добавить тоже можно.

PM>з.ы. Я не говорю, что так нужно делать, но можно — факт

Дружище, спасибо. Посмотрел. Три вопроса.

1) Ромбик мне из объектов не изобразите? Чтобы два иорефа в структуре данных на один объект указывали. Зело хоцца на идентити в действии поглядеть.
2) Потому как идентити я у вас таки не нашел. То что вы говорите про идентити — это не похоже на идентити. Поэтому...
3) ...Будьте любезны, выпишите сингнатуры всех функций и структур данных. Это поможет в поисках идентити, а то я не умею в уме монадные типы выводить.
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 11.05.07 08:53
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>1) Ромбик мне из объектов не изобразите? Чтобы два иорефа в структуре данных на один объект указывали. Зело хоцца на идентити в действии поглядеть.

Да хоть 10.
import Data.IORef
import Control.Monad

type IntPointer = IORef Int

createPtr :: Int -> IO IntPointer
createPtr = newIORef

deref :: IntPointer -> IO Int
deref = readIORef

assign :: IntPointer -> Int -> IO ()
assign = writeIORef

derefList :: [IntPointer] -> IO [Int]
derefList = mapM deref

printPtrs :: [IntPointer] -> IO ()
printPtrs ptrs = derefList ptrs >>= print

main = do
  ptr <- createPtr 1
  let ptrs = replicate 10 ptr
  printPtrs ptrs -- prints [1,1,1,1,1,1,1,1,1,1]
  assign ptr 2
  printPtrs ptrs -- prints [2,2,2,2,2,2,2,2,2,2]
  assign ptr 3
  printPtrs ptrs -- prints [3,3,3,3,3,3,3,3,3,3]

IORef — это обычный указатель, writeIORef — это обычное деструктивное присваивание, readIORef — самое обычное разыменование указателя, один-в-один как на С++. Все, что можно делать с указателями, можно делать с IORef'ами. Но естественно, что это безобразие за пределы IO не выпускают. А над STRef можно, например, грязно императивно надругаться, а потом заморозить, превратить в нормальное неизменяемое значение (хотя это скорее для оптимизации узких мест подойдет, объектную декомпозицию так не сделать, если объекты должны жить на протяжении всей работы программы).

G>2) Потому как идентити я у вас таки не нашел. То что вы говорите про идентити — это не похоже на идентити. Поэтому...

Объясните, как вы понимаете идентити.
G>3) ...Будьте любезны, выпишите сингнатуры всех функций и структур данных. Это поможет в поисках идентити, а то я не умею в уме монадные типы выводить.
Примера выше достаточно, я думаю.
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: Gaperton http://gaperton.livejournal.com
Дата: 11.05.07 09:44
Оценка:
Здравствуйте, palm mute, Вы писали:

G>>2) Потому как идентити я у вас таки не нашел. То что вы говорите про идентити — это не похоже на идентити. Поэтому...

PM>Объясните, как вы понимаете идентити.

Идентити — это, в принципе и есть обычный указатель в гражданских языках. Это некий уникальный ID, обозначающий экземпляр класса — объект. Идентити можно сравнивать отдельно от объектов, идентити применяется для ссылок на объекты, по идентити можно получить сам объект, и изменить его состояние.

Пример экзотического идентити, не являющегося указателем — в Эрланге роль идентити выполняет идентификатор процесса. Объекты же симулируются бесконечно рекурсивными процессами, которые хранят на стеке состояние (передавая его параметром в бесконечной рекурсии), и, зная идентити (PID) друг друга, посылают друг другу сообщения. Это объектная система — в точности такая же модель была в Smalltalk 72.

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

G>>3) ...Будьте любезны, выпишите сингнатуры всех функций и структур данных. Это поможет в поисках идентити, а то я не умею в уме монадные типы выводить.

PM>Примера выше достаточно, я думаю.

В принципе, да. Спасибо, посмотрю.
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: Трурль  
Дата: 11.05.07 12:13
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Трурль, Вы писали:


PM>Следующей просьбой будет, полагаю, реализовать stToIO и writeSTRef.

Однако, шаман русский.
PM>Но ты же не будешь утверждать, что C++, например, не подерживает присваивания на том основании, что нельзя реализовать на C++ оператор присваивания для встроенных типов.
Не буду. А если бы стал, то меня ткнули бы носом в п. 5.17.
Re[14]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 11.05.07 12:22
Оценка:
Здравствуйте, Трурль, Вы писали:

PM>>Следующей просьбой будет, полагаю, реализовать stToIO и writeSTRef.

Т>Однако, шаман русский.
Даруйте, пане, я щирий українець.

PM>>Но ты же не будешь утверждать, что C++, например, не подерживает присваивания на том основании, что нельзя реализовать на C++ оператор присваивания для встроенных типов.

Т>Не буду. А если бы стал, то меня ткнули бы носом в п. 5.17.
Ничего опровергающего мои слова я там не нашел. Или это было согласие?
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.05.07 12:48
Оценка:
Здравствуйте, palm mute, Вы писали:

VD>>А тут девочке еще советовали тему для лабы "Метапрограммирование на шаблонах С++ как средсво шифрования кода". С++ морально устраел для этих целй. ООП на Хаскеле явно его победит.


PM>Я вот по-португальски тоже ничего не понимаю. Странный язык, непонятный. Как на нем люди разговаривают, да еще и песни пишут, загадка.


Ды, ты, как я погляжу, много чего не понимаешь. Вот смысл моего сообщения не понял. На замечание о ужасности и громоздкости кода начинашь о знаниях языка рассуждать. Так что не расстраивайся. Нельзя же понимать все?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.05.07 16:21
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ну, в JavaScript'е (который там приведен) это одно и то же


M>Обычно в JS map реализуется так:

M>
M>function map(arr, fn)
M>{
M>    for(i = 0; i < arr.length; i++)
M>    {
M>        fn(arr[i]);
M>    }
M>}
M>


M> Чтобы голову не заморачивать


map должен возвращать другой массив/список, а не менять имеющися. А проблемы ява-скрипов пусть так и остаются их проблемами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.07 14:34
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Будем считать особенностями реализации В С++ вон map — это вообще тип данных, и ничего


Там мы сравниваем разные вещи имеющие одинаковые названия, или все же в нас еще осталась чистичка разума?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Так в чем же принципиальные отличия ФП от ИП?
От: geniepro http://geniepro.livejournal.com/
Дата: 12.05.07 17:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD2> На замечание о ужасности и громоздкости кода начинашь о знаниях языка рассуждать.


ООП для Хаскелла инороден, а потому и ООП-код на нём выглядит громоздко...
С другой стороны, на С++ такой же код выглядел бы наверняка ещё более громоздко и ужастно...
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: palm mute  
Дата: 12.05.07 20:05
Оценка:
Здравствуйте, geniepro, Вы писали:

G>ООП для Хаскелла инороден, а потому и ООП-код на нём выглядит громоздко...

+10
G>С другой стороны, на С++ такой же код выглядел бы наверняка ещё более громоздко и ужастно...
Да ну, кольцевой список и модификация состояния там как раз получаются абсолютно естественно, т.к. вместо IORef (Maybe MyObject) будет просто my_object*, вместо writeIORef будет '=', вместо readIORef будет просто обращение к переменной, тут С++ на своем поле и состязаться с ним трудно. У С++ другие проблемы.
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.07 22:58
Оценка:
Здравствуйте, geniepro, Вы писали:

G>ООП для Хаскелла инороден, а потому и ООП-код на нём выглядит громоздко...


+1 Но что с того?

G>С другой стороны, на С++ такой же код выглядел бы наверняка ещё более громоздко и ужастно...


Возможно. Хотя вряд ли. Но один плохой пример не оправдывает другой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
От: Tonal- Россия www.promsoft.ru
Дата: 13.05.07 17:55
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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


M>>>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )


VD>>Жаль, правда, что код не идентичный.


G>А мы его немного не то чтобы изменим, а слегка дополним...

Ну, если уж по честному дополнять, то это будет примерно так:
G>
G>inline template<class F, class A,  template<class> Cont >
G>Cont<typename F::RetType> map(const Cont<A> &arr, F some_func) {
    Cont<typename F::RetType> res;
G>  for(i = 0; i < arr.length; i++)
G>    res.push_back(some_func(arr[i]));
G>  return res;
G>}

G>versus //?!

G>arr = [1, 2, 3, 4];

G>map(arr, some_func);
G>


Соответственно, накладываються ограничения на тип контейнера и на тип возврата функции.
Можно, вместо явной передачи контейнера перейти на итераторы — тогда придём к std::transform или std::for_each в зависимости от того нужен нам результат или нет.
Т.е.
ArrType arr[] = {1, 2, 3, 4};
std::for_each(arr, arr + lengthOf(arr), some_func)
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.05.07 01:06
Оценка:
Здравствуйте, Tonal-, Вы писали:

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

T>Можно, вместо явной передачи контейнера перейти на итераторы — тогда придём к std::transform или std::for_each в зависимости от того нужен нам результат или нет.

Вот transform и есть map, только как и многое в С++ громоздкий и неудобный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
От: Tonal- Россия www.promsoft.ru
Дата: 14.05.07 04:26
Оценка:
Здравствуйте, VladD2, Вы писали:
T>>Можно, вместо явной передачи контейнера перейти на итераторы — тогда придём к std::transform или std::for_each в зависимости от того нужен нам результат или нет.

VD>Вот transform и есть map

Если нам результат map-а не нужен, то std::for_each вполне канает.
Хотя в чистом ФП мап без результата похоже не часто встречается.

VD>, только как и многое в С++ громоздкий и неудобный.

Стоит упомянуть С++ или Python и "Остапа понесло"
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
От: deniok Россия  
Дата: 14.05.07 04:41
Оценка:
Здравствуйте, Tonal-, Вы писали:

VD>>Вот transform и есть map

T>Если нам результат map-а не нужен, то std::for_each вполне канает.
T>Хотя в чистом ФП мап без результата похоже не часто встречается.

В чистом ФП функции без возвращаемого значения вообще не бывает
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.