Здравствуйте, VladD2, Вы писали:
VD>1. Нет проблем слабать ленивое дерево и на немрел. На то есть lazy. Ленивость конечно явная, но не думаю, что это создаст такие уж проблемы.
Слабать можно. Так делают?
VD>2. Задача твоя не требует работать с деревом как с деревом. Если я ее првильно понял, в задаче требуется ленивый обход дерева. А это не тоже самое. И это легко делается итераторами.
Конечно, не требует. Мне интересно посмотреть решение на итераторах, раз эта задача на Немерле скорее будет решена так.
VD>[Record] // автоматическая генерация конструктра
VD>class A
VD>{
VD> public salary : int;
VD>}
VD>def salaries = _.Map(_.salary); // тип salaries list[A] -> list[int]
VD>salaries([A(1), A(1)]) // если убрать эту функцию вывод типов не сработает
VD>
А на самом деле ты как напишешь этот код? Именно так или все же предпочтешь другое решение?
Честно, у меня есть сомнения — не доставай наган — что Немерлистом функция salaries будет вообще определена. В реальности (мне кажется) код будет скорее таким:
Здравствуйте, VladD2, Вы писали:
VD>Больше скажу, есть сомнения в том, что Хаскель функциональные языки. Для меня функциональный язык не тот, что позволяет писать функциональный код (Ява тоже позволяет), а тот, который позволяет делать это удобно. Вот писать на Хаскеле совершенно неудобно. Моя практика это всецело подтверждает .
Тебе на Хаскель удобнее писать императивный код?
VD>У всго на свете есть ограничения. Напиши что-то по сложнее детских примеров и вопросы твои отпадут сами собой. В прочем, ты все равно будешь пытаться отыскать Хаскель в любом языке. Так что без перестройки сознания ты так и останешься при своих убеждениях.
Ненаучный подход. Сначала выдвигается гипотеза, а потом даётся непроверяемое обоснование, в случае если она не сработает. Я тебя никак не смогу опровергнуть.
А так — да: любая смена убеждений подразумевает перестройку сознания, это вообще масло масляное Важна не смена убеждений, а основания для этой смены.
По теме:
1. Я писал (и пишу) вещи сложнее детских примеров на Scala. Вопросы только появляются.
2. Haskell в языках не ищу. Тем более в Scala, в которой совсем другие плюшки.
3. Разговор конкретный — язык заявляет о себе как о ФП, но в стиле ФП на нём пишут очень мало.
4. Есть исключение — работа с последовательностями (и то! см. пост Клапауциуса о nemerle-std), что заставляет думать, что это воспринимается как приём, а не как подход. Функционального кода не связанного со списками критически мало — я перед ответом специально облазил http://code.google.com/p/nemerle/source/browse/#svn/nemerle/trunk и ниже.
Под стилем ФП я понимаю стиль, описанный в Why FP matters, например.
Т.е. можно сделать кучу предположений почему так, но дело должно быть или в языке или в разработчиках. С одной стороны, поскольку есть другие языки, на которых те же разработчики пишут в ФП стиле, то можно предположить, что дело в языке. С другой стороны пункт 4 бросает тень на разработчиков. Возможно, истина где-то посередине. Я — не знаю, о чём с самого начала и написал.
Здравствуйте, lomeo, Вы писали:
L>Т.е. можно сделать кучу предположений почему так, но дело должно быть или в языке или в разработчиках. С одной стороны, поскольку есть другие языки, на которых те же разработчики пишут в ФП стиле, то можно предположить, что дело в языке. С другой стороны пункт 4 бросает тень на разработчиков. Возможно, истина где-то посередине. Я — не знаю, о чём с самого начала и написал.
Скорее дело больше в разработчиках и пользователях языка, вот например в OCaml наблюдается обратный перекос ОО возможности
используются редко, даже там где ОО вполне приемлем пишут на модулях и функторах.
Здравствуйте, VladD2, Вы писали:
L>>Я немного о другом. В гибридных языках есть определённая жёсткая реализация ОО. Вполне возможно, что в жертву такому дизайнерскому решению приносятся некоторые особенности, которые сильно облегчили бы использование ФП. Это пока всего лишь чувство, появившееся после использования Scala. VD>Гнилая философия опровергаемая практикой. А практика показывает, что ООП отлично подходит для дизайна системы, или иными словами крупноблочного программирования, а ФП при этом может являеться отличным средством борьбы с рзабуханием тел методов. Таким образом вместе они создают отличный тандем. ООП — дизайн системы, ФП — ее внутрення реализация и склеивание частей (например, реактивное программирование). Сюда же отлично подходит и МП.
1. Чья практика? Если твоя — то ты просто не пробовал другого. Если общая — то есть масса замечательных дизайнов, построенных без ООП.
2. Я могу написать что ООП отвратительно подходит для дизайна системы, но ты же скажешь, что я его просто неправильно готовлю, (= твоя практика > моей практики), верно?
3. При чём тут вообще это? В предположении говорилось совсем о другом. Ну подходит ООП для дизайна, а ФП для методов. Речь о компромиссах, на которые надо идти в случае их объединения в одном языке.
В любом случае, практикой эта "философия" не опровергнута, иначе бы я её отбросил. Потом. Это всего лишь предположение. Я думаю, что оно возможно, я не уверен, что так и есть.
VD>Простой пример. Когда мы пишем парсер, то ФП и МП рулит, так как мы трансформируем что-то во что-то (грамматику в ее АСТ, АСТ в код парсера...). Когда мы пишем ГУЙ который позволяет отредактировать код, отпарсить его и вывести сообщения об ошибках, то рулит ООП. Когда мы пытаемся объедение все это в более большую систему, то опят же рулит ООП, или даже КООП, так как мы уже оперируем крупными строительный блоками.
Мы уже о другом спорим, ну да ладно, почему бы и да?
Я считаю это всего лишь одним из подходов. Не самым лучшим, не самым худшим.
VD>И похоже, что ты уперся в код функций и боишься или не можешь взглянуть чуть выше. Вот и начинаются разговоры о трансформации миров и т.п. А кому они нужны то на практике? Кнопка они и в Африке кнопка. В философии трансформации мира она не нуждается. Она нуждается в банальном состоянии.
Это замечание я вообще не понял. Что значит "упёрся в код функций и боишься или не можешь взглянуть чуть выше"? Про состояние я тоже не понял. Трансформация миров, изменяемые состояния — это всего лишь возможные реализации поведения кнопки. Кроме них есть ещё масса. Как это связано с ООП?
Здравствуйте, lomeo, Вы писали:
L>1. Я писал (и пишу) вещи сложнее детских примеров на Scala. Вопросы только появляются. L>2. Haskell в языках не ищу. Тем более в Scala, в которой совсем другие плюшки. L>3. Разговор конкретный — язык заявляет о себе как о ФП, но в стиле ФП на нём пишут очень мало. L>4. Есть исключение — работа с последовательностями (и то! см. пост Клапауциуса о nemerle-std), что заставляет думать, что это воспринимается как приём, а не как подход. Функционального кода не связанного со списками критически мало — я перед ответом специально облазил http://code.google.com/p/nemerle/source/browse/#svn/nemerle/trunk и ниже. L>Под стилем ФП я понимаю стиль, описанный в Why FP matters, например.
Ты знаешь, тут замкнутый круг. Основная масса "обращенцев" в стан Немерле — это дотнетчики, которые ФП, пользуясь твоими словами, воспринимают именно как прием, а не как подход. (Они, кстати, совсем тут не виноваты — ибо именно так ФП и рекламируется самим вендором платформы, который тут царь и бог).
Те же для кого ФП — это совсем не прием смотрят на их код и думают, что Немерле — какой-то не "тру" функциональный язык, потому что в функциональном стиле на нем практически не пишут.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>lomeo, как я понимаю, привык к этакой point free комбинаторике
Большей частью я пишу на императивных языках, часто с поддержкой ОО. Основной язык — так вообще Java. Говорить, что я привык к pointfree по-моему неправильно.
Речь о моём представлении, что такое ФП. Возможно, оно сильно отличается от других.
Здравствуйте, lomeo, Вы писали:
L>Большей частью я пишу на императивных языках, часто с поддержкой ОО. Основной язык — так вообще Java. Говорить, что я привык к pointfree по-моему неправильно.
ОК, тогда я не угадал.
L>Речь о моём представлении, что такое ФП. Возможно, оно сильно отличается от других.
Пока мы говорили, что такое ФЯ. Для большинства здесь (опять попробую угадать) — ФЯ это язык, в котором есть ФП не обязательно в ущерб другим парадигмам. Так что неудивительно, если в каких-то случаях функциональному пути может быть выбран другой путь для решения проблемы. Есть, конечно, и более радикальная точка зрения.
"Что такое ФП" — вопрос по-моему уж очень сильно философский. Я вот затрудняюсь сформулировать.
Ну т.е. понятно, что в некой редуцированной форме для функционального программирования достаточно двух функций-комбинаторов, однако оно уже как-то очень далеко от практики.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А почему ты сам-то начинаешь более активно использовать ПМ? По логике — все нужные средства у тебя есть. Либо эти средства не работают (отсутствуют какие-либо необходимые возможности), либо они менее удобные — вроде другого не дано.
Хороший вопрос! Чтобы на него ответить я стал пересматривать свой код и вот что обнаружил. Буду говорить на одном примере, чтобы выделить общую мысль на деталях.
Вот есть у меня разбор Option, а в одной из веток ещё один Option разбирается. Почему бы не сделать один разбор пары? Потому что лишнее вычисление, которое нужно выполнить только в одной из веток. Почему бы не использовать аналог функции maybe? Потому что у меня встречается императивный код.
В других случаях то же самое. Возможность смешивать императивный и функциональный код приводит к тому, что решения на таком смешанном коде + ПМ писать проще (и они, кстати, эффективнее), чем их предварительное разделение. Код получается достаточно понятный и эффективнее, чем ФП. Плата — бОльшая связанность. Возможность выделять типичные разборы ПМ в функции на самом деле неудобна из-за того, что части ПМ становятся аргументами (читай — энергично вычисляются). Делать их ленивыми — дополнительная работа, уменьшающая (правда, слегка) удобство и понятность.
Ещё момент — в ветке может часто оказаться несколько строчек (из-за смешивания). А делать их аргументами — будет уже не так симпатично выглядеть.
ВВ>Т.е. если в Окамл — где задачка с зарплатами решается практически так же как на Хаскеле — ООП не вызывает неудобств, то значит не всякое ООП вредно для ФП.
Здравствуйте, FR, Вы писали:
FR>Скорее дело больше в разработчиках и пользователях языка, вот например в OCaml наблюдается обратный перекос ОО возможности
Мы сменили язык — так что дело может быть и в нём Один и тот же человек, который пишет и на Nemerle и на Ocaml — использует одни и те же идиомы?
FR>используются редко, даже там где ОО вполне приемлем пишут на модулях и функторах.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Я немного о другом. В гибридных языках есть определённая жёсткая реализация ОО. Вполне возможно, что в жертву такому дизайнерскому решению приносятся некоторые особенности, которые сильно облегчили бы использование ФП. Это пока всего лишь чувство, появившееся после использования Scala.
VD>Гнилая философия опровергаемая практикой. А практика показывает, что ООП отлично подходит для дизайна системы, или иными словами крупноблочного программирования, а ФП при этом может являеться отличным средством борьбы с рзабуханием тел методов. Таким образом вместе они создают отличный тандем. ООП — дизайн системы, ФП — ее внутрення реализация и склеивание частей (например, реактивное программирование).
Практика как раз показывает что не подходит. Identity и инкапсуляция состояния обычно мешает уменьшает реюз кода. Что из ООП используется это интерфейсы (те группы функций) и динамическая диспетчеризация. Это то что в свое время назвали SOA.
F# например отлично поддерживает интерфейсы: позволяет создавать анонимные объекты, реализующие эти интерфейсы.
В haskell подобная работа с группами функций реализуется с помощью typeclasses и и расширений компилятора для динамической диспетчеризации. Там даже не придется передавать инстанс интерфейса при композиции, он сам подтянется через typeclass. Кроме того инстансы тайпклассов можно определять для существующих типов.
VD>Сюда же отлично подходит и МП.
Непонятно чем, покажешь?
VD>И похоже, что ты уперся в код функций и боишься или не можешь взглянуть чуть выше. Вот и начинаются разговоры о трансформации миров и т.п. А кому они нужны то на практике? Кнопка они и в Африке кнопка. В философии трансформации мира она не нуждается. Она нуждается в банальном состоянии.
А причем тут состояние и ООП? Далеко не все языки чисты, многие позволяют работать с состоянием.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Пока мы говорили, что такое ФЯ. Для большинства здесь (опять попробую угадать) — ФЯ это язык, в котором есть ФП не обязательно в ущерб другим парадигмам. Так что неудивительно, если в каких-то случаях функциональному пути может быть выбран другой путь для решения проблемы. Есть, конечно, и более радикальная точка зрения.
Разумеется! Но пойнт то не в том, что есть два удобных пути и выбирают тот, что более удобен. Пойнт в том, что ФП путь на таких языках изначально неудобен. Выбирать, собственно, не из чего.
Правда, признаю, что в таком случае не работает обоснование "в ФП стиле на таких языка не пишут". Спасибо за это замечание. Значит я могу основываться только на своём опыте работы со Scala и замечаниях типо того, что дал Klapaucius о Nemerle.
Здравствуйте, gandjustas, Вы писали:
G>В haskell подобная работа с группами функций реализуется с помощью typeclasses и и расширений компилятора для динамической диспетчеризации. Там даже не придется передавать инстанс интерфейса при композиции, он сам подтянется через typeclass. Кроме того инстансы тайпклассов можно определять для существующих типов.
Было уже. Влад говорил, что typeclasses в Haskell из мира ОО, так что ты лишь подтверждаешь его мысль
Здравствуйте, lomeo, Вы писали:
L>Разумеется! Но пойнт то не в том, что есть два удобных пути и выбирают тот, что более удобен. Пойнт в том, что ФП путь на таких языках изначально неудобен. Выбирать, собственно, не из чего.
Если судить по твоему соседнему сообщению, то складывается впечатление, что сам факт наличия *двух* удобных путей приводит к тому, что и сам код на таком языке становится как бы гибридным, а в результате, естественно, и не "тру" ФП.
(
Для сравнения — возьмем F# и Немерле. На F#, ноги к-го растут из OCaml, можно писать в императивном стиле, но это менее удобно, чем, скажем, на C#, хотя бы потому что нет конструкций для чисто императивного control flow. На Немерле императивный код писать так же удобно, как на C#. При этом формально оба языка — и Немерле, и F# — считаются гибридными.
Разумеется, несложно представить ситуацию, где важна эффективность, а императивный путь является самым эффективным. Однако на F# я, возможно, не буду, что называется, "жрать кактус" и пожертвую эффективностью. На Немерле — напишу так, как мне это удобно.
)
Иначе говоря, получается, что проблема гибридных языков не в том, что в ФП стиле на них писать неудобно, а в том, что на них удобно писать в *гибридном* стиле.
L>Правда, признаю, что в таком случае не работает обоснование "в ФП стиле на таких языка не пишут". Спасибо за это замечание. Значит я могу основываться только на своём опыте работы со Scala и замечаниях типо того, что дал Klapaucius о Nemerle.
Мне кажется его замечание не показательно в том смысле, что речь идет всего лишь о некоторых ограничения стандартного макроса для list comprehension. Нет никаких идеологических причин в том, чтобы это ограничение существовало. Просто некий добрый человек хорошо доработал *макрос* foreach (поэтому он более удобен, хотя императивен), но *макрос* list comprehension попросту "не допилен". Если его доделать, то замечание нивелируются, а язык от этого вряд ли кардинально изменится.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Иначе говоря, получается, что проблема гибридных языков не в том, что в ФП стиле на них писать неудобно, а в том, что на них удобно писать в *гибридном* стиле.
Я описал причины, почему ФП-стиль неудобен. Приходится писать в ленивом стиле и неэффективный код. Я читаю это как не "неудобнее", а как "неудобно".
ВВ>Мне кажется его замечание не показательно в том смысле, что речь идет всего лишь о некоторых ограничения стандартного макроса для list comprehension. Нет никаких идеологических причин в том, чтобы это ограничение существовало. Просто некий добрый человек хорошо доработал *макрос* foreach (поэтому он более удобен, хотя императивен), но *макрос* list comprehension попросту "не допилен". Если его доделать, то замечание нивелируются, а язык от этого вряд ли кардинально изменится.
list comprehesion вообще не при чём. Общий смысл в том, что цепочка функций порождает промежуточные результаты. Это неизлечимо в общем случае для гибридных языков. Представь, что там не IEnumerable, а некий пользовательский тип (foldable, traversable).
Здравствуйте, lomeo, Вы писали:
L>list comprehesion вообще не при чём. Общий смысл в том, что цепочка функций порождает промежуточные результаты. Это неизлечимо в общем случае для гибридных языков.
Здравствуйте, Воронков Василий, Вы писали:
L>>list comprehesion вообще не при чём. Общий смысл в том, что цепочка функций порождает промежуточные результаты. Это неизлечимо в общем случае для гибридных языков. ВВ>Для гибридных или для энергичных?
Думаю, что для чистых энергичных вполне возможны такие оптимизации. В любом случае, неважно. Мы же о гибридных? А их у нас в обсуждении пока два (Nemerle и Scala), да иногда Ocaml с F# появляются.
— что Немерлистом функция salaries будет вообще определена. В реальности (мне кажется) код будет скорее таким:
.
Я вот затрудняюсь сформулировать.
