Pull to refresh

Comments 12

Наконец-то вменяемое описание композиции Клейсли для инженеров, а не для математиков! Спасибо!

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

да не знаю, вроде после того, как узнаешь про Kleisli всё нормально читается. Может я, конечно, не видел обфусцированного каким-нибудь партизаном кода)
скале с кучей имплиситов можно потом очень долго пытаться понять какие преобразования и откуда применились
вот это я вообще каждый раз удивляюсь как встречаю, что IDE отменили? вроде уже даже Eclipse умеет переходить в имплиситы и подчёркивать их
Здесь конечно слишком мало кода, чтобы можно было оценить возможную обфусцированность. Гораздо интереснее в этом смысле читается код самой Scalaz.

вот это я вообще каждый раз удивляюсь как встречаю, что IDE отменили? вроде уже даже Eclipse умеет переходить в имплиситы и подчёркивать их

В том то и дело, что для того, чтобы понять, что же происходит, надо по каждому методу тыкать ctrl+click и смотреть куда в итоге попадешь, а имплиситы могут быть и многоуровневыми (особенно во всяких Scalaz). В то время как обычный код можно просто читать. Из-за этого разница в скорости понимания происходящего будет в разы.
Из-за этого разница в скорости понимания происходящего будет в разы

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

В scalaz вообще неприпомню необходимости лазать по имплиситам, там они — средство реализации. Если не понимать идей scalaz, разматывание кода по ниточкам не особо приводит к смыслу) На себе ощутил
В плане демострации каких-то математических абстракций может быть действительно это оптимальный подход. Но когда речь идет о таких обыденных вещах, как работа с xml и json, лично мне было бы приятнее работать с библиотекой, по коду которой я без проблем могу сказать, что она делает, не тратя часы на то самое разматывание кода. Ну и опять же, в хаскеле подобный код читается легче из-за большей заточенности языка под функциональный подход и там можно разбираться даже в текстовом редакторе, что как бы говорит о том, что одни и те же вещи можно реализовать с разной красотой и аккуратностью.
Так в обычной жизни разматывание и ненужно… Если сильно хочется на досуге — можно расковырять scalaz, пожалуйста, но я в упор не припомню ни одного случая за последний год, когда нельзя было по типам разобраться, что происходит. Не хотел обидеть, просто постоянно пишут про «многочасовые копания», а моя практика не подтверждает этого
Вообще, при интенсивном использовании любой библиотеки, почти всегда наталкиваешься на какой-то код который работает не так, как этого ожидаешь. И вот тогда неминуемо приходится лезть в исходники. Тут на хабре с год назад эпизод был (ссылку сейчас не найду), когда пытались разобраться, что делает какой-то метод из старой версии Scalaz (в текущей подобного уже нет) и в итоге так никто и не осилил. Если бы подобные библиотеки действительно можно было использовать как «черный ящик», то вопросов бы к ним не было, но на практике это обычно не получается.
Не хотел обидеть

Ну что вы, никто и не думал обижатся. Мы тут, по возможности конструктивно, просто обмениваемся личными мнениями, а они не обязаны совпадать )
Я читаю код и на Haskell, и на Scala. Но не пишу на них. Должен Вам сказать, что воспринимаются они сторонним наблюдателем одинаково тяжело. Основную сложность представляет не синтаксис, а сокрытие потока данных, от чего сложно прослеживать: что, куда и как передаётся. В этом бесточечный код и на Scala, и на Haskell достигают эпических высот невыразительности. Поэтому, как обычно, всё дело в привычке и опыте чтения и написания, а не в конкретном языке. Дело привычки. Статья же хорошая. Потому что про категории Клейсли на Хабре уже было на Haskell. Теперь взгляд под другим углом

Извините, что не "в тему", но что за color scheme на скриншоте? :)

Имхо, слишком сложно для использования на практике.


Начиная с первого же куска кода, зачем использовать for-yield, если можно намного проще?


def getByPath(path: List[String], root: XmlNode): Option[XmlNode] = path match {
      case name::names =>
        root.child.find(_.label == name).flatMap { child =>
          getByPath(names, child)
        }
      case _ => Some(root)
    }

Или еще понятнее:


def getByPath2(path: List[String], root: XmlNode): Option[XmlNode] = path match {
      case name::names =>
        root.child.find(_.label == name) match {
          case Some(child) => getByPath(names, child) 
          case None => None
        }
      case _ => Some(root)
    }

Объем кода такой же, а понять его не в пример проще. Возвращать сообщение об ошибке — так оно уже возвращается, если None — то данные не найдены. Обернуть Option в любой другой тип в отдельной функции и всё.


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


Проблема Scala в том, что он, по сути, содержит в себе два языка программирования — качественный промышленный и обширный экспериментальный. Множество попыток внедрения скалы провалилось из-за того, что первые энтузиасты тщательно зашифровывали исходники библиотеками типа scalaz, превращая текст в подобие двоичного дампа. В этом плане полезно изучить опыт Twitter, а также их исходники.

Sign up to leave a comment.