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

Звучит так, будто вы "подогнали" симуляцию под заранее заготовленный вывод.

P.S. Интересное объяснение парадокса Ферми даёт Лю Цысинь в своей книге "Тёмный Лес".

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

У ВК Видео приложение для смарт тв удобнее. Хотя мне больше импонирует именно ваш подход, что вы структурно копируете YouTube (вплоть до названий ссылок), а не пытаетесь свои собственные абстракции вводить.

Я бы вам оставил подробную обратную связь в приложении, но не нашёл такой опции)

Цикл for очень удобен при "низкоуровневом", алгоритмическом программировании. Особенно когда у нас кастомный алгоритм обхода коллекции, а не банальный инкремент. Но в типовых приложениях чаще всего мы работаем с коллекциями и чаще всего перебираем элементы по очереди от начала до конца. Поэтому видимо авторы и решили оставить только for-each.

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, значит метод декларирует, что он не собирается менять этот список.