Как стать автором
Обновить

Комментарии 7

Всё это, конечное же, выглядит супер классно, но, как вы заметили, отлаживать это — такое себе удовольствие. Даже IDEA не всегда может помочь, к сожалению.
отлаживать такое значительно проще, чем ошибки в рантайме. Компилятор поможет.
На самом деле, как правильно заметил Envy, компилятор хорошо помогает в отладке. Просто нужно понимать куда смотреть. Зато никаких рантайм проверок, всё на этапе компиляции и в итоге код получается безопаснее.
Основная критика была направлена но то, что Scala слишком мощный язык с высоким уровнем свободы, где одно и тоже можно реализовать различными способами.

Меня больше всего достают проблемы обратной совместимости. Фактический лок минорной версии в pom файлах очень частое явление.

Действительно есть такое. Из-за проблем с обратной совместимостью и крупные игроки, типа Confluent, бывает переходят обратно на Java. С другой стороны, это позволяет языку двигаться вперед и развиваться. В принципе, это и послужило причиной появления Dotty.
Я на скале не так уж много писал, но как раз вот имплиситы мне показались каким-то воплощением зла. Ладно еще неявные преобразования типов — немного магии и больше не надо писать простыни конвертаций при вызове Java-кода. Но вот например implicit параметры методов это какой-то вообще ад за гранью добра и зла. Код становится абсолютно нечитаемым, так как на логику безобидно выглядящей строчки может внезапно влиять строчка двумя экранами выше, при этом между этими двумя строчками нет ничего общего (общих переменных) и IDE тут бессильна помочь. Да что там, с имплиситами даже код со Stackoverflow больше нельзя скопировать! На святое покусились! Копируешь кусок кода, вроде бы все необходимые переменные (те которые в нем используются) в нем объявлены, а он не работает. Или что еще хуже — работает как-то не так. Потому что пролез какой-то имплисит откуда-то, или наоборот не пролез.

Мне это напоминает шутку с инструкцией COMEFROM как злого аналога GOTO — совершенно посторонний кусок кода, находящийся возможно даже в другом файле, может сломать вот этот казалось бы совершенно от него независящий фрагмент программы.

Главное совершенно непонятно зачем оно вообще нужно, типа лень написать дополнительный параметр метода? Экономия на спичках.
Бездумное использование implicit, конечно же может привезти к тому, о чём вы пишите. Всё надо делать с умом. Конкретно имплиситными параметрами любят злоупотреблять, но есть случаи, где они полезны. Один из примеров я привел в статье — ad hoc полиморфизм. Т.е. в данной строчке
def as[A](path: String)(implicit reader: Reader[A]): Reader.Result[A]

он необходим, чтобы была возможность в дальнейшем писать такой код:
config.as[String]("path")

Это всё же не то же самое, что
config.as[String]("path")(stringReader)

Вариант с имплиситным параметром более гибкий и простой в использовании.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории