Comments 39
Извините, но именования переменных и функций не очень то сбивающе с толку выглядит
Чтото это мне напоминает… слабую типизацию в JS и другие «нюансы».
Но JS принято хаять, а тут прям как манна небесная все эти возможности запутать код.
Но JS принято хаять, а тут прям как манна небесная все эти возможности запутать код.
В Scala это все compile time магия
Кто Вам сказал, что она слабая? Я не знаю Scala, но судя по Вики и моему знакомству с Хаскелем, типизация у Scala как-раз таки строгая статическая с выводом типов.
Т.е. вот это правильно и все так должны делать?
Пример повышенной читабельности
str charAt 5
Пример повышенной читабельности
Чтото это мне напоминает… слабую типизацию в JS и другие «нюансы»
Scala является strong static type языком. За механизм вывода типа отвечает компилятор, если вы не указываете его явно.
Т.е. вот это правильно и все так должны делать?
Все зависит от вашего style guide. Но обычно такой вызов метода, в infix notation, не используется. Предпочитают более явный: str.charAt(5)
Эта форма используется часто для DSL. В скале это одна из киллер фич. Вы описываете свои операторы для своего языка который вам подходит, получаете максимально выразительный код практически без boilerplate. Не все, конечно, ложится, но для всяких систем правил, ETL и прочего — очень удобно. Когда вы пишете просто императивный код есть соглашение, что когда есть символьные имена используется операторная нотация, а когда нет — обычная через "точку".
В Java есть Optional, REPL и функции как инстансы. Сюрпрайз.
А вообще — удачи!
А вообще — удачи!
Собственно, после этого можно было не читать уже. Есть, и давно. Не говоря уже про то, что сторонние реализации Option существуют с момента появления generics.
Давайте будем снисходительны. Джиниор, думал, что знает Джаву, открыл для себя Скалу, решил поделиться. Ну что плохого то? :)
От скалы тут тоже далеко не главное открыли.
Ну, особо плохого в том, чтобы чего-то не знать, конечно нет. Но понимать, что ты еще почти ничего не знаешь, вообще говоря стоит. У меня несколько двоякое впечатление — с одной стороны, явных ляпов нет, текст нормальный, а с другой — автор явно в глаза не видел Java 8 и новее.
С точки зрения автора — все хорошо. С точки зрения читателя — еще один, сто десятый пост о том, что существует такая штука, как fold?
С точки зрения автора — все хорошо. С точки зрения читателя — еще один, сто десятый пост о том, что существует такая штука, как fold?
Конечно же я это прекрасно понимал, когда писал эту статью :) И мне казалось, явно это дал понять в ней, призывая опытных ребят делится советами с тем, кто только начинает.
Вообще говоря, статью я писал 2 года назад и уже давно забыл про нее. Сейчас за нее немного стыдно)
Но, тем не менее, главная цель — поделиться впечатлениями новичка и рассказать свою историю о том, как пробовал учиться. Для таких же новичков. Если бы я в то время нашел такую статью, мне было бы 100% интересно.
Вообще говоря, статью я писал 2 года назад и уже давно забыл про нее. Сейчас за нее немного стыдно)
Но, тем не менее, главная цель — поделиться впечатлениями новичка и рассказать свою историю о том, как пробовал учиться. Для таких же новичков. Если бы я в то время нашел такую статью, мне было бы 100% интересно.
А отчего же сейчас немного не переписать, если вы понимаете недостатки?
А зачем искажать впечатление? Тогда я думал и знал именно то, что написал. Если сейчас что-то исправлять, то получится уже рассказ совсем от другого человека. Что идет в разрез с тем, ради чего я ее тогда хотел написать.
А про всякие технические неточности и т.п. уже написали, или напишут, в комментариях.
Повторюсь, цель — рассказать историю. А переписывать историю не круто)
А про всякие технические неточности и т.п. уже написали, или напишут, в комментариях.
Повторюсь, цель — рассказать историю. А переписывать историю не круто)
С одной стороны как бы да, вроде ничего плохого…
А с другой стороны, такого материала просто завались в интернете.
Он не добавляет вообще ничего к теме изучения, увеличивает данные при поиске инфы.
Но самое главное! Такие статьи банально вводят в заблуждение неточностью информации. Что порождает чудовищное количество мифов во круг языков вообще и скалы в частности.
Ведь никто не будет править статью, вносить изменения, уточнения и т.д. Она так и будет, извините, «засирать» головы начинающим разработчикам, у которых еще не сформировалось критическое мышление в отношении языков программирования.
ИМХО Таким статьям место в личном бложике, а не на популярных ресурсах.
А с другой стороны, такого материала просто завались в интернете.
Он не добавляет вообще ничего к теме изучения, увеличивает данные при поиске инфы.
Но самое главное! Такие статьи банально вводят в заблуждение неточностью информации. Что порождает чудовищное количество мифов во круг языков вообще и скалы в частности.
Ведь никто не будет править статью, вносить изменения, уточнения и т.д. Она так и будет, извините, «засирать» головы начинающим разработчикам, у которых еще не сформировалось критическое мышление в отношении языков программирования.
ИМХО Таким статьям место в личном бложике, а не на популярных ресурсах.
А можно про REPL для Java поподробнее?
Главная фишка для простого программиста — ее Collections. Там есть immutable collections весьма полезные для параллельного и всякого другого программирования-моделирования где большие данные ветвятся на альтергативные варианты. Т е для реально чего-то сложного. Для обычных бизнес-приложений писать на Scala как ездить на танке в булочную. Прикольно но разницы с велосипедами-мопедами(Go, Kotlin,C#, Python, ..) особой нет.
1. Вот уж параллельные коллекции использовать не надо. Их выпилят в 2.13.
2. Сравнение с танком странное. Если использовать как better-java, то разницы не особо — синтаксис и еще одно стдлиб. Если использовать фп, ну это как раз для бизнес-приложений отлично. Гарантий больше, тестов меньше.
2. Сравнение с танком странное. Если использовать как better-java, то разницы не особо — синтаксис и еще одно стдлиб. Если использовать фп, ну это как раз для бизнес-приложений отлично. Гарантий больше, тестов меньше.
Про параллельные коллекции не заикался. А фп которое поверх коллекций весьма замедляет код, чем в тупую циклы как напр. на Go. Не умеют они их там умно разворачивать, а в новой 2.13 реализации как показывают тесты замены на VIEW варианты(которые там по умолчанию) еще замедляют а не ускоряют код. (P S Для меня Scala №1)
Их не выпилят, а вынесут в отдельный модуль.
Option. Такого в Java нет. В двух словах — это контейнер в котором либо пусто(None, похоже на null, но имеет методы map, filter, ...),
В java иногда (я первый раз в живом коде увидел в 2005 году) применяют паттерн создания статик инстанса объекта с именем NULL. И в методах, где возвращается экземпляр обьекта этого класса, если по ряду причин неудобно кидать эксепшен, возвращают этот NULL. Не всегда применимо, но частенько спасает. Особенно при всяких ETL операциях. Скала походу оттуда это взяла. Вкупе с паттерном «возвращать список» ваще сильно устойчивая ко всяким неожиданностям архитектура получается
применяют паттерн создания статик инстанса объекта с именем NULL
Выглядит как царь-костыль.
Скала походу оттуда это взяла.
Маловероятно, в Scala много чего пришло из Haskell и других ФЯ. Посмотрите там Maybe, очень похоже. Ну а потом, уже видимо из Scala, это перекочевало в Java 8 в виде Optional.
Любой паттерн применяемый везде, где надо и где не надо — станет царь-костылем
Описанный мной паттерн удобно использовать, когда нужно замапить внешние данные в какую либо внутреннюю структуру и при этом нет большого смысла сообщать о нечастых ошибках во входных данных или о том, что незначительно изменилась их структура.
Хотя бы потому, что никаких движений по их исправлению не будет, грубо говоря, заказчика вполне устраивает если будет успешно преобразовано 60..70% входных данных из большой иерархической структуры. Вот там такие «заглушки» вполне к месту.
Описанный мной паттерн удобно использовать, когда нужно замапить внешние данные в какую либо внутреннюю структуру и при этом нет большого смысла сообщать о нечастых ошибках во входных данных или о том, что незначительно изменилась их структура.
Хотя бы потому, что никаких движений по их исправлению не будет, грубо говоря, заказчика вполне устраивает если будет успешно преобразовано 60..70% входных данных из большой иерархической структуры. Вот там такие «заглушки» вполне к месту.
Костыль, костыль.
None это синглтон типа Option[Nothing].
Nothing это синтетический костыль-тип, являющийся подтипом для любого типа. Другими словами Nothing наследуется вообще от всего и сразу.
Option ковариантен. А значит Option[Foo] является супертипом (родителем) для None: Option[Nothing].
Именно ковариантность позволяет использовать None с Option любых типов.
Благо все это существует лишь в разуме компилятора. А потом хренакс: привет стирание типов и Option[Object].
Ну совсем же не похоже — экземпляр класса vs пустая коллекция. Больше похоже на nullable объекты, только проверки на null легко потерять, а в Option/Optional тип хоть не совсем строго, но поощряет правильное использование.
Ну совсем же не похоже — экземпляр класса vs пустая коллекция.
Не совсем понял, что не похоже? Где экземпляр класса? Где коллекция?
Экземпляр — NULL в комментарии tuxi, коллекция — Option.
Я незнаком со Scala, но интересно, почему она в свое время не взлетела как Kotlin для андроида? По примерам из публикации лично у меня никакого дискомфорта нет и вроде как тоже меньше кода пишешь, удобнее
Очень тяжелая во всех смыслах. И для запуска на андроиде и для вхождения в язык широких масс, да и для тулинга тоже. Просто в статье много чего не описано, от этого кажется, что все просто. Посмотрите, например, на библиотеку scalaz, там все поинтереснее. Может возникнуть вопрос: а зачем мне эту дичь использовать? Ответ: вы может и не будете, но кто-то в вашей команде может. То есть, одну и ту же задачу в Скале можно решить множеством способом: и в стиле Java+ и в стиле Хаскеля. Это очень круто, но предъявляет повышенные требования к организации гайдов для кодинга и т.д.
UFO just landed and posted this here
Нульарная Function0 смотрит на вас с обидой.
Sign up to leave a comment.
Как я Scala учил