Comments 106
Справедливости ради, стоит заметить, что в Java сеттеры и геттеры не обязательны. А в этом конкретном случае с ResponseItem от них не так уж много пользы.
Если потребуется описать только геттеры, то код модельки на Kotlin из кареты превратится в тыкву, сопоставимую с кодом на Java.
Тут вы безусловно правы. Но как я сказал ранее: адаптер на Джаве занял 80-90 строк, в то время как на котлине только 50
Если потребуется описать только геттеры, то код модельки на Kotlin из кареты превратится в тыкву, сопоставимую с кодом на Java.
Завит от того, зачем нужны только лишь геттеры. Если для создания неизменяемой модели, то у Kotlin есть val:
class ImmutableModel(val foo: String, val bar: String = "Опциональные аргументы, Java!")
Если же нужно поместить какую-то логику в геттер, то можно так:
val foo: String
get() = TODO("Implement getter")
Стоит отметить что data классы содержат реализации методов equals, hashcode, toString и componentN (для расщепления классов), так что на java ваш класс был бы еще больше. Что важно эти методы реализованы разумно, и разработчики языка учли множество подводных камней при их реализации.
Я дико извиняюсь, что сейчас достанется именно вашему посту, но он стал последней каплей в чашу моего терпения, касательно некоторого множества статей с определенной структурой.
Все написанное ниже является сугубо моим мнением.
В последнее время я наблюдаю в нашей области просто катастрофическое число статей и заметок, которые, на мой взгляд, обладают серьезными ошибками в самой их структуре и логике. В частности:
Нельзя доказывать общие утверждения частными примерами.
Если вы берете некоторую систему или совокупность систем и их зависимостей и утверждаете, что для них выполняется правило X, то без рассмотрения всех вариантов, которые вы затрагиваете формулировкой вашего правила, вы не можете это доказать.
Вы можете доказать примерами неверность тезиса, пример:
Тезис: Java лучше Kotlin.
*Ваш пример с моделью, и тем, что она короче и читается лучше.*
Таким образом мы доказали, что тезис Java лучше Kotlin неверен, поскольку Kotlin лучше Java в конкретном случае, представленном выше.
Если же мы говорим:
Почему же Котлин оказался лучше Джавы?
То, чтобы доказать верность этого утверждения, нужно перебрать все варианты возможного использования Котлина и Джавы, ибо если хоть в одном случае окажется, что Java лучше Kotlin, то утверждение неверно.
Эту формулировку можно спокойно заменить на:
«Мне понравился Kotlin, потому что:»
«Использование Kotlin дает преимущество в ряде случаев, в том числе следующих:»
В общем, сузить область применимости вашего тезиса, до тех случаев где он действительно верен.
P.S.
Я вот думаю, статью на эту тему написать, что ли.
Все написанное ниже является сугубо моим мнением.
В последнее время я наблюдаю в нашей области просто катастрофическое число статей и заметок, которые, на мой взгляд, обладают серьезными ошибками в самой их структуре и логике. В частности:
Нельзя доказывать общие утверждения частными примерами.
Если вы берете некоторую систему или совокупность систем и их зависимостей и утверждаете, что для них выполняется правило X, то без рассмотрения всех вариантов, которые вы затрагиваете формулировкой вашего правила, вы не можете это доказать.
Вы можете доказать примерами неверность тезиса, пример:
Тезис: Java лучше Kotlin.
*Ваш пример с моделью, и тем, что она короче и читается лучше.*
Таким образом мы доказали, что тезис Java лучше Kotlin неверен, поскольку Kotlin лучше Java в конкретном случае, представленном выше.
Если же мы говорим:
Почему же Котлин оказался лучше Джавы?
То, чтобы доказать верность этого утверждения, нужно перебрать все варианты возможного использования Котлина и Джавы, ибо если хоть в одном случае окажется, что Java лучше Kotlin, то утверждение неверно.
Эту формулировку можно спокойно заменить на:
«Мне понравился Kotlin, потому что:»
«Использование Kotlin дает преимущество в ряде случаев, в том числе следующих:»
В общем, сузить область применимости вашего тезиса, до тех случаев где он действительно верен.
P.S.
Я вот думаю, статью на эту тему написать, что ли.
Я могу взять и написать научный трактат на тему: «Преимущества Котлина по сравнению с Джавой». Выложить там кучу сухой и скучной формулировки, но это будет мало кому интересно, ведь объем будет слишком большим, и вечерком сесть и налегке почитать не выйдет. Я уверен что и у Джавы найдется хоть один плюс по сравнению с Котлином, ничто не идеально. Но как мы выбираем что есть лучше? Мы создаем критерии по которым сравниваем два объекта. Какие-то критерии более важны, какие-то менее, другие просто критичны. В результате мы просто подсчитываем балы и тот у кого их больше и будет лучше, так работает наш мозг, потому что ничто в нашем мире не идеально.
Давайте затронем другую животрепещущую тему: что лучше мак ос или винда. Мак быстрее, с малым количеством вирусов и уязвимостей, более стабилен. Но из недостатков то что нужно купить дорогое железо от apple, в то время винда есть и на более дешевых вариантах. Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.
Давайте затронем другую животрепещущую тему: что лучше мак ос или винда. Мак быстрее, с малым количеством вирусов и уязвимостей, более стабилен. Но из недостатков то что нужно купить дорогое железо от apple, в то время винда есть и на более дешевых вариантах. Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.
Я могу взять и написать научный трактат на тему: «Преимущества Котлина по сравнению с Джавой». Выложить там кучу сухой и скучной формулировки, но это будет мало кому интересно
А вот тут вы не правы. Для развлекательного чтива под чай с булочкой возможно. А когда стоит выбор в какой язык упарываться рогом тратить сотни часов на обучение, то максимально субъективное чтиво, пусть и кратко-тезисное в самый раз.
«Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.»
«Не все так однозначно»(С) Ибо вам придется платить за лицензию винды, бюджетным вариантом будет компьютер с Линуксом
«Не все так однозначно»(С) Ибо вам придется платить за лицензию винды, бюджетным вариантом будет компьютер с Линуксом
А давайте лучше научный трактат?) О том, чем Java лучше Kotlin?
Прям любопытно будет прочитать и сравнить.
Прям любопытно будет прочитать и сравнить.
Мне кажется, что вы неверно поняли посыл моего комментария.
Я не просил вас писать сухой текст. Я просил вас выбирать формулировки, не противоречащие логике вашего повествования.
Смотрите, у вас есть некий опыт работы с Kotlin и Java. Вы, основываясь на нем, поняли, что есть много случаев, когда Kotlin предпочтительнее Java и хотите поделиться этой мыслью с другими людьми, чтобы обратить их внимание на этот язык и, возможно, мотивировать на его изучение.
Это то, что я увидел в Вашем тексте, исходя из вывода, тезисов, вступления.
Если коротко:
Вы обращаете внимание читателя на возросшую популярность языка.
Делитесь личным опытом, таким, чтобы читатели, которые являются основной вашей аудиторией(т.е. те, кто не писал на Kotlin) почувствовали, что они находятся в положении близком к Вашему.
Перечисляете характеристики языка, которые наиболее вам понравились и приводите примеры.
Делаете заключение.
И, все бы было хорошо, если бы не маленькая ошибка:
В какой-то момент вы увлекаетесь и переходите на категоричные заявления, вместо того, чтобы продолжить делиться своим личным опытом.
И более того, допускаете логическую ошибку в своих суждениях, о чем я написал выше.
А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.
Я не просил вас писать сухой текст. Я просил вас выбирать формулировки, не противоречащие логике вашего повествования.
Смотрите, у вас есть некий опыт работы с Kotlin и Java. Вы, основываясь на нем, поняли, что есть много случаев, когда Kotlin предпочтительнее Java и хотите поделиться этой мыслью с другими людьми, чтобы обратить их внимание на этот язык и, возможно, мотивировать на его изучение.
Это то, что я увидел в Вашем тексте, исходя из вывода, тезисов, вступления.
Если коротко:
Вы обращаете внимание читателя на возросшую популярность языка.
Делитесь личным опытом, таким, чтобы читатели, которые являются основной вашей аудиторией(т.е. те, кто не писал на Kotlin) почувствовали, что они находятся в положении близком к Вашему.
Перечисляете характеристики языка, которые наиболее вам понравились и приводите примеры.
Делаете заключение.
И, все бы было хорошо, если бы не маленькая ошибка:
В какой-то момент вы увлекаетесь и переходите на категоричные заявления, вместо того, чтобы продолжить делиться своим личным опытом.
И более того, допускаете логическую ошибку в своих суждениях, о чем я написал выше.
А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.
Я не толкаю мысль что Котлин полезнее Джавы, я толкаю мысль — что во многих аспектах он превосходит Джаву. Статья была предназначена для людей у которых был опыт разработки на Java. В комментах уже было упомянуто что документации в Android SDK на Котлине гораздо меньше, и человеку который вообще ничего не знает в андроиде разобраться с ним будет как минимум проблемно. Поэтому нельзя так просто взять и начать кодить на Котлине. Это как: «кодить нужно начинать на Pascal он изи, и только так можно выучить алгоритмы». Котлин сейчас еще слишком молод чтобы знать только его и ничего больше.
ибо если хоть в одном случае окажется, что Java лучше Kotlin
я вот честно не могу придумать хоть одного кейса где java лучше kotlin. Ситуаций где они окажутся равны друг другу — это да. А вот что бы java была лучше и удобнее… Хотя возможно я чего-то не знаю. Если вы сможете предложить подобный кейс — будет интересно.
то утверждение неверно.
не стоит мыслить абсолютами. Если в 9 из 10-ти ситуаций kotlin лучше — то он лучше java. Это работает по сравнению плюсов и минусов. Так же у разных кейсов есть разный приоритет. К примеру null-safety — жирный плюс, с которым сложно считаться. Если какую-то редкую задачу проще решить на java (что сомнительно), то приоритет этого явно ниже. Ну думаю вы поняли идею.
What Java has that Kotlin does not:
Checked exceptions
Primitive types that are not classes
Static members
Non-private fields
Wildcard-types
Важно ли это — не думаю
Checked exceptions
Primitive types that are not classes
Static members
Non-private fields
Wildcard-types
Важно ли это — не думаю
По приведенной вами ссылке можно перейти по каждому пункту и выяснить почему это отсутствует. Там и мотивация почему так, и какая альтернатива… возможностей у вас меньше не стало, да и не забывайте что у Kotlin должна быть совместимость c Java так что в целом отсутствие чего-то не означает что вы не можете чего-то сделать.
В целом я считаю что отсутствие перечисленного это плюс. Ну и сравнивать таким образом языки слишком примитивно.
Пожалуй стоит начать с того что Котлин это следующее поколение, а как известно следующее поколение всегда превосходит предидущее, он создан на основе Джавы, с учетом всего крутого и всех косяков, и действительно тяжело найти кейс где Джава впереди
я бы сказал так: котлин — это джава, какой она должна была бы быть. Котлин перенял многие вкусности из других языков, в то время как джава очень неспешно меняется и зачастую не в том направлении, в котором хотелось бы.
И кто знает, не поспешил ли котлин в погоне за модой и не ждет ли его та же печальная судьба?
И кто знает, не поспешил ли котлин в погоне за модой и не ждет ли его та же печальная судьба?
очень неспешно меняется и зачастую не в том направлении, в котором хотелось бы.
тут на самом деле все очень просто. Для того что бы эволюционировать — нужны эксперименты. Kotlin, Scala и некоторые другие JVM языки являются своего рода экспериментами. Определенные идеи могут спокойно перетечь в java, подтолкнуть его развитие.
Экспериментировать же с самой java весьма дорого, так как язык должен иметь обратную совместимость и неудачную фичу, которую вроде и продумали но не предугадали последствий, выпилить уже не выйдет.
Да вы что, это же не buzzword-oriented подход!
Опрос:
*Java, эти аргументы неубедительны
*перейду на Kotlin прям сегодня
*я уже давно на Котлине
*Возможно начну кодить на Котлине через месяц другой
Жизни за МКАДом не существует? =)
*Java, эти аргументы неубедительны
*перейду на Kotlin прям сегодня
*я уже давно на Котлине
*Возможно начну кодить на Котлине через месяц другой
Жизни за МКАДом не существует? =)
У нас в городе ровно одна вакансия по Kotlin, и 162 вакансии о Java.
Так что я сейчас собираюсь учить именно Java. Потому что, увы, практически исчезли чистые вакансии по PL/SQL, и в основном требуют PL/SQL + Java.
PS посмотрел Москву: 77 вакансий по Kotlin, против 1770 по Java и 1116 по C#.
Я не говорил про вакансии чисто по Котлин. Откройте вакансии по андроид разработке. В скиллах будет написано обязательное знание Джавы, а ниже почти в каждой пятой вакансии будет написано: будет круто если вы еще знаете Котлин.
Раньше такого было намного меньше, а сейчас таких вакансий все больше с каждым днем. Становится очевидным что Котлин набирает популярность. Это как Свифт на ios. Был Objective C вроде нормальный язык, но появился новый Swift, и через какие-то пару лет он уже отъел половину рынка. Не исключено что скоро это повторится и с андроидом.
Раньше такого было намного меньше, а сейчас таких вакансий все больше с каждым днем. Становится очевидным что Котлин набирает популярность. Это как Свифт на ios. Был Objective C вроде нормальный язык, но появился новый Swift, и через какие-то пару лет он уже отъел половину рынка. Не исключено что скоро это повторится и с андроидом.
hh — не показывает вакансии "чисто по Котлин", он показывает ВСЕ вакансии в которых это слово упоминается, а их в Москве 77 вакансий.
Swift полностью поддерживается Apple, включая документацию, обучающие материалы и примеры. А насколько Google поддерживает Kotlin, кроме возможности создания на нём проектов в Android Studio?
Документации на Котлин действительно немного, это можно отнести к разряду минусов, но в скором времени это должно изменится. Официально гугл поддерживает Котлин, но документации по Джаве на порядок больше, ведь она существует куда дольше чем Котлин. И все же людей которые на него переходят все больше и больше, поэтому если Котлин будет развиваться, то и документации будет больше. На самом деле на текущий момент в сети полно туторов, курсов, примеров именно на Котлине, так что кто захочет тот найдет.
На текущий момент комьюнити Котлина по численности сильно уступает комьюнити Jav
На текущий момент комьюнити Котлина по численности сильно уступает комьюнити Jav
Документации на Котлин действительно немного
Документация по Котлину исчерпывающая, на сайте производителя. В слак каналах поддержка осуществляется самими разработчиками. На текущий момент 13447 пользователей, комьюнити очень дружелюбное и помощь поступает незамедлительно.
Не просто по Kotlin надо, а по Android SDK. И официальную документацию, а не Hello World-ы на коленке.
Начнем с того что в Котлине можно использовать Джава классы и поэтому вполне можно использовать документацию Джавы, и не будет никаких проблем.
Честно говоря когда я делал трекер мне требовалась документация на уровне синтаксиса, а части которые относились к Android SDK я писал по аналогии с Java, и при этом не возникало никаких проблем
Честно говоря когда я делал трекер мне требовалась документация на уровне синтаксиса, а части которые относились к Android SDK я писал по аналогии с Java, и при этом не возникало никаких проблем
настолько, что Google нанял Джейка Вортона работать над поддержкой Котлин.
Один из первых результатов его работы — Kotlin code style
Один из первых результатов его работы — Kotlin code style
А это кто?
О мой Бог, вы не знаете кто этот Великий Человек? Он ведущий разработчик в Square, и он подарил миру столько прекрасного и упрощающего рутину обычному программисту: Retrofit(создание запроса с минимальным количеством кода), ButterKnife(упрощение биндинга вьюшек до нельзя, всего одна строка кода на каждую вьюшку, вместо двух с findViewById), приложил руку к Dagger(улучшает тестируемость кода), и это далеко не весь список. Поэтому любой андроидщик хоть раз в жизни юзал творения над которыми он работал. Вот за это он один из самых известных и уважаемых людей в мире андроид разработки.
я вот честно не могу придумать хоть одного кейса где java лучше kotlin. Ситуаций где они окажутся равны друг другу — это да. А вот что бы java была лучше и удобнее… Хотя возможно я чего-то не знаю. Если вы сможете предложить подобный кейс — будет интересно.
секвенсес не могут в параллелизм
стримапи может в параллелизм
но это с точки зрения сахара
Картинка то какая. Телефон на Java убитый и заляпанный, а на Kotlin сияющий и блестящий. Какой-то дотнетщиной пахнуло =)
Нету Getter'ов и Setter'ов
Вы серьёзно?
Во-первых, они есть. Во-вторых, в котлине геттеры и сеттеры вовсю используются неявно и выглядят как обращение к переменной.
Единственный стоящий аргумент — про более короткий код, но пример к нему ужасен.
Почему бы не рассказать про автовывод типов, extension методы и прочие приятные штуки?
Kotlin это когда хочешь писать на C# с JVM.
NPE — это легенда в мире программирования. И в Котлине его просто нету еще до компиляции возможные места возникновения NullPointerException считаются синтаксической ошибкой. Вас просто заставляют сделать проверку на null.
Вот тут Вы слукавили, замечательно прилетает с джавы.
Речь не о джаве, а о том, что дизайн языка запрещает неявный null — либо мы явно используем billable (в джаве все по умолчанию) типы, либо нас заставляют описывать какой-то dummy объект вместо null. Ситуация схожая с проверяемыми исключениями в джаве — либо обработай, либо явно выбрось наверх.
Другой вопрос, хорошо ли это (т.к. почти во всех статьях восхваляют данную фишку). Возможно, пусть прога лучше со свистом грохнется и покажет стектрейс, с исправлением ошибки за минуту, чем прога будет работать, но работать неправильно и хрен ты эту логическую ошибку найдешь.
Другой вопрос, хорошо ли это (т.к. почти во всех статьях восхваляют данную фишку). Возможно, пусть прога лучше со свистом грохнется и покажет стектрейс, с исправлением ошибки за минуту, чем прога будет работать, но работать неправильно и хрен ты эту логическую ошибку найдешь.
Я про то, что NPE на рантайме, и в котлине поймать можно.
О том и речь — конечно, как явление, NPE в котлин существует, но случайно написать код, который его производит, уже чуть сложнее
Суть в том что его поймать тяжело. Конечно если сильно постаратся то и дьявола можно призвать. В Джаве вы можете просто забыть прописать проверку на null и у вас все крешнится. А Котлин заставит вас сделать проверку на null иначе он просто откажется компилироваться.
Я про то, что NPE на рантайме, и в котлине поймать можно.
Типичный статья фаната Котлина который даже не знает о всех его преимуществах и думает что его сила только в украшательствах и сокращении кода. Крайне печально.
Может Вы подскажете в чем сила?
Таких статей бесчетное количество. Например https://academy.realm.io/posts/oredev-jake-wharton-kotlin-advancing-android-dev/
4. Код на порядок короче
Слышали про Lombok? С ним ваш пример на Java приблизится к Котлину
3. Отсутсвие NPE
Лукавство. Есть механизмы по его предотвращению, но сам по себе NPE есть и никуда не делася
1. Отсутсвие точек с запятыми
Тут я сдаюсь и перехожу на Котлин )
Если серьезно, то почему бы не написать про действительно интересные вещи типа корутин, extension, легкости написания dsl и т.д.?
Вот когда хайп уляжется и статьи про поней какающих радугами сойдут на нет, тогда посмотрим.
UFO just landed and posted this here
Хватит рекламить этот котлин! Такое чувство что JetBrains проплачивает такого рода посты. Я лично за Скалу, зачем вообще он был нужен, когда скала на момент создания уже была?
Ну Скалу все равно считают довольно сложным языком, да он легче чем тот же Си, но все же…
Честно говоря еще неделю назад я тоже думал что в нем нету ничего такого. Но виной был страх что-то менять и было немного лень напрягаться.
Честно говоря еще неделю назад я тоже думал что в нем нету ничего такого. Но виной был страх что-то менять и было немного лень напрягаться.
А в чём выражается сложность Скалы? Синтаксис? Стандартная библиотека? Фреймворки? Тулзы для работы?
Да ни в чём.
Синтаксис простой (на мой взгляд проще, чем в котлин).
- В котлине есть специальный синтаксис для определния геттеров-сеттеров, в скале это просто методы типа
def x =...,def x_=(...) - В котлине инлайн-функции втащены на уровень языка. Всё бы ничего, но в некоторых случаях это влияет на возможность использовать слово return.
- В котлине есть более сложные типы (например, IntArray.() -> Unit). Впрочем., в скале есть path-dependent types, которые используются очень редко и отсутствуют в котлине. Синтаксис:
objectName.TypeName - В котлине есть nullable типы. В скале это решено с помощью класса Option из стандартной библиотеки.
- В котлине, чтобы определить оператор +, надо написать operator fun plus(...), в скале достаточно def +(...) и это самый обычный метод.
- В котлин можно переопределить только несколько операторов, в скале — почти всё, что захочется, хоть ||, хоть !!!
- В котлине методы в одну строчку принято определять как fun a() = ..., в несколько строчек
fun a(){...}В скале принят только первый вариант. - Обращение к элементу массива и вызов функции — в котлин разные сущности, в скале и то и другое — круглые скобочки, массив являетя функцией Int=>T.
- В котлин есть extension методы. В скале вместо это используются implicit преобразования, которые дают на порядки больше возможностей (С точки зрения скалы преобразование типа Int -> Long является неявным)
Получается, что в скале идут по пути обобщения и упрощения синтаксиса, а в котлине добавляют маленькие удобные костылики. С костыликами хорошо, пока не захочется сделать что-то необычное.
Стандартная библиотека у скалы своя. Более мощная, чем в джаве и огранично вписывается в язык. Впрочем, написать свою коллекцию будет сложнее. Можно использовать джавовские коллекции.
Фреймворки — там могут очень много навертеть, используя систему типов на полную катушку. Вряд ли это недостаток языка.
Про тулзы — не знаю что сказать.
Со стороны JetBrains, создание своего языка — очень годный ход. Это определенная сфера влияния в бизнесе, которая напрямую ведет к обогащению. Я же не думаю, что есть люди, которые верят в утверждение «мы создали его, чтобы вам было удобнее»? Тот же Oracle, не «так просто» скупает платформы, языки и системы.
JetBrains сделали Котлин в первую очередь для себя. Они активно юзают его внутри компании
Даже в интервью директора была фраза, что сделав язык, они получат влияние.
Настолько «для себя» что этот котлин форсится так неистово, что даже не хочется к нему прикасаться.
На каждом втором русскоязычном бложеке по триста статей уровня «почему котлин в триллион раз лучше жавы, начинайте писать уже сейчас!!1», кликбейты про «новый основной язык разработки под ведроид» и просто откровенная реклама.
Когда тебе так настойчиво запихивают в рот какую-то «вкусняшку», непроизвольно возникает тошнота.
На каждом втором русскоязычном бложеке по триста статей уровня «почему котлин в триллион раз лучше жавы, начинайте писать уже сейчас!!1», кликбейты про «новый основной язык разработки под ведроид» и просто откровенная реклама.
Когда тебе так настойчиво запихивают в рот какую-то «вкусняшку», непроизвольно возникает тошнота.
С другой стороны только так что-то может получить популярность, увы. Скил фильтрации информации подразумевает ее анализ а не игнорирование.
Не только.
Реклама может содержать описание качеств продукта и оставлять пользователю выбор использовать его или нет — если продукт хороший пользователь сам придет к «продавцу». Если бы во всех этих статьях было бы только описание особенностей языка и то какие проблемы он решает — я бы наверняка попробовал на нем писать. Это была бы хорошая реклама которая уважает пользователя.
Есть другая реклама — полные императивных посылов крики «покупай, пользуйся, делай!!11» без единых описаний почему я должен пользоваться чем-то. Это реклама стиральных порошков, бытовых товаров и прочьего ширпотрепа — попытка перекричать голос разума яркими метафорами и безудержным восхвалением. Вот такая реклама у котлина и такая реклама вызывает только тошноту, потому что авторы считают идиотом неспособным к критическому мышлению которого нужно подтолкнуть в сторону «правильного» продукта.
Реклама может содержать описание качеств продукта и оставлять пользователю выбор использовать его или нет — если продукт хороший пользователь сам придет к «продавцу». Если бы во всех этих статьях было бы только описание особенностей языка и то какие проблемы он решает — я бы наверняка попробовал на нем писать. Это была бы хорошая реклама которая уважает пользователя.
Есть другая реклама — полные императивных посылов крики «покупай, пользуйся, делай!!11» без единых описаний почему я должен пользоваться чем-то. Это реклама стиральных порошков, бытовых товаров и прочьего ширпотрепа — попытка перекричать голос разума яркими метафорами и безудержным восхвалением. Вот такая реклама у котлина и такая реклама вызывает только тошноту, потому что авторы считают идиотом неспособным к критическому мышлению которого нужно подтолкнуть в сторону «правильного» продукта.
используя скалу тебе надо тащить весь язык со всеми его библиотеками. Котлин работает поверх Java, коллекции Котлин — это обычные коллекции из Java, например, и потому размер его стандартной библиотеки значительно меньше. Для Андроид, в частности, это очень важно
Я не андроид разработчик, но всетаки поинтересуюсь:
Котлин работает поверх JavaKotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM потом интерпретируется ведроид компилятором под DVM. Не очень понял что вы имеете ввиду?
тащить весь язык со всеми его библиотекамиБоюсь спрашивать, но куда и за какое место вы хотите тащить языки?
Да, он работает поверх Джавы. Поэтому в Котлине можно юзать все что написано на Джаве. Еще он может компилиться в байт-код javascript
работает поверх Джавы
Что вы все заладили, что в вашем понимании это означает? Я то думал это предусмотренная компилятором обратная совместимость с Java, в Scala тоже самое, потому что котлин это попытка JetBrains написать свою скалу, и что то мне подсказывает что писали они ее не с 0.
байт-код javascriptЧто простите? (facepalm) В какой из множества вариаций javascript — bytecode, или они заставили все браузеры перейти на оди и тот же компилятор?
Складывается впечатление что у людей напрочь отсутствует понимание, того как работают языки вне красивых кнопочек и подсветок в их IDE…
Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM
Котлин написан поверх Java и в стандартной библиотеке, к примеру, не имеет своих коллекций, потому что он использует стандартные коллекции из Java. Если посмотреть к примеру ImmutableList — в байткоде это будет стандартный ArrayList из Java. И большая часть библиотеки Kotlin — это extension-функции над существующими классами Java. Поэтому рантайм и библиотека Котлин занимают в разы меньше места, чем аналогичный от Скалы.
Боюсь спрашивать, но куда и за какое место вы хотите тащить языки?Юморок на троечку. Посмотрите структуру apk — основную часть занимает dex-файл(ы). А еще поищите про dex-limit, почитайте вопли юзеров в Play Market, недовольных лишним мегабайтом размера приложения, и вы поймете, что Скала существенно увеличит размер установочного файла.
старый документ, но ознакомиться полезно
А Вы попробуйте. Я два года писал на Scala, проходил курсы на Scala, агитировал руководство и коллег на Scala… А потом попробовал Kotlin и вот совсем на Scala возвращаться не хочется. И коллеги просто не нарадуются на Kotlin.
Отсутсвие — как по стеклу провели.
А чем Groovy плох???
Ну что, вам листать не надоело?
Чтобы избежать бойлерплейта, можно использовать lombok: projectlombok.org/features/all
Я старомоден и я люблю:
1 Java
2 писать код на Java
3 проверки на null в Java
4 геттеры и сеттеры в Java
5 смотреть как работает написанный код в Java
…
этот список могу продолжать бесконечно.
Меня умиляют высказывания вида «мы сможем меньше писать, язык сделает за нас <указать что сделает>». Мне не нравится, когда кто-то за меня что-то делает, да и выглядит все это, будто «пчелы против меда», ну как мы, разработчики, не будем писать код?
Меньше писать, выведение типов, прочие плюшки, очередной JS получается, не так ли?..
Обленились? Деградируем?
P.S. есть вопрос, который мучает меня последние пару лет, почему никто не пытается переписать C? а если пытается, то почему не кричит о том, что «мы сделали лучше чем C, айда все на нем писать»?
1 Java
2 писать код на Java
3 проверки на null в Java
4 геттеры и сеттеры в Java
5 смотреть как работает написанный код в Java
…
этот список могу продолжать бесконечно.
Меня умиляют высказывания вида «мы сможем меньше писать, язык сделает за нас <указать что сделает>». Мне не нравится, когда кто-то за меня что-то делает, да и выглядит все это, будто «пчелы против меда», ну как мы, разработчики, не будем писать код?
Меньше писать, выведение типов, прочие плюшки, очередной JS получается, не так ли?..
Обленились? Деградируем?
P.S. есть вопрос, который мучает меня последние пару лет, почему никто не пытается переписать C? а если пытается, то почему не кричит о том, что «мы сделали лучше чем C, айда все на нем писать»?
почему никто не пытается переписать C? а если пытается, то почему не кричит о том, что «мы сделали лучше чем C, айда все на нем писать»?
В 1983 году именно по этой причине был создан C++.
Если вы так старомодны, так почему не пишите на Асамблере? :)
Наверное потому что Джава — лучше, проще, быстрее, и что-то делает за вас. Упрощение != деградация. Если вы считаете что проще — это хуже, тогда пойдите пешком в Барселону, да это сложнее чем полететь на самолете и через часиков 5 приземлится, но вы же считаете что проще это хуже.
Наверное потому что Джава — лучше, проще, быстрее, и что-то делает за вас. Упрощение != деградация. Если вы считаете что проще — это хуже, тогда пойдите пешком в Барселону, да это сложнее чем полететь на самолете и через часиков 5 приземлится, но вы же считаете что проще это хуже.
Наверное потому что Джава — лучше, проще, быстрее, и что-то делает за вас. Упрощение != деградация. Если вы считаете что проще — это хуже, тогда пойдите пешком в Барселону, да это сложнее чем полететь на самолете и через часиков 5 приземлится, но вы же считаете что проще это хуже.
Не утрируйте, я с удовольствием пишу на асме там, где это удобно. Я с удовольствием пойду в Барсу пешком, мир посмотрю.
Упрощение != деградация
Если речь идет о смене Java на язык, предполагающий смену платформы, я согласен, в остальном, вы не получаете ощутимого преимущества при миграции на котлин.
будто «пчелы против меда», ну как мы, разработчики, не будем писать код?
А вам платят за код? Ну тогда ладно...
Sign up to leave a comment.
Вы все еще кодите на Java? Пора измениться