Java действительно сделала огромный рывок вперед за последние годы, но, насколько я понимаю, большая часть этих нововведений уже давно была в Scala, причем сделана там гораздо лучше. Это как Ахиллес и черепаха. Ресурсов у Оракла гораздо больше, и они очень стараются сделать из джавы хотя бы скалу "на минималках" (или колтин "на минималках", кому что больше нравится). Но все равно они никогда не догонят Scala, потому что нельзя из пожилого императивного языка сделать функциональную конфетку.
Я бы не решился сейчас начинать новый проект на Scala.
Ну если проект на Spark, то тут даже думать не надо. Любой вариант кроме Scala требует экстраординарных обоснований.
Между современной джавой и скалой не такая уж адская пропасть. При желании более-менее сеньорный джавер начинает писать вполне идеоматичный скала-код через несколько недель изучения. Конкретно для спарка — это время вообще измеряется часами, поскольку Java API транслируется в Scala практически дословно. Это гораздо проще и быстрее, чем искать людей с нужными скилами на стороне. При этом 10% (хотя мне кажется больше) вы все так же получите.
Я думаю, главный плюс Scala не в скорости исполнения, а в статической типизации. Компилятор проверяет типы за вас, что исключает целый класс ошибок. Плюс первоклассная поддрежка immutability, что исключает еще один класс ошибок. Но подобные вещи обычно выходят на первый план на масштабах чуть больших, чем пара ноутбуков в зеппелине.
На этот счет уже достаточно давно существуют рекомендации от автора языка Мартина Одерского: https://youtu.be/kkTFx3-duc8?t=1822. Крайне рекомендую к просмотру.
Для тех, кому лень смотреть, продублирую эти простые правила здесь:
если имя метода состоит из символов — всегда инфиксная запись
если имя метода состоит из букв и цифр — можно и так и так
Судя по оглавлению, эта книга больше про Machine Learning, чем про Big Data.
Главная специфика Big Data — это то, как эффективно обрабатывать большие объемы данных, как их правильно хранить, как грамотно строить распределенные архитектуры. В книге похоже совсем про другое.
А, понятно. Я приобщился к слику в 2017, не знаю как он выглядел во времена 2.х. Сейчас запросы пишутся через специальный type-safe DSL, что имхо очень удобно. У современного слика проблемы с поддержкой, пару раз натыкался на баги, которые открыты и не пофикшены уже больше года.
Но опять-таки, по моему мнению, слик и хибер — это как небо и земля, даже если брать хибер со всеми спринговыми нашлепками.
"Магия" интерфейсов хорошо работает для простых кейсов, а чуть что посложнее — пиши SQL в аннотации. Переодически приходится что-то подкручивать напрямую через EntityManager.
Плюс Spring Data JPA же не изолирует от написания энтитей с кучей аннотаций и кучей бойлерплейта в виде с геттеров, сеттеров, equals/hashcode. Это конечно тоже решают с помощью Lombok. Выходит, что сликом на скале можно пользоваться самим по себе, а хибером — нет.
Хм… То есть вы действительно не понимаете разницу между "ФП мало применимо на низком уровне" и "ФП далеко не везде применимо"? С первым мало кто будет спорить, но сводить второе к первому — весьма смелое преувеличение.
Про "головную боль при интеграции с готовыми решениями", опять-таки неверно для скалы, которую вы приводите в пример. И в целом аргументация не учитывает прогресс в софтостроении, "старое" не всегда значит "хорошее".
Про "выбор между архитектурой и кодом" — просто абсурд.
И естественно я согласен с вещами типа "инженер не должен мыслить категориями нравится/не нравится", это вроде достаточно очевидно. Каких еще объяснений вы от меня хотите?
Если выбирать между кодом и архитектурой, то выбор должен падать на второе. Это же тоже понятно?
Перед кем может стоять такой выбор?
Вы же согласны с этим? Почему тогда это не соответствует теме статьи?
Я согласен с введением и заключением, но приведенная аргументация меня не убеждает, поскольку каждый тезис можно опровергнуть, используя ту же логику.
Приведите свои аргументы. Мне правда интересно.
Аргументы против ФП? Даже не знаю. Я всегда использую ФП по умолчанию и отступаю от него только при наличии веских причин это сделать, причем происходит это настолько редко, что с трудом поддается какому-то обобщению.
Ну если для вас текущий проект на Java 5 — это что-то вроде рабства, на всю жизнь — то да, не имеет смысл тратить силы на то, что выходит за его рамки. Но обычно все-таки люди изучают то, что им интересно, и потом находят занятие в соответствие со своими знаниями и интересами.
Я тоже люблю ФП и тоже считаю, что он не везде применим. Но агрументация, приведенная в статье, кажется мне крайне слабой.
ФП далеко не везде применимо — и это "далеко не везде" в итоге сводится к программированию железа. Но вот если что и есть "далеко не везде", так это программирование железа на низком уровне. Большинство популярных языков программирования (Java, C#, Python, JavaScript и т.п.) отделены от железа виртуальными машинами и интерпретаторами и вполне себе высокоуровневые для использования ФП.
Приносит головную боль при интеграции с готовыми решениями — это да, но прогресс не стоит на месте. В той же скале множество задач можно решить без использования джава-фреймворков. Ну и да, если бы люди всегда предпочитали "старые-добрые" EJB всему "новому и непонятному", то Spring никогда не стал бы "хорошо протестированным и отлично детерминированным решением".
Тратить время на ФП не всегда разумно — здесь все сводится к абсурдному тезису, что кроме кода есть еще архитектура. Кроме кода есть еще много чего, но если мы все-таки говорим про именно код, изучение ФП еще как имеет смысл.
Чтобы сделать этот аргумент автора еще более абсурдным, можно переделать так:
Не всегда язык программирования и парадигма определяет качество продукта. Гораздо чаще все зависит от проработки бизнес-требований и техзадания. Поэтому к черту программирование вообще, давайте лучше переучиваться на аналитика.
Почему молчат провайдеры и крупные отечественные интернет-компании? Видимо, потому что блокировки пока не настолько ущемляют их интересы, чтобы ввязываться.
Что же касается профессионального ИТ-сообщества, для которого эти и будущие блокировки (а уже принятых законов вполне достаточно для блокирования всех жизненноважных ИТ-ресурсов) скорее всего будут означать запрет на профессию, не похоже, что в данный момент оно имеет какую-то организацию, способную выступить в интересах отрасли. А это значит, что отрасль будет загибаться, а люди будут еще активнее разъезжаться по более гостеприимным для ИТ странам.
Java действительно сделала огромный рывок вперед за последние годы, но, насколько я понимаю, большая часть этих нововведений уже давно была в Scala, причем сделана там гораздо лучше. Это как Ахиллес и черепаха. Ресурсов у Оракла гораздо больше, и они очень стараются сделать из джавы хотя бы скалу "на минималках" (или колтин "на минималках", кому что больше нравится). Но все равно они никогда не догонят Scala, потому что нельзя из пожилого императивного языка сделать функциональную конфетку.
Ну если проект на Spark, то тут даже думать не надо. Любой вариант кроме Scala требует экстраординарных обоснований.
Между современной джавой и скалой не такая уж адская пропасть. При желании более-менее сеньорный джавер начинает писать вполне идеоматичный скала-код через несколько недель изучения. Конкретно для спарка — это время вообще измеряется часами, поскольку Java API транслируется в Scala практически дословно. Это гораздо проще и быстрее, чем искать людей с нужными скилами на стороне. При этом 10% (хотя мне кажется больше) вы все так же получите.
Я думаю, главный плюс Scala не в скорости исполнения, а в статической типизации. Компилятор проверяет типы за вас, что исключает целый класс ошибок. Плюс первоклассная поддрежка immutability, что исключает еще один класс ошибок. Но подобные вещи обычно выходят на первый план на масштабах чуть больших, чем пара ноутбуков в зеппелине.
На этот счет уже достаточно давно существуют рекомендации от автора языка Мартина Одерского: https://youtu.be/kkTFx3-duc8?t=1822. Крайне рекомендую к просмотру.
Для тех, кому лень смотреть, продублирую эти простые правила здесь:
А как влияет вероисповедание?
Судя по оглавлению, эта книга больше про Machine Learning, чем про Big Data.
Главная специфика Big Data — это то, как эффективно обрабатывать большие объемы данных, как их правильно хранить, как грамотно строить распределенные архитектуры. В книге похоже совсем про другое.
А, понятно. Я приобщился к слику в 2017, не знаю как он выглядел во времена 2.х. Сейчас запросы пишутся через специальный type-safe DSL, что имхо очень удобно. У современного слика проблемы с поддержкой, пару раз натыкался на баги, которые открыты и не пофикшены уже больше года.
Но опять-таки, по моему мнению, слик и хибер — это как небо и земля, даже если брать хибер со всеми спринговыми нашлепками.
В ФП конечно же есть состояния, комментатор выше или неточно сформулировал, или не очень разбирается в вопросе.
"Магия" интерфейсов хорошо работает для простых кейсов, а чуть что посложнее — пиши SQL в аннотации. Переодически приходится что-то подкручивать напрямую через EntityManager.
Плюс Spring Data JPA же не изолирует от написания энтитей с кучей аннотаций и кучей бойлерплейта в виде с геттеров, сеттеров, equals/hashcode. Это конечно тоже решают с помощью Lombok. Выходит, что сликом на скале можно пользоваться самим по себе, а хибером — нет.
Slick и новый не айс, но разве хибер лучше?
Хм… То есть вы действительно не понимаете разницу между "ФП мало применимо на низком уровне" и "ФП далеко не везде применимо"? С первым мало кто будет спорить, но сводить второе к первому — весьма смелое преувеличение.
Про "головную боль при интеграции с готовыми решениями", опять-таки неверно для скалы, которую вы приводите в пример. И в целом аргументация не учитывает прогресс в софтостроении, "старое" не всегда значит "хорошее".
Про "выбор между архитектурой и кодом" — просто абсурд.
И естественно я согласен с вещами типа "инженер не должен мыслить категориями нравится/не нравится", это вроде достаточно очевидно. Каких еще объяснений вы от меня хотите?
Перед кем может стоять такой выбор?
Я согласен с введением и заключением, но приведенная аргументация меня не убеждает, поскольку каждый тезис можно опровергнуть, используя ту же логику.
Аргументы против ФП? Даже не знаю. Я всегда использую ФП по умолчанию и отступаю от него только при наличии веских причин это сделать, причем происходит это настолько редко, что с трудом поддается какому-то обобщению.
Ну если для вас текущий проект на Java 5 — это что-то вроде рабства, на всю жизнь — то да, не имеет смысл тратить силы на то, что выходит за его рамки. Но обычно все-таки люди изучают то, что им интересно, и потом находят занятие в соответствие со своими знаниями и интересами.
Вполне возможно. Но из этого никак не следует, что тем кто пишет код этих микросервисов теперь не обязательно изучать парадигмы программирования.
Я тоже люблю ФП и тоже считаю, что он не везде применим. Но агрументация, приведенная в статье, кажется мне крайне слабой.
ФП далеко не везде применимо — и это "далеко не везде" в итоге сводится к программированию железа. Но вот если что и есть "далеко не везде", так это программирование железа на низком уровне. Большинство популярных языков программирования (Java, C#, Python, JavaScript и т.п.) отделены от железа виртуальными машинами и интерпретаторами и вполне себе высокоуровневые для использования ФП.
Приносит головную боль при интеграции с готовыми решениями — это да, но прогресс не стоит на месте. В той же скале множество задач можно решить без использования джава-фреймворков. Ну и да, если бы люди всегда предпочитали "старые-добрые" EJB всему "новому и непонятному", то Spring никогда не стал бы "хорошо протестированным и отлично детерминированным решением".
Тратить время на ФП не всегда разумно — здесь все сводится к абсурдному тезису, что кроме кода есть еще архитектура. Кроме кода есть еще много чего, но если мы все-таки говорим про именно код, изучение ФП еще как имеет смысл.
Чтобы сделать этот аргумент автора еще более абсурдным, можно переделать так:
Огромное спасибо за ссылки! Действительно, очень интересно.
Хотелось бы уточнить источник этой информации. Вы там присутствовали лично?
Что же касается профессионального ИТ-сообщества, для которого эти и будущие блокировки (а уже принятых законов вполне достаточно для блокирования всех жизненноважных ИТ-ресурсов) скорее всего будут означать запрет на профессию, не похоже, что в данный момент оно имеет какую-то организацию, способную выступить в интересах отрасли. А это значит, что отрасль будет загибаться, а люди будут еще активнее разъезжаться по более гостеприимным для ИТ странам.
Спасибо за анонс! Вопрос — почему в вашем плейлисте на Youtube такие неиформативные названия видео?