Просто тут нет универсального ответа, потому что для кого-то стандартная библиотека в 820KB — это преимущество, например, а кому-то все равно. Кому-то без макросов никуда, а кому-то отлично… Но судя по всему, есть много людей, которых Scala на Андроиде не устраивает (по каким-то из вышеописанных параметров, надо полагать), а Kotlin устраивает.
Наброс засчитан :) Отвечаю в художественной форме, потому что ну не могу уже :)
Чем Kotlin, лучше Scala в android разработке?
Для абстрактной андроид-разработки в вакууме — ничем. Или всем. :)
Какой у Вас юзкейс? Вас интересует размер стандартной библиотеки? Точность диагностик в IDE? Наличие в языке фич, не рекомендованных обычным пользователям? Необходимость конвертировать коллекции при передаче между кодом на разных языках? Null-safety? Наличие синтаксиса для вызова монад? Неявные преобразования в языке? Макросы? Типы высших порядков? Type classes? Тьюринг-полная система типов? Еще что-то?
В зависимости от ответов на эти вопросы можно принять решение о том, что Вам лучше подходит :)
Не хотелось бы скатываться в эмоциональные выпады. Я раскрою немного вопрос про динамику и статику, раз он вызвал такой живой отклик.
Когда мы делали Kotlin, у нас были вполне конкретные требования:
статическая типизация для поддержки больших объемов кода,
очень хороший тулинг (для этого тоже нужна статическая типизация),
совместимость для миграции и переиспользования инфраструктуры,
"демократичность" языка (не нужно делить фичи на "для всех" и "не для всех").
В данном случае нас интересуют первый и второй пункты. Верно ли, что языки должны быть статически типизированными — это бессмысленный вопрос. Некоторые люди предпочитают статически типизированные, а некоторые другие люди — динамически типизированные. Мы относимся к первой группе. Это значит, что мы хотим, чтобы наш код был статически типизированным. Кроме отлова ошибок на стадии компиляции, это, в том числе, дает возможность тулингу много чего про код точно понять, что невозможно в динамическом языке. Естественно, не все люди на свете хотят такой тулинг или ловить баги на стадии компиляции, но мы хотим, и думаем, что есть много людей, которые тоже хотят.
Так вот, если использовать Groovy как статически типизированный язык (а это единственный вариант, который нас устраивает), мы получим систему типов Java, которая нас не устраивает. Поэтому мы дальше особенно не сравнивали, как я и написал в первом же предложении своего комментария.
Еще раз повторю: у кого-то требования к языку могут не совпадать с нашими, это вполне нормально. Этим людям для их задач вполне может подойти Groovy, или Clojure, или Scala, или Fantom, или что-то еще. Нам не подходит, и мы считаем, что многим другим людям тоже не подходит.
Мы, честно говоря, особенно не занимались сравнением с Groovy, потому что это язык преимущественно динамический. Ниже я укажу пару очевидных отличий, а остальное оставлю тем, кто готов сделать более подробный обзор.
Если в Groovy включить статическую компиляцию, то, с точки зрения системы типов, получится Java. В Котлине есть преимущества в системе типов: functional types, nullable types, declaration-site variance, read-only collections.
Использовать Груви на Андроиде я не пробовал, но рантайм там довольно большой, кажется.
Android Annotations должны штатно работать с использованием kapt. Если что-то не в порядке, создайте, пожалуйста, баг в нашем трекере https://youtrack.jetbrains.com/issues/KT
Я, как человек в маркетинге не разбирающийся, хочу задать вопрос:
> Все маркетинговые измерения должны производиться до продукта
Что значит «до продукта»? Верно ли, что после релиза ничего уже не нужно измерять? Или после окончания рекламной кампании не нужно измерять ее эффективность?
На практике комиссия ставит оценку творчески :) И разговор про требования, обозначенные в посте, очень полезен как раз тем, что дает повод этот творческий подход как-то упорядочить. Надеюсь, что со временем у вас это получится.
Спасибо за выписку из стандарта. Релевантная часть: «Магистерская диссертация по направлению 510200 — Прикладная математика и информатика по своему уровню должна соответствовать научной публикации в данной научной области.» То есть это законодательно закреплено.
Тут есть второй вопрос: а как ставить оценки? В посте написано, за что ставить «пять». А «четыре»? А «три»? А при каких обстоятельствах работу не следует допускать к защите?
Магистерская диссертация — это квалификационная работа исследовательского характера, посвященная решению актуальной задачи, имеющая теоретическое или практическое значение для современной науки и техники
Эта крылатая фраза гуглится во многих «положениях» конкретных ВУЗов, а откуда она изначально взялась?
Меня смущает то, что из этой фразы следует, что магистерская диссертация — это совсем не то же самое, что дипломная работа инженера, что настораживает, в свете того, кем работают выпускники технических магистратур (особенно любопытно, что в этом направлении делают, скажем, строители или инженеры-механики). Каково философское обоснование таких требований?
Для абстрактной андроид-разработки в вакууме — ничем. Или всем. :)
Какой у Вас юзкейс? Вас интересует размер стандартной библиотеки? Точность диагностик в IDE? Наличие в языке фич, не рекомендованных обычным пользователям? Необходимость конвертировать коллекции при передаче между кодом на разных языках? Null-safety? Наличие синтаксиса для вызова монад? Неявные преобразования в языке? Макросы? Типы высших порядков? Type classes? Тьюринг-полная система типов? Еще что-то?
В зависимости от ответов на эти вопросы можно принять решение о том, что Вам лучше подходит :)
Когда мы делали Kotlin, у нас были вполне конкретные требования:
В данном случае нас интересуют первый и второй пункты. Верно ли, что языки должны быть статически типизированными — это бессмысленный вопрос. Некоторые люди предпочитают статически типизированные, а некоторые другие люди — динамически типизированные. Мы относимся к первой группе. Это значит, что мы хотим, чтобы наш код был статически типизированным. Кроме отлова ошибок на стадии компиляции, это, в том числе, дает возможность тулингу много чего про код точно понять, что невозможно в динамическом языке. Естественно, не все люди на свете хотят такой тулинг или ловить баги на стадии компиляции, но мы хотим, и думаем, что есть много людей, которые тоже хотят.
Так вот, если использовать Groovy как статически типизированный язык (а это единственный вариант, который нас устраивает), мы получим систему типов Java, которая нас не устраивает. Поэтому мы дальше особенно не сравнивали, как я и написал в первом же предложении своего комментария.
Еще раз повторю: у кого-то требования к языку могут не совпадать с нашими, это вполне нормально. Этим людям для их задач вполне может подойти Groovy, или Clojure, или Scala, или Fantom, или что-то еще. Нам не подходит, и мы считаем, что многим другим людям тоже не подходит.
Если в Groovy включить статическую компиляцию, то, с точки зрения системы типов, получится Java. В Котлине есть преимущества в системе типов: functional types, nullable types, declaration-site variance, read-only collections.
Использовать Груви на Андроиде я не пробовал, но рантайм там довольно большой, кажется.
Так и что же, пришлете нам резюме сами? Или, может быть, кого-то из тех десяти человек к нам направите?
> Все маркетинговые измерения должны производиться до продукта
Что значит «до продукта»? Верно ли, что после релиза ничего уже не нужно измерять? Или после окончания рекламной кампании не нужно измерять ее эффективность?
Тут есть второй вопрос: а как ставить оценки? В посте написано, за что ставить «пять». А «четыре»? А «три»? А при каких обстоятельствах работу не следует допускать к защите?
Эта крылатая фраза гуглится во многих «положениях» конкретных ВУЗов, а откуда она изначально взялась?
Меня смущает то, что из этой фразы следует, что магистерская диссертация — это совсем не то же самое, что дипломная работа инженера, что настораживает, в свете того, кем работают выпускники технических магистратур (особенно любопытно, что в этом направлении делают, скажем, строители или инженеры-механики). Каково философское обоснование таких требований?