Когда Java наконец помрёт, что с этим делать и что будет с JPoint +34





Один из важнейших вопросов интернета — «Когда же наконец джава помрёт?»

Почему это важно нам как 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):

  1. AndyKorg
    /#19373438 / +6

    Че-то напомнило «Delphi живее всех живых»

    • KevlarBeaver
      /#19375034

      О, они наконец-то разродились на бесплатную Community Edition. Беда в том, что я уже вообще не помню, как писать на Delphi. Десять лет назад бы…

  2. AlexTheLost
    /#19373582 / +1

    Java как язык лично для меня умер, и я теперь понимаю что всегда его ненавидел. Уродливый и громоздкий. А вот JVM жива и процветает, под неё огромное кол-во прекрасный языков.
    Собственно если уходить от Java то в отрасле должен начаться фундаментальный сдвиг от ужаса называемого ООП, потому что все более менее популярные на сегодня языки не так уж и далеки от Java.

    • olegchir
      /#19373812 / +7

      > от ужаса называемого ООП

      так, а ООП то чем не угодил?

      • time2rfc
        /#19374178 / +1

        В 2018 году на хабре можно спрашивать "чья версия ООП не угодила ?". Теряюсь постоянно чей ООП более правильный.

      • Mishiko
        /#19374182 / +2

        Слабые умы не могут осилить ООП — это основной недостаток ООП

        • nicholas_k
          /#19374460 / +1

          Я всегда считал, что ООП как раз призван упрощать восприятие программ человеком. Куда проще строить в голове картину связей сущностей, нежели отдельных функций и структур данных. То есть необходимая вычислительная мощность мозга для ООП может быть ниже, чем для процедурного подхода.

          Однако же оказалось, что ООП таит в себе ужасы.

          • psFitz
            /#19376450

            Тут проблема в том, что изучая ООП обычно показывают возможности ООП, но мало кто читает как правильно ими пользоваться, помню как 1 раз писал в ООП стиле не зная при этом ни 1 паттерна и вообще как этим пользоваться, в итоге получился спагетти из extends

            • olegchir
              /#19376918

              > спагетти из extends

              Егора Бугаенко читал?) Может быть, так и надо?

              • poxvuibr
                /#19377388

                У Егора вроде implements в качестве основного ингредиента

              • psFitz
                /#19377728

                Не читал)
                Так не надо было, потому-что была каша, в которой при каждом чихе что-то отваливалось, но лучше плохой опыт, чем без опыта)

            • AlexTheLost
              /#19377970

              Вот бы увидеть хоть исходный код проект где ООП применили как надо и получилось красиво и понятно.)

          • Errandir
            /#19377226

            Скорее, ООП призван упрощать восприятие хорошо спроектированных программ человеком. Но мир, как обычно, оказался неидеален. А ужасы можно везде без особого усердия призвать к существованию.

        • AlexTheLost
          /#19377964 / -1

          Слабые умы не могут осилить ООП — это основной недостаток ООП
          Или же — слабые умы не могут понять что оно не нужно и продолжают верить своим кумирам продвигавшим ООП?) И писать пухлые от лишнего кода проекты.

      • Escalibur
        /#19377124 / -1

        Я не скажу, что я сильный спец, но, насколько я понимаю, ООП — это обмен (структурированными) сообщениями, а не С с классами.

        В этом и есть основная трагедия ООП. Правильный ООП давно забыт и никто его не знает.

        Соответственно, был Смолток, который УЖЕ имел всё, что потом растащили на куски и НЕПРАВИЛЬНО использовали: ВМ, объектная модель, гарбадж коллектор, ОС/ВМ/Среда разработки — в виде комплекса.

        Потом на этот поезд пытался вспрыгнуть Вирт со своим Обероном, но было уже поздно. Жадные и тупые наглосакские капитализды уже нахреначили тонну говнокогда на основе неправильных систем, типа С++ и прочего и так все оно и покатилось.

        • Escalibur
          /#19377326 / -2

          Наслаждайтесь, коллеги! )) Минусуйте дальше.

          Я не собираюсь тешить ваши узколобые комплексы.

          И да, на самом деле, я хорошо разбираюсь в языках программирования, ОС и компиляторах.

          • Whuthering
            /#19377974 / +2

            Более чем уверен, что вас минусуют не из-за несогласия с аргументами, а из-за идиотской манеры речи и коверкания языка (один «наглосакские капитализды» чего стоят).

    • nicholas_k
      /#19374036 / +4

      А можно тезисно изложить основные ужасы ООП и то, как нивелируются эти ужасы в других парадигмах?
      И посоветуйте язык заодно.

      • KevlarBeaver
        /#19375072

        Ну как же. ООП подразумевает сущности с состоянием. А в мире математики и розовых пони нет состояний, потому что у поней от состояний случается диарея радугой. Очевидно, что нужно использовать языки, избавленные от этой мерзости, такие, как божетвенный Haskell. И функции. Вы ведь понимаете, что всё — есть функции. Функции от функций. Функции высшего порядка. Жонглировать функциями. Вычислять функции. Но не сохранять результат. Потому что результат — это состояние, не Вы понели.

        • An70ni
          /#19375436

          любой файл на компьютере — это своего рода состояние. Да и куча других вещей с исчезновением состояний станет невозможной. Не думаю, что нужно везде повально избавляться от этого.

          • nehaev
            /#19375766 / +1

            В ФП конечно же есть состояния, комментатор выше или неточно сформулировал, или не очень разбирается в вопросе.

        • 0xd34df00d
          /#19376330

          В хаскеле вы не избавлены от состояния. В хаскеле вы избавлены от того, что любая функция может иметь любые эффекты. Достаточно посмотреть на сигнатуру функции, чтобы понять, чего она точно делать не может.

        • nicholas_k
          /#19377178

          Так ведь инкапсуляция как раз и спасает от того, чтобы думать о состоянии сущности.

        • AlexTheLost
          /#19377986

          Уровень невежества поражает.)

          • KevlarBeaver
            /#19380188

            Мой комментарий получил девять плюсов и один минус. Тут либо уровень невежества у ещё девяти человек Вас мог бы поразить, либо просто они могут в юмор, а Вы — нет. Но в целом, Вы конечно правы, я в этих Ваших Хаскелях действительно не «рублю».

      • AlexTheLost
        /#19378056

        Тезис прост, объект в 99% задач не нужен — то есть объединение состояния + действия. У вас или данные или действия. Чем проще тем лучше.

    • DelphiCowboy
      /#19376876

      А что теперь вместо Джавы? O_O
      (Java вроде для Веба и Андроидов используется? Что теперь на них?)

      • Whuthering
        /#19377982

        Из JVM-based языков — Scala, Kotlin. Но первый довольно специфичен, а второй еще молод (хотя его уже официально поддерживает Google).

        • JediPhilosopher
          /#19379070

          Scala много лет взлетает-взлетает, но все никак не взлетит. Я бы на нее уже не рассчитывал, она заняла свою довольно узкую нишу и вряд ли из нее уже выберется. Даже наоборот, думаю новые версии джавы и котлин отъедят у нее еще немного популярности.

      • DieSlogan
        /#19378688 / -1

        Для веба я недавно ASP.NET Core открыл. Cross-platform, open source.

  3. leventov
    /#19373734

    Когда перейдем на Java 11, я попробую в своих проектах протолкнуть запрет на var. Мне кажется это одна из существенных вещей, которые делают Scala и Kotlin сложными для чтения: методы с двадцатью+ объявленными переменными, без единого типа.

    • MeGaPk
      /#19373782 / +1

      в AppCode на свифте, подсвечивает какой тип используется в этой переменной. По идеи в Idea так же будет. Не мешает чтению кода, от слова совсем.

      • Free_ze
        /#19373864 / +2

        По идеи в Idea так же будет.

        В Rider нет подсветки, но есть тултип.

      • leventov
        /#19373986 / +6

        Код далеко не всегда просматривается в среде. А даже когда в среде, не удобно гонять курсор повсюду, чтобы увидеть типы, и кешировать их в мозгу, вместо того, чтобы просто их видеть все.


        Вот честно, не понимаю, кому мешают эти типы написанные. Код читается в 10 раз чаще, чем пишется.


        У нас еще, кстати, статические импорты запрещены, и это хорошо.

        • olegchir
          /#19374050

          Ну, иногда тебе не нужно видеть тип. Потому что там мап листов мапов мапов мапов хэшсетов листов кверибилдеров тредэкзекьюторов, и от взгляда на это может начать бить лихоманка. А ты просто пишешь все в стримо-реактивно-функциональном стиле, и когда-нибудь этот ад заредуцируется в .toList, но не сейчас.

          • leventov
            /#19374090 / +1

            А как такое хозяйство ревьюить, чтобы не надо было выкачивать ветку из VCS локально, переключаться на нее в идее, и раскуривать, в итоге тратя столько же времени, сколько автор кода? "LGTM"?

            • olegchir
              /#19374142

              Ну а как ты читаешь код на каком-нибудль кложуре или хашкеле? Промежуточные представления могут быть совершенно дичайшими, но часть магии именно в том, что их никто не сохраняет в промежуточные переменные и не выделяет в отдельные переменные-сущности. «Не сломается того, чего нет». Грубо говоря, у тебя не сломается счетчик цикла, если нет циклов со счетчиком. Не сломаются переменные, если у тебя нет переменных (привет, Ерланг). Не сломается понимание типов, если ты их не видишь.

              Но тут же возникает вопрос, как все-таки отдебажить эту радость. Вот например, есть у тебя стрим на двадцать хопов, и что-то посередине считается не так очевидно, как кажется. Что дальше делать? Или например, хочется закэшировать какой-то промежуточный результат в пайплайне, чтобы два раза не считать. Вот как раз и поползли переменные, которые вроде бы и есть (потому что пришлось), но и знать о них ты ничего не хочешь.

              Ну это так, для примера. Надо подумать. Наверное, lany про это лучше скажет)

              • leventov
                /#19374382 / +1

                Ну а как ты читаешь код на каком-нибудль кложуре или хашкеле? Промежуточные представления могут быть совершенно дичайшими, но часть магии именно в том, что их никто не сохраняет в промежуточные переменные и не выделяет в отдельные переменные-сущности. «Не сломается того, чего нет». Грубо говоря, у тебя не сломается счетчик цикла, если нет циклов со счетчиком. Не сломаются переменные, если у тебя нет переменных (привет, Ерланг). Не сломается понимание типов, если ты их не видишь.

                А кто сказал, что читать код на Clojure и Хаскеле — проще, чем на Java? Очевидно, что сложнее, это если не полностью write-only языки, то приближаются к ним. И может быть это та причина, по которой на большие долгоиграющие проекты эти языки редко берут?


                Кстати, хотя читать Clojure и Хаскель сложнее, чем Java, я не спорю что они при этом гораздо безопаснее. Одно из другого не следует.

              • 0xd34df00d
                /#19376336

                В коде на хаскеле функции, в которых больше трех-четырех локальных let/where-байндингов, заставляют меня уже немножко нервничать и хотеть отрефакторить этот код.

          • dernasherbrezon
            /#19374886

            мапов мапов мапов хэшсетов листов кверибилдеров тредэкзекьюторов

            Когда такое появляется, то это:


            1. Признак неправильной структуры данных
            2. Признак того, что пора делать POJO.

            От того, что слева это будет называться var, проще не станет.

            • poxvuibr
              /#19374930

              Признак того, что пора делать POJO.

              Внимание вопрос. Что такое, по вашему мнению, POJO?

              • dernasherbrezon
                /#19374966

                Похоже надо все таки привести пример.


                Я так понял имелось в виду следующая конструкция:


                Map<String, Map<String, List<QueryBuilder<Executor>>>> entry;

                Что значит "пора делать POJO"? Это значит отрефакторить ее в такую:


                Map<String, ClientExecutor> entry;

                Это читается значительно легче и проблем с <<>>>> нет.

                • olegchir
                  /#19374978 / -1

                  А если там написать var, то это читается еще легче: это просто можно не читать и не видеть.

                  • ExplosiveZ
                    /#19375086 / +1

                    Ну и как этим управлять? Тысячи проверок на get, put. Легче сделать враппер, который всем этим будет управлять. Сам код станет чище.
                    В этом случае — var это просто способ засунуть всё под ковёр, а не решить проблему.

            • olegchir
              /#19374954

              Ты предлагаешь человеку делать то, что может сделать автоматика. А потом эти POJO будут ломаться постоянно, и придется их поддерживать. Не говоря уж о том, что весь этот сейф программинг с перекладыванием пустого в порожнее, DTO в DTO — это адские тормоза. Не лучше ли компилятору заниматься этой грязью, в то время как человек займется чем-то более человеческим — ну, высокоуровневыми вопросами, постановкой задач, вот этим всем. Точно так же когда-то мы отказались от ручного управления оперативной памятью, и это была огромная победа. «Не сломается то, чего нет». Нет памяти, которую можно вручную размечать — нет проблем с памятью. Есть стандартный алгоритм сортировки в коллекциях — нет проблемы с сортировкой. Нет типов, которые нужно вручную выводить — нет проблем с организацией типов. Итп.

              • dernasherbrezon
                /#19374982

                Немного не понял про автоматику. Есть вот такая штука:


                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
                  /#19375022

                  А в чем проблема?
                  Только записать стримами, чтобы не пришлось проверять на null, итп.

                  Мне очень нравится вот этот чувак: blog.ploeh.dk

                  У него есть очень стройная теория по применению функционального подхода к C#. Он берет какие-то приемы из Haskell, адаптирует на F#, и потом рассуждает, как это можно применить в C#, несмотря на то, что C# не имеет всяких продвинутых фичей.

                  В качестве примера рассуждений, есть его доклад на прошлом DotNext 2017 Moscow про Dependency Injection. Ну да, C# это не совсем Java, но с точки зрения общего дизайна они близнецы-братья.

                  Имхо это вопрос не столько конкретно о варах, или о стримах, или еще в какой-то конкретной фиче, а в общем вижене способа кодирования

                  • dernasherbrezon
                    /#19375332

                    Теперь я совсем потерялся… а как стримы помогут взять значение? Можно пример?

                    • olegchir
                      /#19376938

                      Ну, в данном случае — наверное, никак нельзя :-) Я просто попытался сказать, что можно изначально пытаться все писать в функциональном стиле (именно труЪ-функциональном), и тогда вопрос «какой там промежуточный тип» будет стоять сильно меньше. Не знаю, как это рассказать коротко, придумаю — напишу статью. Марк Симанн очень много написал размышлений, как превратить изначально не функциональный язык C# во что-то относительно похожее. К сожалению, опять же, применения этого на реальном проекте я показать не могу, это все пока только идеи.

    • olegchir
      /#19373802 / +6

      А можно как-нибудь протолкнуть запрет на неиспользование мозга? Вары не нужно пихать вообще везде — только там, где типы мешают

      • poxvuibr
        /#19373968 / +4

        А можно как-нибудь протолкнуть запрет на неиспользование мозга?

        Многие пытались, но запрещать фичи языка получается лучше. Ну, то есть результаты лучше, если запретить фичи языка, вместо того, чтобы запрещать неиспользование мозга.


        Вары не нужно пихать вообще везде — только там, где типы мешают

        С таким же успехом можно сказать, что goto не надо использовать везде, а надо использовать только там, где условные операторы мешают.

        • olegchir
          /#19374062 / +1

          Таааак. А goto то чем не угодил?

          • poxvuibr
            /#19374564 / +1

            Таааак. А goto то чем не угодил?

            Дейкстра целую статью на эту тему написал, не думаю, что у меня получится сказать лучше ))). Хотя конкретно в джаве goto это, конечно — добро. Благодаря ему урлы в джаве стали конструкцией языка, которые можно класть прямо в код.

            • F0iL
              /#19374622 / +2

              Благодаря ему урлы в джаве стали конструкцией языка, которые можно класть прямо в код.
              В C++ такая же фигня :)
              А в Java именнованные метки (label) могут использоваться не только с goto (насколько я помню, там идентификатор goto наоборот зарезервирован, но по факту не работает), а, например, с continue/break.

              • transcengopher
                /#19378886

                Можно, к примеру, делать break из проименованного if (вообще-то любого блока, но не суть).
                И единственное, почему это мало кто любит — это то, что конструкция выглядит непривычно. А выглядит она непривычно потому, что так мало кто делает. А делают так мало потому, что не любят. Ну и так далее. А началось с того, что это не любил Дийкстра. Весьма нерациональный подход, на мой вкус.

              • poxvuibr
                /#19379104

                насколько я помню, там идентификатор goto наоборот зарезервирован, но по факту не работает

                Вот я и говорю, в джаве goto — добро. Использовать его нельзя, поэтому он ничего не портит, а http ссылки в конструкции языка добавляет )))

            • buzzi888
              /#19376922

              В си это нормальный такой подход для каких-то системных штук. Весь линукс так выглядит, получается чисто и опрятно. Разве это не прекрасно:

              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
                /#19377190

                Выглядит то хорошо.


                Вот только defer из go для того же выглядит сильно лучше.

              • Whuthering
                /#19377994 / +1

                Как ни крутите, а это все-таки костыль из-за отсутствия в языке исключений.

        • dimakey
          /#19374388 / +1

          Многие пытались, но запрещать фичи языка получается лучше. Ну, то есть результаты лучше, если запретить фичи языка, вместо того, чтобы запрещать неиспользование мозга.

          Сплошную линию пересекают реже, если она из бетона и 40см в высоту?

          • olegchir
            /#19374446

            Если ты именно про высоту, то похоже, даже чаще :mrdestructoid:

      • leventov
        /#19374038 / +1

        С когнитивными искажениями невозможно бороться. Одно из них — когда человек только что написал метод, он кажется ему очевидным. Поэтому не пишут комментарии, и поэтому будут лепить var — "ну тут же очевидно какой тип, а выглядит короче и элегантнее".

        • Free_ze
          /#19374144 / +1

          Тем временем вывод параметров-типов у дженериков никого не смущает)

          • leventov
            /#19374332 / +1

            Мне особенно нравится, когда компилятор ругается на <> и люди просто стирают их оставляя сырой тип, зато все компилируется теперь :)

            • Free_ze
              /#19374358 / +1

              Разве компилятор ворнингами в ответ не бросается?

              • olegchir
                /#19374480

                В Идее при этом всё желто-коричневым перечёркнуто с сообщением, что звать что-то в сыром типе — плохо

                • leventov
                  /#19374620

                  А ещё там в rhs части — анонимный класс на 500 строк, и идея делает его весь жёлтым. Делая проблемы в самом классе неразличимыми. Очень удобно

      • UnclShura
        /#19374964 / +1

        Вары именно что нужно писать везде. Шарписты смотрят с недоумение на этот срач. Мы это прошли лет пять(?) назад. Код либо читается либо нет. Если код читается то вар только помогает. Ибо нефиг мусорить (масло м = новое масло() )! Если код не читается, то ему прописаны типы не помогут.

        • KevlarBeaver
          /#19375104 / +1

          В шарпе программисты многое прошли раньше джавы, которая появилась раньше шарпа. И теперь не нарадуюсь смотреть на то, как шарписты какую-то фичу давно съели и выкакали, а джависты — только ждут в новой версии.

        • vyatsek
          /#19382404

          Вары именно что нужно писать везде.
          Очень сильно утвереждение. Если var myData = new Data() — все понятно, но если же дерьмо вроде
          var data = GetData();
          var convertedData = GetConvertedData(data);
          return convertedData.ToString();

          return convertedData.ToString(); это паттерн бюррократии. Вместо того, чтобы зайти в нужный кабинет сразу, ты сначала по соседним помотайся методам и типам помотайся, а вот потом уже к нам.
          Часто я код смотрб в системе контроля версий или блокноте, потому что пока его склонируешь или откроешь в IDE уйдет вагон времени.

    • vazquez
      /#19373874 / +3

      мне кажется, стоит протолкнуть запрет на создание методов с 20+ переменными)

      • SemperPeritus
        /#19375142

        А заодно и запрет на создание функций с названием более, например, 50 символов тогда уж)

      • psFitz
        /#19377808

        А вы много таких методов видели? Я на джаве не писал, но на пхп такое видел разве что на каком-то вп, а в любом новом фреймворке такого нет, да и писать такого давно не приходилось

    • Ascar
      /#19374014 / +1

      Я конечно пишу на шарпе, но вроде как чисто при объявлении var не возможно использовать без присвоения чего либо ему.

      • KevlarBeaver
        /#19375108

        И в Java это точно так же. Потому что var — это не динамическая типизация, это вывод типа.

        • 0xd34df00d
          /#19376342

          Вывод типа не обязан зависеть только от rhs, вообще говоря. То, что он в джаве и шарпе настолько локальный, делает эту дихотомию несколько ложной.

    • jbaruch
      /#19374074

      Запрет не нужен, нужны giudelines когда использовать, а когда нет. Очевидно, на один borsch в Borsch borsch = new Borsch() это благо. Всё хорошо в меру и без фанатизма. И использование var, и запреты на него.

      • leventov
        /#19374118 / +2

        Я бы сказал, что это будет работать на пет- и соло-проектах, максимум — проектах на два-три человека. В больших проектах с "текучкой" разработчиков бороться с безответственностью невозможно никак кроме полного запрета каких-то вещей.

        • Free_ze
          /#19374194

          Стоит попробовать практиковать код-ревью.

          • leventov
            /#19374314 / +1

            Код-ревью обычно в три раза безответственнее чем само написание кода. Только в мире розовых пони бывают проекты на десять разработчиков, люди приходят и уходят каждые несколько месяцев, но при этом все одинаково ответственны и квалифицированны.

            • Free_ze
              /#19374440 / +1

              Вот что-что, а поспорить насчет оформления кода — это же любимый холивар программистов. Табы vs пробелы, няшное ручное форматирование vs автоформатеры, как лучше обозвать переменную… А в «чужую» бизнес-логику вникать — удел сильных. (=
              Но все же именно в «текучих» крупных командах и окупается даже бестолковое поверхностное код-ревью, против полного его отсутствия. Если есть какие-то правила, то следить за их исполнением должен кто-то уполномоченный таской, а не просто самый ответственный и по настроению достать соседа.

    • solver
      /#19374376 / +1

      Заодно расскажите, как в Java 11 создать методы без указания типов… очень интересно как вы это делаете.

    • zagayevskiy
      /#19380260

      Методы с 20+ объявленными переменными не станут проще только от того, что вы объявите их типы. Декомпозируйте.

    • LMSn
      /#19380398 / +1

      За редкими исключениями, весь мир дотнета пишет var везде, где можно. Абсолютно никого не смущает. Java, конечно, не C#, и вам виднее, и тем не менее чтению не мешает от слова совсем, даже наоборот. Если, конечно, вы не смотрите код из блокнота, но не знаю что может привести человека к такому в 2018.

      • leventov
        /#19380548 / +1

        Да это понятно, в Скале и Котлине эти вары тоже никого не смущают.


        Я едва ли не большую часть времени смотрю на код "из блокнота", который называется Гитхаб :)

      • Foror
        /#19380736

        >Абсолютно никого не смущает.
        Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?

        >что может привести человека к такому в 2018
        Чтение кода в интернете

        >тем не менее чтению не мешает
        Мешает, я уже начинаю на гитхабе сталкиваться с не читаемым джава кодом, где используют var. Приходиться материться, что мою джаву превращают в очередной джаваскрипт.

        Я согласен, что var можно использовать, но в очень ограниченных случаях. К сожалению это не все понимают. Очень много людей до сих пор считают, что важно количество написанных букв, а не скорость чтение написанного кода, пусть и частично избыточного. Прям вот экономят на буквах, как будто они в 70-х. И это очень печально, такой код потом очень тяжело поддерживать.

    • rjhdby
      /#19382240

      Мне кажется, что методы с 20+ объявленными переменными — это, в общем случае, повод не избавляться от var, а повод избавляться от таких методов.
      Опять таки, если это действительно такой уникальный метод, в котором просто необходимы 20+ переменных, то никто не мешает конкретно для этого метода расставить типы.

  4. saag
    /#19374260 / +1

    Java помрёт также как Cobol, вроде помер, а с другой стороны ещё как живой...

    • KevlarBeaver
      /#19375124

      Delphi ещё. Хороший инструмент для своего времени был.

  5. springimport
    /#19374458 / +1

    Когда читаю про java то приходит беспокойство о php. Ведь он в каком-то смысле ее наследник. Да еще и js постоянно набирает обороты.

    • olegchir
      /#19374664

      В PHP все плохо. Недавно как раз ключевые разрабочтики Zend Engine написали, что сбегают из конторы, которая оплачивает банкет и ищут нового работодателя

      • springimport
        /#19374682 / +2

        Помню что уходил основатель. Но если судить чисто по php то php 7.0 просто огромный шаг вместе с 7.1 и 7.2. Сложно сказать что дела идут плохо.

        • olegchir
          /#19374688

          ZendEngine — это и есть сам PHP. Если за него не будут платить (а про это намекали ушедший сооснователь и 2 ключевых разработчика), то PHP дальше чем сейчас никуда не уйдет. Ну то есть, это хорошо что теперь есть 7.2, но если теперь никогда не станет 8, то это фиаско

          • springimport
            /#19374710 / +1

            Посмотрим как будет. В принципе, лет на 5-7 этого хватит если совсем не будет развития.

            • KevlarBeaver
              /#19378830

              Хватит то оно хватит, но лично бы я линял с тонущего корабля одним из первых, и считайте меня кем хотите. Если технология загибается, то я считаю нецелесообразным заниматься ею целых пять лет, а потом впопыхах искать, на что бы перейти… лучше перейти сразу и пять лет в ней стать профессионалом.

              • anprs
                /#19379234

                То неловкое чувство, когда решил перейти от нативных языков к высокоуровневым, выбрав Java, и наткнулся на обсуждение этого поста…

  6. JuniorIL
    /#19374592 / +1

    Пользуясь случаем, расскажите пожалуйста, а уже есть альтернатива Spring Boot для (например) Scala? Чтобы раз — два и вот тебе готовый базовый REST проект, сильно много настраивать не надо, бойлерплейт не писать; потом, когда хочешь добавить ещё возможность, всё уже есть из коробки с готовыми настройками по умолчанию. Когда я вспоминаю старый Slick, мне тошнота подступает к горлу…

    • nehaev
      /#19374724

      Slick и новый не айс, но разве хибер лучше?

      • JuniorIL
        /#19374790

        Когда он стоит за Spring Data JPA замечателен. Просто определи интерфейс и всё сгенерируется само.

        • nehaev
          /#19374972

          "Магия" интерфейсов хорошо работает для простых кейсов, а чуть что посложнее — пиши SQL в аннотации. Переодически приходится что-то подкручивать напрямую через EntityManager.


          Плюс Spring Data JPA же не изолирует от написания энтитей с кучей аннотаций и кучей бойлерплейта в виде с геттеров, сеттеров, equals/hashcode. Это конечно тоже решают с помощью Lombok. Выходит, что сликом на скале можно пользоваться самим по себе, а хибером — нет.

          • JuniorIL
            /#19375198

            Так замечательно же, когда будет сложнее — буду писать сам. А вот в Slick 2.x каждый запрос надо было писать ручками, через боль и слёзы.
            И Энтити с кучей анотаций описывают связи и взаимоотношения, которые помогают разобраться в структуре проекта, что нельзя сказать про запросы.

            Дисклеймер, я очень люблю Скалу, но очень не люблю ту экосистему, с которой я работал в 2015. Это чтобы вы не думали, что я из лагеря староверов :-)

            • nehaev
              /#19375840

              А, понятно. Я приобщился к слику в 2017, не знаю как он выглядел во времена 2.х. Сейчас запросы пишутся через специальный type-safe DSL, что имхо очень удобно. У современного слика проблемы с поддержкой, пару раз натыкался на баги, которые открыты и не пофикшены уже больше года.


              Но опять-таки, по моему мнению, слик и хибер — это как небо и земля, даже если брать хибер со всеми спринговыми нашлепками.

    • akryukov
      /#19375792

      Есть Play framework, который позиционируется для веб-приложений. Можно еще извернуться REST-API на Spark сделать.

  7. eskander_service
    /#19374650 / +4

    Спасибо автору за статью.
    P.S. Дорогие котлинисты и страдающие от «УЖАСЁВ))» ООП, Java никогда не умрёт. Не нравится, не используйте этот язык.

    • makdoc
      /#19375024 / -1

      Я с вами полностью согласен.

    • snuk182
      /#19375044 / +1

      На Java написано (и пишется до сих пор) до черта финтехсофта, как минимум потому и не умрет. Однако Котлин — все же серьезная заявка на кусок JVM-пирога.

      • zirix
        /#19375878

        На Java написано (и пишется до сих пор) до черта финтехсофта

        Я даже больше скажу: весь «энтерпрайз» сидит на java и никуда не хочет с нее уходить.
        А если и захочет, то альтернатив java особо и нет (у компаний, особенно больших, чуть другие требования к языку и экосистеме, чем у пользователей). Разве что C#, но у него кроме плюсов есть и недостатки.

        Очень странно видеть рассуждения о смери активно используемого языка и его сравнения с легаси языками типа cobol и delphi.

      • zagayevskiy
        /#19380302

        Котлин интероперабелен с джавой в обе стороны, так что можно постепенно мигрировать проект, было бы желание.

        • Foror
          /#19380668

          >Котлин интероперабелен с джавой в обе стороны, так что можно постепенно мигрировать проект,
          Для молодежи, которая дальше пет проектов не вылезала. А в нормальном проекте по голове постучат за такие идеи.

      • Foror
        /#19380662

        >Котлин — все же серьезная заявка на кусок JVM-пирога
        Сомнительно. Про груви так же говорили и где он теперь? Для джавы готовят очень много вкусных фич, после которых котлин станет не нужным. Он сейчас не особо нужен, но молодёжь клюёт на рекламу. Еще бы нет, его в IDEA (46% рынка IDE) даже в контекстное меню встроили, причём во многих местах он там отсвечивает.

    • ruslanys
      /#19375188

      А что с Kotlin не так?(

      • easty
        /#19375484

        • Что вы скажите о Котлин?
        • Котлин шмотлин
        • Вы приняты!!!

  8. vitrolov
    /#19375624 / +1

    Если кто-то спросит, можно ли программировать на чём-то кроме IntelliJ IDEA… похоже, иногда можно


    Улыбнуло. Учитывая, что James Gosling написал в твиттер, что он фанат netbeans 10, но как говорится из колхоза видней, как правильно Джаву приготовить.
    ?

    • AlexTheLost
      /#19378100 / +1

      Это всё звучит забавно — про споры о IDE для Java. Без которого на языке писать мягко говоря тяжко.
      С учётом того что есть языки которые позволяют писать код без IDE и продуктивноться не падет.)
      Хорошо бы разработчики одного языка с ними познакомились, бывает если выйти за пределы совего "села" всё привычное уже не кажется каким хорошим. :)

      • akryukov
        /#19378402

        Любопытно что за язык, которому IDE не добавила бы продуктивности.

  9. DieSlogan
    /#19378782 / +1

    Есть просто огромная куча софта, которая написана на Java и которая еще будет поддерживаться кучу лет. С этих проектов уходят люди, требуются новые и новые. Поэтому, Java будет еще долго актуальным языком.
    Вопрос в том, будут ли проекты, на которые зовут программистов, чем-то новым или это будет допиливание модулей на имеющуюся систему?
    Сложно судить, лично я не стану делать новый проект на Java. Если уж на то пошло и JVM обязателен, то я сделаю его на Kotlin.
    И не последнюю роль тут играет Oracle с её людоедской нынешней репутацией.

    • zagayevskiy
      /#19380306

      Прикол в том, что и новые фичи в своем старом проекте на джаве вы можете пилить на Котлине;)

  10. Foror
    /#19380778 / -1

    Умрёт, когда нормальный ЯП запилят, сейчас на рынке одни выскочки со смузи, которые тяжелее члена, ничего в руках не держали. Живут в своём выдуманном мирке, не понимая требований «работников на земле». Но в целом, старички с легаси продолжают держать рынок. И джава, даже со своим легаси, на всём этом фоне еще очень приятно смотрится.