java после C++

неудобство в более медленном наборе и уменьшении читабельности кода, а так не в чём. автодополнение IDE здесь мало помогает. а ещё, перегруженные операторы лучше кладутся на шаблонный код. ах да, в яве и шаблонов-то нормальных нет.

Дело привычки. Мне первый код кажется таким же читабельным, как и второй. И я точно знаю, что в первом случае где-то есть геттеры и сеттеры, а во втором ещё надо поискать, перегружались операторы или нет.

Читабельность кода не уменьшается. А медленный набор — может оно и медленне, но поскольку доля именно набора кода в процессе разработки невелика, экономия будет мизерной. Я больше времени на чаепития трачу, чем получу выгоды от этого.

А вот насчёт шаблонов ничего не скажу, я с крестами не работал и вообще не в курсе что это такое.

Дело привычки.

да, привыкнуть-то можно и тухлятину (https://ru.wikipedia.org/wiki/Копальхен) есть. но существуют определённые ограничения, с которыми бороться не поможет даже сила привычки, например, скорость чтения текста, которая, конечно, у каждого своя, но, в любом случае, не безгранична. уже хотя бы поэтому, первый код заведомо менее читабельней второго, но есть и другие причины. эргономика, сэр.

И я точно знаю, что в первом случае где-то есть геттеры и сеттеры, а во втором ещё надо поискать, перегружались операторы или нет.

на самом деле, не знаете. в том-то и дело, что в явокоде геттеры и сеттеры часто ставят на каждый чих, надо оно или нет. в куте (в самой библиотеке), кстати, тоже, что раздражает.

первый код заведомо менее читабельней второго

Нет. Говорю как человек, который читает код на разных языках (но не на сях, указатели я читать не умею).

в том-то и дело, что в явокоде геттеры и сеттеры часто ставят на каждый чих, надо оно или нет.

Ну если их ставят, значит они есть? Я не говорил об их необходимости (хотя она обусловлена инкапсуляцией, тут спорить бессмысленно в рамках ООП). Если ты видишь сеттер, значит он где-то определён. Нет такого понятия как сеттер по умолчанию, который генерится компилятором автоматически.

Читабельность кода не уменьшается.

[] имеет вполне определённый, очевидный смысл (для человека, знающего соотв. ЯП, разумеется). а вот get(j) хрен его знает, что делает, в общем случае. к тому же, [] — заметны в тексте, а get(j) — нет.

А вот насчёт шаблонов ничего не скажу, я с крестами не работал и вообще не в курсе что это такое.

обобщённое программирование. говорят, дженерики в ява — примитивная версия шаблонов.

Говорю как человек, который читает код на разных языках

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

Ну если их ставят, значит они есть?

есть, но они могут ничего не делать, кроме как тупо присваивать переменной значение

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

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

[] имеет вполне определённый, очевидный смысл (для человека, знающего соотв. ЯП, разумеется). а вот get(j) хрен его знает, что делает, в общем случае. к тому же, [] — заметны в тексте, а get(j) — нет.

Не понимаю, в чём разница очевидности. [] в том же питоне вызывает внутренний метод, который точно так же можно определить как тебе угодно. И get() можно определить как тебе угодно. Но в общем случае они достают элемент.

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

Если я этого не замечаю, то в чём состоит читабельность? В том что если я попробую прочитать 9000 строк кода подряд, в первом случае я это следаю на 0.1 секунды быстрее?

есть, но они могут ничего не делать, кроме как тупо присваивать переменной значение

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

в ява исходят из того, что «вдруг потребуется добавить некий функционал к доступу к переменной».

Не в ява, а в ООП. То, что в некоторых проектах на каком-то языке могут на это забивать, не делает подобные действия стандартом.

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

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

Это неправда. Учебник по матану можно читать по полчаса каждую страницу, перечитывая её по 5 раз, чтобы понять, о чём там пишется, хотя текст более краткий. А приключенческий рассказ можно читать через строчку по 100 страниц в час, хотя текст длинней.

Всё зависит от того, сколько смысловой нагрузки вложено в этот текст. В случае Java код почти всегда просто и понятен, размышлять там не о чём. Если видим == значит сравнение указателей или примитивных значений. Если видем .xxx( значит это вызов метода. И т.д. А если у нас в игру вступает перегрузка операторов, всякие сахары для свойств, то a.b = c может означать присваивание поля, может означать вызов перегруженного оператора = у объекта b, может означать вызов сеттера у объекта a. Может быть ещё что-нибудь может означать. И чтобы понимать код, надо смотреть все эти детали, надо держать их в голове.

При этом я не говорю, что этот подход плох. Нужна золотая середина.

Твои претензии скорее синтаксического характера. Буть выше этого. Вся это философия не больше чем код-стайл. Просто следуй и сосредоточься на бизнес-логике и архитектуре.

Геттеры и сеттеры спасут от опечатки и случайной ошибки.

Я немного о другом.

Если программист допускает ТАКИЕ ошибки в коде, который ушел в репозиторий, то, либо это начинающий студент чей труд увидит лишь преподаватель, либо «программиста» надо из профессии гнать на мороз улицу мести.