Один из важнейших вопросов интернета — «Когда же наконец джава помрёт?»
Почему это важно нам как Java-разработчикам? Очевидно, если Java вдруг начнёт тонуть, нужно побыстрей сбежать с тонущего корабля. А если наоборот, начнёт всплывать — переобуться на ходу и грести с удвоенной силой. Давайте посмотрим, что там творится.
Каждую неделю при подготовке дайджеста мы систематически анализируем огромное количество новостей про Java. Постоянно встречаются результаты всевозможной аналитики популярности языков программирования. Java никогда не выпадала из топа даже у самых упоротых, которые делают эти списки или пишут статьи только чтобы показать преимущество технологии, которую они продают.
Может ли автор JUG-а писать о таких рейтингах? Вспомним последнюю историю с «Яндекс.Радаром», когда Mail.Ru назвала «абсурдным» рейтинг сайтов от «Яндекса» и потребовала удалить из него свои бренды. Вроде как, когда сам являешься игроком на рынке, некорректно вести документы, подразумевающие максимальную объективность.
У людей есть некое подсознательное понимание, что скорее всего, суть таких действий — информационно-паразитическая. Если у рекламщика есть какой-то топ, в него нужно срочно впихнуть свой продукт — неважно, честно он там оказался или нет.
Парадокс с Java в том, что всех, похоже, устраивает текущее положение вещей и её позиция. Нет смысла в отсебятине. Спор о выборе мажорной технологии вроде Java против C#, C++, JavaScript или Python среди серьезных разработчиков может происходить разве что в шутку, ибо у каждой технологии выработалась своя ниша и свой собственный путь, победить в котором с помощью другой технологии — задача титаническая.
Машина локального времени
Забавно наблюдать, как идёт Java по своему Пути. Большинство из нас — простые разработчики, и, не имея доступа ко внутренней кухне проектов вроде JDK, мы можем наблюдать прогресс как цепочки новых версий платформы, фреймворков и фичей в них по ежедневной ленте на Хабре, по программе конференций и так далее.
Взглянем на нашу персональную машину времени — историю хаба Java. Не знаю, как посмотреть это проще, поэтому взял строку
https://habr.com/hub/java/pageN/ и стал увеличивать N. Где-то на N=60 был сентябрь прошлого года, и lany писал про стримы. Java 9 вышла в июле того же года, но люди всё ещё рубились за использование Восьмёрки: эта статья оказалась самой заплюсованной статьёй прошлой осенью (+71, если точнее). Прониклись ли вы сутью стримов за этот год? Как часто используете
.parallel()? :-)
Для сравнения, в том же сентябре Rust вскарабкался на очередной локальный максимум хайпа, и вышла отличная статья «Concurrency паттерны в Rust из Java», которая собрала бы куда больше, чем +33, если бы читатели действительно понимали суть написанного. Зачастую крутые посты оканчивают жизнь в закладках, так как требуют вдумчивого чтения. Она интересна ещё и тем, что ссылается на «Близкие контакты JMM-ной степени» — сумму целой эпохи докладов про JVM concurrency.
На N=115 я внезапно обнаружил свою статью про «Крипту» 2016 года и сейчас не понял в ней ни одного слова. Серьезно, что это за чушь? Что характерно, эта объективно чудовищно плохо написанная статья за годы существования сгенерила десятки панических комментариев в личку.
За 2016 год была куча статей именно о синтаксисе языка и всяких полезностях вроде RxJava. Уже тогда начали писать о JEP-286 — том самом ключевом слове
var, которое мы получили в этом году и которое не все ещё попробовали.Сейчас мы можем взять две фичи, разделённые пропастью версий между Java 8 и Java 10 и скомбинировать вместе с помощью JEP-323, появившегося в Java 11 всего пару месяцев назад. Видите, теперь можно писать var внутри параметров стрима — мелочь, а приятно:
var result = jShell.variables()
.filter((@Nullable var v) -> //var+lambda: Java 11
v.name().equals("result"))
.findAny()
.get();
Машина глобального времени
Взглянем вперёд на конференции, которые отмечают глобальный поток событий. Этой весной на FOSDEM 2018 Марк Рейнхолд впервые анонсировал частые релизы и бесплатные открытые версии JFR, JMC и AppCDS:
Я тоже там был и вместе с ARG89 старался завербовать Марка:
Если честно, для меня эти полгода от прошлого FOSDEM прошли как один длинный-длинный день. Вроде бы очень устал и хочется поспать, но впереди слишком много всего.
Меньше месяца назад на Oracle Code One был новый большой кейноут, «The Future of Java Is Today».
Очень рекомендую посмотреть это видео, даже несмотря на длину в полтора часа. Хотя бы за чудесный момент, когда Марк кодит на Emacs демки для Valhalla. Если кто-то спросит, можно ли программировать на чём-то кроме IntelliJ IDEA… похоже, иногда можно. По крайней мере, если у тебя главный джава-кейноут в мире.
Вкратце, что там было:
- Вступление от Georges Saab (vice president of Software Development for the Java Platform Group);
- Matthew McCullough (VP of Field Services at GitHub) рассказал о том, как Java будет перебираться на GitHub с помощью проекта Skara;
- Saab вернулся на сцену и доверительно сообщил, что Java будет придерживаться своих ценностей: открытости, свободности, качества, секьюрити и так далее;
- Дальше вышел Марк и начал жечь на разные темы.
Некоторые из тем:
- Система модулей (JEP 261) и как она прижилась в реальном мире;
- Новая модель релизов JDK и их поддержки;
- Java 12 и её JEP: Switch expressions, Raw string literals, One AArch64 Port, Not Two, Default CDS Archives.
- Основные проекты OpenJDK: Amber, Panama, Valhalla и Loom. Как раз там был лайвкодинг на емаксе и Java 12. Если с первыми тремя и раньше было всё понятно, то теперь и судьба Loom начинает выглядеть очень хорошо.
Вперед к JPoint!
Посмотрим, какие темы интересуют российское Java-сообщество сегодня.
На протяжении многих лет JUG.ru Group делает Java-конференции, и мы кое-что понимаем в этом вопросе. Во многом они ничем не уступают большим международным событиям вроде оракловских конференций. На последнем Джокере были совершенно мозговыносящие вещи, например, на доклад Паньгина собралось, кажется, больше тысячи человек одновременно.
Как это получается? История Java-конференций в России — это история следования мировым трендам, история вклада в Java-сообщество. Фокус в том, что программа каждой действительно хорошей конференции должна учитывать всё, что было, есть и будет в Java-мире в самое ближайшее время. Это и отражение действительности, и сама по себе веха в глобальной картине всего.
Наступает новый год, и настало время объявить, что мы делаем новый JPoint, который пройдёт 5-6 апреля 2019 года. Это крупнейшая конференция, которая станет зеркалом событий российского и международного Java-сообщества.
Ссылка на сайт ведёт на десктопную версию. Мобильной версии пока нет, она появится на следующей неделе.
Пока что разработка JPoint находится на самой ранней стадии, и мы хотели бы поделиться, какие темы кажутся наиболее популярными.
Короткий список таков:
- JVM/JDK/VM Runtime;
- Reactive programming;
- Всевозможные фреймворки;
- Java 11. Переходить или нет, или если да — то как. А может, уже на Java 12? :-)
Полный список тем, про которые можно было бы поговорить — огромен. За несколько минут можно сгенерить бесчисленное количество идей. Но вот этот укороченный список даёт понимание того, что реально полезно на пороге 2019 года.
По сути, темы, касающиеся low level и перформанса, ждут всегда — кто по чисто рабочим причинам, кто из-за любопытства. Всё остальное зависит от текущей конъюнктуры, положения вещей и событий в Java-мире.
Например, огромный успех развил Project Reactor и другие проекты в этом направлении. Если когда-то все хотя бы краем уха слышали про функциональщину, теперь настоящий бум на реактивщину — такой, какой функциональщине и не снился. Венкат Субраманиам, один из самых известных джава-спикеров и наш докладчик, недавно давал интервью ровно на эту тему:
«Когда меня спрашивают, принадлежит ли будущее функциональному программированию, я отвечаю — нет, оно принадлежит реактивному программированию. Потому что для меня реактивное программирование — это функциональное программирование++»
Отличный способ как-то повлиять на состав программы — оставлять нам обратную связь, в том числе — писать комментарии на Хабре. Мы прислушиваемся не только к мнению Венката, но и ко всем, кому есть чего рассказать.
Но есть способ лучше, чем просто писать комментарии.
Call for Papers
«Люди часто просят меня рассказать о будущем, в то время как всё, что я хочу — изменить его. Даже лучше, построить это будущее. Предсказывать очень просто, в конце-то концов. Ты смотришь на людей вокруг, на улицу, по которой идёшь, вдыхаешь воздуха поглубже — и предсказываешь, что в будущем будет всё то же самое, но куда больше. К чёрту «больше». Я хочу «лучше»». — Рэй Брэдбери
Самый простой способ изменить что-то в Java-мире — это взять и самостоятельно его улучшить.
В плане конференций, можно прийти на новый JPoint с собственным докладом. Помните форму обратной связи, которая заполняется после конференции? В ответ на вопрос «кого позвать делать доклад в следующий раз?» многие отвечают «меня».
Программные комитеты читают совершенно все заявки и внимательно их рассматривают. Да, в списке спикеров много известных личностей, но попасть туда вполне возможно. Придётся, конечно, здорово поработать и над содержанием, и над подачей, но вам будут помогать люди, которые в этом хорошо разбираются.
Есть вполне конкретные критерии принятия доклада, которым можно просто соответствовать. Есть конкретный процесс, который начинается приёмом заявки и заканчивается выступлением на конференции.
Чтобы начать своё путешествие как спикер, нужно перейти по ссылке, всё там внимательно прочитать и сделать как написано. ССЫЛКА.
Возвращаясь к теме этого хабрапоста, тема должна быть актуальна, соответствовать сегодняшнему дню и течению времени. Если вы попробуете рассказать об использовании апплетов и портлетов в легаси-системах, это может показаться странным. Да, такие доклады регулярно подаются. Что интересней — портлеты или реактивщина? О чём бы вы хотели услышать? Напишите в комментариях!
Заключение
Мы стоим на пороге большого будущего.
На пороге большого скачка в Java-технологиях, который основывается на успехах массово используемых проектов вроде Spring, быстром выпуске новых версий JDK, развитии рантаймов (в том числе совершенно особых, вроде GraalVM или Excelsior JET), важных течений в них (Valhalla, Panama, Loom), распространении на новых аппаратных платформах (привет, Bellsoft) и многом другом.
Хорошая новость в том, что, похоже, Java живее всех живых. И мы приложили к этому руку!
Комментарии (127)
AlexTheLost
15.11.2018 15:40+1Java как язык лично для меня умер, и я теперь понимаю что всегда его ненавидел. Уродливый и громоздкий. А вот JVM жива и процветает, под неё огромное кол-во прекрасный языков.
Собственно если уходить от Java то в отрасле должен начаться фундаментальный сдвиг от ужаса называемого ООП, потому что все более менее популярные на сегодня языки не так уж и далеки от Java.olegchir Автор
15.11.2018 16:14+7> от ужаса называемого ООП
так, а ООП то чем не угодил?time2rfc
15.11.2018 16:58+1В 2018 году на хабре можно спрашивать "чья версия ООП не угодила ?". Теряюсь постоянно чей ООП более правильный.
Mishiko
15.11.2018 16:59+2Слабые умы не могут осилить ООП — это основной недостаток ООП
nicholas_k
15.11.2018 17:41+1Я всегда считал, что ООП как раз призван упрощать восприятие программ человеком. Куда проще строить в голове картину связей сущностей, нежели отдельных функций и структур данных. То есть необходимая вычислительная мощность мозга для ООП может быть ниже, чем для процедурного подхода.
Однако же оказалось, что ООП таит в себе ужасы.psFitz
16.11.2018 02:45Тут проблема в том, что изучая ООП обычно показывают возможности ООП, но мало кто читает как правильно ими пользоваться, помню как 1 раз писал в ООП стиле не зная при этом ни 1 паттерна и вообще как этим пользоваться, в итоге получился спагетти из extends
AlexTheLost
16.11.2018 12:22Вот бы увидеть хоть исходный код проект где ООП применили как надо и получилось красиво и понятно.)
Errandir
16.11.2018 10:25Скорее, ООП призван упрощать восприятие хорошо спроектированных программ человеком. Но мир, как обычно, оказался неидеален. А ужасы можно везде без особого усердия призвать к существованию.
AlexTheLost
16.11.2018 12:20-1Слабые умы не могут осилить ООП — это основной недостаток ООП
Или же — слабые умы не могут понять что оно не нужно и продолжают верить своим кумирам продвигавшим ООП?) И писать пухлые от лишнего кода проекты.
Escalibur
16.11.2018 10:00-1Я не скажу, что я сильный спец, но, насколько я понимаю, ООП — это обмен (структурированными) сообщениями, а не С с классами.
В этом и есть основная трагедия ООП. Правильный ООП давно забыт и никто его не знает.
Соответственно, был Смолток, который УЖЕ имел всё, что потом растащили на куски и НЕПРАВИЛЬНО использовали: ВМ, объектная модель, гарбадж коллектор, ОС/ВМ/Среда разработки — в виде комплекса.
Потом на этот поезд пытался вспрыгнуть Вирт со своим Обероном, но было уже поздно. Жадные и тупые наглосакские капитализды уже нахреначили тонну говнокогда на основе неправильных систем, типа С++ и прочего и так все оно и покатилось.Escalibur
16.11.2018 10:46-2Наслаждайтесь, коллеги! )) Минусуйте дальше.
Я не собираюсь тешить ваши узколобые комплексы.
И да, на самом деле, я хорошо разбираюсь в языках программирования, ОС и компиляторах.Whuthering
16.11.2018 12:23+2Более чем уверен, что вас минусуют не из-за несогласия с аргументами, а из-за идиотской манеры речи и коверкания языка (один «наглосакские капитализды» чего стоят).
nicholas_k
15.11.2018 16:40+4А можно тезисно изложить основные ужасы ООП и то, как нивелируются эти ужасы в других парадигмах?
И посоветуйте язык заодно.KevlarBeaver
15.11.2018 19:36Ну как же. ООП подразумевает сущности с состоянием. А в мире математики и розовых пони нет состояний, потому что у поней от состояний случается диарея радугой. Очевидно, что нужно использовать языки, избавленные от этой мерзости, такие, как божетвенный Haskell. И функции. Вы ведь понимаете, что всё — есть функции. Функции от функций. Функции высшего порядка. Жонглировать функциями. Вычислять функции. Но не сохранять результат. Потому что результат — это состояние, не Вы понели.
An70ni
15.11.2018 20:51любой файл на компьютере — это своего рода состояние. Да и куча других вещей с исчезновением состояний станет невозможной. Не думаю, что нужно везде повально избавляться от этого.
nehaev
15.11.2018 22:16+1В ФП конечно же есть состояния, комментатор выше или неточно сформулировал, или не очень разбирается в вопросе.
0xd34df00d
16.11.2018 01:17В хаскеле вы не избавлены от состояния. В хаскеле вы избавлены от того, что любая функция может иметь любые эффекты. Достаточно посмотреть на сигнатуру функции, чтобы понять, чего она точно делать не может.
nicholas_k
16.11.2018 10:13Так ведь инкапсуляция как раз и спасает от того, чтобы думать о состоянии сущности.
AlexTheLost
16.11.2018 12:24Уровень невежества поражает.)
KevlarBeaver
16.11.2018 18:39Мой комментарий получил девять плюсов и один минус. Тут либо уровень невежества у ещё девяти человек Вас мог бы поразить, либо просто они могут в юмор, а Вы — нет. Но в целом, Вы конечно правы, я в этих Ваших Хаскелях действительно не «рублю».
AlexTheLost
16.11.2018 12:35Тезис прост, объект в 99% задач не нужен — то есть объединение состояния + действия. У вас или данные или действия. Чем проще тем лучше.
DelphiCowboy
16.11.2018 09:00А что теперь вместо Джавы? O_O
(Java вроде для Веба и Андроидов используется? Что теперь на них?)Whuthering
16.11.2018 12:24Из JVM-based языков — Scala, Kotlin. Но первый довольно специфичен, а второй еще молод (хотя его уже официально поддерживает Google).
JediPhilosopher
16.11.2018 15:28Scala много лет взлетает-взлетает, но все никак не взлетит. Я бы на нее уже не рассчитывал, она заняла свою довольно узкую нишу и вряд ли из нее уже выберется. Даже наоборот, думаю новые версии джавы и котлин отъедят у нее еще немного популярности.
leventov
15.11.2018 16:04Когда перейдем на Java 11, я попробую в своих проектах протолкнуть запрет на
var. Мне кажется это одна из существенных вещей, которые делают Scala и Kotlin сложными для чтения: методы с двадцатью+ объявленными переменными, без единого типа.MeGaPk
15.11.2018 16:10+1в AppCode на свифте, подсвечивает какой тип используется в этой переменной. По идеи в Idea так же будет. Не мешает чтению кода, от слова совсем.
leventov
15.11.2018 16:36+6Код далеко не всегда просматривается в среде. А даже когда в среде, не удобно гонять курсор повсюду, чтобы увидеть типы, и кешировать их в мозгу, вместо того, чтобы просто их видеть все.
Вот честно, не понимаю, кому мешают эти типы написанные. Код читается в 10 раз чаще, чем пишется.
У нас еще, кстати, статические импорты запрещены, и это хорошо.
olegchir Автор
15.11.2018 16:42Ну, иногда тебе не нужно видеть тип. Потому что там мап листов мапов мапов мапов хэшсетов листов кверибилдеров тредэкзекьюторов, и от взгляда на это может начать бить лихоманка. А ты просто пишешь все в стримо-реактивно-функциональном стиле, и когда-нибудь этот ад заредуцируется в .toList, но не сейчас.
leventov
15.11.2018 16:46+1А как такое хозяйство ревьюить, чтобы не надо было выкачивать ветку из VCS локально, переключаться на нее в идее, и раскуривать, в итоге тратя столько же времени, сколько автор кода? "LGTM"?
olegchir Автор
15.11.2018 16:53Ну а как ты читаешь код на каком-нибудль кложуре или хашкеле? Промежуточные представления могут быть совершенно дичайшими, но часть магии именно в том, что их никто не сохраняет в промежуточные переменные и не выделяет в отдельные переменные-сущности. «Не сломается того, чего нет». Грубо говоря, у тебя не сломается счетчик цикла, если нет циклов со счетчиком. Не сломаются переменные, если у тебя нет переменных (привет, Ерланг). Не сломается понимание типов, если ты их не видишь.
Но тут же возникает вопрос, как все-таки отдебажить эту радость. Вот например, есть у тебя стрим на двадцать хопов, и что-то посередине считается не так очевидно, как кажется. Что дальше делать? Или например, хочется закэшировать какой-то промежуточный результат в пайплайне, чтобы два раза не считать. Вот как раз и поползли переменные, которые вроде бы и есть (потому что пришлось), но и знать о них ты ничего не хочешь.
Ну это так, для примера. Надо подумать. Наверное, lany про это лучше скажет)leventov
15.11.2018 17:29+1Ну а как ты читаешь код на каком-нибудль кложуре или хашкеле? Промежуточные представления могут быть совершенно дичайшими, но часть магии именно в том, что их никто не сохраняет в промежуточные переменные и не выделяет в отдельные переменные-сущности. «Не сломается того, чего нет». Грубо говоря, у тебя не сломается счетчик цикла, если нет циклов со счетчиком. Не сломаются переменные, если у тебя нет переменных (привет, Ерланг). Не сломается понимание типов, если ты их не видишь.
А кто сказал, что читать код на Clojure и Хаскеле — проще, чем на Java? Очевидно, что сложнее, это если не полностью write-only языки, то приближаются к ним. И может быть это та причина, по которой на большие долгоиграющие проекты эти языки редко берут?
Кстати, хотя читать Clojure и Хаскель сложнее, чем Java, я не спорю что они при этом гораздо безопаснее. Одно из другого не следует.
0xd34df00d
16.11.2018 01:19В коде на хаскеле функции, в которых больше трех-четырех локальных let/where-байндингов, заставляют меня уже немножко нервничать и хотеть отрефакторить этот код.
dernasherbrezon
15.11.2018 18:59мапов мапов мапов хэшсетов листов кверибилдеров тредэкзекьюторов
Когда такое появляется, то это:
- Признак неправильной структуры данных
- Признак того, что пора делать POJO.
От того, что слева это будет называться var, проще не станет.
poxvuibr
15.11.2018 19:05Признак того, что пора делать POJO.
Внимание вопрос. Что такое, по вашему мнению, POJO?
dernasherbrezon
15.11.2018 19:12Похоже надо все таки привести пример.
Я так понял имелось в виду следующая конструкция:
Map<String, Map<String, List<QueryBuilder<Executor>>>> entry;
Что значит "пора делать POJO"? Это значит отрефакторить ее в такую:
Map<String, ClientExecutor> entry;
Это читается значительно легче и проблем с <<>>>> нет.
olegchir Автор
15.11.2018 19:14-1А если там написать var, то это читается еще легче: это просто можно не читать и не видеть.
ExplosiveZ
15.11.2018 19:38+1Ну и как этим управлять? Тысячи проверок на get, put. Легче сделать враппер, который всем этим будет управлять. Сам код станет чище.
В этом случае — var это просто способ засунуть всё под ковёр, а не решить проблему.
olegchir Автор
15.11.2018 19:09Ты предлагаешь человеку делать то, что может сделать автоматика. А потом эти POJO будут ломаться постоянно, и придется их поддерживать. Не говоря уж о том, что весь этот сейф программинг с перекладыванием пустого в порожнее, DTO в DTO — это адские тормоза. Не лучше ли компилятору заниматься этой грязью, в то время как человек займется чем-то более человеческим — ну, высокоуровневыми вопросами, постановкой задач, вот этим всем. Точно так же когда-то мы отказались от ручного управления оперативной памятью, и это была огромная победа. «Не сломается то, чего нет». Нет памяти, которую можно вручную размечать — нет проблем с памятью. Есть стандартный алгоритм сортировки в коллекциях — нет проблемы с сортировкой. Нет типов, которые нужно вручную выводить — нет проблем с организацией типов. Итп.
dernasherbrezon
15.11.2018 19:14Немного не понял про автоматику. Есть вот такая штука:
Map<String, Map<String, List<QueryBuilder<Executor>>>> entry = new HashMap<String, Map<String, List<QueryBuilder<Executor>>>>();
Которая будет записана как:
var entry = new HashMap<String, Map<String, List<QueryBuilder<Executor>>>>();
И как это автоматически упростит читаемость? Особенно когда через 10 строчек будет что то вроде:
if( entry.get("test string").get("blahblah").contains("blahblah")) { ... }olegchir Автор
15.11.2018 19:25А в чем проблема?
Только записать стримами, чтобы не пришлось проверять на null, итп.
Мне очень нравится вот этот чувак: blog.ploeh.dk
У него есть очень стройная теория по применению функционального подхода к C#. Он берет какие-то приемы из Haskell, адаптирует на F#, и потом рассуждает, как это можно применить в C#, несмотря на то, что C# не имеет всяких продвинутых фичей.
В качестве примера рассуждений, есть его доклад на прошлом DotNext 2017 Moscow про Dependency Injection. Ну да, C# это не совсем Java, но с точки зрения общего дизайна они близнецы-братья.
Имхо это вопрос не столько конкретно о варах, или о стримах, или еще в какой-то конкретной фиче, а в общем вижене способа кодирования
dernasherbrezon
15.11.2018 20:23Теперь я совсем потерялся… а как стримы помогут взять значение? Можно пример?
olegchir Автор
16.11.2018 09:18Ну, в данном случае — наверное, никак нельзя :-) Я просто попытался сказать, что можно изначально пытаться все писать в функциональном стиле (именно труЪ-функциональном), и тогда вопрос «какой там промежуточный тип» будет стоять сильно меньше. Не знаю, как это рассказать коротко, придумаю — напишу статью. Марк Симанн очень много написал размышлений, как превратить изначально не функциональный язык C# во что-то относительно похожее. К сожалению, опять же, применения этого на реальном проекте я показать не могу, это все пока только идеи.
olegchir Автор
15.11.2018 16:13+6А можно как-нибудь протолкнуть запрет на неиспользование мозга? Вары не нужно пихать вообще везде — только там, где типы мешают
poxvuibr
15.11.2018 16:34+4А можно как-нибудь протолкнуть запрет на неиспользование мозга?
Многие пытались, но запрещать фичи языка получается лучше. Ну, то есть результаты лучше, если запретить фичи языка, вместо того, чтобы запрещать неиспользование мозга.
Вары не нужно пихать вообще везде — только там, где типы мешают
С таким же успехом можно сказать, что goto не надо использовать везде, а надо использовать только там, где условные операторы мешают.
olegchir Автор
15.11.2018 16:44+1Таааак. А goto то чем не угодил?
poxvuibr
15.11.2018 17:56+1Таааак. А goto то чем не угодил?
Дейкстра целую статью на эту тему написал, не думаю, что у меня получится сказать лучше ))). Хотя конкретно в джаве goto это, конечно — добро. Благодаря ему урлы в джаве стали конструкцией языка, которые можно класть прямо в код.
F0iL
15.11.2018 18:06+2Благодаря ему урлы в джаве стали конструкцией языка, которые можно класть прямо в код.
В C++ такая же фигня :)
А в Java именнованные метки (label) могут использоваться не только с goto (насколько я помню, там идентификатор goto наоборот зарезервирован, но по факту не работает), а, например, с continue/break.
transcengopher
16.11.2018 14:59Можно, к примеру, делать break из проименованного if (вообще-то любого блока, но не суть).
И единственное, почему это мало кто любит — это то, что конструкция выглядит непривычно. А выглядит она непривычно потому, что так мало кто делает. А делают так мало потому, что не любят. Ну и так далее. А началось с того, что это не любил Дийкстра. Весьма нерациональный подход, на мой вкус.
poxvuibr
16.11.2018 15:32насколько я помню, там идентификатор goto наоборот зарезервирован, но по факту не работает
Вот я и говорю, в джаве goto — добро. Использовать его нельзя, поэтому он ничего не портит, а http ссылки в конструкции языка добавляет )))
buzzi888
16.11.2018 09:13В си это нормальный такой подход для каких-то системных штук. Весь линукс так выглядит, получается чисто и опрятно. Разве это не прекрасно:
do A if (error) goto out_a; do B if (error) goto out_b; do C if (error) goto out_c; goto out; out_c: undo C out_b: undo B: out_a: undo A out: return ret;merhalak
16.11.2018 10:15Выглядит то хорошо.
Вот только defer из go для того же выглядит сильно лучше.
Whuthering
16.11.2018 12:25+1Как ни крутите, а это все-таки костыль из-за отсутствия в языке исключений.
dimakey
15.11.2018 17:30+1Многие пытались, но запрещать фичи языка получается лучше. Ну, то есть результаты лучше, если запретить фичи языка, вместо того, чтобы запрещать неиспользование мозга.
Сплошную линию пересекают реже, если она из бетона и 40см в высоту?olegchir Автор
15.11.2018 17:39Если ты именно про высоту, то похоже, даже чаще :mrdestructoid:
leventov
15.11.2018 16:41+1С когнитивными искажениями невозможно бороться. Одно из них — когда человек только что написал метод, он кажется ему очевидным. Поэтому не пишут комментарии, и поэтому будут лепить var — "ну тут же очевидно какой тип, а выглядит короче и элегантнее".
UnclShura
15.11.2018 19:11+1Вары именно что нужно писать везде. Шарписты смотрят с недоумение на этот срач. Мы это прошли лет пять(?) назад. Код либо читается либо нет. Если код читается то вар только помогает. Ибо нефиг мусорить (масло м = новое масло() )! Если код не читается, то ему прописаны типы не помогут.
KevlarBeaver
15.11.2018 19:42+1В шарпе программисты многое прошли раньше джавы, которая появилась раньше шарпа. И теперь не нарадуюсь смотреть на то, как шарписты какую-то фичу давно съели и выкакали, а джависты — только ждут в новой версии.
vyatsek
17.11.2018 12:45Вары именно что нужно писать везде.
Очень сильно утвереждение. Еслиvar myData = new Data()— все понятно, но если же дерьмо вроде
var data = GetData();
var convertedData = GetConvertedData(data);
return convertedData.ToString();
return convertedData.ToString();это паттерн бюррократии. Вместо того, чтобы зайти в нужный кабинет сразу, ты сначала по соседним помотайся методам и типам помотайся, а вот потом уже к нам.
Часто я код смотрб в системе контроля версий или блокноте, потому что пока его склонируешь или откроешь в IDE уйдет вагон времени.
vazquez
15.11.2018 16:21+3мне кажется, стоит протолкнуть запрет на создание методов с 20+ переменными)
SemperPeritus
15.11.2018 19:47А заодно и запрет на создание функций с названием более, например, 50 символов тогда уж)
psFitz
16.11.2018 11:55А вы много таких методов видели? Я на джаве не писал, но на пхп такое видел разве что на каком-то вп, а в любом новом фреймворке такого нет, да и писать такого давно не приходилось
Ascar
15.11.2018 16:38+1Я конечно пишу на шарпе, но вроде как чисто при объявлении var не возможно использовать без присвоения чего либо ему.
KevlarBeaver
15.11.2018 19:43И в Java это точно так же. Потому что var — это не динамическая типизация, это вывод типа.
0xd34df00d
16.11.2018 01:22Вывод типа не обязан зависеть только от rhs, вообще говоря. То, что он в джаве и шарпе настолько локальный, делает эту дихотомию несколько ложной.
jbaruch
15.11.2018 16:45Запрет не нужен, нужны giudelines когда использовать, а когда нет. Очевидно, на один borsch в
Borsch borsch = new Borsch()это благо. Всё хорошо в меру и без фанатизма. И использование var, и запреты на него.leventov
15.11.2018 16:51+2Я бы сказал, что это будет работать на пет- и соло-проектах, максимум — проектах на два-три человека. В больших проектах с "текучкой" разработчиков бороться с безответственностью невозможно никак кроме полного запрета каких-то вещей.
Free_ze
15.11.2018 16:59Стоит попробовать практиковать код-ревью.
leventov
15.11.2018 17:21+1Код-ревью обычно в три раза безответственнее чем само написание кода. Только в мире розовых пони бывают проекты на десять разработчиков, люди приходят и уходят каждые несколько месяцев, но при этом все одинаково ответственны и квалифицированны.
Free_ze
15.11.2018 17:38+1Вот что-что, а поспорить насчет оформления кода — это же любимый холивар программистов. Табы vs пробелы, няшное ручное форматирование vs автоформатеры, как лучше обозвать переменную… А в «чужую» бизнес-логику вникать — удел сильных. (=
Но все же именно в «текучих» крупных командах и окупается даже бестолковое поверхностное код-ревью, против полного его отсутствия. Если есть какие-то правила, то следить за их исполнением должен кто-то уполномоченный таской, а не просто самый ответственный и по настроениюдостать соседа.
solver
15.11.2018 17:28+1Заодно расскажите, как в Java 11 создать методы без указания типов… очень интересно как вы это делаете.
zagayevskiy
16.11.2018 18:54Методы с 20+ объявленными переменными не станут проще только от того, что вы объявите их типы. Декомпозируйте.
LMSn
16.11.2018 19:30+1За редкими исключениями, весь мир дотнета пишет var везде, где можно. Абсолютно никого не смущает. Java, конечно, не C#, и вам виднее, и тем не менее чтению не мешает от слова совсем, даже наоборот. Если, конечно, вы не смотрите код из блокнота, но не знаю что может привести человека к такому в 2018.
leventov
16.11.2018 20:12+1Да это понятно, в Скале и Котлине эти вары тоже никого не смущают.
Я едва ли не большую часть времени смотрю на код "из блокнота", который называется Гитхаб :)
Foror
16.11.2018 21:04>Абсолютно никого не смущает.
Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?
>что может привести человека к такому в 2018
Чтение кода в интернете
>тем не менее чтению не мешает
Мешает, я уже начинаю на гитхабе сталкиваться с не читаемым джава кодом, где используют var. Приходиться материться, что мою джаву превращают в очередной джаваскрипт.
Я согласен, что var можно использовать, но в очень ограниченных случаях. К сожалению это не все понимают. Очень много людей до сих пор считают, что важно количество написанных букв, а не скорость чтение написанного кода, пусть и частично избыточного. Прям вот экономят на буквах, как будто они в 70-х. И это очень печально, такой код потом очень тяжело поддерживать.
rjhdby
17.11.2018 11:47Мне кажется, что методы с 20+ объявленными переменными — это, в общем случае, повод не избавляться от var, а повод избавляться от таких методов.
Опять таки, если это действительно такой уникальный метод, в котором просто необходимы 20+ переменных, то никто не мешает конкретно для этого метода расставить типы.
springimport
15.11.2018 17:40+1Когда читаю про java то приходит беспокойство о php. Ведь он в каком-то смысле ее наследник. Да еще и js постоянно набирает обороты.
olegchir Автор
15.11.2018 18:16В PHP все плохо. Недавно как раз ключевые разрабочтики Zend Engine написали, что сбегают из конторы, которая оплачивает банкет и ищут нового работодателя
springimport
15.11.2018 18:22+2Помню что уходил основатель. Но если судить чисто по php то php 7.0 просто огромный шаг вместе с 7.1 и 7.2. Сложно сказать что дела идут плохо.
olegchir Автор
15.11.2018 18:24ZendEngine — это и есть сам PHP. Если за него не будут платить (а про это намекали ушедший сооснователь и 2 ключевых разработчика), то PHP дальше чем сейчас никуда не уйдет. Ну то есть, это хорошо что теперь есть 7.2, но если теперь никогда не станет 8, то это фиаско
springimport
15.11.2018 18:28+1Посмотрим как будет. В принципе, лет на 5-7 этого хватит если совсем не будет развития.
KevlarBeaver
16.11.2018 14:52Хватит то оно хватит, но лично бы я линял с тонущего корабля одним из первых, и считайте меня кем хотите. Если технология загибается, то я считаю нецелесообразным заниматься ею целых пять лет, а потом впопыхах искать, на что бы перейти… лучше перейти сразу и пять лет в ней стать профессионалом.
anprs
16.11.2018 15:57То неловкое чувство, когда решил перейти от нативных языков к высокоуровневым, выбрав Java, и наткнулся на обсуждение этого поста…
JuniorIL
15.11.2018 18:01+1Пользуясь случаем, расскажите пожалуйста, а уже есть альтернатива Spring Boot для (например) Scala? Чтобы раз — два и вот тебе готовый базовый REST проект, сильно много настраивать не надо, бойлерплейт не писать; потом, когда хочешь добавить ещё возможность, всё уже есть из коробки с готовыми настройками по умолчанию. Когда я вспоминаю старый Slick, мне тошнота подступает к горлу…
nehaev
15.11.2018 18:30Slick и новый не айс, но разве хибер лучше?
JuniorIL
15.11.2018 18:41Когда он стоит за Spring Data JPA замечателен. Просто определи интерфейс и всё сгенерируется само.
nehaev
15.11.2018 19:13"Магия" интерфейсов хорошо работает для простых кейсов, а чуть что посложнее — пиши SQL в аннотации. Переодически приходится что-то подкручивать напрямую через EntityManager.
Плюс Spring Data JPA же не изолирует от написания энтитей с кучей аннотаций и кучей бойлерплейта в виде с геттеров, сеттеров, equals/hashcode. Это конечно тоже решают с помощью Lombok. Выходит, что сликом на скале можно пользоваться самим по себе, а хибером — нет.
JuniorIL
15.11.2018 19:59Так замечательно же, когда будет сложнее — буду писать сам. А вот в Slick 2.x каждый запрос надо было писать ручками, через боль и слёзы.
И Энтити с кучей анотаций описывают связи и взаимоотношения, которые помогают разобраться в структуре проекта, что нельзя сказать про запросы.
Дисклеймер, я очень люблю Скалу, но очень не люблю ту экосистему, с которой я работал в 2015. Это чтобы вы не думали, что я из лагеря староверов :-)nehaev
15.11.2018 22:35А, понятно. Я приобщился к слику в 2017, не знаю как он выглядел во времена 2.х. Сейчас запросы пишутся через специальный type-safe DSL, что имхо очень удобно. У современного слика проблемы с поддержкой, пару раз натыкался на баги, которые открыты и не пофикшены уже больше года.
Но опять-таки, по моему мнению, слик и хибер — это как небо и земля, даже если брать хибер со всеми спринговыми нашлепками.
eskander_service
15.11.2018 18:14+4Спасибо автору за статью.
P.S. Дорогие котлинисты и страдающие от «УЖАСЁВ))» ООП, Java никогда не умрёт. Не нравится, не используйте этот язык.snuk182
15.11.2018 19:30+1На Java написано (и пишется до сих пор) до черта финтехсофта, как минимум потому и не умрет. Однако Котлин — все же серьезная заявка на кусок JVM-пирога.
zirix
15.11.2018 22:49На Java написано (и пишется до сих пор) до черта финтехсофта
Я даже больше скажу: весь «энтерпрайз» сидит на java и никуда не хочет с нее уходить.
А если и захочет, то альтернатив java особо и нет (у компаний, особенно больших, чуть другие требования к языку и экосистеме, чем у пользователей). Разве что C#, но у него кроме плюсов есть и недостатки.
Очень странно видеть рассуждения о смери активно используемого языка и его сравнения с легаси языками типа cobol и delphi.
zagayevskiy
16.11.2018 19:06Котлин интероперабелен с джавой в обе стороны, так что можно постепенно мигрировать проект, было бы желание.
Foror
16.11.2018 20:46>Котлин интероперабелен с джавой в обе стороны, так что можно постепенно мигрировать проект,
Для молодежи, которая дальше пет проектов не вылезала. А в нормальном проекте по голове постучат за такие идеи.
Foror
16.11.2018 20:43>Котлин — все же серьезная заявка на кусок JVM-пирога
Сомнительно. Про груви так же говорили и где он теперь? Для джавы готовят очень много вкусных фич, после которых котлин станет не нужным. Он сейчас не особо нужен, но молодёжь клюёт на рекламу. Еще бы нет, его в IDEA (46% рынка IDE) даже в контекстное меню встроили, причём во многих местах он там отсвечивает.
vitrolov
15.11.2018 21:43+1Если кто-то спросит, можно ли программировать на чём-то кроме IntelliJ IDEA… похоже, иногда можно
Улыбнуло. Учитывая, что James Gosling написал в твиттер, что он фанат netbeans 10, но как говорится из колхоза видней, как правильно Джаву приготовить.
?
AlexTheLost
16.11.2018 12:41+1Это всё звучит забавно — про споры о IDE для Java. Без которого на языке писать мягко говоря тяжко.
С учётом того что есть языки которые позволяют писать код без IDE и продуктивноться не падет.)
Хорошо бы разработчики одного языка с ними познакомились, бывает если выйти за пределы совего "села" всё привычное уже не кажется каким хорошим. :)
DieSlogan
16.11.2018 14:42+1Есть просто огромная куча софта, которая написана на Java и которая еще будет поддерживаться кучу лет. С этих проектов уходят люди, требуются новые и новые. Поэтому, Java будет еще долго актуальным языком.
Вопрос в том, будут ли проекты, на которые зовут программистов, чем-то новым или это будет допиливание модулей на имеющуюся систему?
Сложно судить, лично я не стану делать новый проект на Java. Если уж на то пошло и JVM обязателен, то я сделаю его на Kotlin.
И не последнюю роль тут играет Oracle с её людоедской нынешней репутацией.zagayevskiy
16.11.2018 19:08Прикол в том, что и новые фичи в своем старом проекте на джаве вы можете пилить на Котлине;)
Foror
16.11.2018 21:15-1Умрёт, когда нормальный ЯП запилят, сейчас на рынке одни выскочки со смузи, которые тяжелее члена, ничего в руках не держали. Живут в своём выдуманном мирке, не понимая требований «работников на земле». Но в целом, старички с легаси продолжают держать рынок. И джава, даже со своим легаси, на всём этом фоне еще очень приятно смотрится.
AndyKorg
Че-то напомнило «Delphi живее всех живых»
KevlarBeaver
О, они наконец-то разродились на бесплатную Community Edition. Беда в том, что я уже вообще не помню, как писать на Delphi. Десять лет назад бы…