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

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

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

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

Здравствуйте, 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>Не так. В большинстве случаев достаточно представлять поток функцией, тем не менее его представляют объектом. Так пойдет?

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Здравствуйте, FR, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цитатаы, плиз, скипай.

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

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

Значит на счет Лиспа ты согласен. А "не хуже" не значит "не лучше".

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

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

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

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

Для Лиспа и Форта сахарам является все кром базовых вещей. Определение я давал не раз. Да и в Вики оно мало чем отличается.

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

А зачем задавать вопрос на который тебе и так знаком ответ? Зачем приводить в качестве примера языки со встроенным метапрограммированием?

Здравствуйте, 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 утру нос на многих задачах тому кто будет исползовать язык с ФПВ, но без паттерн матчинга, к примеру.

Здравствуйте, 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!

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

Здравствуйте, 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] не выразительнее? Тогда весь вопрос в том, какой смысл вкладывать в термин "выразительность".

Здравствуйте, 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>Применение ФВП же вместо классов относится к выразительности формализма, а не кода.

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

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

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

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

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

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

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

как сказал один мой товарищ "придумали очередной баян и радуются"

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

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

L>>Выразительность — это ясность передачи мысли, я полагаю.

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

ВЫРАЗИТЕЛЬНЫЙ, -ая, -ое; -лен, -льна. 1. Хорошо выражающий что-н., яркий по своим свойствам, внешнему виду. Выразительная речь. Выразительное лицо. Выразительные глаза. 2. Многозначительный, как бы сообщающий что-н. В. взгляд. Выразительно (нареч.) посмотреть. II сущ. выразительность, -и, ж.

(с) Ожегов.

Да ладно придираться.

выразительный [выразительный] 1) а) Живо, непосредственно отражающий внутреннее состояние человека, его чувства, настроение и т.п. (о лице, глазах и т.п.). б) Ясно, во всей полноте, образно раскрывающий, передающий (мысль, характер и т.п.). в) Намеренно подчеркнутый, содержащий намек на то, что хотят сообщить, передать и т.п. 2) Служащий, предназначенный для выражения чего-л.

(c) Ефремова

Ну пусть не ясность, а ясность, образность и полнота

И вообще причем тут выразительность сама по себе? Сахар не добавляет выразительности формализму.
В любом случае — сахар не бывает сам по себе, он предоставляет более сладкую возможность для записи кода. Т.е. семантика должна оставаться та же — меняется только синтаксис. a[i] слаще *(a+i). foreach — for.
А вот если мы назовём ФВП сахаром, то по сравнению с чем?!

L>>Применение ФВП же вместо классов относится к выразительности формализма, а не кода.
VD>Применять ФВП можно в С. Но это не выразительно. А сахар в виде замыканий и лямбд делает применение ФВП выразительными. Андестенд?

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

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