Comments 23
В IntelliJ IDEA можно увидеть все implicit преобразования, которые применяются к токену — наводим на него фокус и Ctrl + Shift + P. Плюс он подчеркивается тоненькой линией.
За стиль изложения — браво. Дочитал до конца :)
Определенно, стиль хорош! Продолжайте в том же духе.
Удивительно, что не было сравнения implicit class с extension methods из C#.
Удивительно, что не было сравнения implicit class с extension methods из C#.
К сожалению с сисярпом знаком лишь понаслышке
Очень похоже на
implicit class StringExtended(val str: String) extemds AnyVal только к интерфейсу привести не позволяют.public static class StringExtended
{
public static void SayIt(this String str)
{
Console.WriteLine(str);
}
public static void SayItLouderBitch(this String str)
{
Console.WriteLine(str.ToUpper() + "!!!");
}
}
По-моему язык, в котором код делает не то, что написано, эффектно бы смотрелся в презентации Акопяна или Кио. Scala со всей своей подкапотной магией, стремится стать сборником всевозможных заклинаний. Куча неявного, скрытого, магического и эзотерического. Когда кругом одна магия начинаешь чувствовать себя Гарри Поттером. Я предпочитаю принцип «less magic, more logic», который со Scala не совместим.
Это утверждение справедливо только в том случае, если использовать инструмент в слепую, не пытаясь в нем разобраться. Сюда же можно приписать и C/++, Java и многие другие.
Скала — сложный язык, с относительно высоким порогом вхождения.
Для большинства старушек компьютер есть шайтан-коробка и вообще от сатаны, срочно поставить кактус рядом. И что ж теперь, использовать печатные машинки и голубиную почту, просто потому что просто?
Скала — сложный язык, с относительно высоким порогом вхождения.
Для большинства старушек компьютер есть шайтан-коробка и вообще от сатаны, срочно поставить кактус рядом. И что ж теперь, использовать печатные машинки и голубиную почту, просто потому что просто?
Вопрос, а стоит ли овчинка выделки? Насколько эффективность разработки на Scala покрывает ее сложность? Если мы возьмем полный цикл разработки проекта в команде, окажется ли он менее затратным, чем, скажем на Java? Я очень сомневаюсь. Методы решения поставленной задачи сильно не отличаются. Да, Scala эффективней тем, что меньше приходится писать. Но написание кода — это лишь небольшой процент от всего объема работы. Возможно, выигрываешь в написании — проигрываешь в отладке и поддержке.
P.S. меня чисто эстетически воротит от Scala. Ее могли сделать только люди с напрочь отбитым эстетическим вкусом. При всей ее сложности синтаксис можно было бы сделять в сто раз приятнее, избегая засилия закорючек. В скале засилие сахара, искусственных конструкций, неявных преобразований и соглашений по умолчанию превышает все мыслимые и немыслимые пределы. Такое впечатление, что основная идея Одерски: «а давайте включим в язык сразу все, что есть в других языках, и это сделает его универсальным на все случаи жизни». Красота как раз в минимализме.
P.S. меня чисто эстетически воротит от Scala. Ее могли сделать только люди с напрочь отбитым эстетическим вкусом. При всей ее сложности синтаксис можно было бы сделять в сто раз приятнее, избегая засилия закорючек. В скале засилие сахара, искусственных конструкций, неявных преобразований и соглашений по умолчанию превышает все мыслимые и немыслимые пределы. Такое впечатление, что основная идея Одерски: «а давайте включим в язык сразу все, что есть в других языках, и это сделает его универсальным на все случаи жизни». Красота как раз в минимализме.
Про Java и крупные проекты… Я работал с крупными проектами на C#, где синтаксис не столь убог, как у Java, но и там отсутствие удобной работы с immutable объектами приводит к крайне плачевным результатам — система становится запутанной и непрозрачной.
В Java с этим еще хуже, там даже вменяемого интерфейса для неизменяемых коллекций нет.
А убийственным становится преимущество scala при работе с многопоточностью. Многопоточность в Java —боль и страдание макароны, непрозрачность и риск ошибок.
По поводу закорючек: у меня есть 2 файла на scala: хотите пари? Один 400 строк без закорючек и логики, просто определение объектной модели. Другой на 100-150 строк с кучей «закорючек».
Сможете переписать их на Java чтоб стало понятнее без закорючек? Готов не учитывать переписывание объектной модели, только переписывание файлика на 100-150 строк. Код написан когда я меньше года как узнал о скале. С вашим опытом Java у вас огромная фора.
После этого пари я готов с вами обсуждать «закорючки» в scala.
В Java с этим еще хуже, там даже вменяемого интерфейса для неизменяемых коллекций нет.
А убийственным становится преимущество scala при работе с многопоточностью. Многопоточность в Java —
По поводу закорючек: у меня есть 2 файла на scala: хотите пари? Один 400 строк без закорючек и логики, просто определение объектной модели. Другой на 100-150 строк с кучей «закорючек».
Сможете переписать их на Java чтоб стало понятнее без закорючек? Готов не учитывать переписывание объектной модели, только переписывание файлика на 100-150 строк. Код написан когда я меньше года как узнал о скале. С вашим опытом Java у вас огромная фора.
После этого пари я готов с вами обсуждать «закорючки» в scala.
если у вас в команде ленивые студенты-второкурсники, которые год назад узнали о существовании плюсов, а в школе максимум на бейсике процедурки писали, то конечно проект на скале не взлетит.
а опус про эстетический вкус — чистейший воды субъективизм, который даже комментировать не хочется.
а опус про эстетический вкус — чистейший воды субъективизм, который даже комментировать не хочется.
В очень многих язык есть возможность «расширить» класс, внести в него доп. методы. Scala тут не особо выделилась. Выше я привел аналог на C#.
Плюс добавили некоторое обобщение над зарекомендовавшим себя в haskell механизмом typeclass.
На любом языке можно писать невнятно. Если же соблюдать конвенции то все понятно и очевидно. Например неявные преобразования в чистом виде (а не в виде implicit class) приведут к предупреждению при компиляции — их вообще рекомендуется использовать только в крайнем случае.
К слову о магии: я не пользуюсь IDE для scala обычно. Это не мешает мне абсолютно точно понимать что происходит.
Плюс добавили некоторое обобщение над зарекомендовавшим себя в haskell механизмом typeclass.
На любом языке можно писать невнятно. Если же соблюдать конвенции то все понятно и очевидно. Например неявные преобразования в чистом виде (а не в виде implicit class) приведут к предупреждению при компиляции — их вообще рекомендуется использовать только в крайнем случае.
К слову о магии: я не пользуюсь IDE для scala обычно. Это не мешает мне абсолютно точно понимать что происходит.
UFO just landed and posted this here
UFO just landed and posted this here
Самое главное в implicit'ах — не переборщить с их количеством, иначе весь код будет действительно как одна сплошная магия выглядеть.
В scala — новичек, хотелось бы комментариев опытных коллег:
обычно натыкаешься на implicit как раз когда начинаешь пользовтаься либами
идешь в мануал — там пример import xxx._
если не работает то еще втыкаешь import.yyy._
Т.е что в java сильно не рекомендуется import xxx.* в скале это норма
Понять что у тебя из либы при этом неявно в код попало- достаточно сложное занятие.
В результате, если библиотека написана грамотно- то заработает, но остнется магией
А вот со spray-routing повезло меньше- там мои save и get начали пересекатся с его внутренностями.
обычно натыкаешься на implicit как раз когда начинаешь пользовтаься либами
идешь в мануал — там пример import xxx._
если не работает то еще втыкаешь import.yyy._
Т.е что в java сильно не рекомендуется import xxx.* в скале это норма
Понять что у тебя из либы при этом неявно в код попало- достаточно сложное занятие.
В результате, если библиотека написана грамотно- то заработает, но остнется магией
А вот со spray-routing повезло меньше- там мои save и get начали пересекатся с его внутренностями.
Со spray-routing — это давно известное и многими расценивается как баг. Может и поправят.
Если либа написана хорошо, то зачастую не требуются wildcard импорты для implicit значений (растащены по компаньонам), либо создан отдельный объект для имплиситов с уникальными именами.
А ошибку при проектировании библиотеки можно совершить и без имплиситов.
Кстати, даже в случае с wildcard импортами в хороших библиотеках можно ограничивать ипортируемое. Например в scalaz можно импортировать все и сразу:
Если либа написана хорошо, то зачастую не требуются wildcard импорты для implicit значений (растащены по компаньонам), либо создан отдельный объект для имплиситов с уникальными именами.
А ошибку при проектировании библиотеки можно совершить и без имплиситов.
Кстати, даже в случае с wildcard импортами в хороших библиотеках можно ограничивать ипортируемое. Например в scalaz можно импортировать все и сразу:
import scalaz._, Scalaz._, но рекомендуют импортировать то, что нужно. Если нужны инструменты для работы с Option: import scalaz.syntax.std.option._.Sign up to leave a comment.
Scala. Всем выйти из сумрака!