alf
Но вот кстати пусть даже скала
И тот же Окасаки, почему бы нам не взять Окасаки? ‎- alf
То что пишет Окасаки на ML — это на Скале будет type classes. То есть у вас где-то есть объект, имплементящий тайпкласс для класса X, и вы его подоткнёте, implicitly or not, куда вам надо. ‎- alf
С другой стороны, у Окасаки нет никакой инкапсуляции вообще — данные приходят как обычный кортеж, (a, a list, a list) — какой-то ворох хлама, про который мы верим (sic!), что он поддерживает весьма нетривиальные инварианты. ‎- alf
Что делает опытный джавер, помня что скала — это такая джава, только хаскел? Понятное дело, заворачивает всё это дело в класс с методами — у нас всё равно есть state, пусть immutable, и у нас есть набор операций над ним (если кто серьёзно считает, что он может прикрутить _снаружи_ *полезную* операцию к той же Hood-Melville queue, я готов послушать). ‎- alf
Это, к слову, возвращает нас в мир ООП с самодержавием и народностью, то есть с инкапсуляцией и полиморфизмом. И даже с наследованием, раз уж у нас есть иерархия Queue — Output-Restricted Deque — Deque. Другое дело, что вся эта иерархия нафиг никому не сдалась в живом проекте — но она есть, это трудно отрицать. Дека это не овальная очередь — это просто очередь. ‎- alf
Это приводит нас обратно к тому ранту. Why not go all the way with this, and give up OOP, and embrace the “functional” style of programming? Да потому что религиозные фанатики никому не нужны. Почему в Хаскеле отладочная печать идёт мимо IO Monad? Потому что когда надо решать проблемы, надо решать проблемы, а не обсуждать преимущество стиля. ‎- alf
Но в Скале так или иначе сработает всё, хоть чистый ООП, хоть тайп классы, хоть тайп классы спрятанные внутрь ОО кода. И я как-то не вижу хорошего ответа на вопрос "что лучше, для чего, и почему?" — хотя, казалось бы, уже пора. ‎- alf
(1) Кортеж при желании легко меняется на ADT с функциями проверки ивариантов. (2) Отладочная печать решает не ту проблему, которую решает разделение pure / effectful кода, поэтому подходы (не "стили") разные. ‎- 9000
Ну так (1) при желании, Why not go all the way with this, and give up FP, and embrace the “object-oriented” style of programming? — дело же не в том, что можно сделать при желании, а в том, что будут делать коллеги по проекту. И очевидно что на джаве они будут делать одно, на скале другое, на ML третье, а на хаскеле ты просто коллег не найдешь. http://www.gnu.org/fun/jokes/helloworld.en.html ‎- alf
Стили — они таки разные; я видел больше одного (внятного, консистентного) стиля на яве и на питоне, а про JS вообще молчу. (Ну и коллег, вообще говоря, я обычно достаточно притально выбираю.) Если кортежем нужно обмениваться как единым целым достчтоно часто и проверят инварианты — делаем class / record / ADT / namedtuple / whatnot. Если надо просто распаковать по месту несколько возвращаемых из функции значений — передаём просто tuple (хаскель умеет для такого делать "raw tuples", которые не составляют объекта, а Go вообще делает только так). Вообще говоря, идея составной сущности, у которой есть именованные под-сущности, сильно старше ООП и восходит по кр. мере к коболу, of all things (1959). ‎- 9000