Comments 133
Java как язык лично для меня умер, и я теперь понимаю что всегда его ненавидел. Уродливый и громоздкий. А вот JVM жива и процветает, под неё огромное кол-во прекрасный языков.
Собственно если уходить от Java то в отрасле должен начаться фундаментальный сдвиг от ужаса называемого ООП, потому что все более менее популярные на сегодня языки не так уж и далеки от Java.
так, а ООП то чем не угодил?
В 2018 году на хабре можно спрашивать "чья версия ООП не угодила ?". Теряюсь постоянно чей ООП более правильный.
Однако же оказалось, что ООП таит в себе ужасы.
Слабые умы не могут осилить ООП — это основной недостаток ООП
Или же — слабые умы не могут понять что оно не нужно и продолжают верить своим кумирам продвигавшим ООП?) И писать пухлые от лишнего кода проекты.
И посоветуйте язык заодно.
Уровень невежества поражает.)
Scala/Kotlin/..., выбирайте что по душе.
Тезис прост, объект в 99% задач не нужен — то есть объединение состояния + действия. У вас или данные или действия. Чем проще тем лучше.
(Java вроде для Веба и Андроидов используется? Что теперь на них?)
Когда перейдем на Java 11, я попробую в своих проектах протолкнуть запрет на var. Мне кажется это одна из существенных вещей, которые делают Scala и Kotlin сложными для чтения: методы с двадцатью+ объявленными переменными, без единого типа.
По идеи в Idea так же будет.
В Rider нет подсветки, но есть тултип.
Код далеко не всегда просматривается в среде. А даже когда в среде, не удобно гонять курсор повсюду, чтобы увидеть типы, и кешировать их в мозгу, вместо того, чтобы просто их видеть все.
Вот честно, не понимаю, кому мешают эти типы написанные. Код читается в 10 раз чаще, чем пишется.
У нас еще, кстати, статические импорты запрещены, и это хорошо.
А как такое хозяйство ревьюить, чтобы не надо было выкачивать ветку из VCS локально, переключаться на нее в идее, и раскуривать, в итоге тратя столько же времени, сколько автор кода? "LGTM"?
Но тут же возникает вопрос, как все-таки отдебажить эту радость. Вот например, есть у тебя стрим на двадцать хопов, и что-то посередине считается не так очевидно, как кажется. Что дальше делать? Или например, хочется закэшировать какой-то промежуточный результат в пайплайне, чтобы два раза не считать. Вот как раз и поползли переменные, которые вроде бы и есть (потому что пришлось), но и знать о них ты ничего не хочешь.
Ну это так, для примера. Надо подумать. Наверное, lany про это лучше скажет)
Ну а как ты читаешь код на каком-нибудль кложуре или хашкеле? Промежуточные представления могут быть совершенно дичайшими, но часть магии именно в том, что их никто не сохраняет в промежуточные переменные и не выделяет в отдельные переменные-сущности. «Не сломается того, чего нет». Грубо говоря, у тебя не сломается счетчик цикла, если нет циклов со счетчиком. Не сломаются переменные, если у тебя нет переменных (привет, Ерланг). Не сломается понимание типов, если ты их не видишь.
А кто сказал, что читать код на Clojure и Хаскеле — проще, чем на Java? Очевидно, что сложнее, это если не полностью write-only языки, то приближаются к ним. И может быть это та причина, по которой на большие долгоиграющие проекты эти языки редко берут?
Кстати, хотя читать Clojure и Хаскель сложнее, чем Java, я не спорю что они при этом гораздо безопаснее. Одно из другого не следует.
Признак того, что пора делать POJO.
Внимание вопрос. Что такое, по вашему мнению, POJO?
Только записать стримами, чтобы не пришлось проверять на null, итп.
Мне очень нравится вот этот чувак: blog.ploeh.dk
У него есть очень стройная теория по применению функционального подхода к C#. Он берет какие-то приемы из Haskell, адаптирует на F#, и потом рассуждает, как это можно применить в C#, несмотря на то, что C# не имеет всяких продвинутых фичей.
В качестве примера рассуждений, есть его доклад на прошлом DotNext 2017 Moscow про Dependency Injection. Ну да, C# это не совсем Java, но с точки зрения общего дизайна они близнецы-братья.
Имхо это вопрос не столько конкретно о варах, или о стримах, или еще в какой-то конкретной фиче, а в общем вижене способа кодирования
А можно как-нибудь протолкнуть запрет на неиспользование мозга?
Многие пытались, но запрещать фичи языка получается лучше. Ну, то есть результаты лучше, если запретить фичи языка, вместо того, чтобы запрещать неиспользование мозга.
Вары не нужно пихать вообще везде — только там, где типы мешают
С таким же успехом можно сказать, что goto не надо использовать везде, а надо использовать только там, где условные операторы мешают.
Таааак. А goto то чем не угодил?
Дейкстра целую статью на эту тему написал, не думаю, что у меня получится сказать лучше ))). Хотя конкретно в джаве goto это, конечно — добро. Благодаря ему урлы в джаве стали конструкцией языка, которые можно класть прямо в код.
И единственное, почему это мало кто любит — это то, что конструкция выглядит непривычно. А выглядит она непривычно потому, что так мало кто делает. А делают так мало потому, что не любят. Ну и так далее. А началось с того, что это не любил Дийкстра. Весьма нерациональный подход, на мой вкус.
насколько я помню, там идентификатор goto наоборот зарезервирован, но по факту не работает
Вот я и говорю, в джаве goto — добро. Использовать его нельзя, поэтому он ничего не портит, а http ссылки в конструкции языка добавляет )))
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;
Многие пытались, но запрещать фичи языка получается лучше. Ну, то есть результаты лучше, если запретить фичи языка, вместо того, чтобы запрещать неиспользование мозга.
Сплошную линию пересекают реже, если она из бетона и 40см в высоту?
С когнитивными искажениями невозможно бороться. Одно из них — когда человек только что написал метод, он кажется ему очевидным. Поэтому не пишут комментарии, и поэтому будут лепить var — "ну тут же очевидно какой тип, а выглядит короче и элегантнее".
Вары именно что нужно писать везде. Шарписты смотрят с недоумение на этот срач. Мы это прошли лет пять(?) назад. Код либо читается либо нет. Если код читается то вар только помогает. Ибо нефиг мусорить (масло м = новое масло() )! Если код не читается, то ему прописаны типы не помогут.
Вары именно что нужно писать везде.Очень сильно утвереждение. Если
var myData = new Data() — все понятно, но если же дерьмо вроде var data = GetData();
var convertedData = GetConvertedData(data);
return convertedData.ToString();
return convertedData.ToString(); это паттерн бюррократии. Вместо того, чтобы зайти в нужный кабинет сразу, ты сначала по соседним помотайся методам и типам помотайся, а вот потом уже к нам.Часто я код смотрб в системе контроля версий или блокноте, потому что пока его склонируешь или откроешь в IDE уйдет вагон времени.
Запрет не нужен, нужны giudelines когда использовать, а когда нет. Очевидно, на один borsch в Borsch borsch = new Borsch() это благо. Всё хорошо в меру и без фанатизма. И использование var, и запреты на него.
Я бы сказал, что это будет работать на пет- и соло-проектах, максимум — проектах на два-три человека. В больших проектах с "текучкой" разработчиков бороться с безответственностью невозможно никак кроме полного запрета каких-то вещей.
Код-ревью обычно в три раза безответственнее чем само написание кода. Только в мире розовых пони бывают проекты на десять разработчиков, люди приходят и уходят каждые несколько месяцев, но при этом все одинаково ответственны и квалифицированны.
Но все же именно в «текучих» крупных командах и окупается даже бестолковое поверхностное код-ревью, против полного его отсутствия. Если есть какие-то правила, то следить за их исполнением должен кто-то уполномоченный таской, а не просто самый ответственный и по настроению
Методы с 20+ объявленными переменными не станут проще только от того, что вы объявите их типы. Декомпозируйте.
Да это понятно, в Скале и Котлине эти вары тоже никого не смущают.
Я едва ли не большую часть времени смотрю на код "из блокнота", который называется Гитхаб :)
Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?
>что может привести человека к такому в 2018
Чтение кода в интернете
>тем не менее чтению не мешает
Мешает, я уже начинаю на гитхабе сталкиваться с не читаемым джава кодом, где используют var. Приходиться материться, что мою джаву превращают в очередной джаваскрипт.
Я согласен, что var можно использовать, но в очень ограниченных случаях. К сожалению это не все понимают. Очень много людей до сих пор считают, что важно количество написанных букв, а не скорость чтение написанного кода, пусть и частично избыточного. Прям вот экономят на буквах, как будто они в 70-х. И это очень печально, такой код потом очень тяжело поддерживать.
Опять таки, если это действительно такой уникальный метод, в котором просто необходимы 20+ переменных, то никто не мешает конкретно для этого метода расставить типы.
Java помрёт также как Cobol, вроде помер, а с другой стороны ещё как живой...
Slick и новый не айс, но разве хибер лучше?
"Магия" интерфейсов хорошо работает для простых кейсов, а чуть что посложнее — пиши SQL в аннотации. Переодически приходится что-то подкручивать напрямую через EntityManager.
Плюс Spring Data JPA же не изолирует от написания энтитей с кучей аннотаций и кучей бойлерплейта в виде с геттеров, сеттеров, equals/hashcode. Это конечно тоже решают с помощью Lombok. Выходит, что сликом на скале можно пользоваться самим по себе, а хибером — нет.
И Энтити с кучей анотаций описывают связи и взаимоотношения, которые помогают разобраться в структуре проекта, что нельзя сказать про запросы.
Дисклеймер, я очень люблю Скалу, но очень не люблю ту экосистему, с которой я работал в 2015. Это чтобы вы не думали, что я из лагеря староверов :-)
А, понятно. Я приобщился к слику в 2017, не знаю как он выглядел во времена 2.х. Сейчас запросы пишутся через специальный type-safe DSL, что имхо очень удобно. У современного слика проблемы с поддержкой, пару раз натыкался на баги, которые открыты и не пофикшены уже больше года.
Но опять-таки, по моему мнению, слик и хибер — это как небо и земля, даже если брать хибер со всеми спринговыми нашлепками.
Есть Play framework, который позиционируется для веб-приложений. Можно еще извернуться REST-API на Spark сделать.
P.S. Дорогие котлинисты и страдающие от «УЖАСЁВ))» ООП, Java никогда не умрёт. Не нравится, не используйте этот язык.
Я с вами полностью согласен.
Котлин интероперабелен с джавой в обе стороны, так что можно постепенно мигрировать проект, было бы желание.
Сомнительно. Про груви так же говорили и где он теперь? Для джавы готовят очень много вкусных фич, после которых котлин станет не нужным. Он сейчас не особо нужен, но молодёжь клюёт на рекламу. Еще бы нет, его в IDEA (46% рынка IDE) даже в контекстное меню встроили, причём во многих местах он там отсвечивает.
А что с Kotlin не так?(
Если кто-то спросит, можно ли программировать на чём-то кроме IntelliJ IDEA… похоже, иногда можно
Улыбнуло. Учитывая, что James Gosling написал в твиттер, что он фанат netbeans 10, но как говорится из колхоза видней, как правильно Джаву приготовить.
А Eclipse уже все забыли?(
Это всё звучит забавно — про споры о IDE для Java. Без которого на языке писать мягко говоря тяжко.
С учётом того что есть языки которые позволяют писать код без IDE и продуктивноться не падет.)
Хорошо бы разработчики одного языка с ними познакомились, бывает если выйти за пределы совего "села" всё привычное уже не кажется каким хорошим. :)
Вопрос в том, будут ли проекты, на которые зовут программистов, чем-то новым или это будет допиливание модулей на имеющуюся систему?
Сложно судить, лично я не стану делать новый проект на Java. Если уж на то пошло и JVM обязателен, то я сделаю его на Kotlin.
И не последнюю роль тут играет Oracle с её людоедской нынешней репутацией.
Когда Java наконец помрёт, что с этим делать и что будет с JPoint