Парадокс Ферми - интересная тема. Я сам периодически размышляю над этим. Однако несколько смущает то, что вы написали в начале:
Основная задача статьи — продемонстрировать, что даже если появление разумной жизни не является редким событием, её целенаправленный поиск может оставаться безрезультатным многие тысячелетия.
Звучит так, будто вы "подогнали" симуляцию под заранее заготовленный вывод.
P.S. Интересное объяснение парадокса Ферми даёт Лю Цысинь в своей книге "Тёмный Лес".
По поводу юзабилити 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 я бы отметил ещё разделение коллекций на изменяемые и неизменяемые.
Парадокс Ферми - интересная тема. Я сам периодически размышляю над этим. Однако несколько смущает то, что вы написали в начале:
Звучит так, будто вы "подогнали" симуляцию под заранее заготовленный вывод.
P.S. Интересное объяснение парадокса Ферми даёт Лю Цысинь в своей книге "Тёмный Лес".
Я как раз имел в виду codex cli. Локальная разработка с помощью агента действительно удобнее и надёжнее, чем в облаке.
Интересно, а почему codex заметно менее популярен (судя по опросу)? Тоже ведь неплохой агент, тем более от одного из лидеров рынка
Спасибо! Будем ждать)
По поводу юзабилити 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
Да, существенных недостатков по большому счету нет)