Re[58]: Scala / F# / Nemerle и мейнстрим
От: Воронков Василий Россия  
Дата: 02.11.10 11:15
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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

Например, было бы очень интересно, если бы ты перечислил те особенности, которые в Scala были принесены в "жертву ООП". Я же так понимаю, речь идет не только об очевидных вещах вроде неудобное каррирование и композиция.
Re[59]: Scala / F# / Nemerle и мейнстрим
От: FR  
Дата: 02.11.10 11:22
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Например, было бы очень интересно, если бы ты перечислил те особенности, которые в Scala были принесены в "жертву ООП". Я же так понимаю, речь идет не только об очевидных вещах вроде неудобное каррирование и композиция.


Если исключить каррирование можно посмотреть разницу между F# и OCaml в первом мейнстримный ООП во втором ООП вполне (насколько это вообще возможно)
гармонично вписанный в ФЯ.
Re[60]: Scala / F# / Nemerle и мейнстрим
От: Воронков Василий Россия  
Дата: 02.11.10 11:27
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Если исключить каррирование можно посмотреть разницу между F# и OCaml в первом мейнстримный ООП во втором ООП вполне (насколько это вообще возможно)

FR>гармонично вписанный в ФЯ.

Ну это проблемы F#, а не ООП. F# адаптировали под имеющуюся систему типов, которая создавалась явно не для ФЯ. В этом-то и кроется основная проблема. Возможно, в Scala сходные проблемы .

Опять же в F# все же присутствует четкое разделение на два мира. Т.е. из-за того, что к нему прикрутили "мейнстримный ООП" ФП не стал менее удобным.

Может, тут на самом деле ларчик просто открывается? Когда дизайнеры языка не хотят делать швы, а пытаются не просто "внедрить ООП", а полноценно приспособить язык к уже существующей платформе, чтобы он был "как родной", то это неизбежно ведет к некоторым компромиссам, и в итоге ФП получается "менее удобным".
Re[60]: Scala / F# / Nemerle и мейнстрим
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.11.10 11:33
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Посмотри тот же SICP в начальных главах там объясняются нормальный и аппликативный порядки вычислений, сложность у них одинаковая. Но нормальный порядок

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

Воспринимается легче как раз аппликативный (evaluate the arguments and then apply).
Re[61]: Scala / F# / Nemerle и мейнстрим
От: FR  
Дата: 02.11.10 11:44
Оценка:
Здравствуйте, samius, Вы писали:

S>Воспринимается легче как раз аппликативный (evaluate the arguments and then apply).


Да вечно их путаю
Конечно аппликативный легче воспринимается и используется в энергичных языках, а ленивый язык получается из языка с нормальным
порядком простой задержкой вычислений до тех пор пока они реально не потребуются.
Re[62]: Scala / F# / Nemerle и мейнстрим
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.11.10 11:46
Оценка: :))
Здравствуйте, FR, Вы писали:

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


S>>Воспринимается легче как раз аппликативный (evaluate the arguments and then apply).


FR>Да вечно их путаю

Я просто один раз запомнил, что то что кажется нормальным (привычным) не является формально нормальным порядком.
Re[59]: Scala / F# / Nemerle и мейнстрим
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.11.10 11:46
Оценка: 16 (2)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Например, было бы очень интересно, если бы ты перечислил те особенности, которые в Scala были принесены в "жертву ООП". Я же так понимаю, речь идет не только об очевидных вещах вроде неудобное каррирование и композиция.


1. Сложность реализации higher-order полиморфизма + неочевидность записи — сравни с Haskell. Мне кажется это из-за изначальной диспетчеризации по одному параметру.
trait Monad[M[_]] {
  def pure[A](a: => A): M[A]
  def bind[A,B](a: M[A], f: A => M[B]): M[B]
}

Что за? Это же функции, а не методы, тут this совсем не будет использоваться.

2. Такое часто — из-за trait предпочитается ОО-полиморфизм вместо функционального — методы вместо функций. Если использовать объекты как неймспейс (объект — это синглтон в Scala, аналог модуля), то можно писать в ФП стиле в принципе.

3. В моих программах на Haskell мало ПМ, в программах на Scala — много. Видно, где я больше работаю с данными. С чем связано — пока не знаю. Может персональное.

4. Про карринг будем говорить. Я вынужден писать полную сигнатуру (с названиями параметров!) в Scala. В Haskell эта-редуцированная форма используется очень часто и не захламляет код. Cм мой пример с salaries, как бы определение этой фунции выглядело в Scala, чтобы было таким же:
def salaries(emps: List[Employee]) = emps.map(_.salary)

А если тип — сложный generic (взятый из typeclasses в Haskell) — то сигнатура получается гораздо сложнее.
В Nemerle вывод типов, слышал, гораздо сильнее, поэтому возможно, что там будет
def salaries = _.Map(_.salary)

не знаю.
Re[60]: Scala / F# / Nemerle и мейнстрим
От: Воронков Василий Россия  
Дата: 02.11.10 12:53
Оценка:
Здравствуйте, lomeo, Вы писали:

L>1. Сложность реализации higher-order полиморфизма + неочевидность записи — сравни с Haskell. Мне кажется это из-за изначальной диспетчеризации по одному параметру.

L>2. Такое часто — из-за trait предпочитается ОО-полиморфизм вместо функционального — методы вместо функций. Если использовать объекты как неймспейс (объект — это синглтон в Scala, аналог модуля), то можно писать в ФП стиле в принципе.

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

L>3. В моих программах на Haskell мало ПМ, в программах на Scala — много. Видно, где я больше работаю с данными. С чем связано — пока не знаю. Может персональное.


Это момент интересный. Мало ПМ потому что более активно используется — в широком смысле — лямбда-исчисление? Т.е. вместо операций над данными, операции над функциями, в Скале же — наоборот, а причиной тому, видимо, что операции над функциями менее удобны? Ну т.е. в сущности это все те же самые "неудобные каррирование, композиция" и проч. Заметь, кстати, тут Влад тебе где-то по-соседству говорит, что в Немерле всякие ">>" и "<<" (в Хаскеле, я так понимаю, это ".") используются не так часто. Тоже показательно весьма.

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

L>4. Про карринг будем говорить. Я вынужден писать полную сигнатуру (с названиями параметров!) в Scala. В Haskell эта-редуцированная форма используется очень часто и не захламляет код. Cм мой пример с salaries, как бы определение этой фунции выглядело в Scala, чтобы было таким же:

L>
L>def salaries(emps: List[Employee]) = emps.map(_.salary)
L>

L>А если тип — сложный generic (взятый из typeclasses в Haskell) — то сигнатура получается гораздо сложнее.
L>В Nemerle вывод типов, слышал, гораздо сильнее, поэтому возможно, что там будет
L>
L>def salaries = _.Map(_.salary)
L>

L>не знаю.

Ну в этом конкретном примере, что конкретно "рулит"? Вывод типов — убираем объявления. Каррированность функций. Лаконичный синтаксис для лямбд.
Например, как бы этот пример мог выглядеть у меня:

>let map(f, l) on _,x::xs -> f(x) + map(f, xs) on _,[] -> 0;

>let list = [(salary:120),(salary:12),(salary:245)]

>let salaries = map(_.salary)

>salaries(list)

377


Достаточно лаконично вроде. Если бы каррирования не было, то пришлось бы писать так:

>let salaries = map(_.salary, _)


Хуже. Но в конкретном примере — некритично. Вот вариант Скалы — да, длинноват.
Re[59]: Scala / F# / Nemerle и мейнстрим
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.11.10 13:04
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

FR>>Ну и чистота вообще ортогональна строгости.


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


И правильно, ленивость с наблюдаемыми сайд-эффектами ведет к непредсказуемому поведению.
Re[54]: Scala / F# / Nemerle и мейнстрим
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.10 01:06
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ну что, покажешь? У меня сомнения вот в этом:


Я не люблю бесцельные упражнения. Надеюсь что найдутся добровольцы без меня. Если до конца праздников не найдется напишу сам, если очень хочешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[54]: Scala / F# / Nemerle и мейнстрим
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.10 01:10
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Например, в нашем примере на Haskell присутствует ленивое дерево, позволяющее разделить две функции — фильтрации и генерации дерева, что, очевидно, добавляет модульности программе. На C#/Nemerle ленивое дерево строится сложнее, чем список, поэтому там скорее всего функции фильтрации и генерации будут объединены.


1. Нет проблем слабать ленивое дерево и на немрел. На то есть lazy. Ленивость конечно явная, но не думаю, что это создаст такие уж проблемы.

2. Задача твоя не требует работать с деревом как с деревом. Если я ее првильно понял, в задаче требуется ленивый обход дерева. А это не тоже самое. И это легко делается итераторами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[54]: Scala / F# / Nemerle и мейнстрим
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.10 03:07
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Больше скажу, есть сомнения в том, что Nemerle/Scala функциональные языки. Для меня функциональный язык не тот, что позволяет писать функциональный код (Ява тоже позволяет), а тот, который позволяет делать это удобно. Здесь могут быть разногласия в термине "удобно" — критерием является только практика - как много на этих языках пишут функциональный код.


Золотые слова! Предлагая отборосить сомнения и начать практиковаться. А то в подобных рассуждениях без потери смысла можно заменить все слова:

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

L>Как показывает моя практика на Scala и сообщения типа этого
Автор: Klapaucius
Дата: 22.10.10
для гибридных языков есть ограничения Но это уже другой вопрос.


У всго на свете есть ограничения. Напиши что-то по сложнее детских примеров и вопросы твои отпадут сами собой. В прочем, ты все равно будешь пытаться отыскать Хаскель в любом языке. Так что без перестройки сознания ты так и останешься при своих убеждениях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[58]: Scala / F# / Nemerle и мейнстрим
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.10 03:25
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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

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

И похоже, что ты уперся в код функций и боишься или не можешь взглянуть чуть выше. Вот и начинаются разговоры о трансформации миров и т.п. А кому они нужны то на практике? Кнопка они и в Африке кнопка. В философии трансформации мира она не нуждается. Она нуждается в банальном состоянии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[60]: Scala / F# / Nemerle и мейнстрим
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.10 03:34
Оценка: 14 (1)
Здравствуйте, lomeo, Вы писали:

L>4. Про карринг будем говорить. Я вынужден писать полную сигнатуру (с названиями параметров!) в Scala. В Haskell эта-редуцированная форма используется очень часто и не захламляет код. Cм мой пример с salaries, как бы определение этой фунции выглядело в Scala, чтобы было таким же:

L>
L>def salaries(emps: List[Employee]) = emps.map(_.salary)
L>

L>А если тип — сложный generic (взятый из typeclasses в Haskell) — то сигнатура получается гораздо сложнее.
L>В Nemerle вывод типов, слышал, гораздо сильнее, поэтому возможно, что там будет
L>
L>def salaries = _.Map(_.salary)
L>

L>не знаю.

Так и есть. Вот реальный пример:
[Record] // автоматическая генерация конструктра
class A
{
  public salary : int;
}

def salaries = _.Map(_.salary); // тип salaries list[A] -> list[int]
salaries([A(1), A(1)]) // если убрать эту функцию вывод типов не сработает
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[60]: Scala / F# / Nemerle и мейнстрим
От: z00n  
Дата: 03.11.10 03:36
Оценка: 8 (1)
Здравствуйте, FR, Вы писали:

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


ВВ>>Я не говорю, что они не детерминированы. Вообще что такое "недетерминированный" язык? Как на таком в принципе можно написать что-то полезное?


FR>Конечно можно, например в SICP есть пример недетерминированного интерпретатора схемы, вводится всего одна особая форма 'amb' http://mitpress.mit.edu/sicp/full-text/sicp/book/node91.html по мощности вполне пролог перекрывает, и даже в реальных схемах http://wiki.call-cc.org/eggref/4/amb?action=show и кажется в диалектах ML присутствует.


Amb сейчас есть даже в .NET Reactive Rx (и под Javascript)
http://msdn.microsoft.com/en-us/library/ff707862(VS.92).aspx
Re[61]: Scala / F# / Nemerle и мейнстрим
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.10 03:37
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну в этом конкретном примере, что конкретно "рулит"? Вывод типов — убираем объявления. Каррированность функций. Лаконичный синтаксис для лямбд.

ВВ>Например, как бы этот пример мог выглядеть у меня:

ВВ>
>>let map(f, l) on _,x::xs -> f(x) + map(f, xs) on _,[] -> 0;

>>let list = [(salary:120),(salary:12),(salary:245)]

ВВ>>let salaries = map(_.salary)

>>salaries(list)

ВВ>377
ВВ>


ВВ>Достаточно лаконично вроде. Если бы каррирования не было, то пришлось бы писать так:


Дык у тебя не Map, а Fold получился. Лаконичный бред .

И ни разу не более лаконичный нежели немерловый вариант.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: Scala / F# / Nemerle и мейнстрим
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.11.10 06:20
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А почему так выходит? Ведь traits по идее те же классы типов, вид сбоку. Мои познания Хаскеля правда основаны на книжке "с картинками" (хорошо хоть, не "раскраска"), но вроде как полиморфизм через классы типов производит впечатление вполне законной фичи, опять же проследить тут некоторую аналогию с ООП несложно.


Аналогию.
Смотри отличия здесь: http://www.haskell.org/haskellwiki/OOP_vs_type_classes

Например, trait реализуется конкретным классом, то есть аналогию c MPTC построить сложновато.

ВВ>Это момент интересный. Мало ПМ потому что более активно используется — в широком смысле — лямбда-исчисление? Т.е. вместо операций над данными, операции над функциями, в Скале же — наоборот, а причиной тому, видимо, что операции над функциями менее удобны? Ну т.е. в сущности это все те же самые "неудобные каррирование, композиция" и проч. Заметь, кстати, тут Влад тебе где-то по-соседству говорит, что в Немерле всякие ">>" и "<<" (в Хаскеле, я так понимаю, это ".") используются не так часто. Тоже показательно весьма.


Да. С чем это может быть связано?

ВВ>Я к чему веду-то собственно — мне кажется, что в языке, подобном Немерле (и возможно Скала) сделать более удобные операции над функциями вполне можно.


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

ВВ>Ну в этом конкретном примере, что конкретно "рулит"? Вывод типов — убираем объявления. Каррированность функций. Лаконичный синтаксис для лямбд.

ВВ>Например, как бы этот пример мог выглядеть у меня:

Окамл — не ОО язык. Тут он кажется не к месту.

ВВ>Хуже. Но в конкретном примере — некритично. Вот вариант Скалы — да, длинноват.


Re[62]: Scala / F# / Nemerle и мейнстрим
От: Воронков Василий Россия  
Дата: 03.11.10 07:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык у тебя не Map, а Fold получился. Лаконичный бред .


Ага, хрень написал. Надо, видимо, как-то так:

let map(f, l) on _,x::xs -> f(x)::map(f, xs) on _,[] -> [];


Кстати, то же самое, но с экспериментальным ML-ным синтаксисом:

let map f x::xs = (f x)::(map f xs) | _ = [];


Скажи честно, тебе какой вариант больше нравится?

VD>И ни разу не более лаконичный нежели немерловый вариант.


Ну суть не в функции map. lomeo, как я понимаю, привык к этакой point free комбинаторике, а она — на мой взгляд — таки да требует для выразительности как каррирование, так и ML-ный синтаксис. Пример с зарплатами есть трансформация кода вида:

let salaries x = map salary x


Заметь, насколько естественным и красивым тут видится устранение этого самого "x". Так, возможно, неудобства, о которых говорит lomeo, комплексные. Часть могут быть и с синтаксисом связаны, почему нет.
Re[62]: Scala / F# / Nemerle и мейнстрим
От: FR  
Дата: 03.11.10 07:35
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Окамл — не ОО язык. Тут он кажется не к месту.


Objective Caml не ОО язык?
Re[62]: Scala / F# / Nemerle и мейнстрим
От: Воронков Василий Россия  
Дата: 03.11.10 07:53
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Аналогию.

L>Смотри отличия здесь: http://www.haskell.org/haskellwiki/OOP_vs_type_classes

Ага, спасибо, почитаю.

ВВ>>Это момент интересный. Мало ПМ потому что более активно используется — в широком смысле — лямбда-исчисление? Т.е. вместо операций над данными, операции над функциями, в Скале же — наоборот, а причиной тому, видимо, что операции над функциями менее удобны? Ну т.е. в сущности это все те же самые "неудобные каррирование, композиция" и проч. Заметь, кстати, тут Влад тебе где-то по-соседству говорит, что в Немерле всякие ">>" и "<<" (в Хаскеле, я так понимаю, это ".") используются не так часто. Тоже показательно весьма.

L>Да. С чем это может быть связано?

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

ВВ>>Ну в этом конкретном примере, что конкретно "рулит"? Вывод типов — убираем объявления. Каррированность функций. Лаконичный синтаксис для лямбд.

ВВ>>Например, как бы этот пример мог выглядеть у меня:
L>Окамл — не ОО язык. Тут он кажется не к месту.

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

Т.е. если в Окамл — где задачка с зарплатами решается практически так же как на Хаскеле — ООП не вызывает неудобств, то значит не всякое ООП вредно для ФП.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.