да чего там сложного в функиональной парадигме. Для тех кто нипанимать, объясню на пальцах смысл. Представьте какой-то паскаль. Там были процедуры и функции. Процедуры от функций отличаются тем, что первые не возвращают значений. Синтаксически в языках вроде Си их объединили, всё функции, а те, которые не возращают значения, возвращают void. Может выше и глупый пример обобщения, но для объяснения думаю пойдет. Функциональная парадигма еще больше обобщает. Она утверждает, что данных нет, всё функции. Т.е. у вас грубо говоря нет даже переменных, чисел, ничего, одни функции. Что такое функция? Это некоторое преобразование того, что приходит ей в аргументах, в возвращаемый параметр. А что если у функция будет всегда возвращать одно и то же? Т.е. константу. Ведь может же быть в математике такая функция? Просто горизонтальная прямая на графике. Вот представьте, что функция всегда возвращает 4. four() Если вы пишете свой компилятор своего языка, то можете всё сделать на функциях абсолютно. Ведь и то что будет приходить на вход от юзера, можно преобразовывать на поток функций констант. И даже то что на диске, данные - это просто поток функций констант. Но при этом, если вы пишете свой компилятор, вы можете делать синтаксический сахар, и вместо функций, вроде four() писать 4. Таким образом вы можете написать язык, в котором будете даже понятно для себя и остальных писать что-то вроде x = 4 + y * 7; но на самом деле это всё функции. Тут нет ни присваивания, ни переменных-чисел. Т.е. функциональная парадигма - это еще на один шаг обобщение. И это прекрасно, если это понять. Функциональная парадигма сама по себе не тяжелее. Смотря как компилятор сделан под капотом. Если там нормально, если на лямбда исчислении и компиляции, то он имеет все шансы быть быстрее на сложных алгоритмах. В самой парадигме заложен огромный потенциал оптимизации кода компилятором. Ну а с остальным, наверное, согласен. Требует выше квалификации, а люди если переходят на нее, то с другой парадигмы, пишут с т.з. функциональной парадигмы говнокод. Чтобы читать этот код, надо иметь опыт. А где его взять?
@@Dmytro-Tsymbaliuk Какая разница что там на диске когда речь идет о выскокоуровневых абстракциях. Да, компилятор для функционального языка скорее всего написан императивно с переменными, циклами и прочими низкоуровневыми ништяками, возможно даже с ручным управлением памятью, но сама абстракция которую предоставляет этот компилятор не имеет переменных, циклов и прочего....
Всё это конечно красиво, если просто обробатывать потоки данных. Но если нужно обрабатывать состояния в функциональной парадигме придется изрядно поизвращаться.
По мне так благодаря функциональной парадигме писать код становится намного проще. Куча ограничений и правил парадигмы (вроде иммутабельности структур данных) в итоге не даёт тебе наступать на грабли. И по большей части язык устроен так, что иначе ты написать не сможешь. Плюс вместо монструозных фреймворков типа Akka сейчас есть куча удобных и маленьких либ вроде Http4s или Fs2 (где работа с потоками вообще превращается просто в работу с коллекциями). Порог входа, может, высоковат, но он того стоит. А ещё, по моим ощущениям, я устроился на Джуна (Скала первый профессиональный язык) как раз благодаря небольшому количеству соискателей.
Если вам достался проект на Scala и вам тяжело и долго было впиливать фичи и чинить баги, то может проблема в том, что у вас Java разработчики, а не Scala, а не в языке?
То что Вы рассказали о фреймворках Scala в дествительности совсем не так. Есть условные две ветки. Первая - Spark и BigData, вторая - энтерпрайз. Энтерпрайз делится условно на три ветки: Scala как Java(без ФП, Spring, Hibernate, один в один Kotlin), Scala как Scala (Akka, Play, Slick) и Scala как Haskell (ФП, cats, zio, fs2, http4s, doobie, circe). Первая ветка практически вымерла. Вторая теряет популярность, но всё еще встречается в вакансиях. Третья модно-стильно-молодежно на всех конфах. Не популярны фреймворки в Scala! Чаще берут стопку библиотек и выбирают то что хочется. Поэтому эти ветки иногда смешивают между собой в любых пропорциях. То что Вы рассказали актуально на год эдак 2015-ый.
@@Anton_Zh язык не сложный. Сложно привыкнуть к тому, что всё иммутабельно. В первую очередь, рекомендуемые коллекции, они же персистентные структуры данных.
@@feoktant Антон помогите ответить на вопрос. Все пытаюсь откосить от курсов гикбрейнс и им подобных.. Будет ли нормально с моей стороны пробиваться через стажировки в компаниях чтоб научиться программировать? По делу как бы сразу и себя проверю заодно потяну я рабочие будни или нет..))
Hello world на Java: public class Main { public static void main(String[] args) { System.out.println("Hello, world!"); } } Hello world на Scala: println("Hello, world")
Scala или другой функциональный язык имеет смысл учить , даже если его не собираетесь его применять. Поднимите свой общий уровень как разрботчика новыми парадигмами. та же Java уже давно черпает идеи для новых фич из функциональных языков. вот что пишет Brian Goetz, Java Language Architect:' "I’d especially recommend learning a functional language, because it will give you a different and useful perspective on how to construct programs, and will stretch your brain (in good ways.)"
Такое пишут все, чтобы купили их книгу. Или вы думаете он напишет правду, чтобы его книгу не покупали? Так можно бесконечно всякую ерунду учить. Языки выдумывают каждый год по несколько десятков. Выживают единицы :) Работать будет некогда из за постоянной учебы. А что касается Scala, то уже 3-й вариант синтаксиса появился. Это говорит об отсутствии каких либо серьезных преимуществ в конструкции языка, если все так кардинально меняется каждый раз.
Функций более высркрго и более низкого порядка нет, а есть только функции высшего порядка. Это такие функции, которые принимают другие функции в качестве аргументов или возвращают функции. Они, в свою очередь делятся на: колбэки, функции-обертки и фабрики функций.
Колбеки еще называют лисенарами или обработчиками событий. А обертки - враперами. Если возвращается функция, созданная внутри другой - создается замыкание и она видит контекст, в котором была создана. На базе этого можно создавать функторы и монады - рекурсивные замыкания или цепочки преобразования значений. Все это, конечно, очень не оптимально, т.к. состояние при любом изменении копируется и старое уничтожается сборщиком мусора. Если рантайм не умеет раскрывать рекурсию и инлайнить функции, то вообще ужас.
@@СергейЛавров-б9й я, если честно, и сам не очень люблю функциональщину, я люблю мультипарадигменный подход, в котором используются элементы ооп, фп, реактивного и асинхронного программирования, где можно иногда написать часть и на старом процедурном и на структурном программировании, и использовать новые пост-ооп подходы, но чтобы так писать, это конечно нужно в нескольких парадигмах шарить и иметь практику их совмещения, это на порядок сложнее, совсем не обязательно приводит к усложнению кода, даже наоборот, это часто позволяет сделать код более читаемым, например, паттерн "стратегия" можно иногда заменить коллекцией функций.
Какая-то дикая каша. Почему когда автор говорит про минусы скалы, он на самом деле говорит про "минусы" ФП, а не языка как такового? На скале можно писать и ФП, и ООП. Так и называйте тогда видео "ФП" vs "ООП". И это уже настолько дикая и холиварная тема будет, что ой ёй ёй, тремя бомбящими скалистами в комментах тут не обойдётся. Что конкретно сложного в скале как в языке по сравнению с джавой? Я хз как можно переписать код со скалы на джаву и чтобы стало проще. Если вы при этом меняли стиль с ФП на ООП, то извините, у вас просто команда могла в ООП, но не могла в ФП, а могло бы быть и наоборот. И язык здесь совершенно ни при чём, могли и на ООП скале остаться. На джаве тоже можно писать очень непонятно. Обмазаться рефлексией или мутабельными вещами в многопоточке и сидеть радоваться. Да вообще на любом языке можно написать очень непонятно при большом желании, так себе аргумент. Про то, как много нужно знать программисту. 1) Скалист знает, что у него есть `==`, он его использует, ему норм, больше ничего не надо. Джавист знает, что у него есть `==` для примитивов, а для объектов нужно `equals`, хотя `==` тоже есть, но его использовать нельзя. Но этого знать мало, ведь ещё перед вызовом `equals` надо проверить левую часть на null, а то NPE будет. 2) Скалист знает, что если метод хочет Double, а у него есть Int, то он просто отдаст туда Int и ему норм. Джавист знает, если метод хочет Double, а у него есть int, то просто так отдать int нельзя, потому что кастинг типов и оборачивание одновременно не сработают. И он получит всратую ошибку компиляции про то что int нельзя привести к Double (лол). 3) Скалист знает, если у него есть List[Int], а метод хочет List[Double], то он просто отдаст туда этот List[Int] и дело с концом. А джавист пойдёт нахрен, потому что оно просто не работает. А если там будут хотя бы наследники, то пойдёт пойдёт страдать и учить pecs. Потому что поддержки вариантности нет и надо играться с `? super` / `? extends`. И это вообще не касаясь бизнес логики (потому что она на обоих языках одинакова), а про то, как пользоваться языком. На скале уже эти детские ошибки учтены и всё работает примерно так, как ожидает человек, который не знает деталей реализации. А на джаве куда ни плюнь так "well yes but actually no". И на каждую конструкцию в языке нужно знать пачку ситуаций, где это тебе выстрелит в ногу. Так где, говорите, нужно знать больше?
@@ДимаШевчук-и7э Именно из литературы есть Programming in Scala от Одерски (автора языка), она хороша. Есть Скала для нетерпеливых от Хорстмана, я её не читал, но говорят что норм. Если скала зайдёт - Functional programming in Scala, но это уже потом, не для начала. Но вообще если с английским языком всё неплохо, то есть очень хороший курс на курсере из 5 частей. Первые две части рассказывает Одерски, они топ, остальные част уже немного в сторону идут (www.coursera.org/specializations/scala). Если не оч хорошо, то есть на степике от тинькова, но он меньше и сложнее для восприятия.
Переведу на русский сказаное про провал проекта на Скале - у нас была команда джавистов, которые ни в зуб ногой Х. Ну мы взяли проект, думая что это то же самое. Народ учил Х конечно, но медленно. Тогда мы решили переписать на джаву, и ничего нового не учить. Работа - не курсы. В этой истории правильное менеджерское решение - переписать на тот язык, которым умеет пользоваться комманда. Если бы проект был на С++ или С#, решение должно было быть ровно таким же. Или взять другую комманду на проект. Была бы у вас комманда скалистов тогда, и курсы по скале сейчас - вы бы говорили, что это лучший язык)
Сначала про скалу: Во-первых, как было справедливо замечено, скала может использовать всё, что есть в обычной джаве. Во-вторых, идеалогия скала не заставляет писать только иммутабельные структуры, но сам синтаксис построен так, что их удобно использовать. Чего стоит объявление константы в одно короткое "val" В-третьих, как ни крути скала лаконичнее. Да, это несёт за собой не только хорошее, но в общем и целом число строчек - тоже метрика читабельности кода. Есть момент - написание в функциональном стиле. То, что это сложнее - не совсем верно. Скажем так, функциональная парадигма определённо имеет более высокий порог вхождения. И действительно, если рассматривать только его, то функциональная парадигма - сложнее. Однако, если рассматривать состояние немного дальше этого самого порога, выясняется другая сторона вопроса: 1. Функциональная парадигма гораздо легче опирается на математику. 2. Чистые функции над иммутабельными объектами из коробки могут исполняться асинхронно. 3. Из двух предыдущих пунктов следует, что функциональная парадигма легче масштабируется. Учитывая это можно сказать, что несмотря на более высокие входные требования к разработчикам, сложность функционального проекта со временем растёт медленнее, чем сложность ООП. Итог таков: всё зависит от того, какие требования предъявляются к проекту. Скала - масштабируемая, джава - проще и дешевле для разработки, но сложность растёт быстрее. Да и ещё, про читабельность кода. 1. Нечитабельный код можно написать на любом языке. 2. Скала лаконичнее, а значит каждая лексема становится более ёмкой, следовательно чтение кода на ней требует больше усилий, но меньше времени. В дополнение могу сказать, что скала имеет больше синтаксического сахара и больше возможностей для написания оного, что с одной стороны облегчает чтение для более продвинутого разработчика, с другой стороны повышает порог вхождения и сложность прочтения кода при знакомстве с скалой. 3. В скале многое доступно "из коробки". Такого, с чем необходимо разобраться: implicit, pattern-matching, case-class, и т.д. Опять-же, увеличивает порог вхождения, но и облегчает чтение скала-код для более продвинутого разработчика. И немного мнения: Мне кажется, что код на скале можно писать очень выразительно и коротко. В среднем получается, что комментарии на скале у меня занимают существенно больше места, чем собственно код. В то время, как на джаве - сравнимое число строчек. И немного горения: Как кажется, вопрос о том, какой язык учить - довольно странный. Если речь идёт о первом языке программирования - это почти не имеет значения. Хотя, наверное, не стоит первым учить lisp, впрочем, дискуссионно. От изучения первого языка человек получает понимание основ программирования - переменная, функция, тип, и т.д. Это есть во всех языках, так что в принципе, не важно, какой учить. Если же речь о том, какой язык осваивать следующим, вопрос ещё более странный. Знаешь джаву - взгляни на скалу, главное, что получишь - понимание того, насколько на самом деле могут быть удобны функциональные конструкции. С тем же успехом, можно было бы освоить и haskell, но синтаксис в scala джависту будет понятнее. Не знаешь джаву, и при этом не очень глубоко в функциональном программировании - сначала возьми джаву. Твой любимый язык - хаскель(или другой язык ФП), тогда в скала добавит немного огня, но там встретишь много знакомого. Как-то так?
Чуть чуть добавлю про Scala в DS: Суть такова, что для анализа больших данных (или потоковых данных) используется Spark и вся его экосистема. Сам по себе Spark Core не зависит от языка программирования (Scala/Java/Python - разницы в коде практически нет) и взаимодействует с данным посредством API (ну а на нодах все реализуют JVM). Однако, т.к. Spark изначально был написал на Scala (а потом добавляли куски кода на Java), то по скорости код на Scala исполняется быстрее (ибо своё, родное). Но это, опять же очень сильно зависит от конкретных задач. Для кого-то важно повышение скорости обработки данных на кластере, а для кого-то нет. Одно дело - потоковая обработка из разных источников (привет Kafka!), другое - периодические выгрузки (в какой-нить Postgres). (вообще на суперкомпьютерах (от 20к ядер) spark не показал разницы по скорости между Scala/Python). Сам функционал анализа данных обеспечивается Spark MLlib API и плакать, колоться, но писать именно на Scala смысла нет (а чаще всего все заканчивается выгрузкой из RDD на любимый комп csv-файла и работой на Python. Зря что ли кросс-валидацию и сэмплирование придумывали?) з.ы. В анализе больших данных нет широкой столбовой дороги и если вы точно не знаете, зачем вам писать код на Scala, значит вам это не нужно - пишите любимой джаве и не парьтесь.
Да спарк на скале роднее пишется, и там и там иммутабельность, лейзи и все такое. Плюс сама апишка на скале красивее всех. И важно не писать на питухоне, а то при первой потребности в udf можно начинать сосать бибу
В перспективы разработчиков вы могли написать про реальные проблемы скалы: токсичное раздробленное сообщество, отсутвие главного стека технологий типа спринг\джанго, скала 3 которую все ждут уже 5 лет, возможный раскол как был в питон 2\3, курс на упрощение имплиситов, желание черпать новых скалистов из питона в конце концов! Но нет! Вы за выпуск повторили "скала сложная" раз 20 ничем не аргументировав.
Было бы круто если бы было пару открытых примеров. Я вот например java трогал одним мизинцем пальца ноги. И сложно на слух воспринимать лёгкий код и сложный код.
Более простой ФП язык врядли появится, потому что что скала и так простой язык, как бы странно это не звучало после просмотра видео. Есть язык Haskell, Idris, Agda, они более приближенны к ФП парадигме и их синтаксис разительно отличается от скалы. Кто-то бы даже сказал, что они гораздо сложнее скалы.
@@feoktant , они менее навороченные (нет тайпклассов и прочего продвинутого ФП из коробки), там старый понятный алгоритм вывода типов, синтаксис очень приятный, вообще языки более целостные сами по себе. ООП не используется практически нигде, всё на простой композиции. С другой стороны есть всякие Units of Measure, active patterns, можно писать быстрый императивный код с симдами, ассемблерными вставками, есть файнал тэглесс. Но обычно везде пишут очень просто и понятно. ИМХО, скала выглядит неряшливо на фоне своих более примитивных собратьев, discriminated unions вообще в библиотеке, а не из коробки. "Принцип компота(с)", короче. Думал Дотти будет ЗНАЧИТЕЛЬНО чище.
@@cryptoworkdonkey тайпклассов из коробки в Скале тоже нет) их пишут через имплиситы, в дотти красивее. На счет неряшливости соглашусь. И синтаксис F# мне нравится больше. Правда, нужно время к нему привыкнуть после си-подобного кода
Выскажу тут своё мнение как скала джун. Учить без знания основ джавы или другого ЯП будет сложновато, сам искал изначально работу в качестве джава разработчика, но случайно попал на скалу, месяца 2-3 испытывал сложности. Язык сам по себе сложноватый, но в целом норм. На Play + Akka пишется всё довольно просто и типично, не особо отличается от круда в том же спринге. Стек с кошками не трогал пока, там уже скала на фулл фп. Скала как вампир - 1 раз укусит джависта и обратно уже не хочется)) Короче, это джава на стероидах. Про матан хз, университетский вообще не помню. Стоит ли учить? Почему бы и нет, особенно после джавы, технологий интересных много, особенно Akka и всё с кошками.
Год работал со скалой в хадупе (а точнее - в спарке), в целом согласен с Сергеем. На скале очень весело писать код, получается довольно красиво и компактно, но вот читать чужой код бывает крайне сложно. Не в последнюю очередь из-за имплиситей, которые некоторые любят пихать в свой код без меры. В результате получается кратко, но фиг разберешься, что тут реально происходит. В общем, я бы не стал на ней большие проекты делать. А сам я перешел писать для спарка на питон, получается не хуже и в моей области (дата саенс) намного удобнее - в питоне для этого есть кроме спарка еще огромное количество либ, которых в скале нет и в помине.
Имплиситы нужны либо в библиотеках, либо в очень редких случаях. Скала 3 наконец разделит эти понятия. И добавит форматирование как в питоне. Ждем вам обратно очень скоро ;)
@@woodzimierz9621 учитывая, что под Android уже тот же Jetpack написали на Котлине, думаю ставки на него очень большие и в ближайшие лет 10 он точно не умрёт. Ну и опять же есть Ktor; тот же Spring сейчас поддерживает разработку на Kotlin.
скала НЕ сложный язык. Проблема сложности программ на нём в том, что там пытаются повторить принятые в мире ФП паттерны, при этом не все возможности чистых функциональный языков поддерживаются. Те же тайпклассы описываются через имплиситы. Плюс у языка много своих возможностей, и к обычным паттернам добавляются ещё и скаловские(типа cake). Но в целом, если есть понимание что автор хочет сказать - никаких проблем для чтения нет. А т.к. язык более выразительный, в итоге более сложные вещи читать и писать проще чем на java. Другими словами тот же уровень абстракции на java выразить если и можно, то читать это будет гораздо сложнее чем скаловский код.
" принятые в мире ФП паттернв, при этом не все возможности чистых функциональный языков поддерживаются" а что более чище в этом плане? haskell? мне действительно любопытно
@@AndriySydorka есть pure fp языки вроде haskell, idris, agda. Haskell, конечно, самый мейнстримовый из них. Чистота в фп означает, что у функций не может быть побочных эффектов. В scala это не так.
@@АндрейРешетченко-т9й Инкапсуляция - это скрытие внутренней реализации от других компонентов. Как раз функции без сайд-эффектов инкапсуляцию улучшают, т.к. зависят только от их сигнатуры и публичных методов принимаемых ими объектов.
@@VaGroz нет, инкапсуляция - это объединение данных и методов в единый компонент. То есть есть клас с состоянием и методы для изменения этого состояния. Но вот изменение состояния объекта является сайд-эффектом.
@@АндрейРешетченко-т9й впервые сталкиваюсь с таким определением. Тем не менее, озвученная проблема - не проблема, т.к. все transform-методы класса просто возвращают новую копию объекта.
Всё у Сергея неплохо, кроме одного - языки которые он не осилил по тем или иным причинам (не думаю что от недостатка мозгов или прочего, скорее - времени или интереса) он считает плохими и всячески ругает, нередко необоснованно. Посмотрел это видео чтобы снова в этом убедиться)
@@Mike19910711 неверную/необоснованную критику (он для того не подходит, на нем код сложнее на пару порядков, тут можно писать только знаю математику (очень интересно какую), язык маргинальный и т.д.) расцениваю как заявления о "плохости" языка, уж простите)
Ну хз, с тем что js стрёмный я например с ним согласен). И да, оговорка что это вкусовщина или лично его отношение к языку, присутствует обычно. Так что всё он нормально говорит.
@@max_mgtow Это прекрасно, только в JS нельзя напрямую работать с функциями и классами написанными на Java или Scala. А на Kotlin можно. Поэтому JS тут неуместен. Если у вас есть большой проект на Java, вы сможете добавлять новые фичи написанные на Kotlin и использовать их в существующем Java коде. С JS так не получится, вам придется полностью переписывать проект. В этом принципиальная разница.
Чувствуется, как Сергей изо всех сил хочет сманипулировать зрителями и внести свой вклад в смерть сообщества скалы. Видео только отчасти правда. Скала из коробки это не какие-то основанные на математических правилах конструкции, это всё те же классы, объекты, методы, лямбды. Кучу фишек скалы можно увидеть в котлине (но не все, есть пара киллер фич из-за которых не ней удобней). Возможно что-то офигенно удобное есть в котлине, чего нет в скале я не знаю. У скалы более увесистая стандартная библиотека (мегабайт 5 вроде) поэтому на ней не часто пишут приложения под андроид, но это возможно (к слову её вполне можно порезать proguard'ом (удовольствие сомнительное, но облегчить артефакт можно сильно)). Вся алгебраическая заумь начинается когда код начинают писать с использованием функциональных библиотек (cats, zio, раньше scalaz), которые подтаскивают хаскельные понятия типа монад, апликативов, но когда разберёшься с этим на ванильную джаву смотришь как на фортран. То что скала прожорливая не совсем правда, на ней можно например написать код с дженериками которые скомпилируется в версию не столько для ссылочных типов но и для примитивов (всех например) и таким образом увернуться от боксинга, другой вопрос, что этим редко кто занимается и вообще не парятся на счёт лишних копирований данных (хотя есть возможности их минимизировать). Скала это про type-safety больше, чем в джава и наверное даже больше, чем в котлине. Про корректную и удобную канкаренси. Про тулы, которые генерят код и если не могут, то мы получаем compile-time ошибки, заместо runtime после месяца эксплуатации в 3 часа ночи в пятницу вечером. Ну и + не нужно дожидаться когда сгенрённый код заоптимизируется dereflection'ом или в рантайме отработает какой-нибудь asm, он сразу есть и сразу быстрый (также, например, как работает джавовый mapstruct или retrofit). Про кучу удобных методов на коллекциях (тут котлин тоже молодец, питон ниже плинтуса, а джава где-то посередине). Ещё фор-компрехеншены, стексейфти и кастомные интерполяторы. Хватит пожалуй.
ну мы както давно в в проекте для видеокамер порвали жавакодеров связкой clojure+erlang, я бы не сказал что фп требовательно к ресурсам, скорее наоборот. Джава для сбора данных с камер постоянно падала и не выдерживал нагрузок, тогда как ерланг стабильно их собирал, мало потреблял и даже траслировал видео. Все остальную бизнес аналитику и бизнеслогику делали на cloure, поддерживалось легко, фичи внедлялись быстро.
Лисп очень даже удобно читается. Польская нотация - это наиболее однозначный тип записи. Он часто используется в SMT солверах, например - то есть там, где необходима однозначность. Ремарка про Clojure.
Ууу... "Функциональная парадигма вообще в принципе ресурсоёмкая" - с этого момента поподробнее. Во-первых, парадигма не может быть ресурсоемкой по определению. Мягкое с тёплым. Читайте словарь. Во-вторых, выйгрыш в использовании ресурсов зависит от конкретной задачи, от кода. Вы же сами сказали, что Scala используется для потоковой обработки данных. Наверно, она используется потому что потребляет меньше ресурсов? А функциональная парадигма одной Scala не ограничивается. По поводу перспектив Java у меня тоже большие сомнения. Кому нужен, по вашим же словам, "сложный язык" со "сложными фреймворками", если можно писать на Ruby, Python, NodeJS? Вы Scala откинули ровно по этим соображениям - слишком сложная.
И снова в рубрике, что лучше: джава или язык, который я не знаю, победила джава) Что лучше: джава или микроволновка. В микроволновке я вчера спалил бутерброд, запах жуткий стоял на всю квартиру, а на джаве 10 лет работаю. Поэтому джава лучше.
Сразу видно, у автора нет опыта в скале и он лишь что-то где-то видел и слышал давным давно, предполагаю что автор даже не слышал про котоэффекты, фс2, хттп4с и тд Слышал ужасы про акку и тд (и даже разбирал легаси проект), но сегодня скала это один из (если не самый) прекрасных языков позволяющий писать невероятно безопасный и тестируемый многопоточный код, где одна строка несёт в себе смысла как 5 джавовых (что, кстати, помогает и с читаемостью кода) С любовью, джун-скалист, не работавший с джавой, из компании на ~100 скалистов с всем бэком на скале
@@vijexa хм. в b2b юрлицом с одной стороны выступает казино, а с другой стороны какое юрлицо, покупающее услугу азартных игр у казино?🙂 форд моторс?) я даже и не знал, что такое существует)
@@manOfPlanetEarth я предполагаю, что с одной стороны реальное казино, а с другой - компания, предоставляющая платформу для казино: игры, чаты, оплаты, инфраструктура и тд
Сергей, а Вы сами программировали на Скале? Я из каждого утюга слышу, что Скала сложная, непонятная, что синтаксис кривой. А в итоге в Java появляются records, а Kotlin от Scala так вообще не всегда отличишь. В моем прошлом месте работы было трое Scala девелопера, без знаний Java. Двое из них джуниоры, и они прекрасно перформили. Один из этих джуниуров студент, Scala его первый коммерческий опыт. У меня ощущение, что Scala мешает всем продавать Java) И заклеймили язык сложным и непонятным. А убери имплиситы, и получишь практически Kotlin. Kotlin сложный?
А какие языки программирования вы считаете наиболее перспективными для старта карьеры в IT? я сам выбирал курсы для веб-разработки, рассматривал разные варианты, но остановился на Skypro из-за хороших отзывов и структуры обучения. Лично я уже через несколько месяцев смог устроиться на работу с хорошей зарплатой))
Немчинский всё время забывает про третью сферу применения Java это автоматизация тестирования, из всех языком имеет самое большое количество библиотек под любые нужды
Я бы раст поучил. Тоже функциональные плюшки есть, хоть и немного многословен, но читается отлично, быстрый, на многое способный и активно поддерживаемый. Думаю, тем, кто все же не особо осилил скалу, может прийтись по вкусу
Для себя норм. Для работы имхо придётся поискать. Я бы начал с прадедушки Си или дедушки плюсов, если хочется в байтах и памяти поковыряться. В раст переключиться, когда он наберёт популярность (лет 5-7) будет несложно. Либо жаба или шарп, если на веб целиться.
Вам не нравится Scala потому что вы привыкли мыслить императивно. В свое время когда учил ФП мне тоже ломало мозг после ООП, но потом при сравнении одного и того же кода я был очень удивлён, что сложная логика, которая в императивном подходе сводилась к лапше из if statements, либо имела много ООПшного бойлерплейта, в ФП подходе выглядит и поддерживается и тестируется гораздо проще. ФП подход идейно задуман для того, чтобы упросить жизнь, а не усложнить. Если в проекте это не так, то подход был применен неправильно.
Cмысл есть. Если ранее программирование не учил, то Java Start поможет за короткий срок освоить основы java и подготовиться к курсу Android. Напиши в Телеграм @FoxmindEd . Менеджер тебе подробно обо всем расскажет
Автор несёт околесицу, делая странные выводы на базе одного проекта который он видел в своей жизни. Более того сначала он сказал что проект был ПЛОХО НЕДОПИСАН и потом делается вывод что Scala плохой язык.
В комментарии выше я выразил своё личное мнение сформированное на базе просмотренного материала и вектора мысли автора. На любом языке программирования можно написать не понятно и не читаемо. В ролике автор повторяет популярное заблуждение что на Scala необходимо обязательно писать только в функциональном стиле, что делает повествование однобоким, плюс получается что в контексте сравнения есть не-функциональная Java и только функциональная Scala, по моему мнению человека который выбирает язык программирования для изучения это может ввести в заблуждение.
@@greenhost87 Я недоджун, но его сравнение java vs scala похоже я дед, который всю жизнь писал на java, и поэтому scala сложнее. Для таких обзоров нужно как минимум знать на хорошем уровне два языка и написать несколько проектов на нем. И уже на них сравнивать конкретные характеристики: производительность и прочее. Про поддерживаемость, конечно, странно, у scala гораздо более лучшая поддержка ооп, даже принципов solid в tf стиле. Короче говоря, возможностей больше, как вы и Ваши работники этим воспользуетесь уже зависит от Вас. То, что java разрабов больше и их легче и дешевле зазвать это совсем другой вопрос. Не знаю, почему именно тут все это написал)
ФП - дело не языка,а либ. Просто в интерфейсы классов либ нужно добавлять методы, возвращающие эти же классы (даже если внутри это void-метод). This (ссылка на себя) - для мутабельности. DeepCopy of This - для иммутебельности.
@@feoktant сам язык выучить несложно, но вот чтение чужого кода может вызывать трудности, поскольку язык позволяет очень плотно концентрировать информацию в коде (это, наверное, проблема всех функциональных языков). Конечно, многое ещё зависит от того, кто пишет код. Поэтому в каком-то смысле соглашусь с Сергеем, что в некоторых случаях этот код write-only (опять же в зависимости от того, кто пишет; и кто читает тоже).
@@Mike19910711 как именно концентрировать ин-цию? Я знаю такой же как в Джаве способ - выносить код в метод или функцию с читаемым названием. Еще есть способ переопределить оператор, Акка этим грешила, сейчас такой код встречается редко и считается антипаттерном. В cats есть определения математики из теорката. Какие еще есть способы?
scala - попытка натянуть хаскель на jvm как сову на глобус. Поучились бы у раста, который успешно проапгрейдил С++ до почти хаскеля. Вот и котлин - тоже удачный апгрейд
Привет, я недавно на этом канале, но интересует вопрос, почему нету курсов на Swift , и вообще в видео вы его очень редко вспоминаете? Буду очень рад получить ответ, спасибо.
Если хочется коммерчески писать ФП - кроме JS и Scala у нас вообще мало вариантов и около 0 вакансий. Clojure, F# и Haskell появляется очень редко на нашем рынке.
И слава богу! Поменьше этой дичи, типа кложуры, будет, большинству будет легче жить. Вообще, все эти ФП штучки начинаются, когда разраб хочет сверкнуть своей сениорностью - это в большинстве случаев. И, бывает так, что подход оправдан, и применяется по назначению. В вебе - это редкость. Тащить туда кложуру - жесть!
@@olezhonnv3215 в этом всё и дело - ООП с нами в коммерческой разработке с середины 80-ых. ФП в коммерческой разработке значительно меньше. Так и получается, что где-то оверинженирим. И ФП должно решать проблемы современного программирования. Мы ж все хотим одного и того же - быстрее закрывать тикеты, и иметь поменьше багов
Я в 14м году входил в Scala после C++, Java не знал вообще :) Зашло очень хорошо, я запустил в продакшен проект с нуля без знаний Scala за месяц в одиночку :)
Не зовсім згоден з автором. Так, java простіша мова і більш базова, тому якщо починати то однозначно з неї. Щодо відмирання Scala я не згоден, зараз вона досить популярна в Bid Data світі, проектів достатньо, перспективи є, багато компаній готові брати джавістів і перевчати на скалістів. Щодо синтаксису теж не згоден - Scala код пишеться набагато швидше і простіше, після того як спробував писати на Scala, на Java повертатися не хочеться. Якщо взяти проект на Spark+AWS SDK, то на Scala він буде значно менший по кількості рядків коду і відповідно швидше написаний. По читабельності коду, так, згоден, буде важче трохи ніж читати java код, але це не так критично, швидко можна навчитися.
Scala - один из тех языков, которых называют "scalable". Можно начать с простых вещей, затем можно углубляться и углубляться. Если остановиться на простых вещах, язык не сложнее жавы. Дальше - больше.
Ответ простой: учите Kotlin. Он тоже прекрасно работает в экосистеме JVM, при этом легок в обучении и мощный в многопоточности. К тому же на нем можно писать в функциональной парадигме, подозреваю что производительность будет выше чем у скалы.
@@SteelS0ldier Вообще-то Kotlin берет идеи и из Scala тоже, особенно в области функционального программирования. Разработчики Kotlin вдохновлялись многими языками, на википедии указаны C#, Eiffel, Gosu, Groovy, Java, ML, Python, Scala, Swift. Так что я бы не сказал что это "улучшенная java", это самостоятельный язык, который к тому же может компилироваться в нативный бинарник, в отличии от Java.
@@maximmodestov1280 я знаю что такое kotlin, и какие возможности он имеет. Scala это про TypeDD, в то время как kotlin - это про то же что и java, классическое ООП. Да, там есть примесь ФП, как и в java, как и в любом другом современном языке. Но со scala по возможностям это не сравнится
@@maximmodestov1280 High Kinded Types, Type Families, Type Class(через имплиситы). И ещё много всего в dotty. Сразу скажу, что со скалой я слабо знаком, но хорошо знаю Java, kotlin и haskell. (и да, я знаю про arrow, но во первых там есть не всё, во вторых если на scala многие вещи выглядят как извращение haskell, то в arrow они выглядят как извращение извращения. И в третьих - это всё-таки кодогенерация, а не возможности самого языка, при желании то же самое можно и для java сделать)
Спасибо, Сергей 👍 Только с полученным опытом понимаешь какой язык пойдет для данного проекта. И целесообразность его использования. Нужно понимать бизнес для этого
я знаю еще одну крутую методику. Работать на двух проектах одновременно. Один из которых написан на джаве, а второй написан на скале и полностью функциональный (не джава стайл). Биполярочка обеспечена.
у меня уже есть биполярочка, в моей конторе половина проектов на .net вторая на node.js, ну а я как бы сказать... пишу и там и там, и если в легких проектах синтаксис не очень отличается(оба языка были под влияниям джавки и плюсов), то в тяжеловесах это два разных мира, которых тебе нужно сталкивать и разделять
Почему не было шутки про компилирующуюся жопу? :) А если по существу, то всё видео можно было подвести одной только фразой. Если пчеловек задаётся вопросом что лучше, скала или джава и учить ли ему скалу или нет, то однозначно нет, ему это не надо.
Читаю коментарі і сміюсь. Людину запитали яку він має думку на дану тему. і він сказав: початок в відео(для особливо кмітливих)!!!!!!!!!!!!! А коменти схожі на те як поціновувачі Mersedes i BMW сперечаються яка марка краща. Сергію і команді ДЯКУЮ!!! Якраз попив чайочку:).
1. Scala не заставляет писать в функциональном стиле. Это мультипарадигменный язык. 2. Scala не сложный язык, синтаксис проще чем в Java. 3. Java очень скудный язык. Сейчас в 15 java появились record, pattern matching, sealed interfaces. Это все из функционального мира! Record работают убого по сравнению с Data class в Котлине или case class в Scala. 4. В scala есть куча клевых инструментов которые идут сразу с языком. В вашей java нужно обвешаться ломбоками чтобы писать более-менее рабочий код. 5. На рынке Scala разработчиков меньше java поэтому вы хейтите ее за это. Вы рассматриваете язык не с точки зрения самого языка а с точки зрения работодателя. 6. Знание Scala это перспектива в карьере разработчика. Развитие. А в вашей java с 8 версии ничего так и не появилось на уровне языка.
@@SergeyNemchinskiy вы тоже повесили своими сравнениями) У вас наверное и опыт коммерческой разработки на Java старый, да и на Скала ничего не писали. В целом ничего удивительного, но вот ответственность лежит на людей, которые просвещают, а обычно вводят в заблуждение без содержательной критики. Ну ладно, увидел что это было 2 года назад и думаю, что вы умеете в рефлексию и поменяли немного формат обзора сравнений
Скала хоть функциональная и крутая, но есть три пути куда потихоньку перебираются: 1) Go - если проект веб 2) Rust - сюда идут кто хочет быть на острие развития 3) Kotlin - развивает инструменты обработки больших данных, data science и т.п.
Scala занимает маргинальную нишу. Clojure - античеловеческая херь. На этих моментах я опешил. Нахожу только одно объяснение: вы любите джаву и чувства застилают вам глаза пеленой. Стыдно такое говорить. Особенно про лисп/кложе.
erlang неплох как фп язык, во всяком случае после камеры пыток haskell, где каждая вторая либа придумывает свои новые операторы из стрелочек и палочек, а док на все это нету нормальных)
Нет, не можешь считать. С это процедурный или структурный язык. К фп он не имеет никакого отношения. То что в С называется функцией, на самом деле ближе к понятию процедур.
Кложура - дичь! Согласен! Мало того, есть люди, которые ее в веб тащат и на бэк, и на фронт кложурескрипт. А потом жалуются на конференциях, что тормозит и придумывают костыли для ускорения.
Тот момент когда смотришь ролик во время войны и увидел букву Z на крышке ноута.. раньше бы даже не обратил внимания)) но ничего Сережа)) мы по одну сторону) все нормально))
Конкретно функциональная парадигма никакого отношения к большему потребления ресурсов не имеет. По существу функциональщина - это ООП, где все классы ровно с одним методом и не имеют изменяемого состояния. Для задач асинхронной потоковой обработки это практически безальтернативная парадигма на данный момент, если потребуется такое делать на Java - будет та же самая функциональщина, но с гораздо более громоздким синтаксисом, и из за громоздкости и корявости код на Java поддерживать будет гораздо менее приятно. А если будем на Java писать в лоб, как делают юниоры - получим совершенно ужасный неподдерживаемый запутанный и громоздкий callback hell. Вторая ниша Scala - это написание DSL для хитрой запутанной и часто меняющейся предметной области. Здесь вообще никто в функциональном стиле писать не заставляет, можно разбор сделать очень читабельным. Для Java собственно тоже в случае запутанной предметной области придется при ограниченном бюджете и времени городить DSL (или мы нанимаем толпу низкоквалифицированных копипастеров, бюджет астрономический, время на изменения огромны), при этом DSL описания предметной области на Scala будет на порядки более читаемый и поддерживаемый. В Scala при проектировании допустили ту же самую ошибку на миллиард долларов, что и в Java - некорректное положение Null в иерархии классов, когда все может быть Null, отсюда костыли с Optional и монады на ровном месте. Это исправили в Kotlin и кажется в Scala 3, не смотрел пока, но очень надеюсь что там исправили все таки правильно. А в действительности Scala - это исправленная Java, позволяющая жить без навороченных фреймворков и обходиться только средствами языка, с иммутабельностью по умолчанию, иммутабельными коллекциями, с гораздо лучшей типизацией, позволяющей ловить кучу ошибок прямо на этапе компиляции.
Тогда уж выбрать GO ! Любой джавист освоит GO за пару недель а результат лучше будет. Я сам участвую в проекте где есть Java, Go, Scala. На Scala пока не пишу (но буду) , так вот делал замер скорости выполнения операций и GO почти в 10 раз выигрывает и пишется очень легко в отличии от Java.
Короче всё ясно. Основная проблема скалы в том, что это не джава
да чего там сложного в функиональной парадигме. Для тех кто нипанимать, объясню на пальцах смысл.
Представьте какой-то паскаль. Там были процедуры и функции. Процедуры от функций отличаются тем, что первые не возвращают значений. Синтаксически в языках вроде Си их объединили, всё функции, а те, которые не возращают значения, возвращают void.
Может выше и глупый пример обобщения, но для объяснения думаю пойдет.
Функциональная парадигма еще больше обобщает. Она утверждает, что данных нет, всё функции. Т.е. у вас грубо говоря нет даже переменных, чисел, ничего, одни функции. Что такое функция? Это некоторое преобразование того, что приходит ей в аргументах, в возвращаемый параметр. А что если у функция будет всегда возвращать одно и то же? Т.е. константу. Ведь может же быть в математике такая функция? Просто горизонтальная прямая на графике.
Вот представьте, что функция всегда возвращает 4.
four()
Если вы пишете свой компилятор своего языка, то можете всё сделать на функциях абсолютно. Ведь и то что будет приходить на вход от юзера, можно преобразовывать на поток функций констант. И даже то что на диске, данные - это просто поток функций констант. Но при этом, если вы пишете свой компилятор, вы можете делать синтаксический сахар, и вместо функций, вроде four() писать 4. Таким образом вы можете написать язык, в котором будете даже понятно для себя и остальных писать что-то вроде
x = 4 + y * 7;
но на самом деле это всё функции. Тут нет ни присваивания, ни переменных-чисел.
Т.е. функциональная парадигма - это еще на один шаг обобщение. И это прекрасно, если это понять.
Функциональная парадигма сама по себе не тяжелее. Смотря как компилятор сделан под капотом. Если там нормально, если на лямбда исчислении и компиляции, то он имеет все шансы быть быстрее на сложных алгоритмах. В самой парадигме заложен огромный потенциал оптимизации кода компилятором.
Ну а с остальным, наверное, согласен. Требует выше квалификации, а люди если переходят на нее, то с другой парадигмы, пишут с т.з. функциональной парадигмы говнокод. Чтобы читать этот код, надо иметь опыт. А где его взять?
на диске это будут обычные переменные
@@Dmytro-Tsymbaliuk Какая разница что там на диске когда речь идет о выскокоуровневых абстракциях. Да, компилятор для функционального языка скорее всего написан императивно с переменными, циклами и прочими низкоуровневыми ништяками, возможно даже с ручным управлением памятью, но сама абстракция которую предоставляет этот компилятор не имеет переменных, циклов и прочего....
@@bubblesort6368 компилятор это анализатор текста раз уж начинать эту тему
@@Dmytro-Tsymbaliuk ок
Всё это конечно красиво, если просто обробатывать потоки данных. Но если нужно обрабатывать состояния в функциональной парадигме придется изрядно поизвращаться.
По мне так благодаря функциональной парадигме писать код становится намного проще. Куча ограничений и правил парадигмы (вроде иммутабельности структур данных) в итоге не даёт тебе наступать на грабли. И по большей части язык устроен так, что иначе ты написать не сможешь.
Плюс вместо монструозных фреймворков типа Akka сейчас есть куча удобных и маленьких либ вроде Http4s или Fs2 (где работа с потоками вообще превращается просто в работу с коллекциями). Порог входа, может, высоковат, но он того стоит.
А ещё, по моим ощущениям, я устроился на Джуна (Скала первый профессиональный язык) как раз благодаря небольшому количеству соискателей.
а кроме Scala, какие еще требовались технологии для трудоустройства?
@@ДмитрийНормов-ю6ц да по мелочи там базовое понимание работы TCP, баз данных и всё такое инфраструктурное, всё то же, что на любой бэк
а я в скалу пришел именно за аккой. Ну и за плей фреймворком.
Если вам достался проект на Scala и вам тяжело и долго было впиливать фичи и чинить баги, то может проблема в том, что у вас Java разработчики, а не Scala, а не в языке?
Может команда Немчинского ничего не поняла в ScalaZ или вообще Кэтсах. Жаль, что не все могут а композицию.
@@cryptoworkdonkey я думаю, скорее Акку не потянули
Ждём интервью с 1С-ником
То что Вы рассказали о фреймворках Scala в дествительности совсем не так. Есть условные две ветки. Первая - Spark и BigData, вторая - энтерпрайз. Энтерпрайз делится условно на три ветки: Scala как Java(без ФП, Spring, Hibernate, один в один Kotlin), Scala как Scala (Akka, Play, Slick) и Scala как Haskell (ФП, cats, zio, fs2, http4s, doobie, circe). Первая ветка практически вымерла. Вторая теряет популярность, но всё еще встречается в вакансиях. Третья модно-стильно-молодежно на всех конфах.
Не популярны фреймворки в Scala! Чаще берут стопку библиотек и выбирают то что хочется. Поэтому эти ветки иногда смешивают между собой в любых пропорциях.
То что Вы рассказали актуально на год эдак 2015-ый.
+
че правда что ль язык страшный? при наличии опыта алгоритмов любой язык учится нормально
@@Anton_Zh язык не сложный. Сложно привыкнуть к тому, что всё иммутабельно. В первую очередь, рекомендуемые коллекции, они же персистентные структуры данных.
@@feoktant Антон помогите ответить на вопрос. Все пытаюсь откосить от курсов гикбрейнс и им подобных.. Будет ли нормально с моей стороны пробиваться через стажировки в компаниях чтоб научиться программировать? По делу как бы сразу и себя проверю заодно потяну я рабочие будни или нет..))
Hello world на Java:
public class Main {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
Hello world на Scala:
println("Hello, world")
Питон тоже простой, если там делать простые вещи
Scala или другой функциональный язык имеет смысл учить , даже если его не собираетесь его применять.
Поднимите свой общий уровень как разрботчика новыми парадигмами. та же Java уже давно черпает идеи для новых фич из функциональных языков.
вот что пишет Brian Goetz, Java Language Architect:'
"I’d especially recommend learning a functional language, because it will give you a different and useful perspective on how to construct programs, and will stretch your brain (in good ways.)"
Такое пишут все, чтобы купили их книгу. Или вы думаете он напишет правду, чтобы его книгу не покупали? Так можно бесконечно всякую ерунду учить. Языки выдумывают каждый год по несколько десятков. Выживают единицы :) Работать будет некогда из за постоянной учебы. А что касается Scala, то уже 3-й вариант синтаксиса появился. Это говорит об отсутствии каких либо серьезных преимуществ в конструкции языка, если все так кардинально меняется каждый раз.
Функций более высркрго и более низкого порядка нет, а есть только функции высшего порядка. Это такие функции, которые принимают другие функции в качестве аргументов или возвращают функции. Они, в свою очередь делятся на: колбэки, функции-обертки и фабрики функций.
Колбеки еще называют лисенарами или обработчиками событий. А обертки - враперами. Если возвращается функция, созданная внутри другой - создается замыкание и она видит контекст, в котором была создана. На базе этого можно создавать функторы и монады - рекурсивные замыкания или цепочки преобразования значений. Все это, конечно, очень не оптимально, т.к. состояние при любом изменении копируется и старое уничтожается сборщиком мусора. Если рантайм не умеет раскрывать рекурсию и инлайнить функции, то вообще ужас.
О, функциональщики подъехали, бегу за попкорном
@@СергейЛавров-б9й я, если честно, и сам не очень люблю функциональщину, я люблю мультипарадигменный подход, в котором используются элементы ооп, фп, реактивного и асинхронного программирования, где можно иногда написать часть и на старом процедурном и на структурном программировании, и использовать новые пост-ооп подходы, но чтобы так писать, это конечно нужно в нескольких парадигмах шарить и иметь практику их совмещения, это на порядок сложнее, совсем не обязательно приводит к усложнению кода, даже наоборот, это часто позволяет сделать код более читаемым, например, паттерн "стратегия" можно иногда заменить коллекцией функций.
@@СергейЛавров-б9й для "функциональщика" колбек матерное слово =)
@@SteelS0ldier 100%, потому, что ни какого возврата назад не бывает, вычисления идут только вперед
Какая-то дикая каша. Почему когда автор говорит про минусы скалы, он на самом деле говорит про "минусы" ФП, а не языка как такового?
На скале можно писать и ФП, и ООП. Так и называйте тогда видео "ФП" vs "ООП". И это уже настолько дикая и холиварная тема будет, что ой ёй ёй, тремя бомбящими скалистами в комментах тут не обойдётся.
Что конкретно сложного в скале как в языке по сравнению с джавой? Я хз как можно переписать код со скалы на джаву и чтобы стало проще. Если вы при этом меняли стиль с ФП на ООП, то извините, у вас просто команда могла в ООП, но не могла в ФП, а могло бы быть и наоборот. И язык здесь совершенно ни при чём, могли и на ООП скале остаться.
На джаве тоже можно писать очень непонятно. Обмазаться рефлексией или мутабельными вещами в многопоточке и сидеть радоваться. Да вообще на любом языке можно написать очень непонятно при большом желании, так себе аргумент.
Про то, как много нужно знать программисту.
1) Скалист знает, что у него есть `==`, он его использует, ему норм, больше ничего не надо.
Джавист знает, что у него есть `==` для примитивов, а для объектов нужно `equals`, хотя `==` тоже есть, но его использовать нельзя. Но этого знать мало, ведь ещё перед вызовом `equals` надо проверить левую часть на null, а то NPE будет.
2) Скалист знает, что если метод хочет Double, а у него есть Int, то он просто отдаст туда Int и ему норм.
Джавист знает, если метод хочет Double, а у него есть int, то просто так отдать int нельзя, потому что кастинг типов и оборачивание одновременно не сработают. И он получит всратую ошибку компиляции про то что int нельзя привести к Double (лол).
3) Скалист знает, если у него есть List[Int], а метод хочет List[Double], то он просто отдаст туда этот List[Int] и дело с концом. А джавист пойдёт нахрен, потому что оно просто не работает. А если там будут хотя бы наследники, то пойдёт пойдёт страдать и учить pecs. Потому что поддержки вариантности нет и надо играться с `? super` / `? extends`.
И это вообще не касаясь бизнес логики (потому что она на обоих языках одинакова), а про то, как пользоваться языком. На скале уже эти детские ошибки учтены и всё работает примерно так, как ожидает человек, который не знает деталей реализации. А на джаве куда ни плюнь так "well yes but actually no". И на каждую конструкцию в языке нужно знать пачку ситуаций, где это тебе выстрелит в ногу. Так где, говорите, нужно знать больше?
Пишите на плюсах и не будет вам головной боли
@@Dmytro-Tsymbaliuk я пишу на скале и у меня болит только когда нужно что-то сделать на джаве :)
@@nikitamyazin6586 Что посоветуете из литературы для входа в Скалу ?
@@ДимаШевчук-и7э Именно из литературы есть Programming in Scala от Одерски (автора языка), она хороша. Есть Скала для нетерпеливых от Хорстмана, я её не читал, но говорят что норм. Если скала зайдёт - Functional programming in Scala, но это уже потом, не для начала.
Но вообще если с английским языком всё неплохо, то есть очень хороший курс на курсере из 5 частей. Первые две части рассказывает Одерски, они топ, остальные част уже немного в сторону идут (www.coursera.org/specializations/scala).
Если не оч хорошо, то есть на степике от тинькова, но он меньше и сложнее для восприятия.
Переведу на русский сказаное про провал проекта на Скале - у нас была команда джавистов, которые ни в зуб ногой Х. Ну мы взяли проект, думая что это то же самое. Народ учил Х конечно, но медленно. Тогда мы решили переписать на джаву, и ничего нового не учить. Работа - не курсы.
В этой истории правильное менеджерское решение - переписать на тот язык, которым умеет пользоваться комманда. Если бы проект был на С++ или С#, решение должно было быть ровно таким же. Или взять другую комманду на проект. Была бы у вас комманда скалистов тогда, и курсы по скале сейчас - вы бы говорили, что это лучший язык)
Сначала про скалу:
Во-первых, как было справедливо замечено, скала может использовать всё, что есть в обычной джаве.
Во-вторых, идеалогия скала не заставляет писать только иммутабельные структуры, но сам синтаксис построен так, что их удобно использовать. Чего стоит объявление константы в одно короткое "val"
В-третьих, как ни крути скала лаконичнее. Да, это несёт за собой не только хорошее, но в общем и целом число строчек - тоже метрика читабельности кода.
Есть момент - написание в функциональном стиле. То, что это сложнее - не совсем верно.
Скажем так, функциональная парадигма определённо имеет более высокий порог вхождения. И действительно, если рассматривать только его, то функциональная парадигма - сложнее. Однако, если рассматривать состояние немного дальше этого самого порога, выясняется другая сторона вопроса:
1. Функциональная парадигма гораздо легче опирается на математику.
2. Чистые функции над иммутабельными объектами из коробки могут исполняться асинхронно.
3. Из двух предыдущих пунктов следует, что функциональная парадигма легче масштабируется.
Учитывая это можно сказать, что несмотря на более высокие входные требования к разработчикам, сложность функционального проекта со временем растёт медленнее, чем сложность ООП.
Итог таков: всё зависит от того, какие требования предъявляются к проекту. Скала - масштабируемая, джава - проще и дешевле для разработки, но сложность растёт быстрее.
Да и ещё, про читабельность кода.
1. Нечитабельный код можно написать на любом языке.
2. Скала лаконичнее, а значит каждая лексема становится более ёмкой, следовательно чтение кода на ней требует больше усилий, но меньше времени. В дополнение могу сказать, что скала имеет больше синтаксического сахара и больше возможностей для написания оного, что с одной стороны облегчает чтение для более продвинутого разработчика, с другой стороны повышает порог вхождения и сложность прочтения кода при знакомстве с скалой.
3. В скале многое доступно "из коробки". Такого, с чем необходимо разобраться: implicit, pattern-matching, case-class, и т.д. Опять-же, увеличивает порог вхождения, но и облегчает чтение скала-код для более продвинутого разработчика.
И немного мнения:
Мне кажется, что код на скале можно писать очень выразительно и коротко. В среднем получается, что комментарии на скале у меня занимают существенно больше места, чем собственно код. В то время, как на джаве - сравнимое число строчек.
И немного горения:
Как кажется, вопрос о том, какой язык учить - довольно странный.
Если речь идёт о первом языке программирования - это почти не имеет значения.
Хотя, наверное, не стоит первым учить lisp, впрочем, дискуссионно. От изучения первого языка человек получает понимание основ программирования - переменная, функция, тип, и т.д. Это есть во всех языках, так что в принципе, не важно, какой учить.
Если же речь о том, какой язык осваивать следующим, вопрос ещё более странный.
Знаешь джаву - взгляни на скалу, главное, что получишь - понимание того, насколько на самом деле могут быть удобны функциональные конструкции. С тем же успехом, можно было бы освоить и haskell, но синтаксис в scala джависту будет понятнее.
Не знаешь джаву, и при этом не очень глубоко в функциональном программировании - сначала возьми джаву.
Твой любимый язык - хаскель(или другой язык ФП), тогда в скала добавит немного огня, но там встретишь много знакомого.
Как-то так?
Название: Java vs Scala. Какой язык программирования учить?
Содержание: Сергей Немчинский обсирает Scala
Скорее Пропаганда джавы, то что можно наблюдать во всех видео.
@Spol77777 it's was a joke
@Spol77777 знаю, бро
Чуть чуть добавлю про Scala в DS:
Суть такова, что для анализа больших данных (или потоковых данных) используется Spark и вся его экосистема. Сам по себе Spark Core не зависит от языка программирования (Scala/Java/Python - разницы в коде практически нет) и взаимодействует с данным посредством API (ну а на нодах все реализуют JVM).
Однако, т.к. Spark изначально был написал на Scala (а потом добавляли куски кода на Java), то по скорости код на Scala исполняется быстрее (ибо своё, родное).
Но это, опять же очень сильно зависит от конкретных задач.
Для кого-то важно повышение скорости обработки данных на кластере, а для кого-то нет.
Одно дело - потоковая обработка из разных источников (привет Kafka!), другое - периодические выгрузки (в какой-нить Postgres).
(вообще на суперкомпьютерах (от 20к ядер) spark не показал разницы по скорости между Scala/Python).
Сам функционал анализа данных обеспечивается Spark MLlib API и плакать, колоться, но писать именно на Scala смысла нет (а чаще всего все заканчивается выгрузкой из RDD на любимый комп csv-файла и работой на Python. Зря что ли кросс-валидацию и сэмплирование придумывали?)
з.ы. В анализе больших данных нет широкой столбовой дороги и если вы точно не знаете, зачем вам писать код на Scala, значит вам это не нужно - пишите любимой джаве и не парьтесь.
Да спарк на скале роднее пишется, и там и там иммутабельность, лейзи и все такое. Плюс сама апишка на скале красивее всех. И важно не писать на питухоне, а то при первой потребности в udf можно начинать сосать бибу
В перспективы разработчиков вы могли написать про реальные проблемы скалы: токсичное раздробленное сообщество, отсутвие главного стека технологий типа спринг\джанго, скала 3 которую все ждут уже 5 лет, возможный раскол как был в питон 2\3, курс на упрощение имплиситов, желание черпать новых скалистов из питона в конце концов! Но нет! Вы за выпуск повторили "скала сложная" раз 20 ничем не аргументировав.
Как же меня бомбит
@@feoktant Скале уже смерть пророчат...
@@ДмитрийНормов-ю6ц слухи эти сильно преувеличеньі) пророчат уже лет 5 как, а воз и ньіне там
Закидать проблему тушками - в золотой фонд цитат)
кстати я думаю этим и можно объяснить популярность NodeJS. порог входа значительно ниже.
Было бы круто если бы было пару открытых примеров. Я вот например java трогал одним мизинцем пальца ноги. И сложно на слух воспринимать лёгкий код и сложный код.
По джаве только в школе книжку читал, первую (и пока единственную) работу начал джуном на скале. У нас много джунов
А что делаешь на скале?
@@fxvlad микро (и не очень) - сервисы, api-s
Более простой ФП язык врядли появится, потому что что скала и так простой язык, как бы странно это не звучало после просмотра видео. Есть язык Haskell, Idris, Agda, они более приближенны к ФП парадигме и их синтаксис разительно отличается от скалы. Кто-то бы даже сказал, что они гораздо сложнее скалы.
Окамл и F# проще скалы.
@@cryptoworkdonkey как вы оцениваете проще/сложнее?
@@feoktant , они менее навороченные (нет тайпклассов и прочего продвинутого ФП из коробки), там старый понятный алгоритм вывода типов, синтаксис очень приятный, вообще языки более целостные сами по себе. ООП не используется практически нигде, всё на простой композиции.
С другой стороны есть всякие Units of Measure, active patterns, можно писать быстрый императивный код с симдами, ассемблерными вставками, есть файнал тэглесс. Но обычно везде пишут очень просто и понятно.
ИМХО, скала выглядит неряшливо на фоне своих более примитивных собратьев, discriminated unions вообще в библиотеке, а не из коробки. "Принцип компота(с)", короче. Думал Дотти будет ЗНАЧИТЕЛЬНО чище.
@@cryptoworkdonkey тайпклассов из коробки в Скале тоже нет) их пишут через имплиситы, в дотти красивее.
На счет неряшливости соглашусь. И синтаксис F# мне нравится больше. Правда, нужно время к нему привыкнуть после си-подобного кода
Выскажу тут своё мнение как скала джун. Учить без знания основ джавы или другого ЯП будет сложновато, сам искал изначально работу в качестве джава разработчика, но случайно попал на скалу, месяца 2-3 испытывал сложности. Язык сам по себе сложноватый, но в целом норм. На Play + Akka пишется всё довольно просто и типично, не особо отличается от круда в том же спринге. Стек с кошками не трогал пока, там уже скала на фулл фп. Скала как вампир - 1 раз укусит джависта и обратно уже не хочется)) Короче, это джава на стероидах. Про матан хз, университетский вообще не помню. Стоит ли учить? Почему бы и нет, особенно после джавы, технологий интересных много, особенно Akka и всё с кошками.
Scala - единственный язык, в котором можно тренироваться на кошках.)))
Редко где увидишь Scalia junior
@@MisaNia25 скала джуниор ~~ джава мидл. У меня на прошлом месте было пару ребят
Scala прям моя мечта, особенно после Валенсой коммента. Но сначала решила все-таки выучить хорошо Java.
@@feoktant ну я не джава мидл. Вообще, искал свою первую работу и учил только джаву. Предложили залететь на скалу, я согласился.
Год работал со скалой в хадупе (а точнее - в спарке), в целом согласен с Сергеем. На скале очень весело писать код, получается довольно красиво и компактно, но вот читать чужой код бывает крайне сложно. Не в последнюю очередь из-за имплиситей, которые некоторые любят пихать в свой код без меры. В результате получается кратко, но фиг разберешься, что тут реально происходит. В общем, я бы не стал на ней большие проекты делать.
А сам я перешел писать для спарка на питон, получается не хуже и в моей области (дата саенс) намного удобнее - в питоне для этого есть кроме спарка еще огромное количество либ, которых в скале нет и в помине.
Имплиситы нужны либо в библиотеках, либо в очень редких случаях. Скала 3 наконец разделит эти понятия. И добавит форматирование как в питоне. Ждем вам обратно очень скоро ;)
про тот год работы - бэк в банке?
Спасибо за видео, интересно бы послушать про Котлин
Kotlin может умереть
У него уже есть про это ролик. Смотри внимательней)
@@woodzimierz9621 учитывая, что под Android уже тот же Jetpack написали на Котлине, думаю ставки на него очень большие и в ближайшие лет 10 он точно не умрёт. Ну и опять же есть Ktor; тот же Spring сейчас поддерживает разработку на Kotlin.
@@Mike19910711 JetBrains может умереть, а вместе с ним и Kotlin. Почему? Смотрите в комментариях ниже.
Наконец-то! Так долго ждал
Большинство видео это не просто вода но и откровенный бред, такое ощущение автор зачитывает первую ссылку в гугле "java vs scala"
Согласен полностью
Большинство видео - это промо мысли автора, за что этого автора и ценят
скала НЕ сложный язык. Проблема сложности программ на нём в том, что там пытаются повторить принятые в мире ФП паттерны, при этом не все возможности чистых функциональный языков поддерживаются. Те же тайпклассы описываются через имплиситы. Плюс у языка много своих возможностей, и к обычным паттернам добавляются ещё и скаловские(типа cake). Но в целом, если есть понимание что автор хочет сказать - никаких проблем для чтения нет. А т.к. язык более выразительный, в итоге более сложные вещи читать и писать проще чем на java. Другими словами тот же уровень абстракции на java выразить если и можно, то читать это будет гораздо сложнее чем скаловский код.
" принятые в мире ФП паттернв, при этом не все возможности чистых функциональный языков поддерживаются" а что более чище в этом плане? haskell? мне действительно любопытно
@@AndriySydorka есть pure fp языки вроде haskell, idris, agda. Haskell, конечно, самый мейнстримовый из них.
Чистота в фп означает, что у функций не может быть побочных эффектов. В scala это не так.
@@SteelS0ldier докажи что это не так
@@yarosav5396 в scala нет никаких ограничений на побочные эффекты на уровне языка. Что тут требуется доказать?
ООП: инкапсуляция, полиморфизм, наследование
ФП: иммутабельность, чистота (pure functions, side-effects)
Классификация в перпендикулярных плоскостях, и вместе прекрасно сочетаются.
с инкапсуляцией сочетается плохо
@@АндрейРешетченко-т9й Инкапсуляция - это скрытие внутренней реализации от других компонентов. Как раз функции без сайд-эффектов инкапсуляцию улучшают, т.к. зависят только от их сигнатуры и публичных методов принимаемых ими объектов.
@@VaGroz нет, инкапсуляция - это объединение данных и методов в единый компонент. То есть есть клас с состоянием и методы для изменения этого состояния. Но вот изменение состояния объекта является сайд-эффектом.
@@АндрейРешетченко-т9й впервые сталкиваюсь с таким определением. Тем не менее, озвученная проблема - не проблема, т.к. все transform-методы класса просто возвращают новую копию объекта.
@@АндрейРешетченко-т9й есть два определения. Это и то, которое озвучил VarGroz выше
Всё у Сергея неплохо, кроме одного - языки которые он не осилил по тем или иным причинам (не думаю что от недостатка мозгов или прочего, скорее - времени или интереса) он считает плохими и всячески ругает, нередко необоснованно. Посмотрел это видео чтобы снова в этом убедиться)
так и есть, смотрю его видео уже год. из видео в видео повторяются одни и те же вещи. никакаких попыток вникнуть
Он же не говорит, что эти языки плохие. Он лишь говорит, что лично ему они не нравятся, но при этом всегда повторяет, что это вкусовщина.
@@Mike19910711 а нахрена нам его недовольство слышать из ролика в ролик?
@@Mike19910711 неверную/необоснованную критику (он для того не подходит, на нем код сложнее на пару порядков, тут можно писать только знаю математику (очень интересно какую), язык маргинальный и т.д.) расцениваю как заявления о "плохости" языка, уж простите)
Ну хз, с тем что js стрёмный я например с ним согласен). И да, оговорка что это вкусовщина или лично его отношение к языку, присутствует обычно. Так что всё он нормально говорит.
scala is very simple for professionals but many of java devs are not proffesionals
Какой язык учить? Java или Java?
Kotlin
JS
@@max_mgtow причем тут JS? Он не компилируется в байткод, в отличии от котлина, и следовательно не работает в экосистеме JVM.
@@maximmodestov1280 с помощью JS сейчас можно везде, от веба до десктопа
@@max_mgtow Это прекрасно, только в JS нельзя напрямую работать с функциями и классами написанными на Java или Scala. А на Kotlin можно. Поэтому JS тут неуместен. Если у вас есть большой проект на Java, вы сможете добавлять новые фичи написанные на Kotlin и использовать их в существующем Java коде. С JS так не получится, вам придется полностью переписывать проект. В этом принципиальная разница.
C++ vs Rust
Чувствуется, как Сергей изо всех сил хочет сманипулировать зрителями и внести свой вклад в смерть сообщества скалы. Видео только отчасти правда. Скала из коробки это не какие-то основанные на математических правилах конструкции, это всё те же классы, объекты, методы, лямбды. Кучу фишек скалы можно увидеть в котлине (но не все, есть пара киллер фич из-за которых не ней удобней). Возможно что-то офигенно удобное есть в котлине, чего нет в скале я не знаю. У скалы более увесистая стандартная библиотека (мегабайт 5 вроде) поэтому на ней не часто пишут приложения под андроид, но это возможно (к слову её вполне можно порезать proguard'ом (удовольствие сомнительное, но облегчить артефакт можно сильно)). Вся алгебраическая заумь начинается когда код начинают писать с использованием функциональных библиотек (cats, zio, раньше scalaz), которые подтаскивают хаскельные понятия типа монад, апликативов, но когда разберёшься с этим на ванильную джаву смотришь как на фортран. То что скала прожорливая не совсем правда, на ней можно например написать код с дженериками которые скомпилируется в версию не столько для ссылочных типов но и для примитивов (всех например) и таким образом увернуться от боксинга, другой вопрос, что этим редко кто занимается и вообще не парятся на счёт лишних копирований данных (хотя есть возможности их минимизировать). Скала это про type-safety больше, чем в джава и наверное даже больше, чем в котлине. Про корректную и удобную канкаренси. Про тулы, которые генерят код и если не могут, то мы получаем compile-time ошибки, заместо runtime после месяца эксплуатации в 3 часа ночи в пятницу вечером. Ну и + не нужно дожидаться когда сгенрённый код заоптимизируется dereflection'ом или в рантайме отработает какой-нибудь asm, он сразу есть и сразу быстрый (также, например, как работает джавовый mapstruct или retrofit). Про кучу удобных методов на коллекциях (тут котлин тоже молодец, питон ниже плинтуса, а джава где-то посередине). Ещё фор-компрехеншены, стексейфти и кастомные интерполяторы. Хватит пожалуй.
Че-то ты сильно котлин завысил, от современный джавы он не далеко ушел, тем более если писать под spring
Главного не сказали Scala строго типизирован, если программа скомпилировалась то 99% что в ней нет багов
ну мы както давно в в проекте для видеокамер порвали жавакодеров связкой clojure+erlang, я бы не сказал что фп требовательно к ресурсам, скорее наоборот. Джава для сбора данных с камер постоянно падала и не выдерживал нагрузок, тогда как ерланг стабильно их собирал, мало потреблял и даже траслировал видео. Все остальную бизнес аналитику и бизнеслогику делали на cloure, поддерживалось легко, фичи внедлялись быстро.
Лисп очень даже удобно читается. Польская нотация - это наиболее однозначный тип записи. Он часто используется в SMT солверах, например - то есть там, где необходима однозначность. Ремарка про Clojure.
это всё вкусовщина и субъективщина, вопрос привычки
Поддерживаю насчет лиспа и Clojure)
Ууу... "Функциональная парадигма вообще в принципе ресурсоёмкая" - с этого момента поподробнее. Во-первых, парадигма не может быть ресурсоемкой по определению. Мягкое с тёплым. Читайте словарь. Во-вторых, выйгрыш в использовании ресурсов зависит от конкретной задачи, от кода. Вы же сами сказали, что Scala используется для потоковой обработки данных. Наверно, она используется потому что потребляет меньше ресурсов? А функциональная парадигма одной Scala не ограничивается.
По поводу перспектив Java у меня тоже большие сомнения. Кому нужен, по вашим же словам, "сложный язык" со "сложными фреймворками", если можно писать на Ruby, Python, NodeJS? Вы Scala откинули ровно по этим соображениям - слишком сложная.
Скажите, пожалуйста, сколько Вы писали на scala? Без обид
Сергей ответил бы, но валидация форм ютуба пустые ответы не принимает)
Зато "пустые" видео принимает) Можно зарабатывать, так сказать)
Что выбрать toyota или УАЗ?
Джава
Конечно же, УАЗ, УАЗ hunter 👍
более простой и понятный функциональный язык это Elixir. можно также вспомнить Kotlin, на котором тоже есть крутые FP штуки.
И снова в рубрике, что лучше: джава или язык, который я не знаю, победила джава)
Что лучше: джава или микроволновка. В микроволновке я вчера спалил бутерброд, запах жуткий стоял на всю квартиру, а на джаве 10 лет работаю. Поэтому джава лучше.
Расходимся, нас накрыли
Сразу видно, у автора нет опыта в скале и он лишь что-то где-то видел и слышал давным давно, предполагаю что автор даже не слышал про котоэффекты, фс2, хттп4с и тд
Слышал ужасы про акку и тд (и даже разбирал легаси проект), но сегодня скала это один из (если не самый) прекрасных языков позволяющий писать невероятно безопасный и тестируемый многопоточный код, где одна строка несёт в себе смысла как 5 джавовых (что, кстати, помогает и с читаемостью кода)
С любовью, джун-скалист, не работавший с джавой, из компании на ~100 скалистов с всем бэком на скале
так а бэк для кого? для банка?
@@manOfPlanetEarth B2B live casino software provider
@@vijexa
хм. в b2b юрлицом с одной стороны выступает казино, а с другой стороны какое юрлицо, покупающее услугу азартных игр у казино?🙂 форд моторс?) я даже и не знал, что такое существует)
@@manOfPlanetEarth я предполагаю, что с одной стороны реальное казино, а с другой - компания, предоставляющая платформу для казино: игры, чаты, оплаты, инфраструктура и тд
@@a.sorokin
ого. спасибо за ответ! а то кодер выше не осилил продолжить такую простую беседу😉🙂
Сергей, а Вы сами программировали на Скале? Я из каждого утюга слышу, что Скала сложная, непонятная, что синтаксис кривой. А в итоге в Java появляются records, а Kotlin от Scala так вообще не всегда отличишь.
В моем прошлом месте работы было трое Scala девелопера, без знаний Java. Двое из них джуниоры, и они прекрасно перформили. Один из этих джуниуров студент, Scala его первый коммерческий опыт.
У меня ощущение, что Scala мешает всем продавать Java) И заклеймили язык сложным и непонятным. А убери имплиситы, и получишь практически Kotlin. Kotlin сложный?
А какие языки программирования вы считаете наиболее перспективными для старта карьеры в IT? я сам выбирал курсы для веб-разработки, рассматривал разные варианты, но остановился на Skypro из-за хороших отзывов и структуры обучения. Лично я уже через несколько месяцев смог устроиться на работу с хорошей зарплатой))
Scala лучше!
Да будет срач - это пять! )))
Немчинский всё время забывает про третью сферу применения Java это автоматизация тестирования, из всех языком имеет самое большое количество библиотек под любые нужды
Я бы раст поучил. Тоже функциональные плюшки есть, хоть и немного многословен, но читается отлично, быстрый, на многое способный и активно поддерживаемый. Думаю, тем, кто все же не особо осилил скалу, может прийтись по вкусу
Так что ты ждёшь?
@@pisdatobi видимо я не правильно выразился) я уже, иначе не стал бы ничего говорить, не будь сам в этом уверен
раст легче скалы что ли?
я оба не знаю, если что.
@@ikunemi
и интересно услышать, что у тебя за проект с растом🤔
Для себя норм. Для работы имхо придётся поискать. Я бы начал с прадедушки Си или дедушки плюсов, если хочется в байтах и памяти поковыряться. В раст переключиться, когда он наберёт популярность (лет 5-7) будет несложно.
Либо жаба или шарп, если на веб целиться.
Вам не нравится Scala потому что вы привыкли мыслить императивно. В свое время когда учил ФП мне тоже ломало мозг после ООП, но потом при сравнении одного и того же кода я был очень удивлён, что сложная логика, которая в императивном подходе сводилась к лапше из if statements, либо имела много ООПшного бойлерплейта, в ФП подходе выглядит и поддерживается и тестируется гораздо проще.
ФП подход идейно задуман для того, чтобы упросить жизнь, а не усложнить. Если в проекте это не так, то подход был применен неправильно.
Если в ООП проекте много "if statements" и "бойлерплейта", то подход также был применен неправильно
@@vt236 Это относительно ФП.
Сергій навіть критикуючи скАлу мотивує її колись її спробувати. Момент про вимоги до потужності ПК та серверів ⚡️
Перед курсом по ANDROID есть смысл пройти курс JAVA Start, ускорит ли он моё обучение ?
Думаю, что если не знаешь теоретических основ, то да
Cмысл есть. Если ранее программирование не учил, то Java Start поможет за короткий срок освоить основы java и подготовиться к курсу Android. Напиши в Телеграм @FoxmindEd . Менеджер тебе подробно обо всем расскажет
Андроид без джавы!? О_0
Автор несёт околесицу, делая странные выводы на базе одного проекта который он видел в своей жизни. Более того сначала он сказал что проект был ПЛОХО НЕДОПИСАН и потом делается вывод что Scala плохой язык.
на каком моменте Сергей говорит, что Скала ПЛОХОЙ язык? он только говорит, что этот язык относительно трудно читаемый
В комментарии выше я выразил своё личное мнение сформированное на базе просмотренного материала и вектора мысли автора.
На любом языке программирования можно написать не понятно и не читаемо.
В ролике автор повторяет популярное заблуждение что на Scala необходимо обязательно писать только в функциональном стиле, что делает повествование однобоким, плюс получается что в контексте сравнения есть не-функциональная Java и только функциональная Scala, по моему мнению человека который выбирает язык программирования для изучения это может ввести в заблуждение.
@@greenhost87 Я недоджун, но его сравнение java vs scala похоже я дед, который всю жизнь писал на java, и поэтому scala сложнее. Для таких обзоров нужно как минимум знать на хорошем уровне два языка и написать несколько проектов на нем. И уже на них сравнивать конкретные характеристики: производительность и прочее. Про поддерживаемость, конечно, странно, у scala гораздо более лучшая поддержка ооп, даже принципов solid в tf стиле. Короче говоря, возможностей больше, как вы и Ваши работники этим воспользуетесь уже зависит от Вас. То, что java разрабов больше и их легче и дешевле зазвать это совсем другой вопрос. Не знаю, почему именно тут все это написал)
видео без воды наконец
ФП - дело не языка,а либ. Просто в интерфейсы классов либ нужно добавлять методы, возвращающие эти же классы (даже если внутри это void-метод). This (ссылка на себя) - для мутабельности. DeepCopy of This - для иммутебельности.
По сути сравнили не языки а парадигмы. Сравните плиз Java и C#. Вот уж точно конкуренты по рынку. Особенно после выхода .net core
Java слишком многословна, Scala - сложна. Kotlin - промежуточный вариант.
Чем конкретно сложна Скала?
@@feoktant сам язык выучить несложно, но вот чтение чужого кода может вызывать трудности, поскольку язык позволяет очень плотно концентрировать информацию в коде (это, наверное, проблема всех функциональных языков). Конечно, многое ещё зависит от того, кто пишет код. Поэтому в каком-то смысле соглашусь с Сергеем, что в некоторых случаях этот код write-only (опять же в зависимости от того, кто пишет; и кто читает тоже).
@@Mike19910711 как именно концентрировать ин-цию? Я знаю такой же как в Джаве способ - выносить код в метод или функцию с читаемым названием. Еще есть способ переопределить оператор, Акка этим грешила, сейчас такой код встречается редко и считается антипаттерном. В cats есть определения математики из теорката. Какие еще есть способы?
scala - попытка натянуть хаскель на jvm как сову на глобус. Поучились бы у раста, который успешно проапгрейдил С++ до почти хаскеля. Вот и котлин - тоже удачный апгрейд
@@CJSurv rust чертовски сложный из-за особенностей работы с памятью, эффективно писать на расте - гораздо сложнее, чем на скале
Привет, я недавно на этом канале, но интересует вопрос, почему нету курсов на Swift , и вообще в видео вы его очень редко вспоминаете? Буду очень рад получить ответ, спасибо.
Если хочется коммерчески писать ФП - кроме JS и Scala у нас вообще мало вариантов и около 0 вакансий. Clojure, F# и Haskell появляется очень редко на нашем рынке.
И слава богу! Поменьше этой дичи, типа кложуры, будет, большинству будет легче жить.
Вообще, все эти ФП штучки начинаются, когда разраб хочет сверкнуть своей сениорностью - это в большинстве случаев.
И, бывает так, что подход оправдан, и применяется по назначению. В вебе - это редкость. Тащить туда кложуру - жесть!
@@olezhonnv3215 в этом всё и дело - ООП с нами в коммерческой разработке с середины 80-ых. ФП в коммерческой разработке значительно меньше. Так и получается, что где-то оверинженирим. И ФП должно решать проблемы современного программирования. Мы ж все хотим одного и того же - быстрее закрывать тикеты, и иметь поменьше багов
Я в 14м году входил в Scala после C++, Java не знал вообще :) Зашло очень хорошо, я запустил в продакшен проект с нуля без знаний Scala за месяц в одиночку :)
а потом проснулся
@@yarosav5396 и повторил всё на яву))
@@HuKuTa944 А то. Я в те времена программировал и во сне, поэтому после того как проснулся мог сделать за день недельную работу типичного мидла :)
@@mormeoi мое почтение сверхпрограммисту
Не зовсім згоден з автором. Так, java простіша мова і більш базова, тому якщо починати то однозначно з неї. Щодо відмирання Scala я не згоден, зараз вона досить популярна в Bid Data світі, проектів достатньо, перспективи є, багато компаній готові брати джавістів і перевчати на скалістів. Щодо синтаксису теж не згоден - Scala код пишеться набагато швидше і простіше, після того як спробував писати на Scala, на Java повертатися не хочеться. Якщо взяти проект на Spark+AWS SDK, то на Scala він буде значно менший по кількості рядків коду і відповідно швидше написаний. По читабельності коду, так, згоден, буде важче трохи ніж читати java код, але це не так критично, швидко можна навчитися.
Scala - один из тех языков, которых называют "scalable". Можно начать с простых вещей, затем можно углубляться и углубляться. Если остановиться на простых вещах, язык не сложнее жавы. Дальше - больше.
Ответ простой: учите Kotlin. Он тоже прекрасно работает в экосистеме JVM, при этом легок в обучении и мощный в многопоточности. К тому же на нем можно писать в функциональной парадигме, подозреваю что производительность будет выше чем у скалы.
>Ответ простой: учите Kotlin
Нет, ответ совсем не такой простой. Kotlin это просто "улучшенная java", а у scala совсем другие возможности и идеи.
@@SteelS0ldier Вообще-то Kotlin берет идеи и из Scala тоже, особенно в области функционального программирования. Разработчики Kotlin вдохновлялись многими языками, на википедии указаны C#, Eiffel, Gosu, Groovy, Java, ML, Python, Scala, Swift. Так что я бы не сказал что это "улучшенная java", это самостоятельный язык, который к тому же может компилироваться в нативный бинарник, в отличии от Java.
@@maximmodestov1280 я знаю что такое kotlin, и какие возможности он имеет. Scala это про TypeDD, в то время как kotlin - это про то же что и java, классическое ООП. Да, там есть примесь ФП, как и в java, как и в любом другом современном языке. Но со scala по возможностям это не сравнится
@@SteelS0ldier О каких возможностях Scala идет речь?
@@maximmodestov1280 High Kinded Types, Type Families, Type Class(через имплиситы). И ещё много всего в dotty.
Сразу скажу, что со скалой я слабо знаком, но хорошо знаю Java, kotlin и haskell.
(и да, я знаю про arrow, но во первых там есть не всё, во вторых если на scala многие вещи выглядят как извращение haskell, то в arrow они выглядят как извращение извращения. И в третьих - это всё-таки кодогенерация, а не возможности самого языка, при желании то же самое можно и для java сделать)
Кароче, выбор мой таков - фронт реакт, бек + работа с ситестемой node J's. А скалу как запасной вариант
Спасибо, Сергей 👍 Только с полученным опытом понимаешь какой язык пойдет для данного проекта. И целесообразность его использования. Нужно понимать бизнес для этого
На самом деле все функциональные языки на основе JVM тако себе, потому что свои возможности они реализуют на ней через костыли.
круто! а давай руби против шарпа
Спасибо) Как всегда четко и по делу)
P. S. Все еще жду видео про блокчейн - разработку на Java
я знаю еще одну крутую методику. Работать на двух проектах одновременно. Один из которых написан на джаве, а второй написан на скале и полностью функциональный (не джава стайл). Биполярочка обеспечена.
у меня уже есть биполярочка, в моей конторе половина проектов на .net вторая на node.js, ну а я как бы сказать... пишу и там и там, и если в легких проектах синтаксис не очень отличается(оба языка были под влияниям джавки и плюсов), то в тяжеловесах это два разных мира, которых тебе нужно сталкивать и разделять
@@ruslan4193 как я вас понимаю... И соболезную
Scala это племянник с#, и сын джавы :)
А почему не котлин и скала?
Разве джава все еще применяется на андроиде? По-моему там царит Kotlin, писать на джаве конечно можно, но на ней уже не пишут под андроид
`Успех пайтона`, где это он преуспел?)
Машин лёрнинг, дата саенс. Он там почти монополист.
На джанго очень весьма неплохие зарплаты, и много вакансий.
Он очень популярен, это уже успех и что-то значит
Как вы думаете, надолго ли ещё останется актуальным разработка под Андроид? Или же enterprise победит?
Так они не соперничают. Андроид- это мобильные приложения. Пока люди пользуются смартфонами андроид будет жить.
Про BigData ничего не услышал, хотя по мне scala там очень популярна. Но возможно ненадолго, если PySpark будет развиваться.
Почему не было шутки про компилирующуюся жопу? :) А если по существу, то всё видео можно было подвести одной только фразой. Если пчеловек задаётся вопросом что лучше, скала или джава и учить ли ему скалу или нет, то однозначно нет, ему это не надо.
Читаю коментарі і сміюсь.
Людину запитали яку він має думку на дану тему. і він сказав: початок в відео(для особливо кмітливих)!!!!!!!!!!!!!
А коменти схожі на те як поціновувачі Mersedes i BMW сперечаються яка марка краща.
Сергію і команді ДЯКУЮ!!! Якраз попив чайочку:).
8:00 порог вхождения в джава.
Java - итеративный(fix императивный) язык(и то есть сахара для функциональщины), Scala - функциональный. Java и Scala являются ООП языками.
Итеративный - это как?
ты бред написал - удали
даешь больше итераций в джаве!!! вот еще парочку умных слов - императивный, итерпретируемый...
@@romasiny опечатался в слове, спасибо)
Императивный*
1. Scala не заставляет писать в функциональном стиле. Это мультипарадигменный язык.
2. Scala не сложный язык, синтаксис проще чем в Java.
3. Java очень скудный язык. Сейчас в 15 java появились record, pattern matching, sealed interfaces. Это все из функционального мира! Record работают убого по сравнению с Data class в Котлине или case class в Scala.
4. В scala есть куча клевых инструментов которые идут сразу с языком. В вашей java нужно обвешаться ломбоками чтобы писать более-менее рабочий код.
5. На рынке Scala разработчиков меньше java поэтому вы хейтите ее за это. Вы рассматриваете язык не с точки зрения самого языка а с точки зрения работодателя.
6. Знание Scala это перспектива в карьере разработчика. Развитие. А в вашей java с 8 версии ничего так и не появилось на уровне языка.
повеселили
@@SergeyNemchinskiy вы тоже повесили своими сравнениями) У вас наверное и опыт коммерческой разработки на Java старый, да и на Скала ничего не писали. В целом ничего удивительного, но вот ответственность лежит на людей, которые просвещают, а обычно вводят в заблуждение без содержательной критики. Ну ладно, увидел что это было 2 года назад и думаю, что вы умеете в рефлексию и поменяли немного формат обзора сравнений
Скала хоть функциональная и крутая, но есть три пути куда потихоньку перебираются:
1) Go - если проект веб
2) Rust - сюда идут кто хочет быть на острие развития
3) Kotlin - развивает инструменты обработки больших данных, data science и т.п.
И да один из разработчиков скалы перешел в clojure ;)
Как следует по тр ахаться 😂👍
Если у вас выбор между Java и Scala - учите C#...
если честно, уже оскомину набил со своей явой
Сергей, заводи тему про Rust
еее, борода)
но это не точно)
Спрашивается…ну и зачем нужна scala ? Согласно видео…она дороже, сложнее и явных преимуществ не дает
@Sergey Nemchinskiy, как думаете, Kotlin все? ruclips.net/video/76orCx7V84I/видео.html
Я уже слышал, пока информация не подтвердили
Апри чем тут котлин? Джетбрейнс юридически - чешская компания.
@@RomanKuvaldin как говорилось в старом анекдоте: бить будут не по паспорту, а по морде.
Scala занимает маргинальную нишу.
Clojure - античеловеческая херь.
На этих моментах я опешил. Нахожу только одно объяснение: вы любите джаву и чувства застилают вам глаза пеленой.
Стыдно такое говорить. Особенно про лисп/кложе.
"Здраствуйте, теперь меня зовут Светлана Немчинская..."
Нит
erlang неплох как фп язык, во всяком случае после камеры пыток haskell, где каждая вторая либа придумывает свои новые операторы из стрелочек и палочек, а док на все это нету нормальных)
Все Java программисти в итоге будуть писать на Scala - просто они пока что об eтом не знают
C функциональный язык и с ним справляюсь. Тогда можно считать что смогу учить и Scala?
С не функциональный язык, и довольно простой.
Нет, не можешь считать. С это процедурный или структурный язык. К фп он не имеет никакого отношения. То что в С называется функцией, на самом деле ближе к понятию процедур.
@@bubblesort6368 суть это не меняет аж вообще, в любом языке это превращается в call с перепрыгиваниями по процедурному коду
@@Dmytro-Tsymbaliuk С таким успехом можно сказать, что любой код в конечном счете набор ноликов и единичек...
Кложура - дичь! Согласен! Мало того, есть люди, которые ее в веб тащат и на бэк, и на фронт кложурескрипт. А потом жалуются на конференциях, что тормозит и придумывают костыли для ускорения.
Тот момент когда смотришь ролик во время войны и увидел букву Z на крышке ноута.. раньше бы даже не обратил внимания)) но ничего Сережа)) мы по одну сторону) все нормально))
так че выбрать то
Лучше вообще в это не лезть.... стой где стоишь
@@pisdatobi питончик
@@pisdatobi
🤣🤣🤣
совет от бога
Да ладно. Все еще Сергей Немчинский. Какая неожиданность!!)
Мне кажется или кое-то готовится к смене пола?
"Здраствуйте, теперь меня зовут Светлана Немчинская..."
👍
Конкретно функциональная парадигма никакого отношения к большему потребления ресурсов не имеет. По существу функциональщина - это ООП, где все классы ровно с одним методом и не имеют изменяемого состояния. Для задач асинхронной потоковой обработки это практически безальтернативная парадигма на данный момент, если потребуется такое делать на Java - будет та же самая функциональщина, но с гораздо более громоздким синтаксисом, и из за громоздкости и корявости код на Java поддерживать будет гораздо менее приятно. А если будем на Java писать в лоб, как делают юниоры - получим совершенно ужасный неподдерживаемый запутанный и громоздкий callback hell. Вторая ниша Scala - это написание DSL для хитрой запутанной и часто меняющейся предметной области. Здесь вообще никто в функциональном стиле писать не заставляет, можно разбор сделать очень читабельным. Для Java собственно тоже в случае запутанной предметной области придется при ограниченном бюджете и времени городить DSL (или мы нанимаем толпу низкоквалифицированных копипастеров, бюджет астрономический, время на изменения огромны), при этом DSL описания предметной области на Scala будет на порядки более читаемый и поддерживаемый. В Scala при проектировании допустили ту же самую ошибку на миллиард долларов, что и в Java - некорректное положение Null в иерархии классов, когда все может быть Null, отсюда костыли с Optional и монады на ровном месте. Это исправили в Kotlin и кажется в Scala 3, не смотрел пока, но очень надеюсь что там исправили все таки правильно. А в действительности Scala - это исправленная Java, позволяющая жить без навороченных фреймворков и обходиться только средствами языка, с иммутабельностью по умолчанию, иммутабельными коллекциями, с гораздо лучшей типизацией, позволяющей ловить кучу ошибок прямо на этапе компиляции.
Пишите на Хаскель не позорьте себя выкидвшом фп парадигмы
Kotlin :)
Вы похожи на припадок 90 летний....
Тогда уж выбрать GO ! Любой джавист освоит GO за пару недель а результат лучше будет. Я сам участвую в проекте где есть Java, Go, Scala. На Scala пока не пишу (но буду) , так вот делал замер скорости выполнения операций и GO почти в 10 раз выигрывает и пишется очень легко в отличии от Java.