Большое кол-во исключений в сигнатуре может быть в сервисных методах самого верхнего уровня, т.к. они могут объединять все исключения с более низких уровней. Но мы конечно всегда можем просто написать throws Exception и не париться)
По поводу интеропа с java, мы стараемся у себя в проектах не смешивать java и kotlin. То есть если пишем на Kotlin, то все исходники должны быть на Kotlin (в том числе юзаем build.gradle.kts вместо грувишного buld.gradle). Но при этом мы активно используем Spring и уже знаем, где могут возникать null при вызове стандартных компонентов, а где не могут. На самом деле, если конфиг правильный, то в большинстве случаев у нас будет создан какой-то инстанс. А если нет - мы узнаем об этом ещё при старте приложения.
Спасибо за дополнение! В Kotlin работа с лямбдами действительно удобна. Однако ими тоже не следует злоупотреблять: большое количество вложенных друг в друга лямбд порождают "лесенку" в коде.
Цикл for очень удобен при "низкоуровневом", алгоритмическом программировании. Особенно когда у нас кастомный алгоритм обхода коллекции, а не банальный инкремент. Но в типовых приложениях чаще всего мы работаем с коллекциями и чаще всего перебираем элементы по очереди от начала до конца. Поэтому видимо авторы и решили оставить только for-each.
Полностью согласен! Я хотел про это написать и действительно забыл) Однако тут есть и обратная сторона медали, как и в случае с возвращаемым значением: с точки зрения единообразия в команде надо договориться, в каких случаях делаем именованные параметры, в каких - не делаем. Или всегда делаем.
Операторы очень выручают при работе со стандартной библиотекой. Я могу использовать математические операторы для работы с числами BigDecimal:
val a = BigDecimal("100.00")
val b = BigDecimal("200.00")
val c = BigDecimal("300.00")
val sum = a * b + c
// против Java-варианта:
BigDecimal sum = a.multiply(b).plus(c);
Согласитесь, что мне не нужно каждый раз лезть в реализацию стандартных математических действий. Но при этом возможность записи всяких формул в естественном виде - это удобно.
То же самое я могу сделать для своего собственного класса, например, для сложения матриц.
При этом в котлине я не могу определять вообще произвольные комбинации символов как операторы. А только фиксированный набор стандартных операторов.
А вот и нет! Мне пришло. Сижу периодически на платформе codingame когда делать нечего. Иногда там встречается соревнование "кто короче напишет" - подсчёт идёт в символах. Удаление всех пробелов очень спасает, иногда даже короче получается, чем у некоторых питонистов. Так что это определённо важная фича, а вы её назвали бесполезной...
Данную статью я писал точки зрения промышленной разработки больших корпоративных проектов (основная ниша java и kotlin). Там всё-таки код в одну строку не пишут.
А почему нет? Это не плюс на самом деле... Это даже скорее минус, что ты не можешь видеть, от чего ты наследуешься: от класса или метода.
По поводу наследования, в процессе agile-разработки очень часто возникает ситуация, что интерфейс превращается в абстрактный класс или наоборот. Вот эти все extends и implements в таком случае особой ценности не несут.
thymeleaf на минималках какой-то... Польза от того сомнительная, но окэй.
Как человек, активно использующий thymeleaf в некоторых проектах, могу вас заверить, что котлиновская интерполяция строк поприятнее, т.к. она мощнее.
Товарищ, вы боритесь менее, чем за 1 строку кода! Остановитесь! Разработчику полезно знать, где вообще подобный эксепшон в перспективе может появиться.
В том-то и дело, что не одну) Очень часто вереница checked-эксепшенов занимает несколько строк. Особенно при использовании автоформатирования.
Если мы хотим выстрелить себе в ногу, то никто нам не может помешать)
Такие конструкции это всё-таки плохой код (мягко говоря), потому что мы нарушаем инкапсуляцию и полиморфизм. Тут речь больше про контракт: если я вижу, что метод принимает read-only list, значит метод декларирует, что он не собирается менять этот список.
На бекенде он тоже используется. Когда только Котлин появился, он закрыл прям заметные проблемы java. Сейчас в java появились аналогичные фичи и в этом немалая заслуга Котлин) а вообще наряду с контролем за null я бы отметил ещё разделение коллекций на изменяемые и неизменяемые.
Да, в таком кейсе, когда не знаешь точно, что должно получиться на выходе - это хорошее подспорье. А когда знаешь - проще контролировать ИИ-модель на каждом этапе.
Ревьюить будет разработчик. Пока что ещё рано из этой цепочки исключать человека, ведь только он знает, что именно нужно делать. А разработчик ещё примерно понимает, как это сделать.
Большое кол-во исключений в сигнатуре может быть в сервисных методах самого верхнего уровня, т.к. они могут объединять все исключения с более низких уровней. Но мы конечно всегда можем просто написать throws Exception и не париться)
По поводу интеропа с java, мы стараемся у себя в проектах не смешивать java и kotlin. То есть если пишем на Kotlin, то все исходники должны быть на Kotlin (в том числе юзаем build.gradle.kts вместо грувишного buld.gradle). Но при этом мы активно используем Spring и уже знаем, где могут возникать null при вызове стандартных компонентов, а где не могут. На самом деле, если конфиг правильный, то в большинстве случаев у нас будет создан какой-то инстанс. А если нет - мы узнаем об этом ещё при старте приложения.
Спасибо за дополнение! В Kotlin работа с лямбдами действительно удобна. Однако ими тоже не следует злоупотреблять: большое количество вложенных друг в друга лямбд порождают "лесенку" в коде.
Цикл for очень удобен при "низкоуровневом", алгоритмическом программировании. Особенно когда у нас кастомный алгоритм обхода коллекции, а не банальный инкремент. Но в типовых приложениях чаще всего мы работаем с коллекциями и чаще всего перебираем элементы по очереди от начала до конца. Поэтому видимо авторы и решили оставить только for-each.
Полностью согласен! Я хотел про это написать и действительно забыл) Однако тут есть и обратная сторона медали, как и в случае с возвращаемым значением: с точки зрения единообразия в команде надо договориться, в каких случаях делаем именованные параметры, в каких - не делаем. Или всегда делаем.
Операторы очень выручают при работе со стандартной библиотекой. Я могу использовать математические операторы для работы с числами BigDecimal:
Согласитесь, что мне не нужно каждый раз лезть в реализацию стандартных математических действий. Но при этом возможность записи всяких формул в естественном виде - это удобно.
То же самое я могу сделать для своего собственного класса, например, для сложения матриц.
При этом в котлине я не могу определять вообще произвольные комбинации символов как операторы. А только фиксированный набор стандартных операторов.
Данную статью я писал точки зрения промышленной разработки больших корпоративных проектов (основная ниша java и kotlin). Там всё-таки код в одну строку не пишут.
По поводу наследования, в процессе agile-разработки очень часто возникает ситуация, что интерфейс превращается в абстрактный класс или наоборот. Вот эти все extends и implements в таком случае особой ценности не несут.
Как человек, активно использующий thymeleaf в некоторых проектах, могу вас заверить, что котлиновская интерполяция строк поприятнее, т.к. она мощнее.
В том-то и дело, что не одну) Очень часто вереница checked-эксепшенов занимает несколько строк. Особенно при использовании автоформатирования.
Если мы хотим выстрелить себе в ногу, то никто нам не может помешать)
Такие конструкции это всё-таки плохой код (мягко говоря), потому что мы нарушаем инкапсуляцию и полиморфизм. Тут речь больше про контракт: если я вижу, что метод принимает read-only list, значит метод декларирует, что он не собирается менять этот список.
В целом понимаю вашу точку зрения. И хочу дополнить, что Kotlin на Android взлетел благодаря поддержке со стороны Google.
Потому что я отталкивался от Котлин. Но можно перечислить.
На бекенде он тоже используется. Когда только Котлин появился, он закрыл прям заметные проблемы java. Сейчас в java появились аналогичные фичи и в этом немалая заслуга Котлин) а вообще наряду с контролем за null я бы отметил ещё разделение коллекций на изменяемые и неизменяемые.
Да, концептуально это тоже заметный плюс, но по факту это не синтаксис, а стандартная библиотека.
В java да, будет npe
Да, существенных недостатков по большому счету нет)
Согласен, это тоже можно было бы добавить, но я хотел прежде всего сравнивать с аналогами в java.
Так же как и с Java. GigaIDE, openIDE, community edition.
Скорее на PHP стали писать как на Java))
Да, в таком кейсе, когда не знаешь точно, что должно получиться на выходе - это хорошее подспорье. А когда знаешь - проще контролировать ИИ-модель на каждом этапе.
с вавилонской башней всё плохо кончилось как раз потому, что тогда у строителей не оказалось переводчиков)
Согласен. Но mvp без правильного маркетинга и раньше было обречено на провал.
Ревьюить будет разработчик. Пока что ещё рано из этой цепочки исключать человека, ведь только он знает, что именно нужно делать. А разработчик ещё примерно понимает, как это сделать.