Ну вот кстати, да. Интересно скольких бы проблем удалось избежать просто накатив win 2k на многострадального ветерана. И ретро-филл сохранится и все-таки на NT-шном ядре можно много чего запустить. В т.ч. благодаря наличию драйверов.
Кстати очень хороший поинт. Хотелось бы посмотреть как развертка будет работать для ARM, а так же как оно будет работать после компиляции в нативный код.
Вот только у IDE после подобных упражнений начнутся проблемы. И придется после этого писать для нее плагин. И скорее всего, это будет плагин для IDEA, который тоже нужно будет поддерживать. Кому-тот придется расширять файлы синтаксиса для vim, а синтакстическим плагинам вима тоже голову будет переодически сносить. Так что если что-то подобное иметь, то из из коробки либо не иметь вовсе.
Знают трое — знает и свинья. С нашим уровнем коррупции, и возможностями пробить всех и вся. И зная некоторые детали болезни можно тихо спокойно и без последствий устранять кого угодно (например владея данными об аллергенах).
Кстати, яндес в этом плане конкретно обнаглел. Причем настолько что мне пришлось снести половину сервисов.А вы были здесь? А оценочку поставите? А здесь были? Не были?
Яндекс, а какое твое дело где я был? Если я захочу поставить месту оценку я сам зайду на карту и поставлю.
Скажу что это очень и очень спорно. У меня нет времени сидеть в группах по интересам. Уверен, что у большинства достойных девушек тоже. И даже если бы было. Сидеть в группе чтобы специально кого-то выцепить? Это в вк сидеть надо дофигищу. В дополнение к закрытым профилям есть еще коты на аватарках. Познакомишься и еще не известно на что ты попадешь.
Крайне неэффективно.
Как мне кажется, с задачей "Объяснить монаду" неплохо справился Миран Липовича в своей книжке с голубым слоном. Но в Scala, не используя scalaz/cats это сделать не просто, скажем так.
С немцами у меня была похожая история. Только там еще в комплекте шел модуль препроцессора для Java (который вызывался внутри ant-таски и переводил ключевые слова с немецкого на английский). Более того: имена классов, методов и переменных были тоже на немецком. УчитываяОсобенностиОнногоЯзыка оно действительно выглядело как нечто родное.
Лаконичность кода на языке K это не столько свойство языка K, сколько умение программиста четко и ясно выражать свои мысли вне зависимости от языка. Даже на Java можно писать коротко и понятно (если уметь). А если дать правильному джависту в руки C...
В последнее время читаю очень много кода на Kotlin. И скажу вам, Котлин, там где я его вижу ни разу не лаконичен. Почему? А потому что пишут на нем как на Java. С таким же страшным форматированием. И Scala не лаконична в неправильных руках. Так что если говорить о преимуществах и недостатках. Да, получается короче, но не очень. И не факт, что те 8500 строк которые вы имеете в проекте, нельзя приравнять к 8500 строкам кода на Java.
Мне интересно где вы это прочитали :), а еще более мне интересно кто эту глупость написал.
Option не подходит для обработки ошибок
Объективно, Option это пожалуй один из самых худших вариантов. Используя Option вы никак не сохраняете информацию об ошибке и ее типе. Концептуальное назначение Option обозначать возможно отсутствующую сущность, но никак не обозначать наличие ошибки
Теперь разберемся с Either и Try.
Для большинства случаев применим Try. Он удобен, понятен, и главное, сохраняет информацию об ошибках. Тогда вопрос, а зачем нам нужен Either? Начнем с того, что Either появился намного раньше Try. scala.util.Try появился в Scala начиная с версии 2.10. Data.Either существовал в Haskell, чтоб не соврать… очень давно. Но не для всех ситуаций Try будет являться лучшим решением.
Когда нам нужен Either
Try не является монадой, потому что не соблюдает монадические законы. А иногда, монадическое поведение бывает необходимо.
Either позволяет переносить более сложную информацию о типе ошибки, где Exception может являться вообще полем класса.
И это еще не все
В scalaz есть Validation, которая оказывается удобнее и Try и Either. В библиотекеfs2 существуют свои способы решать проблемы с исключениями.
Такая тема как обработка исключений требует отдельной и обширной статьи. Надеюсь в этом году у меня найдется на нее время.
Если использовать скалу, как Better Java, то ничего хорошего из этого не получается
Не соглашусь. Во-первых, Scala конечно можно рассматривать как Better Java, но ее так же можно рассматривать и как Better Ruby или Better C#. Ситуация не меняется. И да, многие из нас так и начинали. Да, было сложно, да по дороге пришлось разобраться с Haskell. Scala дает множество преимуществ не связанных с функциональщиной, и ради этих преимуществ достойна изучения и дальнейшего использования.
Scala, при всей своей сложности предоставляет достаточно низкий порог вхождения в функциональное программирование. И для многих Haskell будет являть собой именно следующую ступень (а не нулевую :). Безусловно, знание Haskell будет полезным, но не жизненно необходимым для неофитов.
Беззнаковые типы нужны языку для низкоуровневых задач, а ля разбор бинарных форматов и упакованных структур данных, без UInt-ов это может оказаться предельно неоптимально.
А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты
Начнем пожалуй с неудачной модели. Вы понимаете на что создатели обрекают язык, декларируя обратную совместимость? Java исчерпала свой бюджет сложности (для манкикодеров) когда вышла версия 5.0 Tiger. И это не я сказал, а Джошуа Блох. Java сложный язык. И те, кто считает Java простой не знают Java. Дальше будет тоже что и в случае с С++. И, поправочка, Java была консервативной, когда ей рулил Sun.
Т.е. по вашему мнению платформа идеальна?
Сторонние вендоры вам type-erasure починят? И unsigned типы добавят? и добавят большие массивы? И числовые типы заданной длины (как это сделано например в LLVM)? Там знаете можно сделать Int_256 или Int_128 (уже не помню как типы называются, знающие люди простят). И Java все-равно будет медленной.
Конечно же производительность Java адекватна решаемым ею задачам, однако сейчас мы упираемся в не только в тактовую частоту процессоров (которая не растет), но и в количество ядер, которое… тоже не очень то и растет.
И софт придется оптимизировать. И тут на сцену выйдут языки, с бекендом на LLVM. И, возможно, будут достаточно долго доминировать.
Скажу вот что. Следующему языку скорее быть (и причин на это достаточно). И мне очень хочется ответить на эту статью другой статьей, воторую возможно предстоит написать. Для нового языка есть ряд предпосылок.
проблемы с платформами (такими как JVM)
недостаток производительности (упираемся в кремний)
высокая сложность текущих языков
проблемы с эволюцией текущий языков (неудачная модель развития Python и неудачная модель развития Java).
параллельность на уровне языка
возможность составлять dsl, при максимальной простоте грамматики языка.
Ну вот кстати, да. Интересно скольких бы проблем удалось избежать просто накатив win 2k на многострадального ветерана. И ретро-филл сохранится и все-таки на NT-шном ядре можно много чего запустить. В т.ч. благодаря наличию драйверов.
Кстати очень хороший поинт. Хотелось бы посмотреть как развертка будет работать для ARM, а так же как оно будет работать после компиляции в нативный код.
Вот только у IDE после подобных упражнений начнутся проблемы. И придется после этого писать для нее плагин. И скорее всего, это будет плагин для IDEA, который тоже нужно будет поддерживать. Кому-тот придется расширять файлы синтаксиса для vim, а синтакстическим плагинам вима тоже голову будет переодически сносить. Так что если что-то подобное иметь, то из из коробки либо не иметь вовсе.
Знают трое — знает и свинья. С нашим уровнем коррупции, и возможностями пробить всех и вся. И зная некоторые детали болезни можно тихо спокойно и без последствий устранять кого угодно (например владея данными об аллергенах).
Кстати, яндес в этом плане конкретно обнаглел. Причем настолько что мне пришлось снести половину сервисов.А вы были здесь? А оценочку поставите? А здесь были? Не были?
Яндекс, а какое твое дело где я был? Если я захочу поставить месту оценку я сам зайду на карту и поставлю.
Скажу что это очень и очень спорно. У меня нет времени сидеть в группах по интересам. Уверен, что у большинства достойных девушек тоже. И даже если бы было. Сидеть в группе чтобы специально кого-то выцепить? Это в вк сидеть надо дофигищу. В дополнение к закрытым профилям есть еще коты на аватарках. Познакомишься и еще не известно на что ты попадешь.
Крайне неэффективно.
В эру закрытых профилей такое себе развлечение
Как мне кажется, с задачей "Объяснить монаду" неплохо справился Миран Липовича в своей книжке с голубым слоном. Но в Scala, не используя scalaz/cats это сделать не просто, скажем так.
С немцами у меня была похожая история. Только там еще в комплекте шел модуль препроцессора для Java (который вызывался внутри ant-таски и переводил ключевые слова с немецкого на английский). Более того: имена классов, методов и переменных были тоже на немецком.
УчитываяОсобенностиОнногоЯзыкаоно действительно выглядело как нечто родное.Лаконичность кода на языке K это не столько свойство языка K, сколько умение программиста четко и ясно выражать свои мысли вне зависимости от языка. Даже на Java можно писать коротко и понятно (если уметь). А если дать правильному джависту в руки C...
В последнее время читаю очень много кода на Kotlin. И скажу вам, Котлин, там где я его вижу ни разу не лаконичен. Почему? А потому что пишут на нем как на Java. С таким же страшным форматированием. И Scala не лаконична в неправильных руках. Так что если говорить о преимуществах и недостатках. Да, получается короче, но не очень. И не факт, что те 8500 строк которые вы имеете в проекте, нельзя приравнять к 8500 строкам кода на Java.
Мне интересно где вы это прочитали :), а еще более мне интересно кто эту глупость написал.
Option не подходит для обработки ошибок
Объективно, Option это пожалуй один из самых худших вариантов. Используя
Optionвы никак не сохраняете информацию об ошибке и ее типе. Концептуальное назначениеOptionобозначать возможно отсутствующую сущность, но никак не обозначать наличие ошибкиТеперь разберемся с
EitherиTry.Для большинства случаев применим
Try. Он удобен, понятен, и главное, сохраняет информацию об ошибках. Тогда вопрос, а зачем нам нуженEither? Начнем с того, чтоEitherпоявился намного раньшеTry.scala.util.Tryпоявился в Scala начиная с версии 2.10.Data.Eitherсуществовал вHaskell, чтоб не соврать… очень давно. Но не для всех ситуацийTryбудет являться лучшим решением.Когда нам нужен Either
Tryне является монадой, потому что не соблюдает монадические законы. А иногда, монадическое поведение бывает необходимо.Eitherпозволяет переносить более сложную информацию о типе ошибки, где Exception может являться вообще полем класса.И это еще не все
В scalaz есть Validation, которая оказывается удобнее и
TryиEither. В библиотекеfs2существуют свои способы решать проблемы с исключениями.Такая тема как обработка исключений требует отдельной и обширной статьи. Надеюсь в этом году у меня найдется на нее время.
Спасибо!
В первую очередь, если статья легко читается, то благодарность явно не мне :)
В 2.12 нет радикальных изменений относительно предыдущих версий, однако есть множество deprecations.
По поводу зеленых монстров, я думаю большинство джавистов прекрасно поняли о чем я ;).
Не соглашусь. Во-первых, Scala конечно можно рассматривать как Better Java, но ее так же можно рассматривать и как Better Ruby или Better C#. Ситуация не меняется. И да, многие из нас так и начинали. Да, было сложно, да по дороге пришлось разобраться с Haskell. Scala дает множество преимуществ не связанных с функциональщиной, и ради этих преимуществ достойна изучения и дальнейшего использования.
Scala, при всей своей сложности предоставляет достаточно низкий порог вхождения в функциональное программирование. И для многих Haskell будет являть собой именно следующую ступень (а не нулевую :). Безусловно, знание Haskell будет полезным, но не жизненно необходимым для неофитов.
Большое спасибо что добавили список курсов. Надеюсь что для кого-то они окажутся полезными. Честно скажу, про них я забыл.
Эта тема достаточно не плохо (правда на английском) раскрыта здесь
Беззнаковые типы нужны языку для низкоуровневых задач, а ля разбор бинарных форматов и упакованных структур данных, без UInt-ов это может оказаться предельно неоптимально.
А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты
Начнем пожалуй с неудачной модели. Вы понимаете на что создатели обрекают язык, декларируя обратную совместимость? Java исчерпала свой бюджет сложности (для манкикодеров) когда вышла версия 5.0 Tiger. И это не я сказал, а Джошуа Блох. Java сложный язык. И те, кто считает Java простой не знают Java. Дальше будет тоже что и в случае с С++. И, поправочка, Java была консервативной, когда ей рулил Sun.
Т.е. по вашему мнению платформа идеальна?
Сторонние вендоры вам type-erasure починят? И unsigned типы добавят? и добавят большие массивы? И числовые типы заданной длины (как это сделано например в LLVM)? Там знаете можно сделать Int_256 или Int_128 (уже не помню как типы называются, знающие люди простят). И Java все-равно будет медленной.
Конечно же производительность Java адекватна решаемым ею задачам, однако сейчас мы упираемся в не только в тактовую частоту процессоров (которая не растет), но и в количество ядер, которое… тоже не очень то и растет.
И софт придется оптимизировать. И тут на сцену выйдут языки, с бекендом на LLVM. И, возможно, будут достаточно долго доминировать.
Скажу вот что. Следующему языку скорее быть (и причин на это достаточно). И мне очень хочется ответить на эту статью другой статьей, воторую возможно предстоит написать. Для нового языка есть ряд предпосылок.
Спасибо за уточнение! Добавил ссылку на ваш комментарий!