По поводу юзабилити rutube, я каждый день пользуюсь вашим приложением на Smart TV (платформа Samsung Tizen) и у меня такое ощущение, что создатели сервиса сами своим приложением не пользуются).
Чтобы найти каналы, на которые я подписан - нужно кучу кнопок нажать (меню, подменю). И каждый раз при запуске ранее просмотренного видео этот вопрос "Вы хотите продолжить просмотр или начать с начала?". Очень нужна опция при старте приложения продолжить просмотр последнего видео.
У ВК Видео приложение для смарт тв удобнее. Хотя мне больше импонирует именно ваш подход, что вы структурно копируете YouTube (вплоть до названий ссылок), а не пытаетесь свои собственные абстракции вводить.
Я бы вам оставил подробную обратную связь в приложении, но не нашёл такой опции)
Я нисколько не пытаюсь принизить значимость мультиплатформы, но мне особо не приходилось слышать об успешных кейсах ее применения на практике. Буду признателен, если поделитесь своим. Да и на бэке Котлин до сих пор внедряется не так активно, как хотелось бы.
Возврат значений из управляющих конструкций - да, это удобно. Однако я не назвал бы это киллер фичой. Особенно если вспомнить, что это увеличивает количество возможных стилей написания методов. Скорее, приятный бонус. Мультиплатформа концептуально да, но она как будто не взлетела(
Большое кол-во исключений в сигнатуре может быть в сервисных методах самого верхнего уровня, т.к. они могут объединять все исключения с более низких уровней. Но мы конечно всегда можем просто написать 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 я бы отметил ещё разделение коллекций на изменяемые и неизменяемые.
Да, в таком кейсе, когда не знаешь точно, что должно получиться на выходе - это хорошее подспорье. А когда знаешь - проще контролировать ИИ-модель на каждом этапе.
По поводу юзабилити rutube, я каждый день пользуюсь вашим приложением на Smart TV (платформа Samsung Tizen) и у меня такое ощущение, что создатели сервиса сами своим приложением не пользуются).
Чтобы найти каналы, на которые я подписан - нужно кучу кнопок нажать (меню, подменю). И каждый раз при запуске ранее просмотренного видео этот вопрос "Вы хотите продолжить просмотр или начать с начала?". Очень нужна опция при старте приложения продолжить просмотр последнего видео.
У ВК Видео приложение для смарт тв удобнее. Хотя мне больше импонирует именно ваш подход, что вы структурно копируете YouTube (вплоть до названий ссылок), а не пытаетесь свои собственные абстракции вводить.
Я бы вам оставил подробную обратную связь в приложении, но не нашёл такой опции)
Я нисколько не пытаюсь принизить значимость мультиплатформы, но мне особо не приходилось слышать об успешных кейсах ее применения на практике. Буду признателен, если поделитесь своим. Да и на бэке Котлин до сих пор внедряется не так активно, как хотелось бы.
Возврат значений из управляющих конструкций - да, это удобно. Однако я не назвал бы это киллер фичой. Особенно если вспомнить, что это увеличивает количество возможных стилей написания методов. Скорее, приятный бонус. Мультиплатформа концептуально да, но она как будто не взлетела(
Большое кол-во исключений в сигнатуре может быть в сервисных методах самого верхнего уровня, т.к. они могут объединять все исключения с более низких уровней. Но мы конечно всегда можем просто написать 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))
Да, в таком кейсе, когда не знаешь точно, что должно получиться на выходе - это хорошее подспорье. А когда знаешь - проще контролировать ИИ-модель на каждом этапе.