ФП против ООП - Декларативное программирование

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

L>Оверхед получается из-за того, что о действиях думают как об объектах.

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

L> Отсюда все эти генераторы, треды, различные менеджеры чего-то там.

Генераторы это что? Метапрограммирование? Дык оно совсем от другого. Это автоматизация кодирования вещей которые можно сделать по контексту. Это и в любом ФЯ лишним не будет.

Кто такие "треды" я вообще не знаю.

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

В общем, не вижу ничего рационального в этих рассуждениях.

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

L>Не согласен. Паттерн матчинг и АТД — не сахар — это подход, другой способ взглянуть на вещи.

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

Я уже писал здесь Синтаксический сахар или C++ vs. Nemerle :), что сахар понятие относительное и что зачастую то что является сахаром в одно языке является основной кострукцией в другом, и что эти конструкции могут выражаться друг через друга.

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

Просто пример. Казалось бы конструкция match в Немерле более выразительна и мощьна, но ее всегда можно выразить тем или иным количеством if-ов. И иногда она оказвается более громоздкой. Так если нам нужно всего лишь выполнить действие если некое условие верно, то конструкция when или if окажется более выразительной:

when (isOK)
    DoSomething();

sv.

match (isOK)
{
    | true => DoSomething();
    | _    => () // Do nothing
}

Но в более сложных случаях уже бесспорное лидерство match-а.

Это четкое доказательство того, что "сахар" понятие отностиельное.

L> А уж ФВП сахаром назвать язык не повернётся.

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

C# 2.0 и выше, Немерле и многие другие реализуют замыкания захватывающие контекст метода как классы. И ничто не мешает создать подобный код в языке не поддреживающих замыканий.

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

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

L> А ведь они, может быть, самая важная вещь для обсуждаемого вопроса.

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

L>Воспрос не о императивный vs функциональный, а об объектно-ориентированный vs функциональный и о том, насколько больше приходится держать в голове в случае ОО.

Да без разницы. ООП это тоже сахар. Я писал ОО-программы на С в 1993-ем году. Да было менее удобно чем на С++, но жить было можно. Когда появился сахар в виде классов, виртуальных методов и т.п. я с удовольствием им воспользовался.

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

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

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

L>Не понял, почему?

Что тут не понятного? ФЯ по Гапертону (и тебе, в общем-то) это запрет на модификацию переменных. А это деградация функциональности и больше ничто. Этот запрет не даст никаких приемущество с точки зрения реализации алгоритмов. Никакие паттерн-матчинги от этого не зависят. Никакие функции высшего порядка тоже. Это просто запрет ради запрета. Он яко бы должен привести к гипотетическому упрощению программирования. Но по жизни, как говорится рулят, ковровые бомбордировки и танковые клинья и еще этот, как его? А, гриб Сарумяна. То есть рулят отладчики, IDE, визуальные дизайнеры и т.п.

Если же кому-то хочется полной immutability, то это можно организовать просто добавление некоторого атрибута.

L>Отсутствие сайд-эффекта + функции высшего порядка, по моему, гораздо важнее.

Чем что? Чем они лучше чем "функции высшего порядка" + возможность по желанию сделать "сайд-эффект"?

Вот наличие такой возможности дает возможность более гибкого дизайна. А отсуствие дает только ощущение причястности к религии.

L> Без них код на ФЯ не будет таким выразительным и лаконичным.

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

И вообще как выразительность может зависить от отсуствия некой возможности? Это же нонсенс!

L>Ну так, а в ФП для этого даже не надо выполнять эти правила! Из-за этих правил опять таки в мыслях оверхед.

В ФП из-за этого порой приходится долго трахаться и использовать совершенно не эффективные и/или многословные решения.

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

VD>>Меж тем модификация переменных иногда может быть очень полезна даже если используется весь перечисленный выше сахар. Ни один из приведенных аспектов не противоречит императивному программированию. Не мудренно что из ФЯ в таких условиях пытаются сделать религию.

L>Я сейчас не об императивном говорил,

Да, ну? А как называется модификация переменных? ООП?

L> а об объектно-ориентированном.

И какое отношение к нему имеет немодифицируемость переменных? ООП возможен и в этих условяих. Это неразумно и неудобно, но возможно.

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

Важно убрать религию из областей IT. Вот когда люди будут использовать логику и научные методы для изучения предметов, то не будет и религии. А пока что ФЯ — это религия которая рассказывая все вокруг о своей крутости использует совершенно некорректные методы. Результат маргинальный мир полусумашедших ученых работающих над языками котрые использует немногочисленная групка фанатов и они сами.

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

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

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

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

L>>Первое был вариант с замыканиями, а не вариант с сахаром. От того, что их можно сэмулировать они не становятся сахаром. Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?

FR>Не я проникся они правы, ну сам посмотри:
FR>

FR>_camlTst_01__f_57:
FR>L100:
FR>    lea    eax, DWORD PTR [ebx+eax-1]
FR>    ret
FR>    .CODE
FR>    ALIGN    4
FR>    PUBLIC    _camlTst_01__entry
FR>_camlTst_01__entry:
FR>L101:
FR>    mov    eax, OFFSET _camlTst_01__1
FR>    mov    DWORD PTR _camlTst_01, eax
FR>    mov    eax, 1159
FR>    call    _camlPervasives__string_of_int_153
FR>L102:
FR>    mov    ebx, eax
FR>    mov    eax, DWORD PTR _camlPervasives+92
FR>    call    _camlPervasives__output_string_214
FR>L103:
FR>    mov    eax, 1
FR>    ret
FR>

FR>тут же все кристально ясно, сразу видно и фвп и замыкание, все это чистый сахар

Угу, а сахар у нас, как известно, круче всего добавлять макросами, и только макросами.

Так что макроассемблер должен порвать всех — а Немерле отстой. Это всего лишь сахар.

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

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

http://pobox.com/~oleg/ftp/Scheme/pure-oo-system.scm

;     Purely-functional Object-Oriented System in Scheme
;
; The present code implements a classless, delegation-based OO system, similar
; to those of Self or Javascript. This is a full-fledged OO system with
; encapsulation, object identity, inheritance and polymorphism. It is also
; a purely functional system: there is not a single assignment or
; other mutation in the code below.
;
; A closure (encapsulating a message map, and private parameters if any)
; is the object in this system. Sending a message to an object -- i.e.,
; applying the object to a message selector and arguments, -- results
; in a list. Its head is the object in a new state, having processed the
; message; the rest of the list are the results of the message if any.
; Objects' identity is decided by an eq? predicate applied to the result of
; an 'identity' message. A "set-x" method returns an object with a new state,
; but with the same identity as the source object. An object in a changed
; state is in a sense a "child" of the original object. No wonder
; implementations of "mutation" and inheritance are so similar in this
; OO system.
;
; This code was meant to be "light"; therefore it deliberately uses only the
; most basic Scheme constructions. No macros/syntactic closures are employed
; (although they are certainly possible and appropriate).
;
; This code has been discussed in an article "Re: FP, OO and relations. Does
; anyone trump the others?"
; posted on comp.lang.smalltalk, comp.lang.functional, and comp.lang.scheme
; on Wed Dec 29 05:13:58 1999 GMT, Message-ID: <84c4qe$48j$1@nnrp1.deja.com>
; See also http://pobox.com/~oleg/ftp/Scheme/oop-in-fp.txt
; The article presents a more familiar OO system with mutations, and contrasts
; it with a purely-functional OO system, which is implemented in this present
; file.
...
...

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

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

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

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

За счёт чего создаётся оверхед в ООП? За счёт того, что "о действиях думают как об объектах".

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

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

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

Распараллеливание и прочие вещи, ПРОСТО получающиеся автоматически, берутся не спроста. Это связано с большой ясностью что происходит при отсутсвии сайд-эффектов. Большой ясностью не только для машины, но и для человека. Но ты так не считаешь. В этом, насколько я понимаю, и есть разница в нашем отношении к оспариваемому тезису "ООП vs ФП". Всё остальное — в частности твои разговоры о паттерн матчинге, о том, что всё в этом мире есть сахар, о том, что функциональный стиль может быть в любом языке, а в императивном можно вот так, и твоё постоянное смешивание понятий "функионального программирования" и "функциональных языков" — отношения к разговору не имеют, потому что не доказывают и не опровергают этот тезис.

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

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

FR>>>Тут Re[5]: ФП против ООП Влад уже привел пример когда у объекта нет изменяемого состояния.

G>>Чего тут не понятного. Это не объект. На таких "объектах" ты не сделаешь объектную декомпозицию, у тебя ссылки поплывут сразу. Попробуй посмотреть, что произойдет с кольцевыми ссылками при попытке "изменить" состояние такого объекта — у него нет identity.

G>>Господи, объясните ему кто-нибудь.

FR>Лучше дай правильное по твоему определение объекта.

С этого стоило начать. Есть классическое определение объекта от Кея, которое неоднократно приводилось в философии.

Сводится в результате оно к следующему.

1) Объект имеет состояние. При этом неявно подразумевается, что оно вообще говоря mutable, т.е. изменяемое.
2) Объект имеет identity — если identity совпадает, то это один и тот же объект. Объекты с разным identity могут быть одинаковы, это делу не мешает. == у объекта возможны модифицирующие операции, наличие identity с этим тесно связанно, как и с предыдущим пунктом.
3) Объект сам решает, как обработать "сообщение" == к состоянию объекта нет прямого доступа, оно спрятано == класс объектов определяется не структурой состояния, а набором операций над ним == Abstract Data Type. Смоллтокер тут придерется насчет знаков равенства, по понятной причине

но в нашем случае не так принципиально.

Пункт 3 — ADT (Абстрактный Тип Данных, определяющийся набором операций), вообще говоря не подразумевает соблюдения пунктов 1 и 2, и встречается поодиночке. Например, в Хаскеле. Или в Эрланге — т.н. "абстрактный модуль."

То, что вы приводите в качестве объекта, безусловно является ADT, но лишен (изменяемого) состояния. Т.е. вместо изменения вы должны возвращять его измененную копию, таким образом, все его определение состоит из чистых функций. Фундаментальное отличие экземпляра ADT от объекта состоит в отсутствии identity и инкапсулированного состояния. ADT без состояний невозможно использовать для декомпозиции и моделирования сложной системы, так, как это принято в ООП. ADT не "моделирует реальный мир", как это делают объекты (каждый прячет в себе часть состояния, которое меняется во времени). Для декомпозиции аналогичной объектной в случае применений чистых функций придется использовать технику потоков. Это все достаточно подробно описано в SICP, кстати, который вы мне цитируете.

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

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

FR>>>Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код:
G>>ЛЕКСИЧЕСКИЕ замыкания. Динамические — это НЕ ФП. Мы тут статью обсуждаем, или языками чешем? Нет в Эрланге диамических замыканий.

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

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

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

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

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

L>А где во втором случае ФВП?
Да пожалуйста

    foo () : void
    {
        def i = 234;
        def combine(fn)
        {
            fn(_, i);
        }
        def addI = combine(_ + _);
        def x = addI(123);
    }

private sealed class _N__N_l1193_1471 : Function<int, int>
{
    // Methods
    public _N__N_l1193_1471(Test._N_closure1463 _N_combine_clo1475, Test._N_closure1437 _N_foo_clo1477)
    {
        this._N_combine_clo1475 = _N_combine_clo1475;
        this._N_foo_clo1477 = _N_foo_clo1477;
    }

    public override int apply(int _N_1470)
    {
        return this._N_combine_clo1475._N_fn1468.apply(_N_1470, this._N_foo_clo1477._N_i1442);
    }
    
    // Fields
    private Test._N_closure1463 _N_combine_clo1475;
    private Test._N_closure1437 _N_foo_clo1477;
}

private sealed class _N__N_l1200_1484 : Function<int, int, int>
{
    public override int apply(int _N_1482, int _N_1483)
    {
        return (_N_1482 + _N_1483);
    }
}
private sealed class _N_closure1437
{
    internal int _N_i1442;
}

private sealed class _N_closure1463
{
    internal Function<int, int, int> _N_fn1468;
}
 
private static Function<int, int> _N_combine1445(Test._N_closure1437 _N_foo_cp1444, Function<int, int, int> fn)
{
    Test._N_closure1463 _closure1 = new Test._N_closure1463();
    _closure1._N_fn1468 = fn;
    return new Test._N__N_l1193_1471(_closure1, _N_foo_cp1444);
}
private static void foo()
{
    Test._N_closure1437 _closure1 = new Test._N_closure1437();
    _closure1._N_i1442 = 0xea;
    Function<int, int, int> function1 = new Test._N__N_l1200_1484();
    Test._N_combine1445(_closure1, function1).apply(0x7b);
}

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

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

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

VD>>>>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?

FR>>>А у тебя?

VD>>Месье блюдет национальные традиции или отвечая вопросом на вопрос он пытается уйти от ответа?

FR>Нет, к сожалению не являюсь представителем этой многоуважаемой нации

FR>Кстати задавая этот вопрос ты занимался именно уходом от ответа

FR>Вообще пора закруглятся.

Давно пора. А то весь форум ерундой какой-то загадили — за флудом полезные сообщения найти невозможно. Разборки с Владом переносим в философию, ок? А если честно — я вообще не понимаю, зачем и с какой целью вы отвечаете на всякую ерунду. Что-то новое для себя узнать хотите? Или интересно очень?

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

К>Ключевой момент проскакивал недавно в твоём обсуждении Немерле с Владом, где он тебе показывал, что mutable это не есть гуд с точки зрения масштабируемости, зависимостей и т.д.
К>В ФП если ты знаешь функцию и параметры, то результат функции (если она не имеет побочных действий) будет одним и тем же и в 1-й и в 1000-й вызов её. Методы же в ООП оперируют над объектами, которые содержат их состояния, поэтому для одного и того же результата тебе необходимо чтобы состояния ВСЕХ объектов, участвующих в методе было точно таким же.

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

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

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

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

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

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

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

G>>Не понятно, как такое может работать. Ну допустим, у них глобальные map-ы из identity в объект, через этот identity и идут ссылки. Ну допустим, они протаскивают этот контейнер через все вызовы параметром (кошмар неюзабельный).

Z>Конечно кошмар, и чтобы от него избавится все давно используют монады

Z>Смотрите "State monad" и "O'Haskell" заодно. Монады на Scheme у Олега тоже есть — посмотрите там на сайте.

Монады — это кошмарный кошмар.

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

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

G>>Вот тебе простейший пример — электронная таблица, рекурсивно вычисляющая формулы, и использующая член класса для отметки, что "мы это уже считали" — выявление кольцевых ссылок. Хотя бы это у них сработает? А там можно и более сложные примеры найти. Давай разберемся.

Z>Давайте остановимся на кольцевых ссылках — вот чисто функциональный предикат 'cycle-list?'
Z>Работает он так, давайте запистим по списку двух "пешеходов" — медленного и быстрого. Если они встретятся — список кольцевой — если кто-то дошел до конца — нет. Их состояние мы храним в двух аргументах внутренней функции 'helper':

Круто.

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

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

>> Это просто категорийская ересь. Все прекрасно выражается и без всяких монад.
PA>Я что-то, видимо, пропустил. Если монады — это ересь, то какая религия
PA>нынче самая правильная?

Бритва Оккама.

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

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

VD>>>Так что я наставиваю, что краткось и выразительность кода зависит от сладкости языка программирования от уменя программистов и архитекторов применять этот сахар для решения конкретных задач.

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

) чем на большинстве засахаренных в твоем смысле ОО языков?

VD>Элементарно, Ватсон!

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

Угу только практически весь майнстрим недосахарен в твоем смысле.

VD>Причем сахара может хватать для одной задачи и не хватать для другой. Например, компиляторы получаются самыми короткими на ОКамле и дургих МЛ-клонах (в том числе, гы-гы, и на Немерле).

На рефале и прологе компиляторы получаются не хуже.

VD>2. Многое зависит от того кто пишет. И от того как пишет. Если человек пишет на С++ и пытается выжать максимум скорости, то ежику понятно, что код будет далек от оптимальности с точки зрения компактности. Или если человек вообще не знает даже паттернов ООП, и не особо понимает что значит повторно исползуемый код, то не мудренно что его код пухнет. Меж тем на Лиспах и Фортах в основно пишут посвященные. И сам процесс посвящения отсеивает тех кто не способен писать кратко.

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

VD>3. Сказки о том, что Лисп и Форт не имеет сахара — это даже не скзки а наглая лож.

Дай пожалуйста свое определение сахара, а то я уже начинаю думать что у тебя это универсальное слово через которое можно объяснить вообще все

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

У меня и в мыслях не было ставить тебя в тупик, я думаю это вообще невозможно

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

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

Подозреваю, что здесь спор вот в чём.
Любую фичу можно сделать сахаром, если она прикручена к языку, который без неё обходится.

А именно: замыкания, карринг, лямбда...

Замыкания можно построить двумя способами:
— упоминанием имён из внешнего контекста во вложенной функции
— каррингом свободной функции

-- первый способ
foo (x,y) = ... (bar x) ...
    where
        z = ...
        bar t = y*z*t -- здесь y,z - внешние переменные

-- второй способ
bar' (y,z) t = y*z*t
foo (x,y) = ... (bar x) ...
    where
        z = ...
        bar = (bar' (y,z))

В этом смысле первый способ — сахар. (Хотя для яваскрипта это не так; там передача контекстов — естественная фича реализации).

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

bar' = \ (y,z) -> (\t -> y * z * t)

Какая роль у лямбды в языке?
— способ определения-и-использования вложенной функции — т.е. сахар

bar' (y,z) = baryz
    where
        baryz t = y*z*t -- шайтан! опять появились внешние переменные!!!

— способ трансляции AST из лямбда-исчислительного вида во что-нибудь эквивалентное, более родное для базового языка (например, в комбинаторную форму J или в адский биндинг С++) — это, с некоторой натяжкой, тоже можно считать сахаром
— наконец, это и есть базис языка, основанного на лямбда-исчислении. То есть, компилятор "мыслит" в терминах лямбд.

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

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

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

MK>>Есть такое понятие — лингвистические абстракции (lingustic abstractions). Изначально у нас есть некий базовый язык — по сути описание вычислительной модели. Как правило хорошо поддающийся теоритическим исследованиям, но мало пригодный для программирования на нем человеками. Для повышения удобства начинаем расширять базовый язык, при этом расширения транслируются в простой базовый синтаксис. Так вот эти расширения и разделяют на лингвистические абстракции и синтаксический сахар.

VD>До этого момента вопросов практически нет. Согласен с определениями. Разве что хочу заметить, что для разных языков список таких абстракций может быть разным. И еще что одни бстракции могут выражаться другими. Так что разумнее вести речь о неком минимальном наборе абстракций через которые можно вырзить другой более широкий набор абстракций. Вот он то и будет являться сахаром.

VD>Вот именно об этом я и говорю! Забвно, что lomeo поставил тебе оценку, но при этом во всю спорит со многими тем о чем ты тут сказал.

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

Вот кстати отвлекусь от темы, но не могу удержаться от цитаты

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

Сказано в 1918 году академиком Павловым в его лекции «О русском уме» на вручении Нобелевской премии.

MK>>Очень хорошо и подробно об этом написано в CTM.

VD>Осталось выяснить что такое CTM.

Ну батенька, я уж думал что в "Декларативном программировании" все знают эту аббревиатуру, как и SICP. Это "Concepts, Techniques, and Models of Computer Programming", авторы Peter Van Roy и Seif Haridi. Одна из моих любимейших книг по программированию. Написана очень легким, ясным языком, охватывает огромный класс задач и при этом очень взвешена без перекосов в какую-либо одну парадигму. Тут в форуме была и ссылка на электронный вариант (правда draft).

--
Mikl

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

VD>Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена?

Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.

Gaperton wrote:
> C>Вообще говоря, это необязательно. Никто не мешает делать объекты
> C>иммутабельными, мутирующие функции просто будут возвращать новые объекты
> C>(как со строками в .NET/Java).
> Мешает. Попробуй на таких объектах построить систему, увидишь. На таких
> "объектах" ты не получишь главного — не сможешь сделать декомпозицию
> системы. Просто попробуй, это проще, чем объяснить. Сделай систему с
> кольцевой ссылкой, и посмотри.
Можно и с кольцевой. Громоздно только получается...

class B;

class A
{
   friend class B;
   int var;
   B *b;
public:
   A* mutate_something() const
   {
     A *a=new A;
     a->var=var*2;
     a->b=new B(*b);
     b->a=a;
     return a;
   }
};

class B
{
   friend class A;
   A *a;
public:
   //...
}

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

Не знаю как проще объяснить — вероятно придется писать статью

Posted via RSDN NNTP Server 2.0

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

К>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

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

К> в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.

VladD2,

L>> А уж ФВП сахаром назвать язык не повернётся.

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

VD>C# 2.0 и выше, Немерле и многие другие реализуют замыкания захватывающие контекст метода как классы. И ничто не мешает создать подобный код в языке не поддреживающих замыканий.

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

VD>Так что как не прискорбно но функциональный стиль является всего лишь сахаром котрый можно привнести в любой язык. Собственно это и делается сейчас. Тот же C# в следующей вресии обзаведется лямбдами которые выглядят не хуже чем в самиом из языков. А ведь никаких идеологических изменений в C# нет.

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

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

VD>Вот только к идее запрета на модификацию переменных все это отношения не имеет.

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

В-четвёртых, прозрачность ссылок и ООП — вещи почти несовместимые — при модификации состояния любого объекта рвутся ссылки, что мешает нормальному моделированию. Хотя в соседней ветке Z00N привёл пример жестокой (иного слова подобрать не могу) реализации такого const-OOP через гхм... ну ты понял

В-пятых, в чистом функциональном мире все параметризованные типы могут быть ковариантны (то есть для любого параметризованного типа T: B < D => T[B] < T[D]), что невозможно в случае модифицируемого состояния (необходимость рантайм-проверок для того, чтобы не сломать систему типов).

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

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

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

VD>Да без разницы. ООП это тоже сахар. Я писал ОО-программы на С в 1993-ем году. Да было менее удобно чем на С++, но жить было можно. Когда появился сахар в виде классов, виртуальных методов и т.п. я с удовольствием им воспользовался.

Твоё понятие сахара что-то слишком широко.

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

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

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

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

PS2: Остальное (в частности то, как "рулят" отладчики) требует отдельных священных войн... Потом повоюем

PS3:
VD>> ковровые бомбардировки и танковые клинья и еще этот, как его? А, гриб Сарумяна.
^ это понравилось, но про гриб не понял

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

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

VD>Я считаю монадах вообще опофиозом религиозности ФП. Применение продолжений для вовда/вывода — тоже. Люди уже настолько отдалились от ральности, что выдумывают себе мир и заставляют себя же поверить в его реальность.

VD>Для вовда/вывода нужен всего лишь метод print или что-то вроде того. А как он выводит данные меня трогать не должно.

А он понавыводит конечно в ленивых языках

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

VD>>Так что я наставиваю, что краткось и выразительность кода зависит от сладкости языка программирования от уменя программистов и архитекторов применять этот сахар для решения конкретных задач.

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

) чем на большинстве засахаренных в твоем смысле ОО языков?

Элементарно, Ватсон!

1. Сказки о том, что программы на лиспе получаются более короткими они и есть сказки. Они получаются более лдинными нежели анлогичные написанные на хорошо подслащенных языках. И более короткими по сравнению с недосахаренными языками. Причем сахара может хватать для одной задачи и не хватать для другой. Например, компиляторы получаются самыми короткими на ОКамле и дургих МЛ-клонах (в том числе, гы-гы, и на Немерле).
2. Многое зависит от того кто пишет. И от того как пишет. Если человек пишет на С++ и пытается выжать максимум скорости, то ежику понятно, что код будет далек от оптимальности с точки зрения компактности. Или если человек вообще не знает даже паттернов ООП, и не особо понимает что значит повторно исползуемый код, то не мудренно что его код пухнет. Меж тем на Лиспах и Фортах в основно пишут посвященные. И сам процесс посвящения отсеивает тех кто не способен писать кратко.
3. Сказки о том, что Лисп и Форт не имеет сахара — это даже не скзки а наглая лож.

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

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

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

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

VD>Ясность — она и есть ясность. Например, i++ ничем не яснее чем i += 1 или i = i + 1, а даже наооборот.

Извините, что вмешиваюсь, но i++ не является эквивалентом ни i+=1, ни i=i+1. Это лаконичная запись: (t=i;i+=1;t). Поэтому нельзя сравнивать "ясность" i++ и i+=1. А вот ++i действительно эквивалентна i+=1 и i=i+1, но и ясность этих трех записей одинаковая.

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

L>>А где во втором случае ФВП?

WH>Да пожалуйста

Ну и где там ФВП, то??

L>>Мне кажется, что для замыканий нужна еще (кроме ФВП) сама возможность определения лексического контекста — вот в си, например, ФВП есть, а вложенных функций нет, поэтому замыкание не построишь.

WH>О том тебе и говорят что ФВП нафиг не упали без замыканий, а замыкания это всеголишь сахар.

Неправду мне говорят, не слушай

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

Покажи что замыкания — сахар.

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

L>>Ну и где там ФВП, то??
WH>Вобщето _N_combine1445 принимает функцию и возвращает функцию.

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

L>>Покажи что замыкания — сахар.
WH>Я уже показал вариант с сахаром и без...

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

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

L>Первое был вариант с замыканиями, а не вариант с сахаром. От того, что их можно сэмулировать они не становятся сахаром. Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?

Не я проникся они правы, ну сам посмотри:

_camlTst_01__f_57:
L100:
    lea    eax, DWORD PTR [ebx+eax-1]
    ret
    .CODE
    ALIGN    4
    PUBLIC    _camlTst_01__entry
_camlTst_01__entry:
L101:
    mov    eax, OFFSET _camlTst_01__1
    mov    DWORD PTR _camlTst_01, eax
    mov    eax, 1159
    call    _camlPervasives__string_of_int_153
L102:
    mov    ebx, eax
    mov    eax, DWORD PTR _camlPervasives+92
    call    _camlPervasives__output_string_214
L103:
    mov    eax, 1
    ret

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

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

К>[flame]
К>О! Кстати! Почему об этом ещё молчат?
К>Язык может считаться полноценным ОО в том случае, если класс в нём является first class object.

Вот, например, Python или JavaScript.
К>А то, понимаешь, в ФЯ можно писать функции высшего порядка, а в С++ метаклассы только с помощью велосипедов с квадратными колёсами делаются.

К>

К>[/flame]
К>

Ради справедливости... В Яве классы first class object их можно создавать где угодно, без имен, с замыканиями и даже передовать другому коду по ссылке, да и вообще посылать куда по дальше.

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

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

L>Замени, пожалуйста, мы аббревиатуру потом из этого сделаем. А называть одно другим по моему совсем неверно. Мы начинаем говорить о разных вещах.

А, по-моему, верно. Но дело даже не в этом. Дело в том, что я четко определил значение термина и вряд ли кто-то тут не понимает о чем идет речь.

L>Я с тобой согласен. В данном случае для паттерна for был придуман сахар foreach.

На самом деле все в мире очень относительно. В языке может не быть аналога С-шного for-а. Например, так происходит в Питоне. И аналог этого цикла будет выражаться через foreach:

for i in range(1, 100)
    ...

В таком случае уже сишный for окажется сахаром.

L> Но ты опять берешь сахар и код. Сравни оба эти варианты (которые в этом смысле эквивалентны) с использованием функций высшего порядка:

L>

L>(map display list)
L>

Это другой подход не более чем. Он без проблем возможен даже в старом добром С:

map(list, display);

Так что то что ты привел даже сахаром не является. Сахаром является замыкания или лямбды. И их можно выражазить с помощью классов и методов.

Я не в комем случае не хочу сказать, что методы типа Iter(), ForEach(), Fold() и т.п. являются сахаром для операторов foreach, for и т.п.

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

L>Согласен, что это очень простой случай, но при желании в нем можно увидеть ту разницу, о которой я говорю. И я говорю не о том, что код стал короче.

А он в данном случае и не стал. Он даже не стал яснее и тмболее декларативнее. Вот использование функций типа Map или Fold. Они уже дают серьезный вигрышь. Но как я уже говорил, без сахара код получается очень громоздким и его банально неудобно писать. Плюсь названия тиа Map совершенно не очевидны. Я не раз наблюдал что название ConvertAll намного более понятно тем кто еще не успел заработать плешь в процессе изучения литературы по ФП.

А за счет чего этот выигрышь? Магия ФП? На ни скольчко! Это банальная функциональная декомпозиция. Просто ее сложнее сделать без таких универсальных методов как Map и Fold. А как я уже сказал их применение затруднено отсуствием сахара.

А влияет на наличие Map и Fold то что язык запрещает модифицировать переменные? Да на на грошь! Я без проблем могу в Map или Fold модифицировать переменную объявленную за пределами переданной им функции и при этом не получу ни единой проблемы.

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

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

L>Так все можно заменить чем угодно. Мы же сравниваем два подхода или как?

Ага. Два полхода. И как не странно без того сахара коим изабилуют ФЯ подход ФЯ становится дико неудобным, многословным и убогим.

А вот модификация переменных не сколько не умаляет возможности этого подхода. Код остается все так же кратким и выразительным.

Это же факты! А на них уже не проблема сделать правильный вывод — краткость ФП в основном обусловлен сахаром, а отндь не удалениме из языка возможности изменять переменные.

Это же очевидно как дважды два. Только нужно маленько подумать.

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

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

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

Между прочем "процессы" Эрлэнга по сути те же объекты. Они практически ничем не отличаются от Смолтоковских объектов за тем исключением что принимают сообщения асинхронно.

Ну, и за что идет священная война ООП vs. ФП, если это одно и тоже только вид сбоку?

L>>>С этой точки зрения — ООП ни капли не сахар.
VD>>Это ошибочная точка зрения. Не странно что она приводит к совершенно нелогичным выводам.

L>Нет, это верная точка зрения.

Что же по этому поводу есть две точки зрения.

L> То что тебе дали ОО-сахар (пусть будет так) для программ на Си не значит, что само ООП является сахаром.

Не конечно. Как и ФП не является сахаром. А разве я это утверждал?

L> Ты же зачем то использовал классы, хотя рисовал их в виде структур?

Да. Я использовал ОО-парадигму.

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

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

L>Согласен, но разговор я веду о другом. Ты же опять все сводишь только к языкам и коду.

Ага. Я эдакий романтический прогматик.

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

VD>>Тут г. Гапертон выразил мысль, что главное в ФП это "immutability". А используя ООП я могу сделать класс immutable или mutable. Отличный пример реализация класса строк в std::C++ и в Яве. Пользуясь определением Гапертона, я выбирая реализацию класса делаю выбор между императивным и функциональным дизайном. Так?

L>"Главное", я полагаю, это наиболее важное? Тогда не так, потому что кроме наиболее важного могут присутствовать и другие моменты.

Это что-то очень филосовское.

L> Кстати, я не считаю отсутствие сайд эффектов наиболее главным.

А, ну, тогда мы еще можем прийти к единому мнению.

L> Для меня это скорее пара отсутствие сайд эффектов и ФВП. Причем ФВП даже больше относятся к ФП. Но это субъективный взгляд.

Здорово. Теперь покажи мне как отсуствие побочных эффектов может улучшить действие ФВП? И за одно объясни мне почему ООЯ — Смолток имея ФВП с побочными эффектами без проблем пользуется всеми их приемуществами?

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

L>И ты обвиняешь меня в нелогичности?

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

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

L>Не знаю. Я всё время думал, что делегат — это объект, я ошибался?

Это зависит от точки зрения. В принципе так как его можно куда-то передать и так как над ним можно выполнить действия — то несомненно. Но это функциональный объект. Его можно использовать как функцию. В прочем некторые особенности делегатов были сделаны с дури. Идея функционального типа мне нравится больше. Делегаты вызвают ряд проблем. Но это уже другая история.

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

С другой стороны делегат это объект так как я над ним погу производить операции и у него есть свои методы. Так я могу вызвать делегат асинхронно. Мне удобно думать о нем как об объекте.

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

L>>>Не так. Сахар сокращает код. Из этого не следует, что краткость определяется сахаром.

VD>>Изумительно! Прочти свое высказывение еще раз и попытайся объяснить почему оно на твой взгляд не является противоречищим самому себе.

L>Прочел. Попытайся объяснить почем это оно является противоречащим?

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

L> Для аналогии приведу еще одно: "Перец меняет вкус блюда, но вкус блюда не ОПРЕДЕЛЯЕТСЯ перцем." Может ты хочешь найти у меня какие то максималистические высказывания?

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

VD>>Тогда объясни что дает эту краткость если не сахар вроде клозюров, анонимных и локальных функций, паттерн-матчинга и спец-синтаксиса работы со списками?

L>ФВП.

ФВП — это сахар. Они ничего не дают и могу без проблем быть выражены классами и методами.

L>Я должен сказать о передозировке ООП или предложить вспомнить об уважении друг к другу?

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

L>Напомню, что в Смолтолке реализован паттерн MVC (по крайней мере в том, в котором пишу я). И там не форма выполняет некие действия, а те объекты бизнес модели, которые за эти действия ответственны. Форма же является тем, чем она и должна являться — простым View.

Извини, но это натуральная кала в голове. Смолток не реализует паттерны MVC. Он его позволяет использовать. Точнее даже его библиотеки используют этот паттерн. Точено так же они используют многие другие паттерны.

L>Что же касается применения ООП в GUI, то я над этим не смеялся, ты в очередной раз приписываешь мне свои домыслы.

Ты тут пытался поставить на смех то что форма выражается объектом. Так вот смешны как раз такие попытки. Точно так же как утверждеие, что слушатели (лисенеры) являются неприменным атрибутом ООП.

Просто View — это, кстатий простой объект. В общем, это праздник алогичности мне уже порядком надоел.

L>Значит я ошибался. Тем не менее, если мы возмем библиотеку Struts, то увидим там пример того, о чем мы говорим — использовании объектов, вместо функций. Ну еще есть интерфейс Runnable в Яве. Просто в Яве по другому не выразишь, вот и получаем оверхед по сравнению с исходной мыслью.

А давай мы вместо Явы возмем C# или Смотлок? В них есть ФВП на которых и реализуются все что нужно без какого либо оверхэда. А Яву мы возьмем как прмер языка разрабочкики которого упорно не хотят предоставлять его пользователям необходимый им сахар.

Я надесь, C# и Смотлок не стали ФЯ от того, что в них есть ФВП? И мы можем считать, что ФВП для этих языков являются разумным сахаром, а не мантрой высшего порядка и религиозным объектом поклоенения?

L>Я не о том. Задавать приоритеты потокам приходится не часто.

Частота использования метода к его наличию отношения не имеет. Вот, например, довольно часто поток срубается извне вызовм метода Abort(). Это позволяет думать мне о потоке как об объекте?

L> А вот просто их запускать для выполнения неких действий — это стандартная практика.

И что? Что мешает мне сделать функцию для запуска потока? Эта функция может создавать новый объект "поток" и возвращать его мне. А может (не поверишь) вызвать код в потоке из пула потокв и возвращать полученный поток обратно когда поток больше не нужен.

И где у меня тут оверхэд? Или оверхэд там где не сделали функции дя запуска потока? Ну, то извини банальное проектирование. Я тебе на любом ФЯ запишу весь код в одну большую функцию и сдублирую его по сто раз. Что с того?

L>Мысль тоже, безусловно, глубока. Однако речь идет о сравнении двух подходов — ООП и ФП.

Где сравнение то?

L> А не о том, что где надо используем ООП, а где надо ФП.

А между тем это именно так. И просто верхом неразумности является попытка докзать приемущество ФП над ООП. Хотя почему-то для поклонников ФП она уже стала "идеей фикс".

L> В случаях, где удобнее ООП, наверное, надо использовать его.

Ну, а тогда о чем спор то?

L> А в случаях, где удобнее ФП — использовать ФП.

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

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

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

L> Именно поэтому меня совершенно не интересует синтаксический сахар, о котором ты говоришь.

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

L>Нет, это ошибочное мнение. Из того, что я вижу (и показываю) одно преимущество ФП перед ООП, не значит, что я не вижу преимуществ ООП, а также недостатков ФП.

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

L>Боже мой, Влад, да для тебя это, оказывается, религиозная война?

Для меня — нет. В том смысле, что я не собираюсь в ней участвоать ни на одной из сторон. Я америваюсь взять лучшее из обоих лагерй. Но то что это религиозная война у меня сомнений нет.

L> Дело, конечно, полезное, но бросишься ли ты также рьяно на того, кто заявит о каком нибудь из преимуществ ООП перед ФП?

Ага. Натура такая. Вот недавно обяснял человеку погрязшему в С++, что есть другой мир в котором и языки богаче, и средства расшерения у них (у Лиспа в частности) есть. Зайди в Филосовию, покляди.

L> Или весь твой пыл направлен именно на ФП?

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

Так же я считаю наличие статической типизации благом, а полную динамику недостатком. Но при этом мне очень ненравится ОКамл с его идеей отсуствия up-cast-ов так как это напрочь исключает качественную поддержку компонентной модели. Да и его идея писать код "в обратную сторону" меня чесно сказать раздражает. Плюс я ценю хорошие библиотеки с хорошей документацией.

Возможно какие-то из моих предпочтений кому-то покажется неверными. И он выберет другие приоритеты. Но их хотя бы можно обосновать. А вот отказ от чего-то без обоснования или обосновавая это "не только эитм..." мне кажется явном хождением на поводу у предвзятого мнения.

L>Про полное отрицание ООП и императивного кода поклонниками ФП поскипал, потому что не понимаю, каким это боком ты вяжешь ко мне.

А твои слова о ОО-оверхэде это что?

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

L>Не так. В большинстве случаев достаточно представлять поток функцией, тем не менее его представляют объектом. Так пойдет?

Не пойдем. Это пример фанатизма с другой стороры. Или банально неверного дизайна. Я уже говорил, что можно привести обратный пример.

Пойми любой универсальный ЯП является полным по Тьюрингу, а значит на нем можно решить любую задачу. И то насколько просто она будет решена завист в первую очередь от разумности и опыта разрабочика. В общем, это завист от проектирования системы/кода. Использование менее "сладких" языков приводит к увеличению объема кода и его запутыванию. Но даже если найти самый сладкий язык, то в рукаж среднго индуса он окажется не более полезной вещью чем очки в руках мартышки.

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

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

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

VD>Так что я наставиваю, что краткось и выразительность кода зависит от сладкости языка программирования от уменя программистов и архитекторов применять этот сахар для решения конкретных задач.

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

) чем на большинстве засахаренных в твоем смысле ОО языков?

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

L>>Замени, пожалуйста, мы аббревиатуру потом из этого сделаем. А называть одно другим по моему совсем неверно. Мы начинаем говорить о разных вещах.

VD>А, по-моему, верно. Но дело даже не в этом. Дело в том, что я четко определил значение термина и вряд ли кто-то тут не понимает о чем идет речь.

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

VD>Это другой подход не более чем. Он без проблем возможен даже в старом добром С:
VD>

VD>map(list, display);
VD>

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

Я и не утверждал, что это является сахаром. Я говорил о подходе. Да, это можно выразить на Си, и это уже будет другой подход, в отличие от for/foreach.
Что же касается выражения их с помощью классов и методов — то это к теме спора не относится.

L>>Согласен, что это очень простой случай, но при желании в нем можно увидеть ту разницу, о которой я говорю. И я говорю не о том, что код стал короче.

VD>А он в данном случае и не стал. Он даже не стал яснее и тмболее декларативнее. Вот использование функций типа Map или Fold. Они уже дают серьезный вигрышь. Но как я уже говорил, без сахара код получается очень громоздким и его банально неудобно писать. Плюсь названия тиа Map совершенно не очевидны. Я не раз наблюдал что название ConvertAll намного более понятно тем кто еще не успел заработать плешь в процессе изучения литературы по ФП. :)

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

VD>А за счет чего этот выигрышь? Магия ФП? На ни скольчко! Это банальная функциональная декомпозиция. Просто ее сложнее сделать без таких универсальных методов как Map и Fold. А как я уже сказал их применение затруднено отсуствием сахара.

Представь, что сахар есть. Давай исходить из этого.

VD>А влияет на наличие Map и Fold то что язык запрещает модифицировать переменные? Да на на грошь! Я без проблем могу в Map или Fold модифицировать переменную объявленную за пределами переданной им функции и при этом не получу ни единой проблемы.

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

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

Представь, что сахар есть.

VD>Ага. Два полхода. И как не странно без того сахара коим изабилуют ФЯ подход ФЯ становится дико неудобным, многословным и убогим.

:-)

VD>А вот модификация переменных не сколько не умаляет возможности этого подхода. Код остается все так же кратким и выразительным.

Ну вот видишь! У тебя есть опыт работы с ФЯ, у меня есть. Я заметил, что понимаю быстрее и четче те участки кода, которые не имеют сайд эффектов. Для тебя это не так. Однако это не значит, что я стал ВСЕ писать без сайд эффектов. Просто при прочих равных я предпочитал их не использовать. Если же выгода от их использования перевешивала их недостатки, то я их использовал. Однако, я всегда на чашу весов при выборе клал такое их (отсутствия) преимущество как более ясный код.

VD>Это же факты! А на них уже не проблема сделать правильный вывод — краткость ФП в основном обусловлен сахаром, а отндь не удалениме из языка возможности изменять переменные.
VD>Это же очевидно как дважды два. Только нужно маленько подумать. :xz:

Для меня это не так. Я совершенно по разному дизайню программы на Хаскеле и Яве. Чтобы поиметь выгоды от преимуществ языков — а они у них разные.

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

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

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

Ну там краткость в основном за счет того что есть блоки (аналог лямбд и ФВП) и за счет того, что язык динамический. Потом там действительно есть чуть чуть сахара (но совсем чуть чуть — типа посылок сообщений одному и тому же объекту без повторного указания его имени).

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

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

VD>Ну, и за что идет священная война ООП vs. ФП, если это одно и тоже только вид сбоку?

Пила и молоток — одно и то же?

L>> То что тебе дали ОО-сахар (пусть будет так) для программ на Си не значит, что само ООП является сахаром.
VD>Не конечно. Как и ФП не является сахаром. А разве я это утверждал?

Угу.

L>>С этой точки зрения — ООП ни капли не сахар.
VD>Это ошибочная точка зрения.

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

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

Для меня все таки краткость связана с ФВП.

L>> Для меня это скорее пара отсутствие сайд эффектов и ФВП. Причем ФВП даже больше относятся к ФП. Но это субъективный взгляд.

VD>Здорово. Теперь покажи мне как отсуствие побочных эффектов может улучшить действие ФВП? И за одно объясни мне почему ООЯ — Смолток имея ФВП с побочными эффектами без проблем пользуется всеми их приемуществами?

А зачем я должен показывать, что отсуствие побочных эффектов может улучшить действие ФВП? Вот ты покажи мне как паттерн матчинг улучшает действия лямбд! :-)) Насчет Смолтолка — стоит почитать о достоинствах и недостатках паттерна Value Object. Насчет проблем я уже высказался — видимо, преимущества сайд эффектов перевесили их недостатки при написании кода на этом языке.

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

Угу. Причем ты зачем то приписываешь его мне :)

VD> Нет никакой связи между возможностью использования ФВП и отсуствием побочных эффектов.

Так.

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

Я говорил что это зло? Впрочем, о преимуществе отсутствия сайд эффектов я уже писал.

L>>И ты обвиняешь меня в нелогичности? :-) Влад ты очередной раз приписываешь мне свои домыслы (о том, что я считаю, что с этим должны другие смириться). Мало того в качестве обоснования ты приводишь очень странные доводы. Ведь исходя из них можно сделать вывод, что и ты свои заключения повторяешь для того, чтобы другие с ними смирились?

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

Дают ясность. Краткость достигается за счет ФВП.

L>>>>Не так. Сахар сокращает код. Из этого не следует, что краткость определяется сахаром.
VD>>>Изумительно! Прочти свое высказывение еще раз и попытайся объяснить почему оно на твой взгляд не является противоречищим самому себе.
L>>Прочел. Попытайся объяснить почем это оно является противоречащим?
VD>Это элементарно. Если сахар сокращает код, то он без является состявляющей частью сокращения кода. Возможно конечно, что кроме сахара есть что-то еще. Но! Но что-то еще нам предъявлено не было. Так что данное утверждение просто бессысленно. Оно лишь говорит о том, что в любом результате может быть более одной составляющей. Это очевидная банальность. И смысла она в таком виде не имеет.

Браво! Возможно есть что то еще, но оно предъявлено нам не было, значит оппонент говорит бессмысленные вещи.
Или вот еще шедевр — Это очевидная банальность. И смысла она в таком виде не имеет. Так банальность или смысла не имеет?
Ну и напоследок. Я говорил об основной вещи, которую считаю наиболее главной в деле уничтожения оверхеда — это ФВП. И ФВП — это не сахар. Если он сахар, тогда да — все определяется сахаром, потому что все на этом свете можно определить как сахар.

L>> Для аналогии приведу еще одно: "Перец меняет вкус блюда, но вкус блюда не ОПРЕДЕЛЯЕТСЯ перцем." Может ты хочешь найти у меня какие то максималистические высказывания?

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

ФВП ФВП ФВП — сколько раз надо еще сказать?!

VD>ФВП — это сахар. Они ничего не дают и могу без проблем быть выражены классами и методами.

Пфффф.... Ну могут быть — что с того? Какой это имеет смысл для нашего спора?

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

У меня нет предвзятости по отношению к ООП, это я чувствую предвзятость по отношению ко мне. Утверждение "предвзятость — это факт" есть false. Поверь мне. Я пишу ОО тоже. Иногда это приятно, иногда раздражает, в зависимости от того, на что нарвался. Поэтому больше об этом можешь не говорить :-)

L>>Напомню, что в Смолтолке реализован паттерн MVC (по крайней мере в том, в котором пишу я). И там не форма выполняет некие действия, а те объекты бизнес модели, которые за эти действия ответственны. Форма же является тем, чем она и должна являться — простым View.

VD>Извини, но это натуральная кала в голове. Смолток не реализует паттерны MVC. Он его позволяет использовать. Точнее даже его библиотеки используют этот паттерн. Точено так же они используют многие другие паттерны.

Ты к словам цеплятся долго будешь? Я ведь тоже могу прицепиться и начать утверждать, что в смолтолке есть реализация (причем в том смысле в котором понимаешь ты! — например сама среда) и у нас получится очень глупый спор.

L>>Что же касается применения ООП в GUI, то я над этим не смеялся, ты в очередной раз приписываешь мне свои домыслы.
VD>Ты тут пытался поставить на смех то что форма выражается объектом. Так вот смешны как раз такие попытки. Точно так же как утверждеие, что слушатели (лисенеры) являются неприменным атрибутом ООП.

Клевета! :-) Не смеялся я над тем, что форма выражается объектом! Я обратил твое внимание на "обезображенную ОО мысль" о том, что "форма выполнила некие действия" — перечитай. Также лиснеры — всего лишь пример ОО мышления.

VD>Просто View — это, кстатий простой объект. В общем, это праздник алогичности мне уже порядком надоел.

А мне то как!

VD>А давай мы вместо Явы возмем C# или Смотлок? В них есть ФВП на которых и реализуются все что нужно без какого либо оверхэда. А Яву мы возьмем как прмер языка разрабочкики которого упорно не хотят предоставлять его пользователям необходимый им сахар.

Ну давай! Толку то, я то рассматриваю разницу в подходах, а не языках.

VD>Я надесь, C# и Смотлок не стали ФЯ от того, что в них есть ФВП? И мы можем считать, что ФВП для этих языков являются разумным сахаром, а не мантрой высшего порядка и религиозным объектом поклоенения?

При чем тут ФЯ, ООЯ, плохо понимаю.

VD>Частота использования метода к его наличию отношения не имеет. Вот, например, довольно часто поток срубается извне вызовм метода Abort(). Это позволяет думать мне о потоке как об объекте?

Откуда я знаю? Если ты его вызываешь сам, то может быть тебе так удобнее.

L>> А вот просто их запускать для выполнения неких действий — это стандартная практика.

VD>И что? Что мешает мне сделать функцию для запуска потока? Эта функция может создавать новый объект "поток" и возвращать его мне. А может (не поверишь) вызвать код в потоке из пула потокв и возвращать полученный поток обратно когда поток больше не нужен.

Что мешает? Не знаю, но почему то наблюдаю я совсем другую картину.

L>>Мысль тоже, безусловно, глубока. Однако речь идет о сравнении двух подходов — ООП и ФП.
VD>Где сравнение то?

Я же говорю — не читаешь ты постов.

L>> А не о том, что где надо используем ООП, а где надо ФП.
VD>А между тем это именно так. И просто верхом неразумности является попытка докзать приемущество ФП над ООП. Хотя почему-то для поклонников ФП она уже стала "идеей фикс".

Т.е. ты хочешь сказать, что у ФП перед ООП нет преимуществ?

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

Сравнение не бывает бессмысленным. При сравнении определяются критерии оценки сравниваемых объектов.

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

Лучше, да, однако не идеально хорошо, верно? Вот и сравница разницу.

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

Я не понял — ты хочешь сказать что я использую нечестные методы или что я оболванен пропагандистами?
Как мне вежливо попросить тебя этого больше не делать?

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

Я тебе это предлагал?

VD>Возможно какие-то из моих предпочтений кому-то покажется неверными. И он выберет другие приоритеты. Но их хотя бы можно обосновать. А вот отказ от чего-то без обоснования или обосновавая это "не только эитм..." мне кажется явном хождением на поводу у предвзятого мнения.

Отказа не было. Было непонимание с твоей стороны.

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

Это один из недостатков ОО по сравнению в ФП. Обязательно рядом приводить недостатки ФП по сравнению с ОО? К чему эта политкорректность?

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

А зачем нам его брать не понимаю?

L>>Не так. В большинстве случаев достаточно представлять поток функцией, тем не менее его представляют объектом. Так пойдет?
VD>Не пойдем. Это пример фанатизма с другой стороры. Или банально неверного дизайна. Я уже говорил, что можно привести обратный пример.

Можно.

VD>Так что я наставиваю, что краткось и выразительность кода зависит от сладкости языка программирования от уменя программистов и архитекторов применять этот сахар для решения конкретных задач.

Хм.. Меня не интересует краткость КОДА.

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

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

Золотые слова.

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

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

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

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

L>>Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь.
WH>Легко.

Ты похоже про что-то свое

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

WH>Неммерле
WH>

WH>foo () : void
WH>{
WH>    def i = 234;
WH>    def addI = _ + i;
WH>    def x = addI(123);
WH>}
WH>

WH>А теперь тоже самое без замыканий

Это не тоже самое. А одна из возможных реализаций, бывает и по другому:

def addI(i):
    return lambda x : x + i

print addI(234)(123)

реализация:

Disassembly of addI:
  7           0 LOAD_CLOSURE             0 (i)
              3 LOAD_CONST               1 (<code object <lambda> at 01A17C20, file "D:\temp\Module2.py", line 7>)
              6 MAKE_CLOSURE             0
              9 RETURN_VALUE        
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

WH>Могу повторить все тоже самое на чистых сях. Только это будет выглядить еще страшнее.

А я могу повторить на чистом ассемблере.

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

G>Давно пора. А то весь форум ерундой какой-то загадили — за флудом полезные сообщения найти невозможно. Разборки с Владом переносим в философию, ок? А если честно — я вообще не понимаю, зачем и с какой целью вы отвечаете на всякую ерунду. Что-то новое для себя узнать хотите? Или интересно очень?

ХЗ. Утром пришел, смотрю — мне Влад что то написал, ну я ему и ответил, он, наверное, так же поступает

Прекращаю.

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

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

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

К>>>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

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

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

Все равно получается сопоставимая сложность на одних и тех же задачах.

К>А про замыкание — дак это тот же объект, только вид сбоку (ср. функторы с приватными членами как "замкнутыми" переменными)

Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

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

FR>>Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

G>Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

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

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

G>>Это запросто. Только контекст замыкания не может изменяться, так что нам пофиг, есть замыкание в параметрах, или его нет. Это совершенно все равно. Другое дело, что параметром может припереть функция высшего порядка, которая возвращает функцию высшего порядка, которая... потом будет передана параметром в другую функцию высшего порядка. И так несколько раз.

FR>Изменятся не может но тянуть вызовов и ссылок может не меньше чем объект.
Это не имеет значения, так как тебе не надо отслеживать изменение состояния — вся сложность в последнем. Лексическое замыкание, а именно оно у нас присутствует в ФЯ, не отличимо по своим свойствам от простой "чистой" функции.

FR>>>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.
G>>Ну конечно. А приватные переменные "состояния" не указывают на другие объекты? Глядя на публичный интерфейс ты их не видишь, а по ним, возможно, будут запущены вызовы.

Вот тебе и связность.

FR>Это не связность, а граф вызовов

Это связность, она родимая

. Посредством чего она достигается, и как ты ее назовешь — совершенно не важно.

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

VD>А с этой не совсем. И вообще, что за зверь "объекты"? Какой-то расплывчатый термин. Например, фраза "first class object" о них говорит?

[flame]
О! Кстати! Почему об этом ещё молчат?
Язык может считаться полноценным ОО в том случае, если класс в нём является first class object.

Вот, например, Python или JavaScript.
А то, понимаешь, в ФЯ можно писать функции высшего порядка, а в С++ метаклассы только с помощью велосипедов с квадратными колёсами делаются.

[/flame]

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

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

G>В Эрланге, о котором и говорил автор статьи, такой возможности нет. Эта возможность — императивна, это не ФП, глупо ее противопоставлять ОО, и не важно, присутствует она в языках или нет. Что вы мне все тут доказать хотите?

Вывод. ФП + ИП == ООП.

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

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

C>граммофон wrote:
>> C>Вероятно поэтому функциональщики предпочитают использовать
>> C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
>> C>заменой.
>> В Haskell есть классы типов, в ML — функторы.
C>Вот если ты на них будешь пытаться сделать то, что описывается в GoF —
C>то получишь примерно такое же, что и в GoF (за некоторыми исключениями).
C>Потому как паттерны в GoF — это скорее руководство по тому как
C>использовать полиморфизм.

Изначально речь шла о том, что для большинства GoF-паттернов не нужны ни классы, ни перегрузки, ни функторов. Достаточно алгебраических типов и паттерн-матчинга.
И вырождаются они в нечто по 2-3 строчки.
То етсь теряют свой смысл как некий прием.

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

LCR>Функции Высшего Порядка = HOF = Higher Order Functions

Значит ВВП = Володя Высего Порядка.

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

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

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

L>Ну не совсем, даже в классической книге GoF'а примеры на Смолтолк.
L>Хотя во некоторых случаях твоя правда, ага.

В бандитской книге куча пояснений что для смоллтока данный паттерн делается средствами языка

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

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

VD>1. Сопоставление с образцом (сахар для if-ов и switch-ей).

Это ниразу не сахар для if-ов и switch-ей

VD>2. Алгеброические типы (сахар для классов).

Ни разу не сахар для классов.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>>Это общая проблема switch'ей — они имеет тенденцию распухать.

АХ>>Именно поэтому в таких случаях рулит расширение через добавление классов реализующих общий интерфейс.

L>Всё относительно. По сравнению со свитчами — рулит, а по сравнению с ФВП+паттерн-матчинг — сосёт.

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

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

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

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

G>Какая нам разница, в контексте данного разговора.

Разница такая, что на нужном месте монады красивы и полезны.

Ну а duck coding technique... (крякает как собака и летает как собака, ссссобака бешеная!) тут с тобой, конечно же, соглашусь.

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

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

L>>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий

VD>На C/С++ устроит?

Хорошо, представим что это замыкания. Ну, предположим.

VD>Ну, согласен, что замыкания это сахар?

Нет. Сахар подслащивает код, предоставляя более сладкую возможность для уже имеющейся.
Назови мне что подслащивают показанные тобой ФВП? Какой код был бы не сладким, но семантически эквивалентным?

L>> От того, что их можно сэмулировать они не становятся сахаром.

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

Покажи мне исходные средства языка с той же семантикой, но выглядящие менее сладко?

L>> Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?

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

Тогда у тебя неверное понимание сахара.

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

FR>Если бы другие средства давали бы те же результаты, я бы один раз написал class Closure и везде пользовался им как замыканием, а не писал каждый раз вручную реализацию.

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

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

VD>>Просили функции высшего порядка. Они в С есть штатно. Называются указатели на функции. Так что тут и показывать нечего.

FR>Нет просили показать лямбду в виде сахара.

Врешь.

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

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

L>>А на фига это показывать???

VD>Чтобы ты видил, что они легко выражаются с помощью паттернов в ООЯ.

А на фига мне это видеть??

VD>А раз так, то нет проблем добавить подобный сахар в любой ООЯ. Единственная серьезная проблема — это время жизни. Тут лучше иметь в языке GC.

Влад, то что это можно добавить, я как бы догадываюсь. Спор был о том является ли лямбда сахаром. Исходя из Ландиновского определения сахара, если лямбда является сахаром, то она должна подслащивать некую семантически эквивалентную конструкцию. В данном случае это не наблюдается. Вывод — лямбда не сахар. А из того, что что то можно добавить в язык не следует, что это что то автоматически является сахаром. И уж тем более меня совершенно не интересует сама возможность добавления. Каким это боком к спору о том, сахар лямбда или нет??

VD>>>То что кто-то не хочет это понимать — это проблемы его личного мозга.

L>>Вот именно

VD>Ты сам собой перемигивашся?

Видимо, да

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

VD>На самом деле все очень зависит от точки зрения. Но непонимание того смысла в который вкладывается в слово сахар в данном случае скорее демонстративное. Оно нужно лишь для того чтобы уйти от основного вопроса "Существует ли ОО-оверхэд?". Доказательств обсурдности этого вопроса тут было предостаточно. Но оппонетны решили сосредоточиться на борьбе с терминами.

ОО-оверхэд зависит от задачи, для некторых да существует, для других задач ровно наоборот.
Но если брать так скажем локальный код, то ФЯ стиль для этого случая почти всегда лучше, компактнее и яснее. (В общем это Гаптерон уже лучше меня объяснял).

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

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

LCR>>Есть люди, Antonio Vicente унд Earl Wagner, которые написали статью "Design Patterns in OCaml". Но имхо там они подходили к делу слишком буквально, в отрыве от задач, которые решаются с помощью паттернов. (Например, они смастерили клон паттерна Визитор на окамле (исходник на 1.5 страницы), несмотря на наличие паттерн-матчинга в окамле).

L>Мне более интересно не как создать клон (это то просто), а как решать задачи, которые решает паттерн, но используя функциональный подход.

Вот это смотрел? Здесь, насколько я помню, о том, что в языках Lisp и Dylan большинство паттернов GoF невидимо или тривиально.
http://www.norvig.com/design-patterns/

Однако, там упор на динамические свойства языков. В функциональных языках будет примерно то же самое, даже в строготипизированных, благодаря pattern-matching. Основная причина появления "паттернов" в ООП состоит в ограниченности динамического полиморфизма в модели ОО — вызов диспетчеризуется только по одному аргументу (this). Это заставляет в мало-мальски сложном случае городить лес из классов, размазывая по ним функционал. ФЯ с паттерн-матчингом позволяет выполнять другую группировку функционала, снимая ограничения на полиморфизм. Вот в все. В ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.

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

G>> ФЯ с паттерн-матчингом позволяет выполнять другую группировку функционала, снимая ограничения на полиморфизм. Вот в все. В ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.

C>Однако, иногда полиморфизм используется именно для того, чтобы как раз убрать эту группировку. Классический пример — приложение и плугины, взаимодействие с плугинами идет через интерфейсы/абстрактные классы.

C>Вероятно поэтому функциональщики предпочитают использовать message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной заменой.

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

type 'a MatStat = { median: () -> 'a; dispersion: () -> 'a; }

val matstatList : 'a list -> 'a MatStat
def matstatList xs =
    let m () = ..... (* считаем сумму, делим на длину, ну и т.д. *)
    and d () = .....
    in { median = m; dispersion = d; }
    end

val matstatContinuous : (float -> 'a) -> (float Option, float Option) -> 'a MatStat
def matstatContinuous f (x0,x1) =
    let m () = ..... (* численно находим интеграл... *)
    and d () = .....
    in { median = m; dispersion = d; }
    end

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

FR>Смотрел, правда давно, но помню по сравнению с ОО вариантами (особенно tk и tkinter) не впечатлило.
FR>Вообще конечно интересно бы посмотреть во что выльется на чисто функциональных библиотеках хотя бы простейшее окно с кнопкой при нажатии на которую это окно закрывается, я думаю вряд ли получится проще чем это:
FR>

FR>from Tkinter import *

FR>Button(text = "test", command = Tk().quit).pack()
FR>mainloop()
FR>

A simple pocket calculator

import Fudgets

main = fudlogue (shellF "Pocket Calculator" calcF)

calcF = intDispF >==< mapstateF calc [0] >==< buttonsF

data Buttons = Plus | Minus | Times | Div | Enter | Digit Int   deriving (Eq)

buttonsF = placerF (matrixP 4) (
              listF [d 7, d 8, d 9,op Div,
                     d 4, d 5, d 6,op Times,
                     d 1, d 2, d 3,op Minus,
                     hole,d 0,ent, op Plus])
  where
    d n = (Digit n,buttonF (show n))
    ent = op Enter
    hole = (Enter,holeF)
    op o = (o,buttonF (opLabel o))
      where opLabel Plus = "+"
            opLabel Minus = "-"
            opLabel Times  = "*"
            opLabel Div = "/"
            opLabel Enter = "Ent"

calc (n:s)   (Digit d,_) = new (n*10+d) s
calc s       (Enter,_)   = (0:s,[])
calc (y:x:s) (Plus,_)    = new (x+y) s
calc (y:x:s) (Minus,_)   = new (x-y) s
calc (y:x:s) (Times,_)   = new (x*y) s
calc (y:x:s) (Div,_)     = new (x `div` y) s
calc s       _           = (s,[])

new n s = (n:s,[n])

Неподалеку от него есть и Helloworlds!, и с кнопками тоже.

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

G>Не понятно, как такое может работать. Ну допустим, у них глобальные map-ы из identity в объект, через этот identity и идут ссылки. Ну допустим, они протаскивают этот контейнер через все вызовы параметром (кошмар неюзабельный).

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

Смотрите "State monad" и "O'Haskell" заодно. Монады на Scheme у Олега тоже есть — посмотрите там на сайте.

G>Вот тебе простейший пример — электронная таблица, рекурсивно вычисляющая формулы, и использующая член класса для отметки, что "мы это уже считали" — выявление кольцевых ссылок. Хотя бы это у них сработает? А там можно и более сложные примеры найти. Давай разберемся.

Давайте остановимся на кольцевых ссылках — вот чисто функциональный предикат 'cycle-list?'
Работает он так, давайте запистим по списку двух "пешеходов" — медленного и быстрого. Если они встретятся — список кольцевой — если кто-то дошел до конца — нет. Их состояние мы храним в двух аргументах внутренней функции 'helper':

(define (cycle-list? lst)
  (define (helper fast slow)
    (and (pair? fast)
         (let ([fast (cdr fast)])
           (and (pair? fast)
                (let ([fast (cdr fast)]
                      [slow (cdr slow)])
                  (or (eq? slow fast)
                      (helper fast slow)))))))  
  (helper lst lst))

;; test:
(define probe '(1 2 3 4 5))
probe                              ; => (1 2 3 4 5)
(cycle-list? probe)                ; => #f
(set-cdr! (cddr probe) probe)
probe                              ; => #0=(1 2 3 . #0#)
(cycle-list? probe)                ; => #t

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

L>А на фига мне это видеть??

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

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

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

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

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

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

L>>Что плохого в пиаре ФЯ?

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

Мне так не показалось. Но я понял, это ИМХО, так что не буду спорить.

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

Вот ты говоришь — сахар, сахар. ОО — это же тоже сахар, в таком случае. Но одновременно это и способ мышления. Когда я пишу на ОО, я думаю в объектах, когда на ФЯ — в действиях. Поэтому сахар тут не при чём. Дело в том, что (по моему опыту) думать в объектах приходится больше, чем в действиях. И это понятно — Гапертон объяснил почему. А разница в этих двух "думать" и есть оверхед, который создаёт ОО.

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

L>Ты можешь слово сахар заменить чем нибудь?

Могу но это будет очень длинно.

L> Или давай определимся с терминами. Для меня сахар — слово из словосочетания syntactic sugar. Позволяя записывать код короче, он тем не менее не добавляет выразительность программе, т.е. сахар сжимает код, а не мысль.

Слова "сахар сжимает код, а не мысль" ошибочны. Простой пример. Сравни эти два фрагмента кода:

for (int i = 0; i < list.Length; i++)
    WriteLite(list[i]);

foreach (elem in list)
    WriteLite(elem);

Является ли foreach сахаром? По-моему, несомненно — да.
Сжимает ли он мысль? Сложный вопрос. Оба кода подразумевают одну и туже мысль — перебор списка и вывод его элементов на экран. Но первый вариант — это паттерн и чтобы распознать этот паттерн нам нужно сначала проанализировать код. Мы должны прочесть. Код в котором написано "Создать переменную, проинициализировать ее нулем, проверить не выходит ли ее значение за границу массива, проиндексировать переменную получив ее значение, увеличить значение, повторить проверку...". Если паттерн соотвествует ожиданиям (ведь на самом деле переменная могла быть проинциализированна значением 2, или вместо "list[i]" могло быть написано "list2[i]", или могло быть написано "i--"), то мы делаем вывод, что это тот самый паттерн и оперируем уже им.

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

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

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

L>С этой точки зрения — ООП ни капли не сахар.

Это ошибочная точка зрения. Не странно что она приводит к совершенно нелогичным выводам.

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

Далее я прочел книку Страуструпа по С++ и стал писать ОО-программы уже на ООЯ.

Бли ли мои программы написанные на С объектно-ориентированными? Несоменно — да!
Получил ли я приемущества перейдя на ООЯ? А как же!

И что же я получил? А получил я замечательный сахар который позволил не писать кучу ненужных вещей реализуя ООП паттернами. Вместо этого я смог выражать свои мысли более явно, использовать терминалогию принятую для ООП. Теперь в моих программах не нужно было догадываться что набор действий — это некий паттерн выражающий некую ОО-сущьность (вроде класса). Как следствие — код стал более понятным.

Теперь, внимание, вопрос! А мог ли я писать на С в функциональном стиле? Мне кажется — да. Для этого я только должен был тогда прочесть книгу про ФП и проникнуться его принципами.

Что дал бы мне ФЯ? Он дал бы мне возможность выкинуть паттетры и выражать свои мысли более явно.

L> Это новый взгляд на проблему и именно с этой точки зрения я рассматриваю оспариваемый тезис. Собственно мое мнение можно читать как "объектно ориентированный взгляд на проблему имеет оверхед по сравнению с функциональным".

А я считаю это мнение заблуждением. Ну, что же поделаешь?

VD>>А каковы тогда критерии отнесения чего-то к ООП или императивному программированию (ИП)? Ведь ООП код может быть функциональным по сути, а может быть императивным. Как же быть?

L>Что такое функциональный ООП? Это использование ОО и функциональщины в одном флаконе? Если да, то нам не о чем спорить.

Тут г. Гапертон выразил мысль, что главное в ФП это "immutability". А используя ООП я могу сделать класс immutable или mutable. Отличный пример реализация класса строк в std::C++ и в Яве. Пользуясь определением Гапертона, я выбирая реализацию класса делаю выбор между императивным и функциональным дизайном. Так?

L>>>Дальше моё мнение о том, почему я считаю этот тезис справедливым.
VD>>А повторяешь его ты потом, что считашь, что другие должны с ним смеритсья? Я вот почему-то с ним не согласен. Причем как раньше, так и сейчас.

L>Из чего ты сделал такой вывод?

Из повторения в неизменном виде одного и того же тезиса.

L>>>За счёт чего создаётся оверхед в ООП? За счёт того, что "о действиях думают как об объектах".
VD>>Я уже говорил, что считаю подобные мысли логической ошибкой и объяснял почему.

L>Объясни еще раз.

А смысл? Чтобы получить еще одно повторения твоих мыслей? Я их уже слышал. Я с ними не согласен. И объяснил почему. Чтобы прочесть это нужно всего лишь подняться на сообщение выше. Хотя я и в этом сообщении не мало сказал. Раз мои аргументы не возымели действие, и твои тоже, то повторяться еще раз смысла нет. Лучше поискать другие аргументы.

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

L>Не вижу разницы

Я вижу. Может дело в стойком нежелении видеть?

VD>>Есть твое заблужедение и очередное подтверждение моего тезиса о том, что краткость опеделяется сахаром, а не используемой парадигмой.

L>Не так. Сахар сокращает код. Из этого не следует, что краткость определяется сахаром.

Изумительно! Прочти свое высказывение еще раз и попытайся объяснить почему оно на твой взгляд не является противоречищим самому себе.

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

Вот, вот.

L> Еще раз — когда я говорю о краткости в контексте "ФП vs ООП", то я имею в виде НЕ краткость кода.

Тогда объясни что дает эту краткость если не сахар вроде клозюров, анонимных и локальных функций, паттерн-матчинга и спец-синтаксиса работы со списками?

L>Ну, вот для тебя же нормальным выражением является "форма выполнила некие действия"?

Доктор, а это плохо? Доктор, может это у вас картинки такие? В мысле искревление мышления на почве передозировки ФП?

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

L>Для этого есть Memento, насколько я помню ОО. А команды — это просто напросто функции.

Ты прлохо помнишь. Для этого команды как раз и существуют. Это пример их ГоФ. В прочем, в этой книге паттерны использовались комплексно.

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

L>Э-э-э, а зачем из-за одного threadID делать объект?

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

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

Никакого оверхэда тут нет.

VD>>Хм. А вот скажем функция Console.ReadLine() тоже по-твоему выражена через объект? Что-то притензия выглядит натянутой.

L>Претензия простая — когда на вещи, на которые проще смотреть как на функции, смотрят как на объекты — я называю это оверхедом,

Глубокая мысль.

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

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

L> потому что мне приходится забивать голову ненеобходимыми (сорри за неудобное слово) вещами.

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

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

L>А ты пытаешься навязать свое высосанное из пальца мнение. И?

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

Особо интересует обоснование того в чем же выражается приемущество ФП если не в сахаре.

L>>>Это ФВП+отсутствие сайд эффектов.
VD>>Ага. Это конечно очень помогает нам в области обработки сообщений, генерации данных и управления потоками.

L>Конечно.

Аргументы? Или в это надо верить?

VD>>Ага. ООП тоже позволяет не представлять. Какое совподение? Правда?

L>Ну что за бред? Влад, может ты не с тем утверждением споришь?

Ты тоже заметил в своих словах бред? И, я. Только боляся тебя обидеть этим наблюдением.

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

VD>>Кстати, ФП позволяет нам выражать объекты через функции. Какая засада!
L>Как это помогает нам в деле сокращения оверхеда?

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

L>>> а сайд-эффект вносит дополнительный вклад в ясность представления.
VD>>Тут у вас неувязочка.

L>(Оглядываясь) Где?

Ты точно читашь что написано? Как побочные эффекты могут вообще вносить ясность?
Ты это бредом не считаешь?

VD>>Невероятная вредоностность сайд-эффектов только одна из них.
L>Покажи, где я это говорил!

А разве ты не об этом говоришь? ОК. Договорились. Так что же такое ФП, если это не отсуствие оных эффектов и не сахар? По-моему, от ФП ничего не осталось.

VD>>Другая — это то что ООП заставляет все думать, что мир состоит из одних объектов.
L>Покажи, где я это говорил!

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

VD>>Надо будет попробовать включить дурака и "повоевать" от обратного. Ну, начать поропагандиски вопить на каждом углу, что сайдэффеты это круть невероятна, так как дают дополниткльную гибкость, а ФП заставляет все думать, что все объекты вокруг — это функции. Думаю реакция будет потрясающая. Хотя вроде бы всего лишь довел до догматизма обратные утвеждения.

L>Которые ты сам же и выдумал?

Ага. Тебе же не мешает смело рассуждать над утверждениями которые ты сам выдумал? А что мне должно помешать? Может я так вижу (с).

L>Нет сайд эффектов — нет состояний. Нет состояний — не надо за ними следить. Не надо за ними следить — голова освобождается еще от одной боли.

У меня один простой конкретный вопрос. Как это устраняет это самый синтаксический оверхэд? Не надо про голову. Про еще какую-то фигню. Я хочу видеть обоснование этого утверждения.

Про упрощение отладки я уже сказл. Так в чем же еще? Дайте его "потрогать руками"!

L>Убедил ты меня своим напором. Уберу я слово ПРОСТО и поставлю ПРОЩЕ

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

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

L>Хотя ты, как я понял, с этим согласен.

Я не то что бы не согласен. Я жду ответов.

L>Т.е. ты считашь, что сайд эффекты добавляют ясность. Или нет, я чего не понял?

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

L>Слушай, Влад, а где это я говорил, что ФП — божественное?

Да ты почитай свои сообщения. "и не только"... "что и не только?"... "освобождение разума"... "как убирает оверхэд"... "нет состояния"... Будда отдыхает.

L> Или хотя бы выразил свое к нему отношение? Может это потому, что ты хочешь считать мою позицию догматом?

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

L>Где я говорил, что меня "унижает, что при этом я не не делаю глубокий взох и не говорю о какой-то потоенной крутизне"?

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

Чесно говоря тезис о сахаре которого я придерживаюсь выработался у меня не так давно и я, конечно могу в нем заблуждаться. Именно по этому мне был интересен этор разговр. Цель его была проверить состоятельность этого тезиса. Но к сожалению этого не получилось. Аргументы "свобода разума" и т.п. — это не аргументы, а НЛП-якори, то есть банальная игра на рефлексах. Но я не из тех у кого рефлексы так сильно развиты. Может бытиь это моя беда. Мне ближе научные методы и доказательства. А вот этого я в упор не вижу.

L>"Не только" что? Если ты про сайд эффекты, то выше — отсутствие сайд эффектов добавляет коду ясность.

Всегда? Серьезно? Что не ясного в этом коде:

form.Top = 100;
form.Left = 200;
form.IsWisible = true;

???

Как его записать без сайд-эффектов, чтобы он стал яснее?

Твои слова — это заклинания. Они ничего ровным счетом не доказывают. Если у тебя при их произнесении автоматически поднимается настроение и хочется думать о хорошем (коде, например), то это всего лишь признак гипноза. Я не был гипнотизирован и потому мне нужны объяснения почему это так. Причем мне не нужны отдельны частные случаи. Мол вот в таком случае это удобно. Это я и так прекрасно понимаю. Но даже в С++ есть ключевое слово const позволяющее делать переменные неизменяемыми. Так что мне нужно обоснование того как отсуствие сайд-эффекта позволит мне сделать код более понятным во всех без исключения случаях!

VD>>Мои разговоры — это выражение моего мнения основанного на том, что я вижу. То что ктому-то проще жить в придуманном мире, а не оперировать фактами я не виноват.

L>Так я полагаю это у всех так. Мир дается нам в ощущениях. А потом приходит другой и говорит, что твой мир придуманный.

В мире есть факты. Вот ты вряд ли будешь спорить, что мы общаемя по Интернету. Это факт. А вот мантры вроде "освободи свой разум" мне больше напоминают фантастический боевик Матрица с ее мантрами воде "ложки нет...".

L>Выразительность ФП (не ФЯ, что ты постоянно переводишь то!) зависит также и от отсутствия сайд эффектов.

Докажи это утверждение. За одно обоснуй почему наличие возможности писать на С++ в функциональном стиле не приводит к значительному повышению выразительности. На оборот порой приводитк к обратному эффекту.

L>Почему я попытался выше объяснить.

Не. Не пытался. Ты пытался применить заклинания, но это не RPG или фэнтази-фильм.

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

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

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

Ну, тода это спор о терминах. И споришь ты скорее с Гапертоном. Хотя хоть убей не могут понять как можно спорить с мнением и соглашаться с ним одновременно.

L>Ну и конечно о том, что это неважно — это код, а я говорю о том, как у нас в голове задача формализуется.

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

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

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

L>>Ты можешь слово сахар заменить чем нибудь?

VD>Могу но это будет очень длинно.

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

L>> Или давай определимся с терминами. Для меня сахар — слово из словосочетания syntactic sugar. Позволяя записывать код короче, он тем не менее не добавляет выразительность программе, т.е. сахар сжимает код, а не мысль.

VD>Слова "сахар сжимает код, а не мысль" ошибочны. Простой пример. Сравни эти два фрагмента кода:
VD>Является ли foreach сахаром? По-моему, несомненно — да.

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

(map display list)

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

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

Так все можно заменить чем угодно. Мы же сравниваем два подхода или как?

L>>С этой точки зрения — ООП ни капли не сахар.
VD>Это ошибочная точка зрения. Не странно что она приводит к совершенно нелогичным выводам.

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

VD>Теперь, внимание, вопрос! А мог ли я писать на С в функциональном стиле? Мне кажется — да. Для этого я только должен был тогда прочесть книгу про ФП и проникнуться его принципами.
VD>Что дал бы мне ФЯ? Он дал бы мне возможность выкинуть паттетры и выражать свои мысли более явно.

Согласен, но разговор я веду о другом. Ты же опять все сводишь только к языкам и коду.

VD>Тут г. Гапертон выразил мысль, что главное в ФП это "immutability". А используя ООП я могу сделать класс immutable или mutable. Отличный пример реализация класса строк в std::C++ и в Яве. Пользуясь определением Гапертона, я выбирая реализацию класса делаю выбор между императивным и функциональным дизайном. Так?

"Главное", я полагаю, это наиболее важное? Тогда не так, потому что кроме наиболее важного могут присутствовать и другие моменты. Кстати, я не считаю отсутствие сайд эффектов наиболее главным. Для меня это скорее пара отсутствие сайд эффектов и ФВП. Причем ФВП даже больше относятся к ФП. Но это субъективный взгляд.

VD>>>А повторяешь его ты потом, что считашь, что другие должны с ним смеритсья? Я вот почему-то с ним не согласен. Причем как раньше, так и сейчас.
L>>Из чего ты сделал такой вывод?
VD>Из повторения в неизменном виде одного и того же тезиса.

И ты обвиняешь меня в нелогичности? :-) Влад ты очередной раз приписываешь мне свои домыслы (о том, что я считаю, что с этим должны другие смириться). Мало того в качестве обоснования ты приводишь очень странные доводы. Ведь исходя из них можно сделать вывод, что и ты свои заключения повторяешь для того, чтобы другие с ними смирились?

L>>Не вижу разницы :-)

VD>Я вижу. Может дело в стойком нежелении видеть? :)

Не знаю. Я всё время думал, что делегат — это объект, я ошибался?

L>>Не так. Сахар сокращает код. Из этого не следует, что краткость определяется сахаром.

VD>Изумительно! Прочти свое высказывение еще раз и попытайся объяснить почему оно на твой взгляд не является противоречищим самому себе.

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

VD>Тогда объясни что дает эту краткость если не сахар вроде клозюров, анонимных и локальных функций, паттерн-матчинга и спец-синтаксиса работы со списками?

ФВП.

L>>Ну, вот для тебя же нормальным выражением является "форма выполнила некие действия"? ;-)

VD>Доктор, а это плохо? Доктор, может это у вас картинки такие? В мысле искревление мышления на почве передозировки ФП? :)

Я должен сказать о передозировке ООП или предложить вспомнить об уважении друг к другу?

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

Напомню, что в Смолтолке реализован паттерн MVC (по крайней мере в том, в котором пишу я). И там не форма выполняет некие действия, а те объекты бизнес модели, которые за эти действия ответственны. Форма же является тем, чем она и должна являться — простым View. Что же касается применения ООП в GUI, то я над этим не смеялся, ты в очередной раз приписываешь мне свои домыслы.

L>>Для этого есть Memento, насколько я помню ОО. А команды — это просто напросто функции.
VD>Ты прлохо помнишь. Для этого команды как раз и существуют. Это пример их ГоФ. В прочем, в этой книге паттерны использовались комплексно.

Значит я ошибался. Тем не менее, если мы возмем библиотеку Struts, то увидим там пример того, о чем мы говорим — использовании объектов, вместо функций. Ну еще есть интерфейс Runnable в Яве. Просто в Яве по другому не выразишь, вот и получаем оверхед по сравнению с исходной мыслью.

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

Я не о том. Задавать приоритеты потокам приходится не часто. А вот просто их запускать для выполнения неких действий — это стандартная практика.

VD>>>Хм. А вот скажем функция Console.ReadLine() тоже по-твоему выражена через объект? Что-то притензия выглядит натянутой.

L>>Претензия простая — когда на вещи, на которые проще смотреть как на функции, смотрят как на объекты — я называю это оверхедом,

VD>Из этих "глубочайших" мыслей следует только одно — предметы лучше использовать по назначению.

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

L>> потому что мне приходится забивать голову ненеобходимыми (сорри за неудобное слово) вещами.

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

Нет, это ошибочное мнение. Из того, что я вижу (и показываю) одно преимущество ФП перед ООП, не значит, что я не вижу преимуществ ООП, а также недостатков ФП.

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

Боже мой, Влад, да для тебя это, оказывается, религиозная война? Дело, конечно, полезное, но бросишься ли ты также рьяно на того, кто заявит о каком нибудь из преимуществ ООП перед ФП? Или весь твой пыл направлен именно на ФП?

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

L>>А ты пытаешься навязать свое высосанное из пальца мнение. И?

VD>Я пытаюсь приводить аргументы. А в ответ вижу только кучи логических ошибок и выдачу совственного мнения (например, о том что выражать поток через объект плохо). Вот когда я увижу хотя бы одно обосновнание подобных утверждений, я не буду говорить по палец.

Не так. В большинстве случаев достаточно представлять поток функцией, тем не менее его представляют объектом. Так пойдет?

VD>Особо интересует обоснование того в чем же выражается приемущество ФП если не в сахаре.
L>>>>Это ФВП+отсутствие сайд эффектов.
VD>>>Ага. Это конечно очень помогает нам в области обработки сообщений, генерации данных и управления потоками. :xz:
L>>Конечно.
VD>Аргументы? Или в это надо верить?

Обработка сообщений — на Яве (как пример ОО-подхода) нам пришлось бы писать много много анонимных классов.
Генерация данных — сравни итератор в ООП и поток в ФП.
Управление потоками — погляди Control.Concurrent в Хаскель. При работе с объектами у нас Thread.currentThread().sleep(5000), если разрешено использовать только функции, то threadDelay 5000. Кстати, при работе с потоками отсутствие сайд эффектов очень помогает.

VD>>>Ага. ООП тоже позволяет не представлять. Какое совподение? Правда? :)
L>>Ну что за бред? Влад, может ты не с тем утверждением споришь?
VD>Ты тоже заметил в своих словах бред? И, я. Только боляся тебя обидеть этим наблюдением. :) Действительно утверждение что ООП кого-то заставляет это форменный пароноидальный бред. Тут я с тобой согласен.

:-) Мой моск расплавлен.

VD>>>Кстати, ФП позволяет нам выражать объекты через функции. Какая засада!
L>>Как это помогает нам в деле сокращения оверхеда?
VD>Никак. О том и речь. Эмуляция объектов на функциях приводит к оверхэду. Как эмуляция замыканий на классах. Но это же ты обосновывашь совое утверждение о том, что ООП само по себе — это оврехэд?!

Не так. (Дернул меня черт высказать что то в пользу ФП, так теперь Влад скажет, что все что не ФП я люто бешено ненавижу).

L>>>> а сайд-эффект вносит дополнительный вклад в ясность представления.
VD>>>Тут у вас неувязочка. :)
L>>(Оглядываясь) Где?
VD>Ты точно читашь что написано? Как побочные эффекты могут вообще вносить ясность?
VD>Ты это бредом не считаешь?

Опечатка.

VD>>>Невероятная вредоностность сайд-эффектов только одна из них.
L>>Покажи, где я это говорил!
VD>А разве ты не об этом говоришь? ОК. Договорились. Так что же такое ФП, если это не отсуствие оных эффектов и не сахар? По-моему, от ФП ничего не осталось.

ФВП.

VD>>>Другая — это то что ООП заставляет все думать, что мир состоит из одних объектов.
L>>Покажи, где я это говорил!
VD>О, как?! Ты и от этого тезиса отказашся? Но ты же говорил об этом несколькими строками выше. Офигеть. Тогда у нас не осталось разногласий. Вот только тезис об оверхэде ООП уже вообще становися призрачным. :)

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

L>>Которые ты сам же и выдумал?
VD>Ага. Тебе же не мешает смело рассуждать над утверждениями которые ты сам выдумал? А что мне должно помешать? Может я так вижу (с).

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

L>>Нет сайд эффектов — нет состояний. Нет состояний — не надо за ними следить. Не надо за ними следить — голова освобождается еще от одной боли.
VD>У меня один простой конкретный вопрос. Как это устраняет это самый синтаксический оверхэд? Не надо про голову. Про еще какую-то фигню. Я хочу видеть обоснование этого утверждения.

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

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

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

L>>Т.е. ты считашь, что сайд эффекты добавляют ясность. Или нет, я чего не понял? :-)

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

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

L>>Слушай, Влад, а где это я говорил, что ФП — божественное?

VD>Да ты почитай свои сообщения. "и не только"... "что и не только?"... "освобождение разума"... "как убирает оверхэд"... "нет состояния"... Будда отдыхает. :)

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

L>> Или хотя бы выразил свое к нему отношение? Может это потому, что ты хочешь считать мою позицию догматом?

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

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

L>>Где я говорил, что меня "унижает, что при этом я не не делаю глубокий взох и не говорю о какой-то потоенной крутизне"?

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

Ну так это твои проблемы :) И еще раз — освободи разум — твои слова — задумайся об этом.

VD>Чесно говоря тезис о сахаре которого я придерживаюсь выработался у меня не так давно и я, конечно могу в нем заблуждаться. Именно по этому мне был интересен этор разговр. Цель его была проверить состоятельность этого тезиса. Но к сожалению этого не получилось. Аргументы "свобода разума" и т.п. — это не аргументы, а НЛП-якори, то есть банальная игра на рефлексах. Но я не из тех у кого рефлексы так сильно развиты. Может бытиь это моя беда. Мне ближе научные методы и доказательства. А вот этого я в упор не вижу.

См. мой ответ выше.

L>>"Не только" что? Если ты про сайд эффекты, то выше — отсутствие сайд эффектов добавляет коду ясность.
VD>Всегда? Серьезно? Что не ясного в этом коде:

Что "всегда"? Конечно не всегда, что ты из меня делаешь максималиста, учись читать то что тебе говорят, а не то, что ты хочешь прочесть.

VD>Как его записать без сайд-эффектов, чтобы он стал яснее?

А смысл?

VD>Твои слова — это заклинания. Они ничего ровным счетом не доказывают. Если у тебя при их произнесении автоматически поднимается настроение и хочется думать о хорошем (коде, например), то это всего лишь признак гипноза. Я не был гипнотизирован и потому мне нужны объяснения почему это так. Причем мне не нужны отдельны частные случаи. Мол вот в таком случае это удобно. Это я и так прекрасно понимаю. Но даже в С++ есть ключевое слово const позволяющее делать переменные неизменяемыми. Так что мне нужно обоснование того как отсуствие сайд-эффекта позволит мне сделать код более понятным во всех без исключения случаях!

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

VD>>>Мои разговоры — это выражение моего мнения основанного на том, что я вижу. То что ктому-то проще жить в придуманном мире, а не оперировать фактами я не виноват. :xz:
L>>Так я полагаю это у всех так. Мир дается нам в ощущениях. А потом приходит другой и говорит, что твой мир придуманный.
VD>В мире есть факты. Вот ты вряд ли будешь спорить, что мы общаемя по Интернету. Это факт. А вот мантры вроде "освободи свой разум" мне больше напоминают фантастический боевик Матрица с ее мантрами воде "ложки нет...".

Ну так не читай эти мантры! Я же не читаю ;-)

L>>Выразительность ФП (не ФЯ, что ты постоянно переводишь то!) зависит также и от отсутствия сайд эффектов.
VD>Докажи это утверждение. За одно обоснуй почему наличие возможности писать на С++ в функциональном стиле не приводит к значительному повышению выразительности. На оборот порой приводитк к обратному эффекту.

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

L>>Почему я попытался выше объяснить.
VD>Не. Не пытался. Ты пытался применить заклинания, но это не RPG или фэнтази-фильм.

Это ты пытался. Сказал какую то чушь про "освободи свой разум", присвоил ее мне и повторил ее много много раз, видимо, чтобы я поверил, что это я сказал.

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

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

VD>Ну, тода это спор о терминах. И споришь ты скорее с Гапертоном. Хотя хоть убей не могут понять как можно спорить с мнением и соглашаться с ним одновременно. :xz:

Здесь не понял поясни с чем это я одновременно согласен и спорю?

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

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

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

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

L>>Выразительность — это ясность передачи мысли, я полагаю.

VD>Ясность — она и есть ясность. Например, i++ ничем не яснее чем i += 1 или i = i + 1, а даже наооборот. А выразительность — это:
VD>

ВЫРАЗИТЕЛЬНЫЙ, -ая, -ое; -лен, -льна. 1. Хорошо выражающий что-н., яркий по своим свойствам, внешнему виду. Выразительная речь. Выразительное лицо. Выразительные глаза. 2. Многозначительный, как бы сообщающий что-н. В. взгляд. Выразительно (нареч.) посмотреть. II сущ. выразительность, -и, ж.

(с) Ожегов.

Да ладно придираться.

выразительный [выразительный] 1) а) Живо, непосредственно отражающий внутреннее состояние человека, его чувства, настроение и т.п. (о лице, глазах и т.п.). б) Ясно, во всей полноте, образно раскрывающий, передающий (мысль, характер и т.п.). в) Намеренно подчеркнутый, содержащий намек на то, что хотят сообщить, передать и т.п. 2) Служащий, предназначенный для выражения чего-л.

И вообще причем тут выразительность сама по себе? Сахар не добавляет выразительности формализму.
В любом случае — сахар не бывает сам по себе, он предоставляет более сладкую возможность для записи кода. Т.е. семантика должна оставаться та же — меняется только синтаксис. a[i] слаще *(a+i). foreach — for.
А вот если мы назовём ФВП сахаром, то по сравнению с чем?!

L>>Применение ФВП же вместо классов относится к выразительности формализма, а не кода.
VD>Применять ФВП можно в С. Но это не выразительно. А сахар в виде замыканий и лямбд делает применение ФВП выразительными. Андестенд?

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

Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь.

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

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

К>>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

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

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

К>> в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

FR>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.
Ну конечно. А приватные переменные "состояния" не указывают на другие объекты? Глядя на публичный интерфейс ты их не видишь, а по ним, возможно, будут запущены вызовы.

Вот тебе и связность.

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

К>>А про замыкание — дак это тот же объект, только вид сбоку (ср. функторы с приватными членами как "замкнутыми" переменными)

FR>Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

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

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

Пастернака не читал, но осуждаю :-)

VD>Такое ощущение что в функциональной программе не может быть объектов.

Это ощущение, наверное, из-за сабжа. Он действительно несколько агрессивен. На самом деле в статье говорится о том, о чём сказал Курилка:

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

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

G>Я имел в виду лексические замыкания. Динамические замыкания — это не ФП. Как и Схема, которую ты привел — полноценный императивный язык.

Возможность изменять переменную определенную локально есть и в ML и в OCaml. Нет такой возможности в чистых языках.

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

К>Ты программируешь основываясь на ощущениях?

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

К>ФП и ООП не противопоставляются и могут существовать, есть же и окамл и клос в лиспе и ещё много чего.

С этой мыслью полностью согласен.

К>Только вот объекты в данном случае получаются зачастую излишни и задача декомпозируется без них.

А с этой не совсем. И вообще, что за зверь "объекты"? Какой-то расплывчатый термин. Например, фраза "first class object" о них говорит?

Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена? Мне кажется, что для некоторых задачь классы отличный выбор. Хотя для других может быть и не лучший. В общем, это зависит от задачи и от требований. Не вижу смысла вообще противопоставлять ООП и ФС.

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

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

LCR>Есть люди, Antonio Vicente унд Earl Wagner, которые написали статью "Design Patterns in OCaml". Но имхо там они подходили к делу слишком буквально, в отрыве от задач, которые решаются с помощью паттернов. (Например, они смастерили клон паттерна Визитор на окамле (исходник на 1.5 страницы), несмотря на наличие паттерн-матчинга в окамле).

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

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

L>Что плохого в пиаре ФЯ?

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

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

L> То, что ты подобное читал много раз?

Что?

L>>>

L>>>Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией

VD>>Мне эти слова кажутся спорными.

L>Что именно?

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

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

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

C>Gaperton wrote:
>> ФЯ с паттерн-матчингом позволяет выполнять другую
>> группировку функционала, снимая ограничения на полиморфизм. Вот в все. В
>> ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.
C>Однако, иногда полиморфизм используется именно для того, чтобы как раз
C>убрать эту группировку. Классический пример — приложение и плугины,
C>взаимодействие с плугинами идет через интерфейсы/абстрактные классы.

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

C>Вероятно поэтому функциональщики предпочитают использовать
C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
C>заменой.

Почему нет?

Говорить про Эрланг — там с компонентностью все более чем в порядке, и ничего больш не нужно. Благодаря, конечно, процессам

— они выполняют роль объектов при крупноблочной декомпозиции системы.

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

Г>Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода, чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.

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

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

T>>"скорее всего всё изменяется согласованно," "если код класса написан правильно," "система правильно декомпозирована."
T>>Три условия должны выполняться одновременно.
T>>Для ФЯ это никуда не девается, но получить получается легче.

FDS>Личное мнение. Бездоказательное.

??? Сергей же подчеркнул, то что сказали Вы — что чтобы получить так как в ФЯ (устранить оверхед) необходимо чтобы выполнялись три условия (да Вы и сами это написали). В ФЯ же их выполнять не надо в силу природы ФП — у него нет переменных, только values. Что тут доказывать и где тут личное мнение?

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

Г>>Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода, чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.

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

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

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

L>Вот ты говоришь — сахар, сахар. ОО — это же тоже сахар, в таком случае. Но одновременно это и способ мышления. Когда я пишу на ОО, я думаю в объектах, когда на ФЯ — в действиях. Поэтому сахар тут не при чём. Дело в том, что (по моему опыту) думать в объектах приходится больше, чем в действиях. И это понятно — Гапертон объяснил почему. А разница в этих двух "думать" и есть оверхед, который создаёт ОО.

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

Так вот его то сахар и убирает. Во многих ООЯ сахара просто недостаточно. От того и выражение мыслей бывает более длинным и запутанным.

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

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

).

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

Я считаю, что пропагандируемем выразительность ФП в основном основывается на сахаре добавленном в ФЯ. Так я бы выделил:
1. Сопоставление с образцом (сахар для if-ов и switch-ей).
2. Алгеброические типы (сахар для классов).
3. Спец.синтаксис (сахар для работы со списками, строками, и т.п.).
4. Операции над функциями (частичное применение, локальные функции, лямбды).

Вроде ничего не забыл. Вот эти составляющие и опеделяют выразительность. А сказки про то что изменение переменных ужасно усложняет программу, они и есть сказки. Я не испытвал проблем с этим в C# нигогда. Достаточно было выполнять несколько простых правил и проблема исчезала сама собой.

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

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

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

G>Почему нет?

— они выполняют роль объектов при крупноблочной декомпозиции системы.

Вывод. Эрланг — это ООП глазами функционального программиста.

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

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

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

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

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

VladD2 wrote:
> C>Для некоторых — да. Но многие паттерны (типа визитора или прокси)
> Вот как раз Посетитель то становится довольно бессмысленным при наличии
> паттерн-матчинага и алгеброических типов. Что-то ни в одном языке с
> этими фичами Посетителей не видать.
Визитор нужен для разделения обхода и обработки. Например, FR приводил
пример с обходом AST в Питоне. Без визитора был бы длииииииииииинный
метод, а так его можно просто разбить на разные классы.

Posted via RSDN NNTP Server 2.0

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

VD>ФП и ООП могут выражаться друг через друга
Нет.

VD>а стало быть легко могут сосуществовать в рамках одной модели и даже одного языка.
Да.

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

L>>Ты можешь что нибудь предложить?

VD>Любые задачи эмуляции чего-то с сотоянием. Особенно если требуется получить быстрое решение с малым расходом памяти.

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

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

G>Да лана тебе. Все равно Ифы и Свитчи — сахар для команд JNZ и JZ, а функции — сахар для инструкций CALL и RET.

На современных x86 они тоже сахар для RISC микрокодов

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

L>Тут проблема точно такая же как в паттерне Visitor — при расширении типа данных приходится проходить по всем посетителям.

Угу про это и речь.
Да и еще это у тебя в хаскеле несколько функций(хотя логически она тоже одна) а ML и Nemerle будет одна, тут уже в философии прошлись по поводу размеров таких функций

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

FR>Да и еще это у тебя в хаскеле несколько функций(хотя логически она тоже одна) а ML и Nemerle будет одна, тут уже в философии прошлись по поводу размеров таких функций :)

Это общая проблема switch'ей — они имеет тенденцию распухать.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>1. Сопоставление с образцом (сахар для if-ов и switch-ей).

ANS>Это ниразу не сахар для if-ов и switch-ей

Твои знания потрясают.

VD>>2. Алгеброические типы (сахар для классов).

ANS>Ни разу не сахар для классов.

Опять же.

ЗЫ

Целяйся сильнее за свой Смолток. Это то что нужно для того чтобы отстать на век.

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

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

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

L>Треды — это потоки (Thread), которые почему то представляют опять же объектами, чем не оверхед?

Оверхед это когда затраты есть, а выгод нету. А это не оверхед, а плата за доп.удобства.

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

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

К>Это ты говоришь о монадах, реализующих последовательный конвеер (IO, State и т.п.)
К>Но есть ещё и монады-множества — список, Maybe, Either и т.д., позволяющие компактно выражать функции над множеством через функции над элементами.

Это просто категорийская ересь. Все прекрасно выражается и без всяких монад.

Gaperton wrote:

> Дык, я на самом деле не о монадах вообще, а об их применении для эмуляции императивных фич. Как-то — ООП и состояний. Ну и тем более — у меня не было даже в мыслях отбирать у вас соху, т.е. монады

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

В красноречии тебе, уважаемый Гапертон, не откажешь.
Но речь уже не только об императивных фичах, т.к. ув. тов. Кодт упомянул
Maybe, Either и List, а ув. тов. Трурль все предал анафеме, причем в
обычной своей лаконичной манере. А остальным только гадать остается —
как так выражается, почему ересь? Мне казалось, что наоборот, через
монады можно выразить много чего. В общем, не мешало бы мысль прояснить.

Posted via RSDN NNTP Server 2.0

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

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

FR>>А он понавыводит конечно в ленивых языках

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

Ну а они-то проблему решили, по своему, а то что это тебе не нравится твои проблемы

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

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

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

L>Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь.
Легко.
Неммерле

foo () : void
{
    def i = 234;
    def addI = _ + i;
    def x = addI(123);
}

А теперь тоже самое без замыканий

private sealed class _N_closure1425
{
    internal _N_closure1425()
    {
    }
    internal int _N_i1430;
}
private sealed class _N__N_l1189_1438 : Function<int, int>
{
    public _N__N_l1189_1438(Test._N_closure1425 _N_foo_clo1442)
    {
        this._N_foo_clo1442 = _N_foo_clo1442;
    }
    public override int apply(int _N_1437)
    {
        return (_N_1437 + this._N_foo_clo1442._N_i1430);
    }
    private Test._N_closure1425 _N_foo_clo1442;
}
private static void foo()
{
    Test._N_closure1425 _closure1 = new Test._N_closure1425();
    _closure1._N_i1430 = 0xea;
    Function<int, int> function1 = new Test._N__N_l1189_1438(_closure1);
    function1.apply(0x7b);
}

(C)Reflector
Могу повторить все тоже самое на чистых сях. Только это будет выглядить еще страшнее.

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

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

А>Извините, что вмешиваюсь, но i++ не является эквивалентом ни i+=1, ни i=i+1. Это лаконичная запись: (t=i;i+=1;t). Поэтому нельзя сравнивать "ясность" i++ и i+=1. А вот ++i действительно эквивалентна i+=1 и i=i+1, но и ясность этих трех записей одинаковая.

Это очень ценное замечание проясняющее суть проблемы.

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

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

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

IT>А если будет что-то посложнее такой примитивщины и компилятор не сможет её заинлайнить?

Компилятору в данном случае плевать на сложность, так как VM напрямую подерживает такую сущность как closure.

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

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

FR>>Вроде просили показать как сделать лямбду,

VD>Просили функции высшего порядка. Они в С есть штатно. Называются указатели на функции. Так что тут и показывать нечего.

Нет просили показать лямбду в виде сахара.

VD>А показал он реализацию замыканий и вложенных фунций на базе классов. То что кто-то не хочет это понимать — это проблемы его личного мозга.

Угу, а тут Re[31]: ФП против ООП таже самая реализация на x86 ассемблере (хороший компилятор у окамла, оптимизирующий

) если кто-то видит между этими реализациями большую разницу у того тоже проблемы с пониманием

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

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

L>>Неа, он принимает не функцию, а объект, который эмулирует функцию, и возвращает тоже объект.
L>>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий

VD>На C/С++ устроит?

Это не замыкание, нет захвата свободных переменных.

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

VD>А показал он реализацию замыканий и вложенных фунций на базе классов.

А на фига это показывать???

VD>То что кто-то не хочет это понимать — это проблемы его личного мозга.

Вот именно

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

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

L>>А на фига это показывать???

VD>Чтобы ты видил, что они легко выражаются с помощью паттернов в ООЯ.
VD>А раз так, то нет проблем добавить подобный сахар в любой ООЯ. Единственная серьезная проблема — это время жизни. Тут лучше иметь в языке GC.

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

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

FR>>нет захвата свободных переменных.

VD>А кто-то просил замыкания? Просили ФВП. Если у тебя снова проблемы с терминологией, то я тут не причем.

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

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

FR>Фвп не интерсно, они и так в си есть.
FR>Надо подождать автора, я судил по этой его строке
FR>

FR>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий

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

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

IT>В этом нет абсолютно никакой необходимости. Лучше направить усилия на оптимизацию работы джита, который в результате может от объектов и следа не оставить.

Может и так, но об этом пусть у ms голова болит.
Просто уже смешно смотреть на эти "доказательства" сахарности из рефлектора.

FR>>>>Ты про ссылки слышал?
IT>>>Ссылки куда?
FR>>На переменые. Точнее так на каждую связываю переменную формируется так называемая ячейка которая и содержит эту переменную, func_closure это список (вернее tuple) всех исползуемых в замыкании ячеек:

IT>Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?

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

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

FR>Просто уже смешно смотреть на эти "доказательства" сахарности из рефлектора.

Так оно так и есть. Есть только одна принципиальная вещь, которая не позволяет сделать полноценное замыкание — это отсутствие GC. Всё остальное детали реализации, которые безусловно интересны с позновательной точки зрения, но на саму концепцию не влияют никак.

IT>>Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?

FR>А ничего что список практически состоит из указателей на переменные? (cell это указатель который позволяет ссылатся на переменные из чужой области).

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

FR>И еще не понятно что будет больше один объект с полями или список указателей.

А ты сам подумай

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

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

FR>>>нет захвата свободных переменных.

VD>>А кто-то просил замыкания? Просили ФВП. Если у тебя снова проблемы с терминологией, то я тут не причем.

L>Не просил я ничего эмулировать. Я просил показать, что ФВП сахар.

Зачем? Я тебе показал, что ФВП есть в любом языке. Так что можно не обсуждат сахар они или нет. Для ассемблера они сахар. Для любого языка начиная с С встроенная возможноть.

L> Или замыкания. Или лямбды.

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

L>Вы показали, что их можно сэмулировать. Поздравляю!

Их можно вырзить другими средствами языка. Никакой эмуляции.

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

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

IT>Так оно так и есть. Есть только одна принципиальная вещь, которая не позволяет сделать полноценное замыкание — это отсутствие GC. Всё остальное детали реализации, которые безусловно интересны с позновательной точки зрения, но на саму концепцию не влияют никак.

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

IT>>>Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?

FR>>А ничего что список практически состоит из указателей на переменные? (cell это указатель который позволяет ссылатся на переменные из чужой области).

IT>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?

На питоне да, в ocamle нет. Я уже приводил ассемблерный код в который вырождается простое замыкание на окамле.

FR>>И еще не понятно что будет больше один объект с полями или список указателей.

IT>А ты сам подумай

Лучше ты когда думаешь снимай NET'овые очки

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

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

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

FR>>forth, fortran, старый паскаль, бейсик?

VD>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?

А у тебя?

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

FR>>То есть мы наконец нашли единственную несахарную конструкцию?
FR>>Удивительное открытие, может разъяснишь?

IT>Да вроде тут уже обсуждали. Например, на C++ полноценные замыкания невозможно сделать из-за отсутствия контроля времени жизни объектов самим рантаймом.

Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).
Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.

IT>Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?

Только тем что реализовать можно по разному, даже в NET при желании можно сделать не через объекты, а как в окамле или питоне. И поэтому код из рефлектора никак ни катит в качестве доказательства того что те же замыкания являются синтаксическим сахаром.

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

IT>>Да вроде тут уже обсуждали. Например, на C++ полноценные замыкания невозможно сделать из-за отсутствия контроля времени жизни объектов самим рантаймом.

FR>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).

Ключевое слово я выделил. Смысл в том, что без стопроцентной поддержки со стороны runtime — это всё только разговоры. Мне достаточно вернуть не объект функтор, а указатель на него и вся твоя стройная теория рассыпется.

FR>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.

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

IT>>Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?

FR>Только тем что реализовать можно по разному, даже в NET при желании можно сделать не через объекты, а как в окамле или питоне. И поэтому код из рефлектора никак ни катит в качестве доказательства того что те же замыкания являются синтаксическим сахаром.

Код из рефлектора не просто не "не катит", он явно и наглядно демонстрирует, что это всё сахар. Не видеть этого нужно очень очень сильно хотеть. Вот примерно как ты

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

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

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

FR>>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).
FR>>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.

VD>Минус за это.

Зря, если бы в C++ указатели на функции были объектами то эмуляция на них замыканий быда бы идентична шарповой.

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

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

FR>>С этим можно согласится, но здесь утверждают что всё (кажется кроме GC это похоже некая священная корова) сахар.

VD>Все относительно. Для языка вроде ассемблера сахаром будет почти что угодно. А для С, например, уже нет.

Нет сахар это только косметика.

VD>В общем, можешь называть это как угодно. Можешь фичами, можешь сахаром, можешь трехэтажным словосочетанием. Главное смысл. А смысл в том, что у ООП или ФЯ нет и не может быть оверхэда так как это паттерны. Нет реализации этих паттернов в языке и писать в этом стиле становится громоздко и неуклюже. Есть — и все становится куда лушче. Использовать возможности языка не по назначеню можно независимости от того ООЯ он или ФЯ. Каждый из типов языков хорош в одном и плох в другом.

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

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

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

VD>>>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?

FR>>А у тебя?

VD>Месье блюдет национальные традиции или отвечая вопросом на вопрос он пытается уйти от ответа?

Нет, к сожалению не являюсь представителем этой многоуважаемой нации

Кстати задавая этот вопрос ты занимался именно уходом от ответа

Вообще пора закруглятся.

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

IT>>Ключевое слово я выделил. Смысл в том, что без стопроцентной поддержки со стороны runtime — это всё только разговоры. Мне достаточно вернуть не объект функтор, а указатель на него и вся твоя стройная теория рассыпется.

FR>А ты не возвращай указатель. И то что все рассыплется это нормально для C++

Это нормально для C++, но не нормально для FP.

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

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

VD>>Ты постоянно говоря о лябдах но аппелировал к ФВП.

L>Покажи, пожалуйста, хоть одно место.

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

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

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

L>>Я тоже. Но ты начинаешь развешивать ярлыки.

VD>Погоди. А кто о мифическом ООП-оверхэде говорил? Я?

Это ты говорил о мифическом, я говорил о реальном.

VD>>>Это ты тут доказываешь какой-то выдуманный оверхэд ООП.

L>>Да, ОО более многословен. Он использует больше сущностей.

VD>Значит таки подсаживлася.

Твоя логика меня поражает.

VD>>>А я просто использую ООП там где от него есть реальная польза.

L>>Аналогично. Может я на ОО тоже подсел?

VD>А ты его используешь? Это видимо из-за того что он более многословный, а вам за количество символо платят. Да?

Использую. Не из-за этого. За количество не платят.
Еще версии?

L>>Да и с твоим определением сахара вроде разобрались, чего уж там дальше?

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

Ты хочешь еще поговорить об этом? Зачем? Я уже понял, что любое расширение сахар.

VD>Мы тут с полностью мифически ОО-оверхэдом разобраться то не можем.

А зачем вы там с чем то мифическим разбираетесь? То с мифическим оверхедом, то с мифическим сахаром (кстати, так твой сахар буду называть, чтобы отличать). С реальным разбирайтесь.

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

L>Ну так ты убедился, что когда я говорил об ФВП, я говорил об ФВП или нет?

Я убедился, что с догмами спорить безсполезно. Одна сменяет другую.

Если же ты говорил о ФВП, то твои слва лишены всяческого смысла, так как ФВП по определению есть в большинстве языков.

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

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

G>>Давно пора. А то весь форум ерундой какой-то загадили — за флудом полезные сообщения найти невозможно. Разборки с Владом переносим в философию, ок? А если честно — я вообще не понимаю, зачем и с какой целью вы отвечаете на всякую ерунду. Что-то новое для себя узнать хотите? Или интересно очень?

L>ХЗ. Утром пришел, смотрю — мне Влад что то написал, ну я ему и ответил, он, наверное, так же поступает

Это потому что желание общаться превыше желания выделить истину

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

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

Итого: а зачем, собственно, мы обсуждаем — "ФП относительно ООП"?

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

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

). И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N), в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

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

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

Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны (

не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП

.

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

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

FDS>

.

В том и дело что никто ничему не должен в обычных ООЯ, императивных...
Ключевой момент проскакивал недавно в твоём обсуждении Немерле с Владом, где он тебе показывал, что mutable это не есть гуд с точки зрения масштабируемости, зависимостей и т.д.
В ФП если ты знаешь функцию и параметры, то результат функции (если она не имеет побочных действий) будет одним и тем же и в 1-й и в 1000-й вызов её. Методы же в ООП оперируют над объектами, которые содержат их состояния, поэтому для одного и того же результата тебе необходимо чтобы состояния ВСЕХ объектов, участвующих в методе было точно таким же.
Или вот пример (не ругай за его глупость, но первое, что в голову пришло):

class Counter{
 private int i = 0;
 public void Inc() { i++; }
 public int Get() { return i;}
}

class A{
  private Counter myCounter = new Counter();
  private void SomeSuperFunc();
  public GetMySuperInt() { 
    // тут совершается что-то после чего надо счётчик увеличить
    SomeSuperFunc();
    myCounter.Inc(); 
    return myCounterGet(); 
  }
}

Причём тут вообще метод без параметров, только внутреннее состояние. Что тут несогласовано? И сравни что произойдёт при первом вызове и при следующем метода A::GetMySuperInt() одного и того же объекта.
Это пример чуть надуманый, но ООП поощеряет вот такие конструкции, когда состояние прячется внутрь и появляются зависимости по состоянию.
При функциональном подходе композиция была бы проделана иначе (счётчик был бы вынесен из класса, но зачем, если он чётко связан с объектом класса A, скажут апологеты ООП?), можно и на ООП языке сделать такую декомпозицию, но тогда все ООП особенности будут уже не в тему.

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

Кто тебе это сказал?

И в блоге есть примеры, кто захочет, тот запросто найдёт.

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

FR>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.

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

)

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

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

FR>>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.

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

На связность это не влияет.

К>А про публичный интерфейс — хоть он запубличный будет, но в любом случае у тебя всё поведение объекта определяется его состоянием, которое как раз на приватных полях основано (в общем случае, хотя не обязательно

)

Поведение да, но связность

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

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

FDS>>

.

К>В том и дело что никто ничему не должен в обычных ООЯ, императивных...
К>Ключевой момент проскакивал недавно в твоём обсуждении Немерле с Владом, где он тебе показывал, что mutable это не есть гуд с точки зрения масштабируемости, зависимостей и т.д.
К>В ФП если ты знаешь функцию и параметры, то результат функции (если она не имеет побочных действий) будет одним и тем же и в 1-й и в 1000-й вызов её. Методы же в ООП оперируют над объектами, которые содержат их состояния, поэтому для одного и того же результата тебе необходимо чтобы состояния ВСЕХ объектов, участвующих в методе было точно таким же.

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

FDS>

.

"скорее всего всё изменяется согласованно," "если код класса написан правильно," "система правильно декомпозирована."

Три условия должны выполняться одновременно.

Для ФЯ это никуда не девается, но получить получается легче.

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

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

Кстати, вот ОКамл — это ФЯ или ООЯ?

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

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

Цитируй по меньше, пожалуйста.

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

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

G>Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

class Point
{
    public Point(int x, int y)
    {
        X = x;
        Y= y;
    }
    
    public Point Offset(int xOffset, int yOffset)
    {
        Point(x + xOffset, y + xOffset)
    }
    
    public readonly int X;
    public readonly int Y;
}

...

Point pt = new Point(1, 3);
Point pt2 = pt.Offset(1, 0);

Внимание, вопрос! Point не объект?

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

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

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

G>Это запросто. Только контекст замыкания не может изменяться, так что нам пофиг, есть замыкание в параметрах, или его нет. Это совершенно все равно. Другое дело, что параметром может припереть функция высшего порядка, которая возвращает функцию высшего порядка, которая... потом будет передана параметром в другую функцию высшего порядка. И так несколько раз.

Изменятся не может но тянуть вызовов и ссылок может не меньше чем объект.

К>>> в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

FR>>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.
G>Ну конечно. А приватные переменные "состояния" не указывают на другие объекты? Глядя на публичный интерфейс ты их не видишь, а по ним, возможно, будут запущены вызовы.

Вот тебе и связность.

Это не связность, а граф вызовов

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

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

FR>>>Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

G>>Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

FR>В чистой функциональщине да сосотояния нет, но в том же лиспе (и императивщине с замыканиями) очень похоже на объект.
FR>Да и в ЧФ замыкание также как и объект может служить черным ящиком поведение которого зависит от начальных данных.

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

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

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

Излишнее цитирование удалено.

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

А как же пример Пола Грехема про аккумулятор? Где как раз у него в замыкании этот счётчик и содержится

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

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

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

VD>Статью пока не читал, но с твоих слов выглядит что статья очередной бред.
Как-то даже отвечать особо на такое не хочется...
Но коли начал

VD>Такое ощущение что в функциональной программе не может быть объектов.
Ты программируешь основываясь на ощущениях?

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

Gaperton wrote:
>Объект характеризуется наличием mutable state...
> <skipped>
> Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
???
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html#%_sec_3.1.1

(define (make-account balance)
  (define (withdraw amount)
    (if (>;= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        "Insufficient funds"))
  (define (deposit amount)
    (set! balance (+ balance amount))
    balance)
  (define (dispatch m)
    (cond ((eq? m 'withdraw) withdraw)
          ((eq? m 'deposit) deposit)
          (else (error "Unknown request -- MAKE-ACCOUNT"
                       m))))
  dispatch)

И на Яваскрипте, AFAIK, объекты эмулируют точно так же.

Posted via RSDN NNTP Server 2.0

Gaperton wrote:
> Функциональщина или не функциональщина тут не причем. Объект
> характеризуется наличием *изменяемого состояния*, и абстрактным
> интерфейсом доступа, т.е. состояние "спрятано".
Вообще говоря, это необязательно. Никто не мешает делать объекты
иммутабельными, мутирующие функции просто будут возвращать новые объекты
(как со строками в .NET/Java).

Posted via RSDN NNTP Server 2.0

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

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

К>А как же пример Пола Грехема про аккумулятор? Где как раз у него в замыкании этот счётчик и содержится

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

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

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

Тут Re[5]: ФП против ООП Влад уже привел пример когда у объекта нет изменяемого состояния.

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

Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код:

(define x 0)

(define (f) (lambda (y) (+ x y)))

(display ((f) 3))
(display "\n")  

(set! x 10)

(display ((f) 3))
(display "\n")

Выведет
3
13

Развить из этого полноценные объекты несложно. (В CLisp они вроде так и делаются)

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

C>Gaperton wrote:
>> Функциональщина или не функциональщина тут не причем. Объект
>> характеризуется наличием *изменяемого состояния*, и абстрактным
>> интерфейсом доступа, т.е. состояние "спрятано".
C>Вообще говоря, это необязательно. Никто не мешает делать объекты
C>иммутабельными, мутирующие функции просто будут возвращать новые объекты
C>(как со строками в .NET/Java).

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

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

PA>Gaperton wrote:
>>Объект характеризуется наличием mutable state...
>> <skipped>
>> Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
PA>???
Я имел в виду лексические замыкания. Динамические замыкания — это не ФП. Как и Схема, которую ты привел — полноценный императивный язык.

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

G>Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.

Ммм, можно про "динамическое" поподробней, ссылочку или ещё что — что-то не помню подобных классификации замыканий.

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

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

G>>Я имел в виду лексические замыкания. Динамические замыкания — это не ФП. Как и Схема, которую ты привел — полноценный императивный язык.

Q>Возможность изменять переменную определенную локально есть и в ML и в OCaml. Нет такой возможности в чистых языках.

В Эрланге, о котором и говорил автор статьи, такой возможности нет. Эта возможность — императивна, это не ФП, глупо ее противопоставлять ОО, и не важно, присутствует она в языках или нет. Что вы мне все тут доказать хотите?

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

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

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

FR>Тут Re[5]: ФП против ООП Влад уже привел пример когда у объекта нет изменяемого состояния.

Чего тут не понятного. Это не объект. На таких "объектах" ты не сделаешь объектную декомпозицию, у тебя ссылки поплывут сразу. Попробуй посмотреть, что произойдет с кольцевыми ссылками при попытке "изменить" состояние такого объекта — у него нет identity.

Господи, объясните ему кто-нибудь.

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

FR>Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код:
ЛЕКСИЧЕСКИЕ замыкания. Динамические — это НЕ ФП. Мы тут статью обсуждаем, или языками чешем? Нет в Эрланге диамических замыканий.

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

G>>Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.

К>Ммм, можно про "динамическое" поподробней, ссылочку или ещё что — что-то не помню подобных классификации замыканий.

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

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

FR>>Тут Re[5]: ФП против ООП Влад уже привел пример когда у объекта нет изменяемого состояния.

G>Чего тут не понятного. Это не объект. На таких "объектах" ты не сделаешь объектную декомпозицию, у тебя ссылки поплывут сразу. Попробуй посмотреть, что произойдет с кольцевыми ссылками при попытке "изменить" состояние такого объекта — у него нет identity.

G>Господи, объясните ему кто-нибудь.

Лучше дай правильное по твоему определение объекта.

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

FR>>Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код:
G>ЛЕКСИЧЕСКИЕ замыкания. Динамические — это НЕ ФП. Мы тут статью обсуждаем, или языками чешем? Нет в Эрланге диамических замыканий.

Ну тема же не про эрланг а "ФП против ООП", а ты ее сузил до "чистый ФП против ООП"

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

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

G>>>Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.

К>>Ммм, можно про "динамическое" поподробней, ссылочку или ещё что — что-то не помню подобных классификации замыканий.

FR>В замыкании может быть статическое или динамическое связывание. При статическом всегда захватывается значение переменных в момент определения замыкания, при динамическом связывание происходит в момент использования. Тут пример динамического связывания на схеме

По-моему лексическое, а не статическое. Так в CL scope лексический, хотя есть динамически связываемые переменные (которые special)

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

FR>Ну тема же не про эрланг а "ФП против ООП", а ты ее сузил до "чистый ФП против ООП"

Ну вообще-то началось всё как раз с эрланга, про который Ярив писал

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

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

FR>>Ну тема же не про эрланг а "ФП против ООП", а ты ее сузил до "чистый ФП против ООП"

К>Ну вообще-то началось всё как раз с эрланга, про который Ярив писал

Ну значит ты дал некорректное имя теме

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

FR>>В замыкании может быть статическое или динамическое связывание. При статическом всегда захватывается значение переменных в момент определения замыкания, при динамическом связывание происходит в момент использования. Тут пример динамического связывания на схеме

К>По-моему лексическое, а не статическое. Так в CL scope лексический, хотя есть динамически связываемые переменные (которые special)

Филд с Харрисоном обзывают статическим.

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

C>Не знаю как проще объяснить — вероятно придется писать статью

Было бы интересно почитать

Курилка wrote:
> C>Не знаю как проще объяснить — вероятно придется писать статью
> Было бы интересно почитать
Я уже должен одну статью в форум про Java написать

Так что буду
заниматься во время отпуска.

Оффтоп: а кто-нибудь будет на RSDN Event в СПб?

Posted via RSDN NNTP Server 2.0

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

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

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

L>Пастернака не читал, но осуждаю

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

"Пастернака" тоже прочу, но позже. Вот только вышел на работу после отпуска. Надо дела разгребать.

L>

L>Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией

Мне эти слова кажутся спорными.

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

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

C>Громоздко, но возможно.
Ай-ай-ай.
1) А чего это ты к приватному состоянию B из класса A лезешь?

Инкапсуляцию нарушаем? Нехорошо!
2) Ты забыл из нутра метода mutate_something вызвать подобный метод класса В. Вот тут самое интересное начнется, а ты это заинтересованной общественности не показал.

Особенно прикольно будет, когда ты третий, четвертый класс добавишь, и все они друг друга по ассоциациям дергать начнут за методы mutate some shit. Повеселимся?

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

К>[flame]
К>О! Кстати! Почему об этом ещё молчат?
Да я вообще считаю — доколе?!!!

Gaperton wrote:
> C>Громоздко, но возможно.
> Ай-ай-ай.
> 1) А чего это ты к приватному состоянию B из класса A лезешь?
> Инкапсуляцию нарушаем? Нехорошо!
Детали, считай это просто частью конструирования объекта.

> 2) Ты забыл из нутра метода mutate_something вызвать подобный метод
> класса В. Вот тут самое интересное начнется, а ты это заинтересованной
> общественности не показал.
Да без проблем — сначала получаем измененный объект A в связке с B.
Дергаем метод у B и получаем еще одну новую связку A-B и возвращаем из
нее объект A в качестве результата.

> Особенно прикольно будет, когда ты третий, четвертый класс добавишь, и
> все они друг друга по ассоциациям дергать начнут за методы mutate some
> shit. Повеселимся?
Для большей сложности, естественно, нужен общий механизм (чтобы все это
не писать каждый раз).

Posted via RSDN NNTP Server 2.0

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

Цитируй меньше.

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

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

L>>Пастернака не читал, но осуждаю :-)

VD>Сочувствую тебе, но Пастернак тут не причем. Изложенное Курилкой вообще характерно для пиара ФЯ. И читал я подобные вещи много раз.

Что плохого в пиаре ФЯ? То, что ты подобное читал много раз?

VD>"Пастернака" тоже прочу, но позже. Вот только вышел на работу после отпуска. Надо дела разгребать.

Аналогично :-(

L>>

L>>Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией

VD>Мне эти слова кажутся спорными.

Что именно?

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

>> 1) А чего это ты к приватному состоянию B из класса A лезешь?
>> Инкапсуляцию нарушаем? Нехорошо!
C>Детали, считай это просто частью конструирования объекта.
Ок, это придирки, согласен.

>> 2) Ты забыл из нутра метода mutate_something вызвать подобный метод
>> класса В. Вот тут самое интересное начнется, а ты это заинтересованной
>> общественности не показал.
C>Да без проблем — сначала получаем измененный объект A в связке с B.
C>Дергаем метод у B и получаем еще одну новую связку A-B и возвращаем из
C>нее объект A в качестве результата.

А что произойдет с указателем на объект B из объекта С?

И с указателем на объект А из объекта D? Они будут указывать на старый объект, не измененный — не так ли?

>> Особенно прикольно будет, когда ты третий, четвертый класс добавишь, и
>> все они друг друга по ассоциациям дергать начнут за методы mutate some
>> shit. Повеселимся?
C>Для большей сложности, естественно, нужен общий механизм (чтобы все это
C>не писать каждый раз).

Да не сделаешь ты такой механизм. Нельзя его сделать в общем случае.

lomeo,

VD>>Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена?

L>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.

Классная идея.

Есть люди, Antonio Vicente унд Earl Wagner, которые написали статью "Design Patterns in OCaml". Но имхо там они подходили к делу слишком буквально, в отрыве от задач, которые решаются с помощью паттернов. (Например, они смастерили клон паттерна Визитор на окамле (исходник на 1.5 страницы), несмотря на наличие паттерн-матчинга в окамле).

Ссылки у меня к сож. нет, осталась распечатка только.

Gaperton wrote:
> ФЯ с паттерн-матчингом позволяет выполнять другую
> группировку функционала, снимая ограничения на полиморфизм. Вот в все. В
> ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.
Однако, иногда полиморфизм используется именно для того, чтобы как раз
убрать эту группировку. Классический пример — приложение и плугины,
взаимодействие с плугинами идет через интерфейсы/абстрактные классы.

Вероятно поэтому функциональщики предпочитают использовать
message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
заменой.

Posted via RSDN NNTP Server 2.0

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

C>Однако, иногда полиморфизм используется именно для того, чтобы как раз
C>убрать эту группировку. Классический пример — приложение и плугины,
C>взаимодействие с плугинами идет через интерфейсы/абстрактные классы.

C>Вероятно поэтому функциональщики предпочитают использовать
C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
C>заменой.

В Haskell есть классы типов, в ML — функторы.

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

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

VD>>Давай уж конкретно. Тебе не нравятся классы? В ФЯ есть им полноценная замена?

L>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.

Слушай, думал-думал, но так и не понял, что за ФВП? Функциональное что?

граммофон wrote:
> C>Вероятно поэтому функциональщики предпочитают использовать
> C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
> C>заменой.
> В Haskell есть классы типов, в ML — функторы.
Вот если ты на них будешь пытаться сделать то, что описывается в GoF —
то получишь примерно такое же, что и в GoF (за некоторыми исключениями).
Потому как паттерны в GoF — это скорее руководство по тому как
использовать полиморфизм.

Posted via RSDN NNTP Server 2.0

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

L>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.

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

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

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

G>Вот это смотрел? Здесь, насколько я помню, о том, что в языках Lisp и Dylan большинство паттернов GoF невидимо или тривиально.
G>http://www.norvig.com/design-patterns/

Спасибо! Супер...

G>Однако, там упор на динамические свойства языков. В функциональных языках будет примерно то же самое, даже в строготипизированных, благодаря pattern-matching. Основная причина появления "паттернов" в ООП состоит в ограниченности динамического полиморфизма в модели ОО — вызов диспетчеризуется только по одному аргументу (this). Это заставляет в мало-мальски сложном случае городить лес из классов, размазывая по ним функционал. ФЯ с паттерн-матчингом позволяет выполнять другую группировку функционала, снимая ограничения на полиморфизм. Вот в все. В ФЯ практически нет паттернов в смысле GoF — там все делается прямолинейно.

Хотел собрать всё это в одном месте, для демонстрации (пиара ФП по VladD2)

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

К>Слушай, думал-думал, но так и не понял, что за ФВП? Функциональное что?

функции высшего порядка, сорри.

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

L>>Кстати, всё давно хочу написать как ООП решения, типа GoF паттернов решаются без классов с помощью ФВП.

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

Я не особенно сравнивал ещё ОО и ФП, чтобы их противопоставлять :-(
Поэтому мне интересно было бы поискать такие задачи, которые решаются с помощью классов лучше, чем в ФП.

Ты можешь что нибудь предложить?

граммофон wrote:
> C>Вот если ты на них будешь пытаться сделать то, что описывается в GoF —
> C>то получишь примерно такое же, что и в GoF (за некоторыми исключениями).
> C>Потому как паттерны в GoF — это скорее руководство по тому как
> C>использовать полиморфизм.
> Изначально речь шла о том, что для большинства GoF-паттернов не нужны ни
> классы, ни перегрузки, ни функторов. Достаточно алгебраических типов и
> паттерн-матчинга.
Для некоторых — да. Но многие паттерны (типа визитора или прокси)
специально задумывались, чтобы можно было распределять код.

Точно так же ведь можно и обычные виртуальные функции заменить switch'ем
(как частный случай pattern-matching'а). Но вот проблема в том, что
виртуальные функции как раз придумали чтобы заменить switch

Posted via RSDN NNTP Server 2.0

Курилка,

К>Слушай, думал-думал, но так и не понял, что за ФВП? Функциональное что?

Функции Высшего Порядка = HOF = Higher Order Functions

Кодт wrote:
> C>Вероятно поэтому функциональщики предпочитают использовать
> message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
> заменой.
> Так ведь и полиморфизм сделать — не есть большая сложность. Тип
> интерфейса — кортеж сигнатур функций. Реализация — замыкания функций на
> общую структуру данных.
Просто при использовании такого полиморфизма получим тот же GoF.
Собственно, именно это я и пытаюсь сказать.

Posted via RSDN NNTP Server 2.0

Gaperton wrote:
> C>Однако, иногда полиморфизм используется именно для того, чтобы как раз
> C>убрать эту группировку. Классический пример — приложение и плугины,
> C>взаимодействие с плугинами идет через интерфейсы/абстрактные классы.
> Ну, это не фокус, прямо скажем. В эрланге, например, есть два
> ортогональных способа это обеспечить.
> 1) Модули. На базе них "плагин" делается на раз-два. Просто программа
> предполагает, что в некотором (заранее неизвестном) модуле объявлены
> некоторые (заранее известные) функции.
Это как раз пример name-based полиморфизма. Просто Erlang — динамический
язык и ему не надо явно выделять наборы сигнатур функций. А если их явно
выделить — получатся старые добрые интерфейсы

> Пример — OTP behaviours. Никто не мешает делать так в любом языке.
> В SML вот, я слышал, имеется какое-то "исчисление модулей", наверняка
> как раз об этом.
Посмотрю.

> C>Вероятно поэтому функциональщики предпочитают использовать
> C>message-passing-интерфейсы. Оно, конечно, хорошо — но не является полной
> C>заменой.
> Почему нет? Говорить про Эрланг — там с компонентностью все более чем в
> порядке, и ничего больш не нужно. Благодаря, конечно, процессам — они
> выполняют роль объектов при крупноблочной декомпозиции системы.
Я тебе приводил мой пример — сейчас я его переписываю в более
функциональном стиле, но все же полностью не получится. Да и, как бы его
не ругали, RPC — это удобная вещь.

Posted via RSDN NNTP Server 2.0

lomeo,

L>Я не особенно сравнивал ещё ОО и ФП, чтобы их противопоставлять

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

L>Ты можешь что нибудь предложить?

Хм. Вроде бы у меня есть кандидат — GUI. Батоны, окна, батнклики и проч...

Библиотеку gs из Эрланга (или её аналог из Хаскеля) не предлагать, ибо там взаимодействие между виджетами осуществляется через асинхронную передачу сообщений => работа основана на побочных эффектах, то есть посылках сообщений.

Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.

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

FDS>>

.

T>"скорее всего всё изменяется согласованно," "если код класса написан правильно," "система правильно декомпозирована."

T>Три условия должны выполняться одновременно.

T>Для ФЯ это никуда не девается, но получить получается легче.

Личное мнение. Бездоказательное.

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

L>Я не особенно сравнивал ещё ОО и ФП, чтобы их противопоставлять

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

L>Ты можешь что нибудь предложить?

GUI

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

C>Точно так же ведь можно и обычные виртуальные функции заменить switch'ем
C>(как частный случай pattern-matching'а). Но вот проблема в том, что
C>виртуальные функции как раз придумали чтобы заменить switch

А классы придумали, чтобы заменить указатели на функции.
Хорошая такая замена!

Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода, чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.

граммофон wrote:
> C>Точно так же ведь можно и обычные виртуальные функции заменить switch'ем
> C>(как частный случай pattern-matching'а). Но вот проблема в том, что
> C>виртуальные функции как раз придумали чтобы заменить switch
> А классы придумали, чтобы заменить указатели на функции.
> Хорошая такая замена!
Нет, не указатели на функции, а набор указателей на функции.
Почуствуй разницу.

Заодно над этим набором потом вводят дополнительную функциональность —
наследование, выделение интерфейсов и т.п.

> Если уж на чистом Си у меня все эти прокси требуют раз в 10 меньше кода,
> чем на ОО-языках, то в функциональном случае это даже обсуждения не стоит.
Ну-ка, продемонстрируй "в 10 раз меньше" на С.

Posted via RSDN NNTP Server 2.0

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

LCR>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.

<a href="http://www.cs.chalmers.se/ComputingScience/Research/Functional/Fudgets/">Fudgets</a> видел?
Можно создавать виджеты (что значит динамически??), можно менять состояния (если имеется в виду button.setTitle("New")), не всё как в нормальной, разумеется, например, я не знаю как менять look&feel, кроме как через параметры, но функциональный подход демонстрирует.

А вообще есть толпа библиотек http://haskell.org/haskellwiki/Libraries_and_tools/GUI_libraries

Правда, многие — калька с императивных (один из самых популярных, wxhaskell например). Но подход fudgets очень симпатичный — мне нравится больше, чем ООшный.

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

LCR>Библиотеку gs из Эрланга (или её аналог из Хаскеля) не предлагать, ибо там взаимодействие между виджетами осуществляется через асинхронную передачу сообщений => работа основана на побочных эффектах, то есть посылках сообщений.
Для Ерланга есть другая либа gtkNode
---------------------------------------------------------
Yet Another GUI framework for Erlang — gtkNode

DESIGN GOALS

* GUI separated from application by message passing
* distributed (application and GUI can run on different machines)
* centered around a GUI builder
* small volume of (hand-written) code
* pre-documented

ARCHITECTURE

a c-node (a daemon that implements the Erlang distribution protocol)
that instantiates the GUI from a configuration file. the c-node sends
messages to the Erlang node when the user interacts with the GUI; the
Erlang application changes the state of the GUI by sending messages to
widgets in the c-node. the widgets should look like Erlang processes
with registered names. the protocol should look something like this.

CnodePid ! {aWidget,dosomething,Args} % erlang->cNode
ApplicationPid ! {reply, Val} % cNode->Erlang
ApplicationPid ! {signal,aWidget,eventType} % cNode->erlang
-------------------------------------------------------------
использует GTK. можно строить ГУЙ при помощи GLADE.
Но, конечно, все на сообщениях...

LCR>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.
А все это можно — сообщения и процессы "спасут отца русской демократии" ! 8))

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

L>>Ты можешь что нибудь предложить?

FR>GUI :)

И ты, Брут! :-) См. ответы выше.

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

C>Ну-ка, продемонстрируй "в 10 раз меньше" на С.

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

Сидеть же и считать этот синтаксически оверхед от описания классов и интерфейсов лень.
Уж не знаю в 10 раз там разница или в 9,5 — мне хватает.

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

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

L>Ты можешь что нибудь предложить?

Любые задачи эмуляции чего-то с сотоянием. Особенно если требуется получить быстрое решение с малым расходом памяти.

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

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

C>Для некоторых — да. Но многие паттерны (типа визитора или прокси)

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

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

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

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

L>>>Ты можешь что нибудь предложить?

FR>>GUI

L>И ты, Брут!

См. ответы выше.

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

from Tkinter import *

Button(text = "test", command = Tk().quit).pack()
mainloop()

граммофон wrote:
> C>Ну-ка, продемонстрируй "в 10 раз меньше" на С.
> В простейшем случае просто один указатель на функцию заменяется другим.
> Без оглядки на типы и прочее.
То ставится функция другого типа?

void (*ptr)(int p1, p2);

void func1(int p1, int p2)
{
//...
}

double func1(double p1, double p2)

ptr=((void*)(int,int))func1;
ptr(1,2); //Упс.

Так что ли?

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

> Сидеть же и считать этот синтаксически оверхед от описания классов и
> интерфейсов лень.
> Уж не знаю в 10 раз там разница или в 9,5 — мне хватает.
> прежде чем понять рекурсию, необходимо понять рекурсию.
Покажи пример.

Posted via RSDN NNTP Server 2.0

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

FDS>Личное мнение. Бездоказательное.

Цитируй меньше.

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

gandalfgrey,

LCR>>Библиотеку gs из Эрланга (или её аналог из Хаскеля) не предлагать, ибо там взаимодействие между виджетами осуществляется через асинхронную передачу сообщений => работа основана на побочных эффектах, то есть посылках сообщений.
G>Для Ерланга есть другая либа gtkNode
...
G>Но, конечно, все на сообщениях...
Принципиальной разницы между gs и gtkNode нет. Поэтому отметаем.

LCR>>Интересует подход в рамках чистого ФП, причём можно было бы динамически создавать виджеты, менять их состояние, вешать длительные вычисления на события и т.п., короче всё как в нормальной импиративной GUI-библиотеке а ля Swing, SWT, WinForms etc.
G>А все это можно — сообщения и процессы "спасут отца русской демократии" ! 8))
Да, асинхронный обмен рулит и т.д. и т.п., но где здесь ФП? Напомню, спор вызвал тезис lomeo:

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

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

C>Визитор нужен для разделения обхода и обработки. Например, FR приводил
C>пример с обходом AST в Питоне. Без визитора был бы длииииииииииинный
C>метод, а так его можно просто разбить на разные классы.

Это не совсем точно. Визитор использует разделение обхода и обработки. Но нужен он не для этого.

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

Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.

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

C>>Визитор нужен для разделения обхода и обработки. Например, FR приводил
C>>пример с обходом AST в Питоне. Без визитора был бы длииииииииииинный
C>>метод, а так его можно просто разбить на разные классы.

L>Это не совсем точно. Визитор использует разделение обхода и обработки. Но нужен он не для этого.

L>

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

L>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.

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

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

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

L>>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.

FR>Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.

Кто сказал что внутри одной функции? Мультиметоды на то и мульти-

Много их — столько сколько захочешь

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

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

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

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

Не согласен. Паттерн матчинг и АТД — не сахар — это подход, другой способ взглянуть на вещи. А уж ФВП сахаром назвать язык не повернётся. А ведь они, может быть, самая важная вещь для обсуждаемого вопроса.

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

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

VD>И вообще, большой вопрос что считать функциональным, а что императивным. Лично я считаю фунциональным стиль программирования в котором программист старается использовть вычисление выражений вместо выполнения инструкций. Гапертон же тут рядом заявил, что если в программе используется модификация переменных, то это уже "императивщина" (таки оскорбление какое-то :) ).

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

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

Не понял, почему?

VD>Я считаю, что пропагандируемем выразительность ФП в основном основывается на сахаре добавленном в ФЯ. Так я бы выделил:
VD>1. Сопоставление с образцом (сахар для if-ов и switch-ей).
VD>2. Алгеброические типы (сахар для классов).
VD>3. Спец.синтаксис (сахар для работы со списками, строками, и т.п.).
VD>4. Операции над функциями (частичное применение, локальные функции, лямбды).

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

VD>А сказки про то что изменение переменных ужасно усложняет программу, они и есть сказки. Я не испытвал проблем с этим в C# нигогда. Достаточно было выполнять несколько простых правил и проблема исчезала сама собой.

Ну так, а в ФП для этого даже не надо выполнять эти правила! Из-за этих правил опять таки в мыслях оверхед.

VD>Меж тем модификация переменных иногда может быть очень полезна даже если используется весь перечисленный выше сахар. Ни один из приведенных аспектов не противоречит императивному программированию. Не мудренно что из ФЯ в таких условиях пытаются сделать религию.

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

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

L>>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.

FR>Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.

А?!

data Tree a = Node a | Branch (Tree a) (Tree a)

visit n@(Node _)   f = f n
visit t@(Tree l r) f = do
    f t
    f l
    f r

-- один визитор
treeLength _ = update (+1)

-- второй визитор
treeSum (Node a) = update (+a)
treeSum _        = get

Тут проблема точно такая же как в паттерне Visitor — при расширении типа данных приходится проходить по всем посетителям.

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

LCR>Принципиальной разницы между gs и gtkNode нет. Поэтому отметаем.

Разница единственно в том, что в одном случа используется TK, а в другом GTK. В обоих случаях ГУЙ может находиться на другой машине.

LCR>Да, асинхронный обмен рулит и т.д. и т.п., но где здесь ФП? Напомню, спор вызвал тезис lomeo:
LCR>[q]
Тут я затрудняюсь привести какой-то особый пример для ГУЯ. Сообщения — они как-то от языка не зависят. Для их обработки весьма хорош и приятен паттерн-матчинг, но это не особенность ФЯ
Вот разве что в Clean был весьма специфичный ГУЙ, прямо заточенный под язык...

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

L>>>Из-за наличия диспетчеризации по нескольким параметрам (паттерн матчинг + ФВП) этот паттерн легко расписывается на ФЯ.

FR>>Расписывается легко, но в результате все получается внутри одной функции, что может быть проблемой если нужна легкая расширяемость.

К>Кто сказал что внутри одной функции? Мультиметоды на то и мульти-

Много их — столько сколько захочешь

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

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

G>Да лана тебе. Все равно Ифы и Свитчи — сахар для команд JNZ и JZ, а функции — сахар для инструкций CALL и RET.

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

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

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

VD>>ФП и ООП могут выражаться друг через друга
M>Нет.

Обоснование есть? Я вижу это повсеместно.

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

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

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

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

Z>http://pobox.com/~oleg/ftp/Scheme/pure-oo-system.scm

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

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

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

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

FR>>Да и еще это у тебя в хаскеле несколько функций(хотя логически она тоже одна) а ML и Nemerle будет одна, тут уже в философии прошлись по поводу размеров таких функций

L>Это общая проблема switch'ей — они имеет тенденцию распухать.

Именно поэтому в таких случаях рулит расширение через добавление классов реализующих общий интерфейс.

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

L>>Это общая проблема switch'ей — они имеет тенденцию распухать.

АХ>Именно поэтому в таких случаях рулит расширение через добавление классов реализующих общий интерфейс.

Всё относительно. По сравнению со свитчами — рулит, а по сравнению с ФВП+паттерн-матчинг — сосёт.

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

LCR>>Функции Высшего Порядка = HOF = Higher Order Functions

VD>Значит ВВП = Володя Высего Порядка.

Ну да, а ЖЦ — это Жарбач Цоллектор.

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

АХ>Не согласен. Паттерн-матчинг — это свитч на стероидах.

Свитчу до него как до луны. Так что я бы тогда уж сказал что это свитч с могзгами. Там нехилые алгоритмы вывода используются все же.

АХ>Если ты захочешь расширить вариант, то тебе скорее всего придется добавлять код там где делается паттерн-матчинг по этому варианту.

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

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

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

АХ>А если просто отнаследовать класс, то код обработки, вызывающий виртуальные функции менять не придется.

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

К тому же у подходов с классами есть одна огромная проблема — отсутсвие контроля. В отличии от закрытых вариантов наследование никем не контроливется и никто не подскажет что нужно что-то там переоределять.

АХ>Всему свое место. Для не слишком сложных структур данных — варианты и паттерт-матчинг.

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

АХ>Для более навороченных — классы, интерфейсы и полиморфизм.

Такое ощущение, что варианты это не полимофизм.

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

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

L>>Всё относительно. По сравнению со свитчами — рулит, а по сравнению с ФВП+паттерн-матчинг — сосёт.

АХ>Не согласен. Паттерн-матчинг — это свитч на стероидах. Но тем не менее свитч.
АХ>Если ты захочешь расширить вариант, то тебе скорее всего придется добавлять код
АХ> там где делается паттерн-матчинг по этому варианту.
АХ>Таким образом получается размазывание добавления новой функциональности по коду.

АХ>А если просто отнаследовать класс, то код обработки, вызывающий виртуальные функции менять не придется.

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

Не согласен ;-) Ты (можно?) забыл про функции высшего порядка, которые куда как проще наследования с виртуальными функциями.

Для не слишком сложных структур данных — варианты и паттерт-матчинг.
Для более навороченных — + функции высшего порядка.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Оверхед это когда затраты есть, а выгод нету. А это не оверхед, а плата за доп.удобства. ;) Например, процесс в ST можно сериализовать-десериализовать и запустить. О полезности/бесполезности такого сейчас не нужно говорить — я так никогда не делал, но в форуме по Squeak видел, что люди справшивали можно ли такое сделать и делали.

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

Вообще, мне не очень нравится это слово — оверхед.

А насчёт ST — так он использует очень много из функционального подхода, и при работе с ним легко думать о блоках как о фунциях, а не объектах. Собственно, чем он мне и нравится.

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

G>Монады — это кошмарный кошмар.

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

Это ты говоришь о монадах, реализующих последовательный конвеер (IO, State и т.п.)
Но есть ещё и монады-множества — список, Maybe, Either и т.д., позволяющие компактно выражать функции над множеством через функции над элементами. Те же list comprehensions, например. Выглядят искусственно в любом языке, кроме Хаскелла. (имхо)

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

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

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

Это смотря как написать.

type Var = Foo | Bar | Buz {- добавьте сюда ещё Err -}

f :: a -> Var -> a
f x Foo = x+1
f x Bar = x*2
f x _   = x*x  -- как бы сэкономили на последней проверке

g :: a -> Var -> a
g x Foo = x-1
g x Bar = x/2
g x _   = sqrt x

Опять же, что быстрее — один раз построить функцию и передавать/вызывать её, или же каждый раз выполнять сопоставление.

type Var' a = Vars { there :: a->a, back :: a->a }

foo = Vars (\x -> x+1) (\x -> x-1)
bar = Vars (\x -> x*2) (\x -> x/2)
buz = Vars (\x -> x*x) (\x -> sqrt x)

f x var = (there var) x
g x var = (back var) x

(этот пример, конечно, утрирован).

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

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

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

G>>Монады — это кошмарный кошмар.

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

К>Это ты говоришь о монадах, реализующих последовательный конвеер (IO, State и т.п.)
Я вообще говорю об ООП и моделировании состояния.

К>Но есть ещё и монады-множества — список, Maybe, Either и т.д., позволяющие компактно выражать функции над множеством через функции над элементами. Те же list comprehensions, например. Выглядят искусственно в любом языке, кроме Хаскелла. (имхо)

Какая нам разница, в контексте данного разговора.

Трурль wrote:
> Это просто категорийская ересь. Все прекрасно выражается и без всяких монад.
Я что-то, видимо, пропустил. Если монады — это ересь, то какая религия
нынче самая правильная?

Posted via RSDN NNTP Server 2.0

Gaperton wrote:
> PA>Я что-то, видимо, пропустил. Если монады — это ересь, то какая религия
> PA>нынче самая правильная?
>
> Бритва Оккама.

Ответ не катит

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

Posted via RSDN NNTP Server 2.0

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

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

PA>>>Я что-то, видимо, пропустил. Если монады — это ересь, то какая религия нынче самая правильная?

G>>Бритва Оккама.

К>О! Живой программист на Оккаме! Ну и как Оккам? (- Он спрашивает "ну и какакам?" — Ответь ему "ну и кукукум!")

Кукукум!

Так и знал, что кто-нибудь пошутит на эту тему

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

LCR>Во-первых, ФВП — это другая абстракция, нежели классы.

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

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

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

LCR>В-третьих, передача и возвращение функций с побочными эффектами — это опасная конструкция.

Не более чем возврат ссылки на экземпляр класса методы кторого меняют состяние экземпляра.

LCR> А именно: поскольку любой мало-мальски сложный метод модифицирует приватное состояние, то передавать этот метод куда-то наружу — это вносить хаос в состояние объекта.

Неверный вывод. Сама функция является средством инкапсуляции.

LCR> И чем шире будет использоваться эта возможность, тем более непредсказуемым будет поведение программы.

Это боязнь на уровне шаманства. Не делай так, а то боги разгневаются. И такая аргументация в ФЯ повсеместно. Вот это мне и не нравится.

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

Идея о том, что изменение состояния экземпляра класса — это нормально, а переменных замыкания, нет, мне кажется просто стереотипом. Классы от замыканий ничем не отличаются в данном аспкте (аспекте инкапсуляции).

LCR> И этой возможностью будут пользоваться как можно реже, только когда по-другому совсем никак.

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

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

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

LCR>В-четвёртых, прозрачность ссылок и ООП — вещи почти несовместимые — при модификации состояния любого объекта рвутся ссылки, что мешает нормальному моделированию.

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

LCR>В-пятых, в чистом функциональном мире все параметризованные типы могут быть ковариантны (то есть для любого параметризованного типа T: B < D => T[B] < T[D]), что невозможно в случае модифицируемого состояния (необходимость рантайм-проверок для того, чтобы не сломать систему типов).

ОК. Ковариантность это несомненный плюс. Но давай будем честными сами с собой. Как часто бывает нужно применять эту ковариантность? Я вот практически не помню применения ковариантности по делу. К тому же ковариантность на уровне интерфейсов доступна без проблем. Так что фактически пробелем нет.

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

Какое отношение вывод типов имеет к ООП или ФП? Это очередной миф. То что что-то родилось в некотором месте делает эито что-то присущим только этому месту.

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

В общем, это совсем ничтожный аргумент высасанный из пальца.

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

Я не знаю зачем нужна крутость. Предпочитаю удобные по жизни вещи, а не крутые. Будем честными. Хаскель не рассатривают в серьез даже ярые поклонники ФП. Они почему-то предпочитают разные Эрланги и ОКамлы.

LCR>В двух словах: те абстракции, которые отлично работают в случае ФП не факт что будут работать в общем случае.

Факт. Причем проверенный на практике.

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

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

VD>>Да без разницы. ООП это тоже сахар. Я писал ОО-программы на С в 1993-ем году. Да было менее удобно чем на С++, но жить было можно. Когда появился сахар в виде классов, виртуальных методов и т.п. я с удовольствием им воспользовался.

LCR>Твоё понятие сахара что-то слишком широко.

В самый раз. Это вообще спорный термин. И его восприятие зависит от ширины кругозора.

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

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

Для вовда/вывода нужен всего лишь метод print или что-то вроде того. А как он выводит данные меня трогать не должно.

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

А бывает наоборот. Когда ограничения возмодятся в догму и приводят к запутанным и невнятным решениям.

LCR>PS1: Никто не отказывается от хэш-таблиц, а их просто прячут внутрь языка, библиотек или ещё чего-нибудь.

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

LCR>PS2: Остальное (в частности то, как "рулят" отладчики) требует отдельных священных войн... Потом повоюем

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

VD>>> ковровые бомбардировки и танковые клинья и еще этот, как его? А, гриб Сарумяна.
LCR>^ это понравилось, но про гриб не понял

Это потому что ты смотришь кино в неправильных переводах. В свое время Гоблин неплохо перевел "Братьев кольца" (что ли) по Толкиену. Филь был откровенно слабым, но с этим перводом стал вполне забавным.

Так что если Толкиен не стал религией, то очень советую к просмотру.

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

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

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

Хм. Где дедушка Фрэйд? Тут как раз ему работа.

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

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

Хм. Что же такое пропустил?

L>Напомню для начала о чём мы спорим, — спор был вызван тезисом о том, что ООП даёт больший оверхед, чем ФП.

И моем возражении о том, что это мягко говоря неправда.

L>Поэтому не скатывайся каждый раз к императивному программированию.

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

L> Речь именно об ООП. О том, что в ИЯ что то есть или чего то нет для этого тезиса совершенно не интересно.

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

L>Дальше моё мнение о том, почему я считаю этот тезис справедливым.

А повторяешь его ты потом, что считашь, что другие должны с ним смеритсья? Я вот почему-то с ним не согласен. Причем как раньше, так и сейчас.

L>За счёт чего создаётся оверхед в ООП? За счёт того, что "о действиях думают как об объектах".

Я уже говорил, что считаю подобные мысли логической ошибкой и объяснял почему.

L>О действиях, о которых думают как об объектах. Распишу ещё раз. Подробнее.
L>Различные классы Listener-ов, которые по сути представляют собой функцию. Есть такое?

Где? В Яве? Я на ней не пишу. Listener-ы это действительно средство эмуляции ФВП. Я вот почему-то болеше предпочитал C# и там обработка событий производится через (извините за коломбур) события. События же реализуются на делегатах, но для них есть относительно неполохой сахар.

L> Есть.

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

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

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

L> Поэтому насчёт того, что ты не видел применения паттерна Команда я даже не знаю, что сказать.

А в таких случаях вопросы задавай, раз сказать нечего. И уж темболее не надо перевирать мои слова. Я не говорил, что не видел применения паттерна Команда. Я сказал, что не видел, чтобы им заменяли методы (т.е. действия). И вообще, применение этого паттерна довольно редкое явление. Классический пример команды в редакторе и undo/redo Вот в нем его в основном и видел. Это паттерн в котором действитльно на действия смотришь как на объекты, но оно хорошо в данном случае. Ведь думать о методах как о хранителей информации для undo мне кажется плохой идеей.

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

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

L>Треды — это потоки (Thread), которые почему то представляют опять же объектами, чем не оверхед?

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

L>Генераторы — это то, что порождает (генерирует) некоторые данные. Однозначно действие, однако, представляется объектом. К метапрограммированию отношения не имеет.
L>Недостаточно примеров?

Хм. А вот скажем функция Console.ReadLine() тоже по-твоему выражена через объект? Что-то притензия выглядит натянутой.

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

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

В общем, твое мнение меня совсем не убеждает.

L>Теперь, что нам даёт взамен ФП (для выразительности, т.е. полного и ясного представления мысли — я верно понимаю слово "выразительность"?).
L>Это ФВП+отсутствие сайд эффектов.

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

L> ФВП позволяет не представлять действия в виде объектов,

Ага. ООП тоже позволяет не представлять. Какое совподение? Правда?

Кстати, ФП позволяет нам выражать объекты через функции. Какая засада!

L> а сайд-эффект вносит дополнительный вклад в ясность представления.

Тут у вас неувязочка.

L> Насколько я понимаю разногласия у нас именно в сайд-эффекте.

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

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

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

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

L>Распараллеливание и прочие вещи, ПРОСТО получающиеся автоматически, берутся не спроста.

Ну, это же банальная лож! Просто только кошки родятся. И то только в поговорках. А автоматическое распараллеливание — это нехилые навороты в компиляторе. Это хайтек котрый пока что я в живую не видел! И не надо мне тыкать Эрлангом. Нет в нем автоматического распараллеливания. Там ручное распараллеливание. А да недавнего времени вообще кооперативка была голимая. А вот где те изумительные компиляторы которые сами и эффективно распраллеливают компиляцию? А вот Intel C, прости господи, ++ и, прости господи, Microsoft, мать его VC++ это как раз делают. Только код надо специальным обрзом аннотировать. И что забавно сайд-эффекты не очень то и мешают. То есть на деле императивнные ООЯ параллелятся во всю, да еще и не безопасные, а просто таки созданные для этого ФЯ — хрен! Вывод?! Параллелить можно хоть черта лысого, но сам процесс — это хайтек требующий нехилого вливания денег. Вот и выходит, что в MS думают о создании PLinq-а (параллельной версии Linq-а который войдет в C# 3.0), поклонники ФП рассказвают остальным, что "Распараллеливание... ПРОСТО получающиеся автоматически".

L> Это связано с большой ясностью что происходит при отсутсвии сайд-эффектов.

Большая ясность всего лишь упрощает решение задачи. Не более того, но и не менее. Я как бы "за" то что неизменяемость упрощает распараллеливания. Но этого мало.

L> Большой ясностью не только для машины, но и для человека.

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

L> Но ты так не считаешь.

Где? Ты меня не придумал случаем?

L> В этом, насколько я понимаю, и есть разница в нашем отношении к оспариваемому тезису "ООП vs ФП".

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

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

Какой тезис? Извини за грубость, но подобные тезисы ростые люди назвают болтовней.

Напомню, что кто-то обещал рассказать о неком "не только". Вот было бы интересно послушать.

Мои разговоры — это выражение моего мнения основанного на том, что я вижу. То что ктому-то проще жить в придуманном мире, а не оперировать фактами я не виноват.

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

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

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

Т>Вопрос, конечно, интересный. Еще недавно Символ Веры гласил: "нет бога кроме дотнета и сишарп пророк его". Но ныне это уже Ветхий Завет. Ибо явился Мессия и теперь мы все знаем, на какую букву начинается название Истинного Языка.
А Жаба как же ? Или это уже совсем язычество в ПРАВИЛЬНОМ понимании текущего момента ? 8))
Или это первородный хаос, из коего все было создано :
"Мир был безвиден и пуст, и дух божий носился над Жабой" (с) библия

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

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

L> А уж ФВП сахаром назвать язык не повернётся.

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

Я понимаю, что это были слова не обо мне, а о третьих лицах. Только зачем тогда писать о них в ответе мне?

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

Конечно, иначе бы не было спора.

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

Ты можешь слово сахар заменить чем нибудь? Или давай определимся с терминами. Для меня сахар — слово из словосочетания syntactic sugar. Позволяя записывать код короче, он тем не менее не добавляет выразительность программе, т.е. сахар сжимает код, а не мысль.

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

VD>А каковы тогда критерии отнесения чего-то к ООП или императивному программированию (ИП)? Ведь ООП код может быть функциональным по сути, а может быть императивным. Как же быть?

Что такое функциональный ООП? Это использование ОО и функциональщины в одном флаконе? Если да, то нам не о чем спорить.

L>>Дальше моё мнение о том, почему я считаю этот тезис справедливым.
VD>А повторяешь его ты потом, что считашь, что другие должны с ним смеритсья? Я вот почему-то с ним не согласен. Причем как раньше, так и сейчас.

Из чего ты сделал такой вывод?

L>>За счёт чего создаётся оверхед в ООП? За счёт того, что "о действиях думают как об объектах".
VD>Я уже говорил, что считаю подобные мысли логической ошибкой и объяснял почему.

Объясни еще раз.

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

Не вижу разницы :-)

VD>Есть твое заблужедение и очередное подтверждение моего тезиса о том, что краткость опеделяется сахаром, а не используемой парадигмой.

Не так. Сахар сокращает код. Из этого не следует, что краткость определяется сахаром. Я тебе такой охрененный алгоритм на простую задачку выдам, задолбаешься его подслащивать. Впрочем, речь не об этом. Еще раз — когда я говорю о краткости в контексте "ФП vs ООП", то я имею в виде НЕ краткость кода.

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

Ну, вот для тебя же нормальным выражением является "форма выполнила некие действия"? ;-)

VD>А в таких случаях вопросы задавай, раз сказать нечего. И уж темболее не надо перевирать мои слова. Я не говорил, что не видел применения паттерна Команда. Я сказал, что не видел, чтобы им заменяли методы (т.е. действия). И вообще, применение этого паттерна довольно редкое явление. Классический пример команды в редакторе и undo/redo Вот в нем его в основном и видел. Это паттерн в котором действитльно на действия смотришь как на объекты, но оно хорошо в данном случае. Ведь думать о методах как о хранителей информации для undo мне кажется плохой идеей.

Для этого есть Memento, насколько я помню ОО. А команды — это просто напросто функции.

L>>Треды — это потоки (Thread), которые почему то представляют опять же объектами, чем не оверхед?

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

Э-э-э, а зачем из-за одного threadID делать объект?

VD>Хм. А вот скажем функция Console.ReadLine() тоже по-твоему выражена через объект? Что-то притензия выглядит натянутой.

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

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

VD>А я скажу, что ты птаешся навязать свое высосанное из пальца мнение.
А ты пытаешься навязать свое высосанное из пальца мнение. И?

VD>И еще видишь какой-то оверхэд так где лично я его не вижу.
Это всего лишь говорит о том, что ты не видишь оверхеда там, где вижу его я.

VD>В общем, твое мнение меня совсем не убеждает.
Мнение не для того, чтобы убеждать. Убеждать — прерогатива доводов.

L>>Это ФВП+отсутствие сайд эффектов.
VD>Ага. Это конечно очень помогает нам в области обработки сообщений, генерации данных и управления потоками. :xz:

Конечно.

L>> ФВП позволяет не представлять действия в виде объектов,

VD>Ага. ООП тоже позволяет не представлять. Какое совподение? Правда? :)
Ну что за бред? Влад, может ты не с тем утверждением споришь?

VD>Кстати, ФП позволяет нам выражать объекты через функции. Какая засада!
Как это помогает нам в деле сокращения оверхеда?

L>> а сайд-эффект вносит дополнительный вклад в ясность представления.
VD>Тут у вас неувязочка. :)

(Оглядываясь) Где?

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

VD>Невероятная вредоностность сайд-эффектов только одна из них.
Покажи, где я это говорил!

VD>Другая — это то что ООП заставляет все думать, что мир состоит из одних объектов.
Покажи, где я это говорил!

VD>Надо будет попробовать включить дурака и "повоевать" от обратного. Ну, начать поропагандиски вопить на каждом углу, что сайдэффеты это круть невероятна, так как дают дополниткльную гибкость, а ФП заставляет все думать, что все объекты вокруг — это функции. Думаю реакция будет потрясающая. Хотя вроде бы всего лишь довел до догматизма обратные утвеждения. :)

Которые ты сам же и выдумал?

L>> Ты считаешь, что сайд эффект (отсутствие) нужен для автоматического распараллеливания, может быть для лучшей тестируемости код (в силу того, что функции получаются чистыми). Для меня же не только это.
VD>Да, считаю. И вижу тому четкие подтверждения. А вот "не только" это, для меня не более чем докма вбитая в головы людей откровенным внушением. И не надо меня обвинять в неуважении. Если это не внушение, то где, черт побери, банальные доказательстви и обосновния?

Нет сайд эффектов — нет состояний. Нет состояний — не надо за ними следить. Не надо за ними следить — голова освобождается еще от одной боли.

L>>Распараллеливание и прочие вещи, ПРОСТО получающиеся автоматически, берутся не спроста.

VD>Ну, это же банальная лож!
Тут я поскипал очень много полезной информации

Убедил ты меня своим напором. Уберу я слово ПРОСТО и поставлю ПРОЩЕ :-)
Нет сайд-эффектов — нет состояний. Нет состояний — не надо за ними следить. Не надо за ними следить — не надо проверять два вычисляемых аргумента у функции на взаимозависимость (как по русски?). Не надо проверять — движок освобождается от дополнительной проверки.
Хотя ты, как я понял, с этим согласен.

L>> Это связано с большой ясностью что происходит при отсутсвии сайд-эффектов.
VD>Большая ясность всего лишь упрощает решение задачи. Не более того, но и не менее. Я как бы "за" то что неизменяемость упрощает распараллеливания. Но этого мало.

L>> Большой ясностью не только для машины, но и для человека.
VD>Человек и без машины может все что хочешь распараллелить. Да и ты вроде хотел рассказать о "не только", а на деле повторяешь мои слова, и почему-то так как будто я с тбой спорю.

L>> Но ты так не считаешь.
VD>Где? Ты меня не придумал случаем? :)

Т.е. ты считашь, что сайд эффекты добавляют ясность. Или нет, я чего не понял? :-)

L>> В этом, насколько я понимаю, и есть разница в нашем отношении к оспариваемому тезису "ООП vs ФП".
VD>В том, что ты говоришь, что "ФП упрощает распараллеливание поотом что оно (божественное) ФП", а я просто говорю что "ФП упрощает распараллеливание"? Ну, да именно в этом. Именно по этому позицию подобную твоей я считаю догматом. Я вижу что А дает Б и говорю об этом. А тебя почему-то унижает, что при этом я не не делаю глубокий взох и не говорю о какой-то потоенной крутизне.

Слушай, Влад, а где это я говорил, что ФП — божественное? Или хотя бы выразил свое к нему отношение? Может это потому, что ты хочешь считать мою позицию догматом?
Где я говорил, что меня "унижает, что при этом я не не делаю глубокий взох и не говорю о какой-то потоенной крутизне"? Обоснуй, пожалуйста, свои слова, или это ты сказал просто так, для поддержания разговору? ;-)
Да и вообще, где я писал о потаенной крутости?

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

VD>Какой тезис? Извини за грубость, но подобные тезисы ростые люди назвают болтовней.

Ну так мы чем с тобой здесь занимаемся то, вместо того, чтобы делами заниматься? ;) Я полагаю, ростые люди не будут даже время тратить на прочтение таких тезисов, так же?

VD>Напомню, что кто-то обещал рассказать о неком "не только". Вот было бы интересно послушать.

"Не только" что? Если ты про сайд эффекты, то выше — отсутствие сайд эффектов добавляет коду ясность.

VD>Мои разговоры — это выражение моего мнения основанного на том, что я вижу. То что ктому-то проще жить в придуманном мире, а не оперировать фактами я не виноват. :xz:

Так я полагаю это у всех так. Мир дается нам в ощущениях. А потом приходит другой и говорит, что твой мир придуманный.

VD>Так что я еще раз повторю свою мысль. Рассказы о том, что немодифицируемость переменных каким-то чудотворным образом делает программы читабельнее и проще — это миф и пропаганда. Неизменяемость упрощает отладки и распраллеливание, но до некоторого предела. Ничего сверхестествнного тут нет. А вот как раз краткость ивыразительность ФЯ никак от неизменяемости не зависит.

Выразительность ФП (не ФЯ, что ты постоянно переводишь то!) зависит также и от отсутствия сайд эффектов. Почему я попытался выше объяснить.

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

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

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

VD>Идея о том, что изменение состояния экземпляра класса — это нормально, а переменных замыкания, нет, мне кажется просто стереотипом. Классы от замыканий ничем не отличаются в данном аспкте (аспекте инкапсуляции).

Есть, есть тут одно отличие. А именно, идентичность.

Для ООП идентичность — фундаментальное свойство, ему уделяется много внимания. Поэтому
1) различаются поверхностное и глубокое копирование (т.е. копирование ссылок и содержимого)
2) данные (которые и являются предметом идентичности) отделены от кода; можно, во-первых, очертить контекст, а во-вторых, управлять глубиной копирования

А в ФП роль идентичности гораздо менее заметна.
1) для констант нет разницы между поверхностным и глубоким копированием (кроме вопросов производительности) — есть конвенции о том, что происходит на самом деле (причём для каждого языка свои!)
2) синтаксис большинства языков позволяет писать замыкания так, что данные размазываются.

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

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

Вот пример-страшилка на F# / CaML (не задействуя его ОО-возможности)

let make() =
    let x = ref 0 // создаём долгоживущую переменную
    in
    let work () =
        x := !x + 1 ;
        !x
    in
    work // возвращаем замыкание

let show r = printf "%d\n" (r ())

let r1 = make() // создали функцию, которая будет на каждый вызов инкрементировать внутренние данные
let r2 = r1 // увы, здесь происходит поверхностное копирование

do show r1 // 1
do show r2 // 2
do show r1 // 3
do show r2 // 4

Есть разные способы:
— можно раздеть функцию, вынеся данные наружу

type runnerData = RunnerData of int ref // или просто int ref
// все три функции - содержательные
let make () = RunnerData (ref 0)
let run   (RunnerData x) = x:=!x+1; !x
let clone (RunnerData x) = RunnerData (ref !x)

— можно создать функцию, принимающую управляющие воздействия

type todo = Run | Clone
type result = Result of (todo -> (int,Result)) // здесь приходится вводить имя, чтобы не было бесконечного типа
// хелперы
let run   r = let Result(v,_)=(r Run  ) in v
let clone r = let Result(_,c)=(r Clone) in c

// содержательная часть упрятана
let make () =
    let work x = x:=!x+1; !x // содержательная
    in
    let rec service x a = // и служебная части
        match a with
          Run   -> Result (work x, service x       )
        | Clone -> Result (0     , service (ref !x))
    in
    service (ref 0) // производящей функции

— можно, наконец, создать пару функций (это мы уже в полшаге от интерфейса)

type runnerVtbl = Runner of ( unit->int ) * ( unit->runnerVtbl ) // опять же, разруливаем бесконечность
// хелперы
let run   Runner(r,_) = r()
let clone Runner(_,c) = c()

// содержательная часть упрятана
let make () =
    let work x = x:=!x+1; !x
    in
    let rec build x = Runner ( (fun()->work x), (fun()->build (ref !x)) )
    in
    build (ref 0)

Правильный ответ — это ОО — Отделяем мух От котлет.

type runner = class
    val mutable x : int
    
    new(x0) = { x = x0 }
    static member make() = new runner(0)
    member this.run() = this.x<-this.x+1; this.x
    member this.clone() = new runner(this.x)
end

let show (r : runner) = printf "%d " (r.run())

let r1 = runner.make()
let r2 = r1.clone()

do show r1
do show r2
do show r1
do show r2

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

Кодт wrote:
> > — можно, наконец, создать пару функций (это мы уже в полшаге от интерфейса)
> >

> > type runnerVtbl = Runner of ( unit->int ) * ( unit->runnerVtbl ) // опять же, разруливаем бесконечность
> > // хелперы
> > let run   Runner(r,_) = r()
> > let clone Runner(_,c) = c()
> > 
> > // содержательная часть упрятана
> > let make () =
> >     let work x = x:=!x+1; !x
> >     in
> >     let rec build x = Runner ( (fun()->work x), (fun()->build (ref !x)) )
> >     in
> >     build (ref 0)
> >

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

type counter = {
  next : unit -> int;
  clone : unit -> counter
}

let rec make_counter x =
  let state = ref x in
    {
      next = (fun () -> incr state; !state);
      clone = (fun () -> make_counter !state)
    }

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

> > type runner = class
> >     val mutable x : int
> >     
> >     new(x0) = { x = x0 }
> >     static member make() = new runner(0)
> >     member this.run() = this.x<-this.x+1; this.x
> >     member this.clone() = new runner(this.x)
> > end
> >

Кстати, дурацкая мысль — если объект эмулируется замыканием функции эдак
4-го уровня вложенности, то между static-данными и членами данных
объекта появляются промежуточные уровни:

type weird_sharing = {
  next1 : unit -> int;
  next2 : unit -> int;
  next3 : unit -> int;
  clone_shallow : unit -> weird_sharing;
  clone_deeper :  unit -> weird_sharing;
  clone_really_deep : unit -> weird_sharing
}

let rec make_weird x y z =
  let _x = ref x in
  let rec make_inner y z =
    let _y = ref y in
    let rec make_innermost z =
      let _z = ref z in
      let incr_and_ret v () = incr v; !v in
        {
          next1 = incr_and_ret _x;
          next2 = incr_and_ret _y;
          next3 = incr_and_ret _z;
          clone_shallow = (fun () -> make_innermost !_z);
          clone_deeper = (fun () -> make_inner !_y !_z);
          clone_really_deep = (fun () -> make_weird !_x !_y !_z)
        } in
      make_innermost z in
    make_inner y z

# let w1 = make_weird 0 0 0;;
val w1 : weird_sharing =
  {next1 = <fun>; next2 = <fun>; next3 = <fun>; clone_shallow = <fun>;
   clone_deeper = <fun>; clone_really_deep = <fun>}
# w1.next1 ();;
- : int = 1
# w1.next3();;
- : int = 1
# w1.next3();;
- : int = 2
# let w2 = w1.clone_shallow ();;
val w2 : weird_sharing =
  {next1 = <fun>; next2 = <fun>; next3 = <fun>; clone_shallow = <fun>;
   clone_deeper = <fun>; clone_really_deep = <fun>}
# w2.next1();;
- : int = 2
# w1.next1();;
- : int = 3
# let w3 = w2.clone_really_deep();;
val w3 : weird_sharing =
  {next1 = <fun>; next2 = <fun>; next3 = <fun>; clone_shallow = <fun>;
   clone_deeper = <fun>; clone_really_deep = <fun>}
# w3.next1();;
- : int = 4
# w3.next1();;
- : int = 5
# w1.next1();;
- : int = 4
# w2.next1();;
- : int = 5
# w1.next1();;
- : int = 6
# w2.next1();;
- : int = 7
# w3.next1();;
- : int = 6
#

Мда, больная идея. Не знаю, кому может такое понадобиться.

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

PA>Я не призываю отказываться от "настоящих" объектов в пользу их эмуляции
PA>на замыканиях, но мне кажется, что тут ты намеренно усложняешь код на
PA>замыканиях.

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

PA>Так вот попроще будет и не сильно отличается от "правильного" решения,
PA>приведенного ниже.
PA>

PA>type counter = {
PA>  next : unit -> int;
PA>  clone : unit -> counter
PA>}

PA>let rec make_counter x =
PA>  let state = ref x in
PA>    {
PA>      next = (fun () -> incr state; !state);
PA>      clone = (fun () -> make_counter !state)
PA>    }
PA>

Здесь пользователь вынужден знать (т.е. уметь конструировать) начальное состояние. А вот не факт, что ему это нужно и что он вообще это умеет.
Придётся инкапсулировать...

let start_counter () =
    let rec make_counter x =
        let state = ref x
        in { ...... }
    in make_counter 0

PA>Кстати, дурацкая мысль — если объект эмулируется замыканием функции эдак
PA>4-го уровня вложенности, то между static-данными и членами данных
PA>объекта появляются промежуточные уровни:
PA>

PA>type weird_sharing = {
PA>  next1 : unit -> int;
PA>  next2 : unit -> int;
PA>  next3 : unit -> int;
PA>  clone_shallow : unit -> weird_sharing;
PA>  clone_deeper :  unit -> weird_sharing;
PA>  clone_really_deep : unit -> weird_sharing
PA>}
PA>

PA>Мда, больная идея. Не знаю, кому может такое понадобиться.

Это какие-то руины дизайна.
У объекта могут быть роли:
— значение: требуется глубокое копирование всех индивидуальных агрегатов; (хотя могут быть ещё и разделяемые агрегаты)
— фасад: управляет ассоциированной структурой, скрытой за ним — в том числе может клонировать; сохраняя при этом себя неизменным
Бывает, что обе роли присутствуют одновременно. Но зачем устраивать комбинаторику из операций? Пусть отдельно он копируется со всеми персональными агрегатами, отдельно клонирует ассоцииации.
А ситуацию "недоклонирования" я представить не могу. Какие-то сиамские близнецы получаются. Хотя такая штука возникает при реализации Copy-On-Write — но это ж всё сокрыто, пользователю доступно только "некое клонирование" (а отложенное оно или немедленное — не заботит).

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

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

FR>А он понавыводит конечно в ленивых языках

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

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

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

К>Есть, есть тут одно отличие. А именно, идентичность.

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

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

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

FR>Угу только практически весь майнстрим недосахарен в твоем смысле.

Цитатаы, плиз, скипай.

VD>>Причем сахара может хватать для одной задачи и не хватать для другой. Например, компиляторы получаются самыми короткими на ОКамле и дургих МЛ-клонах (в том числе, гы-гы, и на Немерле).

FR>На рефале и прологе компиляторы получаются не хуже.

Значит на счет Лиспа ты согласен. А "не хуже" не значит "не лучше".

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

Не факт. Думаю матерый орел и на Яве уделает на большом проекте средненького программиста на любом языке.

VD>>3. Сказки о том, что Лисп и Форт не имеет сахара — это даже не скзки а наглая лож.

FR>Дай пожалуйста свое определение сахара, а то я уже начинаю думать что у тебя это универсальное слово через которое можно объяснить вообще все

Для Лиспа и Форта сахарам является все кром базовых вещей. Определение я давал не раз. Да и в Вики оно мало чем отличается.

FR>У меня и в мыслях не было ставить тебя в тупик, я думаю это вообще невозможно

А зачем задавать вопрос на который тебе и так знаком ответ? Зачем приводить в качестве примера языки со встроенным метапрограммированием?

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

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

L>Дело в том, что твой термин — это только твой термин. Если ты называешь ФВП сахаром, то давай я их буду называть их классами и скажу — я же четко определил значение термина! Давай все таки пользоваться устоявшейся терминологией, а не то, что мы придумываем по ходу разговора.

А я и пользуюсь устоявшимеся значениями. Я не виноват, что кое-то думает по другому. Более тог я тебе скажу, что ты и термин ФВП испльзуешь неверно. Он означает всего лишь возможность передать функции в качестве параметра. А это делается даже в С. Так что ты под термином ФВП подразумеваешь термины: 1) замыкание, 2) анонимные функции/лямбды, 3) локальные фукнции.

Но я до твоих слов не докапываюь, так как опнимаю о чем ты ведешь речь.

L>Ну вот видишь! У тебя есть опыт работы с ФЯ, у меня есть. Я заметил, что понимаю быстрее и четче те участки кода, которые не имеют сайд эффектов. Для тебя это не так. Однако это не значит, что я стал ВСЕ писать без сайд эффектов. Просто при прочих равных я предпочитал их не использовать. Если же выгода от их использования перевешивала их недостатки, то я их использовал. Однако, я всегда на чашу весов при выборе клал такое их (отсутствия) преимущество как более ясный код.

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

Я тоже предпочитаю писать без можификации переменных если это возможно. Но в "если это возможно" я вкладываю ряд факторов от удобства до производительности. И часто бывает так что эти факторы важнее. Да и "без" я тоже понимаю по своему. Я не считаю, например, побочные эффекты вроде переменной цикла проблемой. Для меня она часть вражения паттерна. Не считаю так же проблемаи циклы. Часто они более выразительны. У меня очень много кода выглядит вот так:

def comparer(x, y)
{
    def (x, y) = (x.BodyLocation, y.BodyLocation);
    if (x.Line == y.Line) x.Column - y.Column else if (x.Line > y.Line) 1 else 0
}
// Filter member whith this fileIndex, convert list to list[MemberBuilder] and sort the result list.
def fileMembers = builder.GetDirectMembers().Map(m => m :> MemberBuilder).Filter(fun(m)
    { m.BodyLocation.FileIndex == fileIndex }).Sort(comparer);

foreach (member in fileMembers)
{
    addLocation(nodes, member.ToString(), " ", member.Location);
    addLocation(currNode.Nodes, "BodyLocation", " ", member.BodyLocation);
}

Это код императивный или функциональный? С побочным эффектами тут все ОК. Без них GUI фиг сделаешь.
Зачем мне отказываться от того ради чего я все это делаю?

Удобнее вызвать функцию — возову ее. Нет — создам цикл.

Примеры с паттерн-матчинком в forach-ях я уже приводил. Повторяться не буду.

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

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

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

VD>Значит на счет Лиспа ты согласен. А "не хуже" не значит "не лучше".

Да есть языки которые лучше лиспа

Может и лучше, к сожалению моих умственных способностей не хватило до конца справится с рефалом

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

VD>Не факт. Думаю матерый орел и на Яве уделает на большом проекте средненького программиста на любом языке.
На любом вряд ли.

VD>Для Лиспа и Форта сахарам является все кром базовых вещей. Определение я давал не раз. Да и в Вики оно мало чем отличается.

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

FR>>У меня и в мыслях не было ставить тебя в тупик, я думаю это вообще невозможно

VD>А зачем задавать вопрос на который тебе и так знаком ответ? Зачем приводить в качестве примера языки со встроенным метапрограммированием?
А там даже мета не так важно, даже без макросов на той же схеме получаются вполне компактные программы, меня это даже удивило.
Мне ответ не был известен. Хотелось узнать что ты понимаешь под словом сахар, похоже не судьба.

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

L>>Дело в том, что твой термин — это только твой термин. Если ты называешь ФВП сахаром, то давай я их буду называть их классами и скажу — я же четко определил значение термина! Давай все таки пользоваться устоявшейся терминологией, а не то, что мы придумываем по ходу разговора.

VD>А я и пользуюсь устоявшимеся значениями.

Я тебе давал ссылку на википедию, вот еще на каннингамовскую вики: http://c2.com/cgi/wiki/fullSearch?SyntacticSugar

Ну не сахар ФВП ни разу.

VD> Я не виноват, что кое-то думает по другому. Более тог я тебе скажу, что ты и термин ФВП испльзуешь неверно. Он означает всего лишь возможность передать функции в качестве параметра. А это делается даже в С. Так что ты под термином ФВП подразумеваешь термины: 1) замыкание, 2) анонимные функции/лямбды, 3) локальные фукнции.

Я не понимаю под ФВП 1,2,3. Это ты неверно используешь ФВП. ФВП — это не "всего лишь" возможность передать функцию в качестве параметра.
Это также и возможность получения функции в качестве результата. О замыканиях, лямбдах и прочем я не говорил.

VD>Но я до твоих слов не докапываюь, так как опнимаю о чем ты ведешь речь.

Потому что я использую верные термины?

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

VD>Это ты изменил свою позицию. Вроде бы недавно ты говорил, что языки с побочными эффектами вообще ФЯ то называться не могут.

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

VD>Я тоже предпочитаю писать без можификации переменных если это возможно. Но в "если это возможно" я вкладываю ряд факторов от удобства до производительности. И часто бывает так что эти факторы важнее.

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

VD>Зачем мне отказываться от того ради чего я все это делаю?

Незачем.

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

Пфф... Влад, я не о коде говорю, честно-честно.

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

VD>Для Лиспа и Форта сахарам является все кром базовых вещей. Определение я давал не раз. Да и в Вики оно мало чем отличается.

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

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

L>Я тебе давал ссылку на википедию, вот еще на каннингамовскую вики: http://c2.com/cgi/wiki/fullSearch?SyntacticSugar

Чем тебе не понравилось:

Constructs that have been added to a language in order to make life easier for programmers.

Very often, they improve writability a lot more than readability!

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

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

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

L>>Я тебе давал ссылку на википедию, вот еще на каннингамовскую вики: http://c2.com/cgi/wiki/fullSearch?SyntacticSugar

VD>Чем тебе не понравилось:
VD>

Constructs that have been added to a language in order to make life easier for programmers.
Very often, they improve writability a lot more than readability!

Понравилось понравилось — это подходит к обоим определениям — и твоему и ландиновскому, так что спорить тут не о чем, кроме того, что изначально термин все таки придумал он.

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

Ну так "to make life easier for programmers"! У них есть хороший пример: a[i] вместо *(a + i)

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

L>Ну так "to make life easier for programmers"! У них есть хороший пример: a[i] вместо *(a + i)

И что a[i] не выразительнее? Тогда весь вопрос в том, какой смысл вкладывать в термин "выразительность".

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

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

VD>И что a[i] не выразительнее? Тогда весь вопрос в том, какой смысл вкладывать в термин "выразительность".

Выразительность — это ясность передачи мысли, я полагаю.
В любом случае a[i] — выразительнее для кода, но не для исходного формализма.
Применение ФВП же вместо классов относится к выразительности формализма, а не кода.

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

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

VD>>И что a[i] не выразительнее? Тогда весь вопрос в том, какой смысл вкладывать в термин "выразительность".

L>Выразительность — это ясность передачи мысли, я полагаю.

Ясность — она и есть ясность. Например, i++ ничем не яснее чем i += 1 или i = i + 1, а даже наооборот. А выразительность — это:

ВЫРАЗИТЕЛЬНЫЙ, -ая, -ое; -лен, -льна. 1. Хорошо выражающий что-н., яркий по своим свойствам, внешнему виду. Выразительная речь. Выразительное лицо. Выразительные глаза. 2. Многозначительный, как бы сообщающий что-н. В. взгляд. Выразительно (нареч.) посмотреть. II сущ. выразительность, -и, ж.

(с) Ожегов.

L>В любом случае a[i] — выразительнее для кода, но не для исходного формализма.
L>Применение ФВП же вместо классов относится к выразительности формализма, а не кода.

Применять ФВП можно в С. Но это не выразительно. А сахар в виде замыканий и лямбд делает применение ФВП выразительными. Андестенд?

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

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

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

как сказал один мой товарищ "придумали очередной баян и радуются"

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

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

L>>Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь.

WH>Легко.

А где во втором случае ФВП?

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

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

L>Ну и где там ФВП, то??
Вобщето _N_combine1445 принимает функцию и возвращает функцию.

L>Покажи что замыкания — сахар.
Я уже показал вариант с сахаром и без...

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

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

FR>Вроде просили показать как сделать лямбду,

Просили функции высшего порядка. Они в С есть штатно. Называются указатели на функции. Так что тут и показывать нечего.

А показал он реализацию замыканий и вложенных фунций на базе классов. То что кто-то не хочет это понимать — это проблемы его личного мозга.

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

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

L>Неа, он принимает не функцию, а объект, который эмулирует функцию, и возвращает тоже объект.
L>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий

На C/С++ устроит?

int f1(int i)
{
  return i * 2;
}

int f2(int i)
{
  return i + 20;
}

int fun1(int i);

typedef int (*FuncTypeIntToInt)(int);

FuncTypeIntToInt hof(FuncTypeIntToInt f)
{
  return f2;
}


void main()
{
    FuncTypeIntToInt funcVariable = hof(f1);
  printf("%d\n", funcVariable(3));
}

L>>>Покажи что замыкания — сахар.
WH>>Я уже показал вариант с сахаром и без...

L>Первое был вариант с замыканиями, а не вариант с сахаром.

Ну, согласен, что замыкания это сахар?

L> От того, что их можно сэмулировать они не становятся сахаром.

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

L> Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?

Верно. Потому для ассемблера паттерном является if и while. И средствами некоторых макро-ассемблеров они с успхом воспроизводились.

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

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

VD>В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.

Какие?

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

FR>реализация:
FR>

FR>Disassembly of addI:
FR>  7           0 LOAD_CLOSURE             0 (i)
FR>              3 LOAD_CONST               1 (<code object <lambda> at 01A17C20, file "D:\temp\Module2.py", line 7>)
FR>              6 MAKE_CLOSURE             0
FR>              9 RETURN_VALUE        
FR>             10 LOAD_CONST               0 (None)
FR>             13 RETURN_VALUE        
FR>

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

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

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

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

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

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

IT>>А если будет что-то посложнее такой примитивщины и компилятор не сможет её заинлайнить?

FR>Компилятору в данном случае плевать на сложность, так как VM напрямую подерживает такую сущность как closure.

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

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

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

FR>Угу, а тут Re[31]: ФП против ООП таже самая реализация на x86 ассемблере (хороший компилятор у окамла, оптимизирующий

) если кто-то видит между этими реализациями большую разницу у того тоже проблемы с пониманием

Так тебе тогда надо сравнивать свой ассемблер не с MSIL, а с тем, что сгенерирует JIT.

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

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

IT>Так тебе тогда надо сравнивать свой ассемблер не с MSIL, а с тем, что сгенерирует JIT.

не вижу разницы.

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

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

IT>>>А если будет что-то посложнее такой примитивщины и компилятор не сможет её заинлайнить?

FR>>Компилятору в данном случае плевать на сложность, так как VM напрямую подерживает такую сущность как closure.

IT>Ты опять не понял. Заинлайнить локальную функцию можно не всегда. Например, мне интересно, что получится в твоём случае при передаче замыкания в качестве параметра.

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

def addI(i):
    return lambda x : x + i

print addI(123).func_closure
print addI(234).func_closure

выведет:

(<cell at 0x008903B0: int object at 0x008C1084>,)
(<cell at 0x008903B0: int object at 0x008C0EF8>,)

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

VD>>В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.

А>Какие?

http://nemerle.org/

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

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

VD>>На C/С++ устроит?

FR>Это не замыкание,

Как догадался?

FR>нет захвата свободных переменных.

А кто-то просил замыкания? Просили ФВП. Если у тебя снова проблемы с терминологией, то я тут не причем.

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

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

FR>Не получается использовать не хватает семантики,

Да получается, получаеся. Риво но получается. А чтобы было прямо и нужен сахар. Вот замыкания и лямбы это и есть сахар.

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

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

L>Ага, но все равно это было бы эмуляцией замыкания. И в любом случае не сахаром — нет исходного не подслащенного варианта.

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

Вы меня извините, но тема пошла на третий круг. Я за сим откланиваюсь.

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

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

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

L>>>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий

VD>>На C/С++ устроит?

L>Хорошо, представим что это замыкания. Ну, предположим.

Зачем? Ты просил ФВП? Ты их получил? В чем еще вопрос?

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

L>Нет. Сахар подслащивает код, предоставляя более сладкую возможность для уже имеющейся.

А что не имеется то? Все что нужно имеется в С.

L>Назови мне что подслащивают показанные тобой ФВП? Какой код был бы не сладким, но семантически эквивалентным?

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

L>Покажи мне исходные средства языка с той же семантикой, но выглядящие менее сладко?

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

Ладвно. Эта музыка будет вечна. Так что батарейки лучше не менять.

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

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

L>А на фига это показывать???

Чтобы ты видил, что они легко выражаются с помощью паттернов в ООЯ.
А раз так, то нет проблем добавить подобный сахар в любой ООЯ. Единственная серьезная проблема — это время жизни. Тут лучше иметь в языке GC.

VD>>То что кто-то не хочет это понимать — это проблемы его личного мозга.

L>Вот именно

Ты сам собой перемигивашся?

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

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

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

VD>>>Просили функции высшего порядка. Они в С есть штатно. Называются указатели на функции. Так что тут и показывать нечего.

FR>>Нет просили показать лямбду в виде сахара.

VD>Врешь.

ты

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

FR>>Это не замыкание,

VD>Как догадался?

шибко доГадливый

FR>>нет захвата свободных переменных.

VD>А кто-то просил замыкания? Просили ФВП. Если у тебя снова проблемы с терминологией, то я тут не причем.

Фвп не интерсно, они и так в си есть.
Надо подождать автора, я судил по этой его строке

Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий

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

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

FR>>Не получается использовать не хватает семантики,

VD>Да получается, получаеся. Риво но получается. А чтобы было прямо и нужен сахар. Вот замыкания и лямбы это и есть сахар.

Переведи пожалуйста выделеннное слово

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

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

FR>Ты мне объясни почему ты именно к инлайнингу прицепился?

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

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

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

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

IT>>Так тебе тогда надо сравнивать свой ассемблер не с MSIL, а с тем, что сгенерирует JIT.

FR>не вижу разницы.

А зря. На таком идиотском примере джит может всё нафиг заинлайнить.

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

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

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

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

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

FR>Фвп не интерсно, они и так в си есть.

Их и просили. А ты прежде чем влезать в разговор читал бы внимательнее.

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

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

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

FR>>Ты мне объясни почему ты именно к инлайнингу прицепился?

IT>Я прицепился? Ты там выше про убогость рассуждал и приводил результат на чистом ассемблере. Так вот мне и интересно на сколько всё действительно круто на самом деле, а не на дибильных демонстрационных примерах.

Я просто назвал все как есть, не смогли или не захотели делать и эмулируют.

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

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

Ты про ссылки слышал?
Кстати а в net что будет в этом случае?

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

VD>>>В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.

А>>Какие?

VD>http://nemerle.org/

Т.е. всего один, и тот экспериментальный? И почему в документации по нему говорится только о префиксных формах ++ и --? Где искать постфиксные?

Unary operator for numeric types:
++ prefix increment with void return type
-- prefix decrement with void return type
+ a noop
— negation

Integer types also have the ~ (bitwise negation) defined. Boolean type has ! (boolean negation).

User defined types can have some other operators defined.

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

FR>>Нет просили показать лямбду в виде сахара.

VD>Врешь.

Я, наверное, лучше знаю, что просил:

Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию.

Так что FR прав. А ты опять невнимательно читаешь.

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

FR>>Фвп не интерсно, они и так в си есть.

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

Влад, посторонний человек подумает ведь, что это FR читал невнимательно, а не ты

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

VD>Не эмуляция, а реализация паттерна средствами языка. А сахар это встравиваение паттерна в язык.

Где ты видел такое определение?

VD>Вы меня извините, но тема пошла на третий круг. Я за сим откланиваюсь.

Хозяин — барин.

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

L>>Хорошо, представим что это замыкания. Ну, предположим.

VD>Зачем? Ты просил ФВП? Ты их получил? В чем еще вопрос?

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

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

Т.е. замыкания не сахар?

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

Буква А тоже есть в любом современно языке — она сахар? Или одного этого факта всё таки мало?

L>>Покажи мне исходные средства языка с той же семантикой, но выглядящие менее сладко?

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

Вольхаунд не показал, что именно подслащивает ФВП. Она подслащивает объекты? Ну так это разная семантика.

VD>Ладвно. Эта музыка будет вечна. Так что батарейки лучше не менять.

Нечего сказать?

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

IT>>Я прицепился? Ты там выше про убогость рассуждал и приводил результат на чистом ассемблере. Так вот мне и интересно на сколько всё действительно круто на самом деле, а не на дибильных демонстрационных примерах.

FR>Я просто назвал все как есть, не смогли или не захотели делать и эмулируют.

Что значит не захотели делать?

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

FR>Ты про ссылки слышал?

Ссылки куда?

FR>Кстати а в net что будет в этом случае?

В .NET будет всё тот же объект со всеми захваченными переменными и двумя функциями.

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

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

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

IT>>>Я прицепился? Ты там выше про убогость рассуждал и приводил результат на чистом ассемблере. Так вот мне и интересно на сколько всё действительно круто на самом деле, а не на дибильных демонстрационных примерах.

FR>>Я просто назвал все как есть, не смогли или не захотели делать и эмулируют.

IT>Что значит не захотели делать?

Подержку замыканий виртуальной машиной

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

FR>>Ты про ссылки слышал?

IT>Ссылки куда?

На переменые. Точнее так на каждую связываю переменную формируется так называемая ячейка которая и содержит эту переменную, func_closure это список (вернее tuple) всех исползуемых в замыкании ячеек:

ef tst(x, y):
    return lambda: x + 1,  lambda: x + y,
        
f1, f2 = tst(1, 2)

print f1(), f2()

print f1.func_closure
print f2.func_closure

вывод:

2 3
(<cell at 0x008F4C90: int object at 0x00837088>,)
(<cell at 0x008F4B10: int object at 0x00837470>, <cell at 0x008F4C90: int object at 0x00837088>)

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

FR>>>Я просто назвал все как есть, не смогли или не захотели делать и эмулируют.
IT>>Что значит не захотели делать?
FR>Подержку замыканий виртуальной машиной

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

FR>>>Ты про ссылки слышал?
IT>>Ссылки куда?
FR>На переменые. Точнее так на каждую связываю переменную формируется так называемая ячейка которая и содержит эту переменную, func_closure это список (вернее tuple) всех исползуемых в замыкании ячеек:

Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?

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

FR>>>Нет просили показать лямбду в виде сахара.

VD>>Врешь.

L>Я, наверное, лучше знаю, что просил:

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

Еще вопросы?

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

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

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

FR>>>Фвп не интерсно, они и так в си есть.

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

L>Влад, посторонний человек подумает ведь, что это FR читал невнимательно, а не ты

Так и есть. Ты упорно свои слова. Ты постоянно говоря о лябдах но аппелировал к ФВП. У тебя эта абревиатура (редко используемая надо сказать) уже самое частое слово.

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

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

L>Вопрос — где исходная конструкция, которую подслащивают ФВП?

Для особо упертых повторяю последний раз. ФВП есть в любом языке. А их подслащивания есть только в некоторых. О том и речь. Как вам не обидно и прискорбно об этом думать, но один из языков с подслащиванеим ФВП — это C#. В нем есть и лябды, и замыкания. Только в 2.0 синтаксис слишком пухлый. В 3.0 уже лучше чем во многих ФЯ. Так что расслабьтесь. ФП это такой же набор паттернов как и ООП, и применять его можно почти везде. А удобство его применения определяется наличием сахара/урощения реализации паттернов.

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

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

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

VD>>>>В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.

А>>>Какие?

VD>>http://nemerle.org/

А>Т.е. всего один, и тот экспериментальный?

Одного достаточно чтобы придраться к славам. И уверен, что он не один. Просто я не "пылиглот"

.

А> И почему в документации по нему говорится только о префиксных формах ++ и --? Где искать постфиксные?

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

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

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

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

L>>Вопрос — где исходная конструкция, которую подслащивают ФВП?

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

forth, fortran, старый паскаль, бейсик?

VD>А их подслащивания есть только в некоторых. О том и речь. Как вам не обидно и прискорбно об этом думать, но один из языков с подслащиванеим ФВП — это C#. В нем есть и лябды, и замыкания.

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

VD>Только в 2.0 синтаксис слишком пухлый. В 3.0 уже лучше чем во многих ФЯ. Так что расслабьтесь. ФП это такой же набор паттернов как и ООП, и применять его можно почти везде. А удобство его применения определяется наличием сахара/урощения реализации паттернов.

Угу, сами себе придумаем терминалогию и можем доказать все.

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

IT>Т.е. для этого создаётся не один объект как в .NET, а целый список — по одному объекту на каждую захваченную переменную?

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

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

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

IT>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?

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

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

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

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

FR>forth, fortran, старый паскаль, бейсик?

У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?

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

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

К>То есть, компилятор "мыслит" в терминах лямбд.

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

Собственно я и говорю, что сахар — это очень относительное понятие. Все эти "гы-гы" по поводу того что if это тоже сахар не более чем недомыслие. Для ассемблера сахаром является почти любая конструкция С и уж темболее С++. Хотя был TASM с ООП, но это скорее экзотика когда в такой низкоуровневый язык попытались всунуть ООП.

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

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

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

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

FR>При вашем понимании сахара GC тоже сахар

Нет. GC тоже сахар при вашем понимании нешего понимания. Но судя по всему наше понимание и ваше понимание нашего понимания удаляются друг от друга на очень большой скорости.

IT>>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?

FR>На питоне да, в ocamle нет. Я уже приводил ассемблерный код в который вырождается простое замыкание на окамле.

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

IT>>А ты сам подумай

FR>Лучше ты когда думаешь снимай NET'овые очки

Я вот не пойму, это ты неудачно попытался нахамить или пошутить?

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

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

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

FR>>При вашем понимании сахара GC тоже сахар

IT>Нет. GC тоже сахар при вашем понимании нешего понимания. Но судя по всему наше понимание и ваше понимание нашего понимания удаляются друг от друга на очень большой скорости.

То есть мы наконец нашли единственную несахарную конструкцию?
Удивительное открытие, может разъяснишь?

IT>>>Правильно ли я понимаю, что в приводимых тобой в качестве примеров языках, переменные никогда не выделяются на стеке, а только в хипе, даже если это простой int?

FR>>На питоне да, в ocamle нет. Я уже приводил ассемблерный код в который вырождается простое замыкание на окамле.

IT>Т.е. в осамле простой int создаётся на стеке. И как теперь будут работать ссылки на него в замыканиях, если это замыкание будет передано куда-либо вне вызывающей функции?

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

IT>>>А ты сам подумай

FR>>Лучше ты когда думаешь снимай NET'овые очки

IT>Я вот не пойму, это ты неудачно попытался нахамить или пошутить?

Это я почти серъезно и без хамства.

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

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

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

К>Подозреваю, что здесь спор вот в чём.
К>Любую фичу можно сделать сахаром, если она прикручена к языку, который без неё обходится.

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

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

IT>>Нет. GC тоже сахар при вашем понимании нешего понимания. Но судя по всему наше понимание и ваше понимание нашего понимания удаляются друг от друга на очень большой скорости.

FR>То есть мы наконец нашли единственную несахарную конструкцию?
FR>Удивительное открытие, может разъяснишь?

Да вроде тут уже обсуждали. Например, на C++ полноценные замыкания невозможно сделать из-за отсутствия контроля времени жизни объектов самим рантаймом.

IT>>Т.е. в осамле простой int создаётся на стеке. И как теперь будут работать ссылки на него в замыканиях, если это замыкание будет передано куда-либо вне вызывающей функции?

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

Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?

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

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

FR>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).
FR>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.

Минус за это.

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

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

IT>Код из рефлектора не просто не "не катит", он явно и наглядно демонстрирует, что это всё сахар. Не видеть этого нужно очень очень сильно хотеть. Вот примерно как ты

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

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

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

VD>>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?

FR>А у тебя?

Месье блюдет национальные традиции или отвечая вопросом на вопрос он пытается уйти от ответа?

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

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

FR>С этим можно согласится, но здесь утверждают что всё (кажется кроме GC это похоже некая священная корова) сахар.

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

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

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

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

FR>>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).

IT>Ключевое слово я выделил. Смысл в том, что без стопроцентной поддержки со стороны runtime — это всё только разговоры. Мне достаточно вернуть не объект функтор, а указатель на него и вся твоя стройная теория рассыпется.

А ты не возвращай указатель. И то что все рассыплется это нормально для C++

FR>>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.

IT>И это тоже, что лишь доказывает, что если язык/среда выполнения не позволяют, то никакой сахар не уже поможет.

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

IT>>>Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?

FR>>Только тем что реализовать можно по разному, даже в NET при желании можно сделать не через объекты, а как в окамле или питоне. И поэтому код из рефлектора никак ни катит в качестве доказательства того что те же замыкания являются синтаксическим сахаром.

IT>Код из рефлектора не просто не "не катит", он явно и наглядно демонстрирует, что это всё сахар. Не видеть этого нужно очень очень сильно хотеть. Вот примерно как ты

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

FR>Кстати задавая этот вопрос ты занимался именно уходом от ответа

FR>Вообще пора закруглятся.

То есть на вопрос я ответ не получу? Тогдя я не считаю нужным отвечать на твои вопросы.

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

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

VD>То есть на вопрос я ответ не получу? Тогдя я не считаю нужным отвечать на твои вопросы.

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

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

FR>А вопрос то был?

Re[37]: ФП против ООП

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

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

L>>Я, наверное, лучше знаю, что просил:

VD>

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

Эти слова как то доказывают, что я не знаю, чего просил??
Почитай на что отвечал WolfHound, и что ему ответил FR.

Дурацкий какой то спор получается уже...

Здравствуйте, VladD2, Вы писали:

VD>Ты постоянно говоря о лябдах но аппелировал к ФВП.

Покажи, пожалуйста, хоть одно место.

Здравствуйте, VladD2, Вы писали:

L>>Не просил я ничего эмулировать. Я просил показать, что ФВП сахар.

VD>Зачем?

Затем, что ты это утверждал.

L>> Или замыкания. Или лямбды.

VD>Это я тебе показал.

VD>Пчитай еще на досуге Паттерны суть слабости языков программирования. Там как раз о том же говориться.

Почитаю, спасибо.

VD>Просто вам подсевшим на ФЯ не вызвает проблем говорить о недостатках не ФЯ м не хочется признать что ФЯ сами не предоставляют тучи сахара (не реализуют паттернов). Только это ОО-сахар, ОО-паттерны.

А вам, подсевшим на ОО, тяжело смириться с тем, что ФВП — не сахар.

L>>Вы показали, что их можно сэмулировать. Поздравляю!

VD>Их можно вырзить другими средствами языка. Никакой эмуляции.

Это одно и то же. Эмуляция — это имитация поведения (функционирования) чего то с помощью другого чего то. Так что это другое что то ведет себя как первое.

Здравствуйте, VladD2, Вы писали:

L>>А на фига мне это видеть??

VD>Ты споришь с очевидным. Не очевидно это для тебя только потому, что ты упорно не хочешь видеть.

Нет, я стараюсь быть объективным. Из определения сахара следует, что лямбда не сахар.

L>>Влад, то что это можно добавить, я как бы догадываюсь. Спор был о том является ли лямбда сахаром.

VD>Средствами языка выражается? Да. Добавить можно не меня ничего? Несомнно. О чем тут можно спорить?
VD>Лябда есть реализация паттерна который и так можно получить, но при этом будет больше кода и каждый раз прийдется следить за саблюдением паттерна. Встраивание паттера в язык увеличивает количество сахара.

Ага. Значит, если некий паттерн, который мы рисуем на языке, мы будем выражать с помощью новой конструкции, то эта конструкция становится сахаром. Я имею в виду — не было раньше ФВП, мы эмулировали их объектами, появились — мы стали ими пользоваться. Это называется сахаром, потому что раньше мы могли их выразить другими средствами языка. Про семантическую эквивалентность и выразительную мощь забудем.

Хорошо, пусть это будет определением твоего понятия сахара.

VD>В общем, не хотел снова влезать в этот бесцельнысй сопр. Логика все равно в нем давно отсуствует. А религия меня не интересут. Наверное зря я все таки влез. Ну, да ладно...

Религия меня тоже не интересует.

Здравствуйте, lomeo, Вы писали:

L>Затем, что ты это утверждал.

Я утверждал что сахар — это замыкания и лямбды.
Так же утверждал что слова "оверхэд ООП" — это бессмыслица.

В общем-то ты не привел ни одного аргумента против кроме того что тебе кажется что это не так.

L>А вам, подсевшим на ОО, тяжело смириться с тем, что ФВП — не сахар.

А я ни на что не подсаживался. Я рассматриваю все не более чем как приемы программирования, а наличие средств поддержки этих приемов в языке как полезный сахар этого языка упрощающий мне жизнь. Только и всегт. Так что когда я познакомился с ООП, то с удовольствием стал применять его приемы в работе. Когда познакомился с ФП, то и его приемы стал с удовольствием применять. И паттерны тоже. И все остальное тоже. Так что я за более богатые языки позволяющие выражать мысли кратче и с использованием большего количества выразительных средств.

Это ты тут доказываешь какой-то выдуманный оверхэд ООП. А я просто использую ООП там где от него есть реальная польза. А на термины мне в обще-то начхать. Сахар, паттерны, фичи. Все равно. Лиш бы было они были.

L>Это одно и то же. Эмуляция — это имитация поведения (функционирования) чего то с помощью другого чего то.

А где ты видишь имитацию? Это оно и есть ФП. Только выражается без нужных фич (встроенных паттернов или сахара, как тебе удобнее).

Так что ты просто не верно смотришь на проблему. Ты считаешь эмитацией банальное использование паттерна не встроенного в язык явно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Mikl Kurkov, Вы писали:

MK>Есть такое понятие — лингвистические абстракции (lingustic abstractions). Изначально у нас есть некий базовый язык — по сути описание вычислительной модели. Как правило хорошо поддающийся теоритическим исследованиям, но мало пригодный для программирования на нем человеками. Для повышения удобства начинаем расширять базовый язык, при этом расширения транслируются в простой базовый синтаксис. Так вот эти расширения и разделяют на лингвистические абстракции и синтаксический сахар.

До этого момента вопросов практически нет. Согласен с определениями. Разве что хочу заметить, что для разных языков список таких абстракций может быть разным. И еще что одни бстракции могут выражаться другими. Так что разумнее вести речь о неком минимальном наборе абстракций через которые можно вырзить другой более широкий набор абстракций. Вот он то и будет являться сахаром.

MK>Основное отличие — лингвистические абстракции не привязаны к конкретному языку, примеры — оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п.

А вот тут уже не согласен. Конструкции вроде "оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п." могут отсуствовать в языке и тогда они будут синтаксическим сахаром для этого языка, а могут являться его базой.

Отличным примером этого служит Немерле где понятие базы языка четко выделено. В языке нет "операторов условного перехода if, list comprehensiions, карринга, оператор for, foreach, а так же, return, continue, break и т.п.". За-то есть замыкания, локальные функции, лябды, изменяемые переменные, оператор match, и блоки (позволяющие прервать нормальный ход выполнения функции (замена return, continue и break), классы, варианты (алгеброические типы), перечисления, методы, свойства и атрибуты (расширение методанных как в C#). На этой базе те самые отсуствующие сущности: "операторов условного перехода if, list comprehensiions, карринга, оператор for, foreach, а так же, return, continue, break и т.п." реализуются с помощью маросов. Причем сам факт реализации на макросах говорит отом, что сущности являются тем самым сахаром.

Так вот на самом деле набор базовых фич может быть и другим. В общем-то замыкания и лямбды тоже можно заменить на более базовые вещи — классы. Но это будет уже другой язык.

MK> Синтаксический же сахар это расширение синтаксиса базового языка не вносящее новых абстракций, просто служащее сокращению кода и повышения его читабельности. При этом сахар специфичен для каждого языка и более того среди разных групп разработчиков имеются свои представления о кратком и читабельном коде

Вот именно об этом я и говорю! Забвно, что lomeo поставил тебе оценку, но при этом во всю спорит со многими тем о чем ты тут сказал.

MK>Очень хорошо и подробно об этом написано в CTM.

Осталось выяснить что такое CTM.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

VD>>>Ты постоянно говоря о лябдах но аппелировал к ФВП.

L>>Покажи, пожалуйста, хоть одно место.

VD>Например, здесь ты ведешь речь об ФВП, но реально подразумеваешь замыкания и лямбды. Иначе твои слова бессмысленны. Ведь ФВП по их классическому определению есть почти в любом языке. Тогда о каких приемущесвах и ФП идет речь. В других языках просто не делают мантру из повседневных вещей. Мне лично по фигу называется ли нечто умным словом ФВП или просто колбэками.

Влад ты ошибаешься, я веду речь именно об ФВП. (map display list) — это применение ФВП map.
Преимущество ее по сравнению с циклом foreach в отсутсвии дополнительной сущности — идентификатора элемента списка, а по сравнению со списком for — ещё и счётчика цикла. И я не вёл речь о языке, поэтому то, что ФВП есть в любом языке — это не ко мне.

Когда я говорю что главные отличительные черты функционального подхода — это ФВП и отсутствие сайд-эффекта, то под ФВП я понимаю именно ФВП. А не лямбды и замыкания. И пусть ты называешь их колбэками.

Повторяю — во всех своих сообщениях, говоря об ФВП, я подразумевал ФВП. Даже если от этого мои слова казались тебе бессмысленными.

Здравствуйте, VladD2, Вы писали:

L>>А вам, подсевшим на ОО, тяжело смириться с тем, что ФВП — не сахар.

VD>А я ни на что не подсаживался.

Я тоже. Но ты начинаешь развешивать ярлыки.

VD>Это ты тут доказываешь какой-то выдуманный оверхэд ООП.

Да, ОО более многословен. Он использует больше сущностей.

VD>А я просто использую ООП там где от него есть реальная польза.

Аналогично. Может я на ОО тоже подсел?

L>>Это одно и то же. Эмуляция — это имитация поведения (функционирования) чего то с помощью другого чего то.

VD>А где ты видишь имитацию? Это оно и есть ФП. Только выражается без нужных фич (встроенных паттернов или сахара, как тебе удобнее).
VD>Так что ты просто не верно смотришь на проблему. Ты считаешь эмитацией банальное использование паттерна не встроенного в язык явно.

Не хочу. А то будем выяснять что такое эмуляция и что такое имитация

Да и с твоим определением сахара вроде разобрались, чего уж там дальше?

Здравствуйте, lomeo, Вы писали:

L>Когда я говорю что главные отличительные черты функционального подхода — это ФВП и отсутствие сайд-эффекта, то под ФВП я понимаю именно ФВП. А не лямбды и замыкания. И пусть ты называешь их колбэками.

А, ну, мы плавно вернулись обратно к главенствованию неизменямости данных. Ясно.

- А где вы деньги берете?
— В тумбочке.
— А в тумбочке откуда деньги берутся?
— Жена кладет.
— А жена где берет?
— Я даю.
— А вы где берете?
— Я же уже говорил!...

Вот в С есть и ФВП и "айдэфеты". И что? И никаких проблем по этому поводу.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, lomeo, Вы писали:

L>Я тоже. Но ты начинаешь развешивать ярлыки.

Погоди. А кто о мифическом ООП-оверхэде говорил? Я?

VD>>Это ты тут доказываешь какой-то выдуманный оверхэд ООП.

L>Да, ОО более многословен. Он использует больше сущностей.

Значит таки подсаживлася.

VD>>А я просто использую ООП там где от него есть реальная польза.

L>Аналогично. Может я на ОО тоже подсел?

А ты его используешь? Это видимо из-за того что он более многословный, а вам за количество символо платят. Да?

L>Да и с твоим определением сахара вроде разобрались, чего уж там дальше?

Интересный у вас подход к разбирательству. А еще о ярлыках веч ведете...

Мы тут с полностью мифически ОО-оверхэдом разобраться то не можем.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

MK>>Очень хорошо и подробно об этом написано в CTM.

VD>Осталось выяснить что такое CTM.

Уж не Concepts, Techniques, and Models of Computer Programming ли?

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, VladD2, Вы писали:

L>>Когда я говорю что главные отличительные черты функционального подхода — это ФВП и отсутствие сайд-эффекта, то под ФВП я понимаю именно ФВП. А не лямбды и замыкания. И пусть ты называешь их колбэками.

VD>А, ну, мы плавно вернулись обратно к главенствованию неизменямости данных. Ясно.

Ну так ты убедился, что когда я говорил об ФВП, я говорил об ФВП или нет?

Анекдот неплохой, спасибо.

Здравствуйте, VladD2, Вы писали:

VD>Я убедился, что с догмами спорить безсполезно. Одна сменяет другую.

Ага, я помню, ты себе мир придумываешь и тебе в нём хорошо жить. Вот и про ФВП ты придумал, что я под ними что то другое подразумевал. И все остальные выводы относительно меня оказались ложны. Ну, а что ж ты хотел? Мир то придуманный.

VD>Если же ты говорил о ФВП, то твои слва лишены всяческого смысла, так как ФВП по определению есть в большинстве языков.

А я не говорил о языках, я говорил о подходах, если ты этого до сих пор не понимаешь, что я могу поделать?

Здравствуйте, lomeo, Вы писали:

L>Ага, я помню, ты себе мир придумываешь и тебе в нём хорошо жить. Вот и про ФВП ты придумал, что я под ними что то другое подразумевал. И все остальные выводы относительно меня оказались ложны. Ну, а что ж ты хотел? Мир то придуманный.

Ой, как мне это тебя напоминает.

L>А я не говорил о языках, я говорил о подходах, если ты этого до сих пор не понимаешь, что я могу поделать?

А я тебе говорил, что подходы хороши к месту, и прикливать к ним ярляки минимум не разумно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

L>>А я не говорил о языках, я говорил о подходах, если ты этого до сих пор не понимаешь, что я могу поделать?

VD>А я тебе говорил, что подходы хороши к месту, и прикливать к ним ярляки минимум не разумно.

У этого подхода такой то недостаток — это ярлык?

Здравствуйте, Mikl Kurkov, Вы писали:

MK>

Ну вот же в следующем предложении я говорю что лингвистические абстракции не привязаны к какому-то языку. Это кирпичики, блоки из которых и строятся языки. Естественно что набор абстракций в разных языках разный. И реализуются они по разному. Но это не повод смешивать их с синтаксическим сахаром. Это разные понятия. О чем я и пытался рассказать.

ОК. Есть ли описание предложенной тобой терминологии? И где тогда лежит грать между сахаром и "лингвистическими абстракциями"?

MK>>>Основное отличие — лингвистические абстракции не привязаны к конкретному языку, примеры — оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п.

VD>>А вот тут уже не согласен. Конструкции вроде "оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п." могут отсуствовать в языке и тогда они будут синтаксическим сахаром для этого языка, а могут являться его базой.

MK>Опять же и синтаксический сахар и лингвистические абстракции — суть расширения синтаксиса базового языка. Но они имеют одно важное отличие. И заключается оно в том, что синтаксический сахар не привносит в язык новых абстракций.

Определи, плиз, по четче, понятие "новых абстракций".

MK> Он просто немного меняет синтаксис, как правило позволяя пропускать какие-то ключевые слова или использовать более краткую форму какой-либо конструкции.

foreach является новой абстракцией в этой терминалогии?

MK> Этим изменениям и названия-то как правило дать нельзя. И никакой разницы что есть в базовом языке, а чего нету. Мы же говорим о расширении. Ну да есть у нас в базовом языке такое понятие как функция (в смысле процедура, возращающая значение) ну это всего лишь означает что такое расширение нам не понадобится. А вот например в Mozart\Oz есть только процедуры и функции в нем — это расширение , которое транслируется потом в базовый синтаксис. И расширение это правильнее называть лингвистической абстракцией,а не сахаром, т.к. понятие функции достаточно абстрактно и целостно.

Откровенно говоря не вижу этой грани. Тогда нужно просто выбросить понятие сахара как недетерминированное и пользоваться понятием "лингвистическая абстракция".

MK>Факт реализации на макросах ни о чем не говорит. Ну какая разница на макросах это сделано или доработкой компилятора.

Это самоценно, так как выделяет базис языка (то есть вещи без которых нельзя обойтись без потери полноты по Тьюрингу), и есть вещи которые делают язык выразительнее, богаче. Я бы такие вещи и называл сахаром. То есть для меня сахар это то что не входит в обязательный базис языка.

Твое поерделение "лингвистической абстракции" не подразумевает такое деление и автоматом для меня является ущербным (не отрахающей той сути о которой я говорю).

MK> Важен сам факт расширения базового языка, и что при этом сам базовый язык остался неизменным и все наши знания о нем остаются в силе. А то что ты смог назвать все эти сущности по именам говорит о том что это как раз лингвистические абстракции, а не сахар.

Я все сущьности языка могу как-то назвать. Если взять классический пример сахара, то "++" — это инкремент на еденицу, "+=" — это инкремент на Х, а "х + у" — это сложение. По твоей логике это тоже не должно являться сахаром. Но ты вроде говорил, что это все же сахар. Неувязочка?

VD>>Вот именно об этом я и говорю! Забвно, что lomeo поставил тебе оценку, но при этом во всю спорит со многими тем о чем ты тут сказал.

MK>Я попытался вникнуть в суть ваших разногласий, но ,честно говоря, быстро потерял нить. Как я понял, главная претензия к тебе что ты слишком широко толкуешь понятие синтаксического сахара.

Воообще-то понятие сахар я использую исключительно для того, чтобы иметь емкий термин выражающий дополнительные (сверх минимума) возможности языка. Другого термина не предложено, да и я много раз дал определение того что я понимаю под этим термином. Так что вроде бы недопонимания быть не должно. Но суть спора в другом. Изначально спор был о неком (мифическом с моей точки зрения) оверхэде ООП по сравнению с ФП. Причем в ходе спора стало четко видно, что речь идет не ФЯ и ООЯ, а именно о парадигмах ООП и ФП.

Так что борьба с термином "сахар" является на мой взгляд всего лишь способом уйти от исходной темы. Или неумением принимать локальную терминалогию.

Термин "лексическая абстракция" хотя и близок к приемлемому все же не отражает сути (он по твои словам не позволяет поделить эти самые абстракции на базовые и расширения), а стало быть не пригоден для выражения мыслей по данному вопросу. Так что нужен или другой принцип или все же испльзовать тот самый термин сахар. По-моему, с указанными огворками он более чем приемлем. Хотя я лично не наставиваю. Если будт более подходящий термин, то я с радостью его прийму.

MK> Почти все из того что ты называешь сахаром является лингвистическими абстракциями. И я конечно разделяю твою радость от того что многие возможности ФЯ можно реализовать в других языках, но не согласен с выводом что все их преимущества на этом заканчиваются. Но новый флейм по этому поводу думаю раздувать не стоит.

Я не говорил о том где заканчиваются приемущества. Я объяснял, что ФП-абстракции (давай это так называть) такие же реализации паттернов как и ОО-абстрации. И что говорить о оверхеде парадигм вообще говоря глупо. Можно только говорить о уместности выбора той или иной парадигмы для того или иного проектного решения и о количестве и мощьности реализованных в языке паттетнов.

Грубо говоря я говорил о том, что если взять некий сильно урезанный язык (например, С), то даже при выборе подходящей парадигмы (скажем, ФП), мы получим невероятный оверхед просто в следствии того, что язык не обладает нужными "абстракциями" и их приходится выражать более универсальными, но менее выразительными средствами. Точно так же будут обстоять дела с применением ООП в ФЯ не поддерживющих ООП и темболее в чистых ФЯ.

MK>Вот кстати отвлекусь от темы, но не могу удержаться от цитаты
MK>

MK>Возьмем наши споры. Они характеризуются чрезвычайной расплывчатостью, мы очень скоро уходим от основной темы. Это наша черта. Возьмем наши заседания. У нас теперь так много всяких заседаний, комиссий. До чего эти заседания длинны, многоречивы и в большинстве случаев безрезультатны и противоречивы! Мы проводим многие часы в бесплодных, ни к чему не ведущих разговорах. Ставится на обсуждение тема, и сначала обыкновенно и благодаря тому, что задача сложная, охотников говорить нет. Но вот выступает один голос, и после этого уже все хотят говорить, говорить без всякого толку, не подумав хорошенько о теме, не уясняя себе, осложняется ли этим решение вопроса или ускоряется. Подаются бесконечные реплики, на которые тратится больше времени, чем на основной предмет, и наши разговоры растут, как снежный ком. И в конце концов вместо решения получается запутывание вопроса.

MK>Сказано в 1918 году академиком Павловым в его лекции «О русском уме» на вручении Нобелевской премии.

Есть такое дело. И именно по этому нужно стремиться к конструктиву. Но это стремление обязательно должно быть обоюдным. Главное чтобы разговор не превращался в упирание рогом, повторение заученных чужих слов (религиозных проповедей) и основывался на аргументации, а не незыблемом мнении о врености своего мнения. Я готов к этому.

MK>>>Очень хорошо и подробно об этом написано в CTM.

VD>>Осталось выяснить что такое CTM.

MK>

Ну батенька, я уж думал что в "Декларативном программировании" все знают эту аббревиатуру, как и SICP. Это "Concepts, Techniques, and Models of Computer Programming", авторы Peter Van Roy и Seif Haridi.

1. Совершенно естественно, что знают это не все. Как минимум не все живут на этом форуме. Многие заходят сюда случайно.
2. Даже житие на этом форуме не позволяет оперировать редко используемыми абривиатурами и не быть при этом неуверенным в них.

... << RSDN@Home 1.2.0 alpha rev. 637>>

От:	Gaperton	http://gaperton.livejournal.com
Дата:	15.09.06 13:10
Оценка:	15 (1)

	От:	Mikl Kurkov
	Дата:	02.10.06 08:45
	Оценка:	56 (7) +3

От:	Gaperton	http://gaperton.livejournal.com
Дата:	13.09.06 08:55
Оценка:	+2

	От:	Кодт
	Дата:	15.09.06 13:43
	Оценка:

	От:	Трурль
	Дата:	22.09.06 06:56
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	14.09.06 23:13
Оценка:	2 (2) +4 -1

От:	lomeo	http://lomeo.livejournal.com/
Дата:	15.09.06 08:41
Оценка:	30 (4) +1

	От:	Cyberax
	Дата:	11.09.06 13:42
	Оценка:	10 (2) +1

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	15.09.06 05:31
Оценка:	1 (1) +2

	От:	Аноним
	Дата:	27.09.06 09:04
	Оценка:	1 (1) +2

От:	konsoletyper	https://github.com/konsoletyper
Дата:	26.09.06 16:37
Оценка:	1 (1) +1

	От:	граммофон
	Дата:	12.09.06 12:37
	Оценка:	+2

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	13.09.06 08:20
Оценка:	+1

	От:	Андрей Хропов
	Дата:	14.09.06 21:13
	Оценка:	-1

От:	thesz	http://thesz.livejournal.com
Дата:	12.09.06 18:32
Оценка:	5 (1)

От:	Курилка	http://kirya.narod.ru/
Дата:	10.09.06 11:32
Оценка:	+1

	От:	Programmierer AG
	Дата:	15.09.06 13:18
	Оценка:	+1

От:	IT	linq2db.com
Дата:	29.09.06 15:06
Оценка:	+1

От:	FDSC	consp11.github.io блог
Дата:	10.09.06 10:31
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	14.09.06 20:26
Оценка: