Ко всему этому еще стоит добавить, что оптимизировать глядя только на код — это вообще малоперспективное занятие. По уму вам надо сначала взять профайлер, найти узкие места и оптимизировать только их. Более того, необходимо с помощью соответсвующих тулов убеждаться, что каждая внесенная оптимизация дает измеримый прирост производительности.
Спасибо за список! Правда, насколько я могу судить, согласно этому списку ситуация с «очень много удобных штук по сравнению с...» ровно противоположна той, что заявил автор комментария выше :)
Прецедент с обвинительным приговором торговцу наклейками, нанесшему мизерный ущерб истцу, открывает для правообладателей широкое поле для преследования рядовых пользователей.
Что-то я не уловил логику перехода от торговли контрафактом до «преследования рядовых пользователей». В исходной статье «Известий» ничего такого нет.
Никто не мешает делать простые проекты без паттернов и абстракций (типа HelloWorld). Правда, за такие проекты не особо платят. Хорошо платят почему-то за сложные проекты, и первоисточником сложности является как правило предметная область или требования, а не инструменты. Инструменты и практики (ООП одна из них) как раз призваны сократить сложность задачи.
Если не нравится (не подходит) ООП — никаких проблем, берите что-нибудь другое. Например, в процедурном программировании нет проблемы состояния и поведения, потому что нет объектов.
Смотрите на ООП не как на максимально близкий к оригиналу способ моделирования мира, а просто как на инженерную практику, позволяющую компоновать состояние и поведение таким образом, чтобы это потом было относительно удобно расширять и поддерживать.
Посмотреть на тот же SOLID, он оперирует понятиями исключительно на уровне абстракции ООП (классы, интерфейсы, наследование и т.п.) Там ни слова про то, насколько близко должна быть модель к реальности, надо ли чтобы кто-то открывал дверь, или чтобы она сама открывалась.
всё происходит как у David Pollak-a, но если смотреть не с точки зрения человека, а с точки зрения компании
Там смысл статьи как раз в том, что он признает, что с точки зрения бизнеса как минимум половину Java-проектов невыгодно переводить на Scala. И пытается уколоть технарей, хочешь ли конкретно ты как технарь прозябать на таких проектах. Ведь это как продолжать копать палкой-копалкой, когда рядом стоит экскаватор. «Там столько непонятных кнопочек и рычажков, и вообще большинство копают палками...»
я лучше буду тратить время, чтобы улучшить мир джавы
Можно только пожелать удачи, потому что тренинги по спарку принесут пользу и самому спарку, и джаве, и даже скале.
переходить на Scala, учить все с нуля? Зачем? Если на Java все работает не хуже.
Весь мой опыт конвертации Java-разработчиков в Scala-разработчиков показывает, что если человек сидит на своем теплом ламповом спринге-хибернейте и ему ничего больше не нужно для счастья — надо просто оставить его в покое.
Кстати об этом же, но в гораздо менее толерантной манере уже давно написал David Pollak. Позволю себе процитировать:
Мы живем в мире, где средний разработчик пишет 3250 строк кода в год (около 20 в день). Это происходит в Eclipse, нажатием кнопки «дай мне шаблон X» с подстановкой кода в предложенные средой разработки места. Потом поход на несколько митингов. И они называют это рабочим днем. Мы не можем уволить всех этих разработчиков. Мы не можем обучить их, чтобы они стали лучше. Это Середняки. Это именно те, кто использует Java. У таких программистов нет той самой комбинации врожденных способностей и желания стать лучше.
Не то, чтобы 100% случаев, но очень часто те, кто отказываются от изучения Scala, мотивируют это тем, что им и так хорошо, их и так все устраивает.
Несколько обидно, что голоса таких людей преобладают на некоторых популярных у нас в стране конференциях, но и от них есть польза. А имеющие глаза увидят сами, на каком языке удобнее разрабатывать под Spark.
properties, extension-functions, nullability, readonly collection, first class functions, primary constructors, data class и тд — этого в Java придется ждать очень долго (ведь совместимость для нее важнее).
Если бы вопрос был только в количестве фич, то скала уже давно была бы мейнстримовым мейнстримом. Похоже джава просто ждет, какие из фич новых языков лучше всего выстреливают, перенимает их себе и делает (условно) 95% JVM-программистов вполне удовлетворенными, снимая при этом с их менеджмента огромные риски от перехода на новый язык.
в JB заявили что они начали разработку компилятора Kotlin->LLVM и возможно в следующем году, можно будет «соскочить» но только уже с JVM
Вряд ли, потому что вся огромная Java-экосистема заточена под JVM, а еще один LLVM-язык без экосистемы едва ли кому-то нужен. А вот если джава таки осилит AOT-компиляцию, которую они уже давно обещают, многим уже существующим LLVM-поделушкам может прийти внезапный конец.
Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).
Но ведь Java тоже всерьез рассматривает переход на val/var, судя по недавнему голосованию. Может так получиться, что через n лет, когда котлин станет менее сырым, все его фичи не будут стоить того, чтобы соскакивать с джавы.
Нет бесплатного профайлера в Java? Конечно есть, хорош для решения основных пробем с производительностью, имеется куча плагинов, называется VisualVM.
Нельзя подключиться профайлером к удаленному серверу? Конечно можно, включаем JMX, пробрасываем порт и вперед. На самом сервере всегда можно заюзать консольные утилитки типа jmap, hprof и т.п.
Race conditions — это действительно головная боль писателей многопоточных приложений, но далеко не всех. Некоторые все-таки знают про shared mutable state и избегают его, используя либо стратегию share-nothing (каналы в Go, Akka — в Java), либо функциональное программирование (переход на immutable).
Стоит ли ява программисту полностью переходить на go? Нет.
Не возьмусь сейчас утверждать, что все контракты в языке надо описывать типами, но опциональность значения — это точно случай когда тип решает проблему.
null размывает контракт, делая любое значение потенциально отсутствующим. Option определяет контракт явно, и компиятору не нужно никакого адского статического анализа, чтобы понять, что кто-то делает Option.get без проверки.
С NPE больше всего проблем в больших системах, когда где-то кем-то провалидированные данные с null'ами внутри, успешно пройдя транзитом через несколько границ подсистем и слоев абстракциии, используются в отрыве от их исходного контракта. Option в этом плане сложнее протащить через всю систему насквозь, его место — на границе, а внутри будут циркулировать значения без всяких сюрпризов, о чем явно будет свидетельствовать их тип.
Тоже неверно. В языке без нулевых указателей просто появятся другие специальные значения, которые будут приводить к другим ошибкам, но такого же рода. В реальности нужен язык с контрактами и статической их проверкой (null-абилити — это всего лишь частный случай контракта).
Явное указание в типе о том, что значения может не быть (Option) — это и есть решение. Но чтобы оно работало и код гарантированно был null-безопасным, надо убрать поддержку null из ЯП.
Вот тут очень бы хотелось увидеть конкретный список.
Что-то я не уловил логику перехода от торговли контрафактом до «преследования рядовых пользователей». В исходной статье «Известий» ничего такого нет.
copyLocalToLocal
copyLocalToRemote
copyRemoteToLocal
copyRemoteToRemote
В «функциональщине» это можно абстрагировать вот так (язык Scala):
Если не нравится (не подходит) ООП — никаких проблем, берите что-нибудь другое. Например, в процедурном программировании нет проблемы состояния и поведения, потому что нет объектов.
Посмотреть на тот же SOLID, он оперирует понятиями исключительно на уровне абстракции ООП (классы, интерфейсы, наследование и т.п.) Там ни слова про то, насколько близко должна быть модель к реальности, надо ли чтобы кто-то открывал дверь, или чтобы она сама открывалась.
Там смысл статьи как раз в том, что он признает, что с точки зрения бизнеса как минимум половину Java-проектов невыгодно переводить на Scala. И пытается уколоть технарей, хочешь ли конкретно ты как технарь прозябать на таких проектах. Ведь это как продолжать копать палкой-копалкой, когда рядом стоит экскаватор. «Там столько непонятных кнопочек и рычажков, и вообще большинство копают палками...»
Можно только пожелать удачи, потому что тренинги по спарку принесут пользу и самому спарку, и джаве, и даже скале.
И да, а что не так с Eclipse?
Весь мой опыт конвертации Java-разработчиков в Scala-разработчиков показывает, что если человек сидит на своем теплом ламповом спринге-хибернейте и ему ничего больше не нужно для счастья — надо просто оставить его в покое.
Кстати об этом же, но в гораздо менее толерантной манере уже давно написал David Pollak. Позволю себе процитировать:
Не то, чтобы 100% случаев, но очень часто те, кто отказываются от изучения Scala, мотивируют это тем, что им и так хорошо, их и так все устраивает.
Несколько обидно, что голоса таких людей преобладают на некоторых популярных у нас в стране конференциях, но и от них есть польза. А имеющие глаза увидят сами, на каком языке удобнее разрабатывать под Spark.
Если бы вопрос был только в количестве фич, то скала уже давно была бы мейнстримовым мейнстримом. Похоже джава просто ждет, какие из фич новых языков лучше всего выстреливают, перенимает их себе и делает (условно) 95% JVM-программистов вполне удовлетворенными, снимая при этом с их менеджмента огромные риски от перехода на новый язык.
Вряд ли, потому что вся огромная Java-экосистема заточена под JVM, а еще один LLVM-язык без экосистемы едва ли кому-то нужен. А вот если джава таки осилит AOT-компиляцию, которую они уже давно обещают, многим уже существующим LLVM-поделушкам может прийти внезапный конец.
Но ведь Java тоже всерьез рассматривает переход на val/var, судя по недавнему голосованию. Может так получиться, что через n лет, когда котлин станет менее сырым, все его фичи не будут стоить того, чтобы соскакивать с джавы.
Нет бесплатного профайлера в Java? Конечно есть, хорош для решения основных пробем с производительностью, имеется куча плагинов, называется VisualVM.
Нельзя подключиться профайлером к удаленному серверу? Конечно можно, включаем JMX, пробрасываем порт и вперед. На самом сервере всегда можно заюзать консольные утилитки типа jmap, hprof и т.п.
Race conditions — это действительно головная боль писателей многопоточных приложений, но далеко не всех. Некоторые все-таки знают про shared mutable state и избегают его, используя либо стратегию share-nothing (каналы в Go, Akka — в Java), либо функциональное программирование (переход на immutable).
А вот с выводом-то особо и не поспоришь :)
null размывает контракт, делая любое значение потенциально отсутствующим. Option определяет контракт явно, и компиятору не нужно никакого адского статического анализа, чтобы понять, что кто-то делает Option.get без проверки.
С NPE больше всего проблем в больших системах, когда где-то кем-то провалидированные данные с null'ами внутри, успешно пройдя транзитом через несколько границ подсистем и слоев абстракциии, используются в отрыве от их исходного контракта. Option в этом плане сложнее протащить через всю систему насквозь, его место — на границе, а внутри будут циркулировать значения без всяких сюрпризов, о чем явно будет свидетельствовать их тип.
Явное указание в типе о том, что значения может не быть (Option) — это и есть решение. Но чтобы оно работало и код гарантированно был null-безопасным, надо убрать поддержку null из ЯП.