Я очень долго не хотел смотреть в сторону Котлина. Но вот когда я листал список вакансий я стал все чаще замечать графу: Плюсом также будет знание Kotlin. И как-то вечерком увидел вот эту статью на хабре: 8 учебных проектов. Мне там приглянулся трекер криптовалют. Но как-то было слишком просто: обыкновенный Get-запрос, совсем не интересно. И здесь я решил попробовать написать все это на Kotlin. Трекер криптовалют стал тренировочным полигоном для изучения Котлина. После создания этой приложухи было вынесено несколько важных уроков.
Всем кому интересно прошу под кат.
Кратко обо мне
Когда я начал это все делать то у меня была масса предубеждений насчет этого языка. Что он не удобный, что он не красивый, что он плохой, и тормознутый. Это все было из-за того что я не хотел выходить из своей зоны комфорта. Я знаю Джаву она хорошая, и вообще зачем что-то менять пускай все будет как есть, зачем напрягаться. Но интерес взял свое. И могу сказать что я был очень не прав.
Что же такого особенного в Котлине чего нету в Java?
1. Отсутсвие точек с запятыми
Это бросилось в глаза с самого начала. Их отсутствие показалось просто приятным бонусом, хотя рука все равно дергалась :). Но наличие/отсутсвие такой мелочи вовсе не повод любить/ненавидеть язык (хотя когда у тебя тысячи строк кода уже вроде и не мелочь).
2. Биндинг вьюшек
Как только я закончил клепать макеты появился вопрос о том как биндить вьюхи. Я полез гуглить:«Butterknife kotlin». Вот тут-то я и поплыл. Оказалось что использовать ButterKnife в Котлине просто нету смысла. Нужно просто брать и юзать вьюшки, при этом не имея ни малейшего риска получить NPE.
public class MainActivity {
private TextView textView; //1-ая строка
@Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = findViewById(R.id.textView);//2-ая строка
textView.setText("Hello world!");//3-я строка
}
}
public class MainActivity...{
@BindView(R.id.textView)TextView textView; //1-ая строка
@Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
ButterKnife.bind(this);//2-ая строка
textView.setText("Hello world!");//3-я строка
}
}
class MainActivity: AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
textView.text = "Hello world!"//1-ая и последняя строка
}
}
3. Отсутсвие NPE
NPE — это легенда в мире программирования. И в Котлине его просто нету еще до компиляции возможные места возникновения NullPointerException считаются синтаксической ошибкой. Вас просто заставляют сделать проверку на null.
4. Код на порядок короче
По статистике код в Котлине на 40% короче, и в этом легко убедится. Для того чтобы парсить ответ нужно было сделать модели. Никогда не думал что модель со столькими полями может быть такой короткой.
data class ResponseItem(@SerializedName("id")
@Expose var id: String?,
@SerializedName("name")
@Expose var name: String?,
@SerializedName("symbol")
@Expose var symbol: String?,
@SerializedName("rank")
@Expose var rank: String?,
@SerializedName("price_usd")
@Expose var priceUsd: String?,
@SerializedName("price_btc")
@Expose var priceBtc: String?,
@SerializedName("24h_volume_usd")
@Expose var _24hVolumeUsd: String?,
@SerializedName("market_cap_usd")
@Expose var marketCapUsd: String?,
@SerializedName("available_supply")
@Expose var availableSupply: String?,
@SerializedName("total_supply")
@Expose var totalSupply: String?,
@SerializedName("max_supply")
@Expose var maxSupply: String?,
@SerializedName("percent_change_1h")
@Expose var percentChange1h: String?,
@SerializedName("percent_change_24h")
@Expose var percentChange24h: String?,
@SerializedName("percent_change_7d")
@Expose var percentChange7d: String?,
@SerializedName("last_updated")
@Expose var lastUpdated: String?)
На самом деле код короче, потому что 2 аннотации(expose и serialized) в одну строку.
@SerializedName("id")
@Expose
private String id;
@SerializedName("name")
@Expose
private String name;
@SerializedName("symbol")
@Expose
private String symbol;
@SerializedName("rank")
@Expose
private String rank;
@SerializedName("price_usd")
@Expose
private String priceUsd;
@SerializedName("price_btc")
@Expose
private String priceBtc;
@SerializedName("24h_volume_usd")
@Expose
private String _24hVolumeUsd;
@SerializedName("market_cap_usd")
@Expose
private String marketCapUsd;
@SerializedName("available_supply")
@Expose
private String availableSupply;
@SerializedName("total_supply")
@Expose
private String totalSupply;
@SerializedName("max_supply")
@Expose
private Object maxSupply;
@SerializedName("percent_change_1h")
@Expose
private String percentChange1h;
@SerializedName("percent_change_24h")
@Expose
private String percentChange24h;
@SerializedName("percent_change_7d")
@Expose
private String percentChange7d;
@SerializedName("last_updated")
@Expose
private String lastUpdated;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getSymbol() {
return symbol;
}
public void setSymbol(String symbol) {
this.symbol = symbol;
}
public String getRank() {
return rank;
}
public void setRank(String rank) {
this.rank = rank;
}
public String getPriceUsd() {
return priceUsd;
}
public void setPriceUsd(String priceUsd) {
this.priceUsd = priceUsd;
}
public String getPriceBtc() {
return priceBtc;
}
public void setPriceBtc(String priceBtc) {
this.priceBtc = priceBtc;
}
public String get24hVolumeUsd() {
return _24hVolumeUsd;
}
public void set24hVolumeUsd(String _24hVolumeUsd) {
this._24hVolumeUsd = _24hVolumeUsd;
}
public String getMarketCapUsd() {
return marketCapUsd;
}
public void setMarketCapUsd(String marketCapUsd) {
this.marketCapUsd = marketCapUsd;
}
public String getAvailableSupply() {
return availableSupply;
}
public void setAvailableSupply(String availableSupply) {
this.availableSupply = availableSupply;
}
public String getTotalSupply() {
return totalSupply;
}
public void setTotalSupply(String totalSupply) {
this.totalSupply = totalSupply;
}
public Object getMaxSupply() {
return maxSupply;
}
public void setMaxSupply(Object maxSupply) {
this.maxSupply = maxSupply;
}
public String getPercentChange1h() {
return percentChange1h;
}
public void setPercentChange1h(String percentChange1h) {
this.percentChange1h = percentChange1h;
}
public String getPercentChange24h() {
return percentChange24h;
}
public void setPercentChange24h(String percentChange24h) {
this.percentChange24h = percentChange24h;
}
public String getPercentChange7d() {
return percentChange7d;
}
public void setPercentChange7d(String percentChange7d) {
this.percentChange7d = percentChange7d;
}
public String getLastUpdated() {
return lastUpdated;
}
public void setLastUpdated(String lastUpdated) {
this.lastUpdated = lastUpdated;
}
Ну что, вам листать не надоело?
Мне кажется разница на лицо. Скажете: ну это модели, с ними такое бывает. Когда я писал адаптер для RecylerView он был длиной всего в 50 строк. Такой же адаптер на джаве занял бы 80 — 90 строк.
5. Нету Getter'ов и Setter'ов
Это одна из главных причин по которой модели в Котлине такие короткие. Для того чтобы поменять значение переменной достаточно просто сделать:
someModel.name = "new name"
В Джаве для того же результата нужно объявить сеттеры, и только потом к ним обращаться. А один сеттер занимает 3 строки кода. И как вы видели в предидущем примере эта разница существенна.
Заключение
На самом деле у Котлина куда больше плюсов, я написал только про те которые явно бросаются в глаза, детальнее про фишки Котлина вы можете почитать в документации языка. В принципе мне он понравился и в следущий раз я его уже буду использовать в реальном проекте. Несмотря на мое упрежденное мнение он показал себя с лучшей стороны. Код куда проще и короче чем на Джаве. Сейчас Котлин это тренд и при этом он быстро набирает обороты. Еще два года тому назад его считали сыроватым и ним пользовалось меньше 5 процентов всех андроидщиков. С таким языком в багаже у вас будет преимущества на собеседованиях, при разработке, а также котлин компилится в байт код JavaScript, что может в один день при смене профиля пригодиться.
Самым важным уроком который я сегодня извлек был: не нужно боятся пробовать что-то новое, возможно, оно даже лучше чем старое.
Комментарии (89)
LonelyDeveloper97
12.12.2017 22:06+1Я дико извиняюсь, что сейчас достанется именно вашему посту, но он стал последней каплей в чашу моего терпения, касательно некоторого множества статей с определенной структурой.
Все написанное ниже является сугубо моим мнением.
В последнее время я наблюдаю в нашей области просто катастрофическое число статей и заметок, которые, на мой взгляд, обладают серьезными ошибками в самой их структуре и логике. В частности:
Нельзя доказывать общие утверждения частными примерами.
Если вы берете некоторую систему или совокупность систем и их зависимостей и утверждаете, что для них выполняется правило X, то без рассмотрения всех вариантов, которые вы затрагиваете формулировкой вашего правила, вы не можете это доказать.
Вы можете доказать примерами неверность тезиса, пример:
Тезис: Java лучше Kotlin.
*Ваш пример с моделью, и тем, что она короче и читается лучше.*
Таким образом мы доказали, что тезис Java лучше Kotlin неверен, поскольку Kotlin лучше Java в конкретном случае, представленном выше.
Если же мы говорим:
Почему же Котлин оказался лучше Джавы?
То, чтобы доказать верность этого утверждения, нужно перебрать все варианты возможного использования Котлина и Джавы, ибо если хоть в одном случае окажется, что Java лучше Kotlin, то утверждение неверно.
Эту формулировку можно спокойно заменить на:
«Мне понравился Kotlin, потому что:»
«Использование Kotlin дает преимущество в ряде случаев, в том числе следующих:»
В общем, сузить область применимости вашего тезиса, до тех случаев где он действительно верен.
P.S.
Я вот думаю, статью на эту тему написать, что ли.vlad2711 Автор
12.12.2017 22:24Я могу взять и написать научный трактат на тему: «Преимущества Котлина по сравнению с Джавой». Выложить там кучу сухой и скучной формулировки, но это будет мало кому интересно, ведь объем будет слишком большим, и вечерком сесть и налегке почитать не выйдет. Я уверен что и у Джавы найдется хоть один плюс по сравнению с Котлином, ничто не идеально. Но как мы выбираем что есть лучше? Мы создаем критерии по которым сравниваем два объекта. Какие-то критерии более важны, какие-то менее, другие просто критичны. В результате мы просто подсчитываем балы и тот у кого их больше и будет лучше, так работает наш мозг, потому что ничто в нашем мире не идеально.
Давайте затронем другую животрепещущую тему: что лучше мак ос или винда. Мак быстрее, с малым количеством вирусов и уязвимостей, более стабилен. Но из недостатков то что нужно купить дорогое железо от apple, в то время винда есть и на более дешевых вариантах. Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.Nikobraz
13.12.2017 04:57Я могу взять и написать научный трактат на тему: «Преимущества Котлина по сравнению с Джавой». Выложить там кучу сухой и скучной формулировки, но это будет мало кому интересно
А вот тут вы не правы. Для развлекательного чтива под чай с булочкой возможно. А когда стоит выбор в какой язык упарываться рогом тратить сотни часов на обучение, то максимально субъективное чтиво, пусть и кратко-тезисное в самый раз.
saag
13.12.2017 11:39+1«Если цена для нас не критична мы выберем мак, но если у нас небольшой бюджет выбор очевиден.»
«Не все так однозначно»(С) Ибо вам придется платить за лицензию винды, бюджетным вариантом будет компьютер с Линуксом
TheKnight
13.12.2017 14:18А давайте лучше научный трактат?) О том, чем Java лучше Kotlin?
Прям любопытно будет прочитать и сравнить.
LonelyDeveloper97
13.12.2017 15:01+1Мне кажется, что вы неверно поняли посыл моего комментария.
Я не просил вас писать сухой текст. Я просил вас выбирать формулировки, не противоречащие логике вашего повествования.
Смотрите, у вас есть некий опыт работы с Kotlin и Java. Вы, основываясь на нем, поняли, что есть много случаев, когда Kotlin предпочтительнее Java и хотите поделиться этой мыслью с другими людьми, чтобы обратить их внимание на этот язык и, возможно, мотивировать на его изучение.
Это то, что я увидел в Вашем тексте, исходя из вывода, тезисов, вступления.
Если коротко:
Вы обращаете внимание читателя на возросшую популярность языка.
Делитесь личным опытом, таким, чтобы читатели, которые являются основной вашей аудиторией(т.е. те, кто не писал на Kotlin) почувствовали, что они находятся в положении близком к Вашему.
Перечисляете характеристики языка, которые наиболее вам понравились и приводите примеры.
Делаете заключение.
И, все бы было хорошо, если бы не маленькая ошибка:
В какой-то момент вы увлекаетесь и переходите на категоричные заявления, вместо того, чтобы продолжить делиться своим личным опытом.
И более того, допускаете логическую ошибку в своих суждениях, о чем я написал выше.
А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.vlad2711 Автор
13.12.2017 15:15-1Я не толкаю мысль что Котлин полезнее Джавы, я толкаю мысль — что во многих аспектах он превосходит Джаву. Статья была предназначена для людей у которых был опыт разработки на Java. В комментах уже было упомянуто что документации в Android SDK на Котлине гораздо меньше, и человеку который вообще ничего не знает в андроиде разобраться с ним будет как минимум проблемно. Поэтому нельзя так просто взять и начать кодить на Котлине. Это как: «кодить нужно начинать на Pascal он изи, и только так можно выучить алгоритмы». Котлин сейчас еще слишком молод чтобы знать только его и ничего больше.
Fesor
12.12.2017 23:14ибо если хоть в одном случае окажется, что Java лучше Kotlin
я вот честно не могу придумать хоть одного кейса где java лучше kotlin. Ситуаций где они окажутся равны друг другу — это да. А вот что бы java была лучше и удобнее… Хотя возможно я чего-то не знаю. Если вы сможете предложить подобный кейс — будет интересно.
Djaler
12.12.2017 23:48What Java has that Kotlin does not:
Checked exceptions
Primitive types that are not classes
Static members
Non-private fields
Wildcard-types
Важно ли это — не думаюFesor
13.12.2017 09:21По приведенной вами ссылке можно перейти по каждому пункту и выяснить почему это отсутствует. Там и мотивация почему так, и какая альтернатива… возможностей у вас меньше не стало, да и не забывайте что у Kotlin должна быть совместимость c Java так что в целом отсутствие чего-то не означает что вы не можете чего-то сделать.
В целом я считаю что отсутствие перечисленного это плюс. Ну и сравнивать таким образом языки слишком примитивно.
vlad2711 Автор
12.12.2017 23:52Пожалуй стоит начать с того что Котлин это следующее поколение, а как известно следующее поколение всегда превосходит предидущее, он создан на основе Джавы, с учетом всего крутого и всех косяков, и действительно тяжело найти кейс где Джава впереди
Lure_of_Chaos
13.12.2017 06:45я бы сказал так: котлин — это джава, какой она должна была бы быть. Котлин перенял многие вкусности из других языков, в то время как джава очень неспешно меняется и зачастую не в том направлении, в котором хотелось бы.
И кто знает, не поспешил ли котлин в погоне за модой и не ждет ли его та же печальная судьба?Fesor
13.12.2017 09:02очень неспешно меняется и зачастую не в том направлении, в котором хотелось бы.
тут на самом деле все очень просто. Для того что бы эволюционировать — нужны эксперименты. Kotlin, Scala и некоторые другие JVM языки являются своего рода экспериментами. Определенные идеи могут спокойно перетечь в java, подтолкнуть его развитие.
Экспериментировать же с самой java весьма дорого, так как язык должен иметь обратную совместимость и неудачную фичу, которую вроде и продумали но не предугадали последствий, выпилить уже не выйдет.
myxo
12.12.2017 22:22+1Опрос:
*Java, эти аргументы неубедительны
*перейду на Kotlin прям сегодня
*я уже давно на Котлине
*Возможно начну кодить на Котлине через месяц другой
Жизни за МКАДом не существует? =)Idot
13.12.2017 05:15У нас в городе ровно одна вакансия по Kotlin, и 162 вакансии о Java.
Так что я сейчас собираюсь учить именно Java. Потому что, увы, практически исчезли чистые вакансии по PL/SQL, и в основном требуют PL/SQL + Java.
PS посмотрел Москву: 77 вакансий по Kotlin, против 1770 по Java и 1116 по C#.
vlad2711 Автор
13.12.2017 11:48Я не говорил про вакансии чисто по Котлин. Откройте вакансии по андроид разработке. В скиллах будет написано обязательное знание Джавы, а ниже почти в каждой пятой вакансии будет написано: будет круто если вы еще знаете Котлин.
Раньше такого было намного меньше, а сейчас таких вакансий все больше с каждым днем. Становится очевидным что Котлин набирает популярность. Это как Свифт на ios. Был Objective C вроде нормальный язык, но появился новый Swift, и через какие-то пару лет он уже отъел половину рынка. Не исключено что скоро это повторится и с андроидом.Idot
13.12.2017 12:09hh — не показывает вакансии "чисто по Котлин", он показывает ВСЕ вакансии в которых это слово упоминается, а их в Москве 77 вакансий.
yarric
13.12.2017 13:18Swift полностью поддерживается Apple, включая документацию, обучающие материалы и примеры. А насколько Google поддерживает Kotlin, кроме возможности создания на нём проектов в Android Studio?
vlad2711 Автор
13.12.2017 13:38Документации на Котлин действительно немного, это можно отнести к разряду минусов, но в скором времени это должно изменится. Официально гугл поддерживает Котлин, но документации по Джаве на порядок больше, ведь она существует куда дольше чем Котлин. И все же людей которые на него переходят все больше и больше, поэтому если Котлин будет развиваться, то и документации будет больше. На самом деле на текущий момент в сети полно туторов, курсов, примеров именно на Котлине, так что кто захочет тот найдет.
На текущий момент комьюнити Котлина по численности сильно уступает комьюнити Javqwert_ukg
13.12.2017 13:51Документации на Котлин действительно немного
Документация по Котлину исчерпывающая, на сайте производителя. В слак каналах поддержка осуществляется самими разработчиками. На текущий момент 13447 пользователей, комьюнити очень дружелюбное и помощь поступает незамедлительно.
yarric
13.12.2017 13:52Не просто по Kotlin надо, а по Android SDK. И официальную документацию, а не Hello World-ы на коленке.
vlad2711 Автор
13.12.2017 14:15Начнем с того что в Котлине можно использовать Джава классы и поэтому вполне можно использовать документацию Джавы, и не будет никаких проблем.
Честно говоря когда я делал трекер мне требовалась документация на уровне синтаксиса, а части которые относились к Android SDK я писал по аналогии с Java, и при этом не возникало никаких проблемIdot
13.12.2017 14:18писал по аналогии с Java
Современный вариант классического "программист на Фортране, способен на любом языке писать на Фортране"?
basnopisets
13.12.2017 22:16+1настолько, что Google нанял Джейка Вортона работать над поддержкой Котлин.
Один из первых результатов его работы — Kotlin code styleyarric
15.12.2017 10:25+1А это кто?
vlad2711 Автор
15.12.2017 10:44О мой Бог, вы не знаете кто этот Великий Человек? Он ведущий разработчик в Square, и он подарил миру столько прекрасного и упрощающего рутину обычному программисту: Retrofit(создание запроса с минимальным количеством кода), ButterKnife(упрощение биндинга вьюшек до нельзя, всего одна строка кода на каждую вьюшку, вместо двух с findViewById), приложил руку к Dagger(улучшает тестируемость кода), и это далеко не весь список. Поэтому любой андроидщик хоть раз в жизни юзал творения над которыми он работал. Вот за это он один из самых известных и уважаемых людей в мире андроид разработки.
GrandArchTemplar
12.12.2017 23:48я вот честно не могу придумать хоть одного кейса где java лучше kotlin. Ситуаций где они окажутся равны друг другу — это да. А вот что бы java была лучше и удобнее… Хотя возможно я чего-то не знаю. Если вы сможете предложить подобный кейс — будет интересно.
секвенсес не могут в параллелизм
стримапи может в параллелизм
но это с точки зрения сахара
Terras
13.12.2017 00:12Картинка то какая. Телефон на Java убитый и заляпанный, а на Kotlin сияющий и блестящий. Какой-то дотнетщиной пахнуло =)
lgorSL
13.12.2017 00:57Нету Getter'ов и Setter'ов
Вы серьёзно?
Во-первых, они есть. Во-вторых, в котлине геттеры и сеттеры вовсю используются неявно и выглядят как обращение к переменной.
Единственный стоящий аргумент — про более короткий код, но пример к нему ужасен.
Почему бы не рассказать про автовывод типов, extension методы и прочие приятные штуки?
vlad2711 Автор
13.12.2017 12:03Ладно, они реально есть, но фишка в том что они уже зашиты в сам язык, и не нужно объявлять их в коде.
Solexid
13.12.2017 03:20Kotlin это когда хочешь писать на C# с JVM.
qwert_ukg
13.12.2017 06:07Давно простится статья «Kotlin vs C#». Сам ушел с C# на Kotlin, много плюшек есть в обоих языках (может потому что Бреслав работал в MS, до работы на JetBrains), но в котлине, на мой взгляд, все более удобно, те же екстеншены.
basnopisets
13.12.2017 22:24из команды Котлин Илья Рыженков ранее работал над Resharper — тоже без влияния C# не обошлось
qwert_ukg
13.12.2017 05:54NPE — это легенда в мире программирования. И в Котлине его просто нету еще до компиляции возможные места возникновения NullPointerException считаются синтаксической ошибкой. Вас просто заставляют сделать проверку на null.
Вот тут Вы слукавили, замечательно прилетает с джавы.Lure_of_Chaos
13.12.2017 06:40Речь не о джаве, а о том, что дизайн языка запрещает неявный null — либо мы явно используем billable (в джаве все по умолчанию) типы, либо нас заставляют описывать какой-то dummy объект вместо null. Ситуация схожая с проверяемыми исключениями в джаве — либо обработай, либо явно выбрось наверх.
Другой вопрос, хорошо ли это (т.к. почти во всех статьях восхваляют данную фишку). Возможно, пусть прога лучше со свистом грохнется и покажет стектрейс, с исправлением ошибки за минуту, чем прога будет работать, но работать неправильно и хрен ты эту логическую ошибку найдешь.qwert_ukg
13.12.2017 06:45Я про то, что NPE на рантайме, и в котлине поймать можно.
Lure_of_Chaos
13.12.2017 06:49О том и речь — конечно, как явление, NPE в котлин существует, но случайно написать код, который его производит, уже чуть сложнее
vlad2711 Автор
13.12.2017 11:52Суть в том что его поймать тяжело. Конечно если сильно постаратся то и дьявола можно призвать. В Джаве вы можете просто забыть прописать проверку на null и у вас все крешнится. А Котлин заставит вас сделать проверку на null иначе он просто откажется компилироваться.
Arnis71
13.12.2017 10:05Типичный статья фаната Котлина который даже не знает о всех его преимуществах и думает что его сила только в украшательствах и сокращении кода. Крайне печально.
qwert_ukg
13.12.2017 10:46Может Вы подскажете в чем сила?
Arnis71
13.12.2017 15:17Таких статей бесчетное количество. Например https://academy.realm.io/posts/oredev-jake-wharton-kotlin-advancing-android-dev/
vlad2711 Автор
13.12.2017 15:21Я описал то что реально меня очень впечатлило и чего я реально не ожидал. Если бы я описывал все его фичи, то статья б началась и закончилась ссылкой на документацию по Котлину :). А так я лишь делился своими ощущениями и впечатлениями.
maxzh83
13.12.2017 10:274. Код на порядок короче
Слышали про Lombok? С ним ваш пример на Java приблизится к Котлину
3. Отсутсвие NPE
Лукавство. Есть механизмы по его предотвращению, но сам по себе NPE есть и никуда не делася
1. Отсутсвие точек с запятыми
Тут я сдаюсь и перехожу на Котлин )
Если серьезно, то почему бы не написать про действительно интересные вещи типа корутин, extension, легкости написания dsl и т.д.?qwert_ukg
13.12.2017 10:39Если серьезно, то почему бы не написать про действительно интересные вещи типа корутин, extension, легкости написания dsl и т.д.?
Про корутины, это да, а про все остальное тут полно всего.
vlad2711 Автор
13.12.2017 16:21Lombok — это круто, но это сторонняя библиотека, а здесь уже все зашито в сам язык
OLDRihard
13.12.2017 11:18Вот когда хайп уляжется и статьи про поней какающих радугами сойдут на нет, тогда посмотрим.
Konachan700
13.12.2017 11:501. Отсутсвие точек с запятыми
Мне Котлин напомнил VB этим пунктом. Со многострочными конструкциями снова будут прыжки с бубном и обратными слешами? И конструкция a?.b?.c?.d() подозрительно напоминает On Error Resume Next, создающий массу неопределенного поведения.
В целом сама идея Котлина годная, но многие вещи очень спорны пока что.
Space_Cowboy
13.12.2017 11:54Хватит рекламить этот котлин! Такое чувство что JetBrains проплачивает такого рода посты. Я лично за Скалу, зачем вообще он был нужен, когда скала на момент создания уже была?
vlad2711 Автор
13.12.2017 12:01Ну Скалу все равно считают довольно сложным языком, да он легче чем тот же Си, но все же…
Честно говоря еще неделю назад я тоже думал что в нем нету ничего такого. Но виной был страх что-то менять и было немного лень напрягаться.Enverest
13.12.2017 16:26А в чём выражается сложность Скалы? Синтаксис? Стандартная библиотека? Фреймворки? Тулзы для работы?
lgorSL
14.12.2017 15:20Да ни в чём.
Синтаксис простой (на мой взгляд проще, чем в котлин).
- В котлине есть специальный синтаксис для определния геттеров-сеттеров, в скале это просто методы типа
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 является неявным)
Получается, что в скале идут по пути обобщения и упрощения синтаксиса, а в котлине добавляют маленькие удобные костылики. С костыликами хорошо, пока не захочется сделать что-то необычное.
Стандартная библиотека у скалы своя. Более мощная, чем в джаве и огранично вписывается в язык. Впрочем, написать свою коллекцию будет сложнее. Можно использовать джавовские коллекции.
Фреймворки — там могут очень много навертеть, используя систему типов на полную катушку. Вряд ли это недостаток языка.
Про тулзы — не знаю что сказать.
qwert_ukg
15.12.2017 06:03В котлин можно переопределить только несколько операторов, в скале — почти всё, что захочется, хоть ||, хоть !!!
А зачем?
- В котлине есть специальный синтаксис для определния геттеров-сеттеров, в скале это просто методы типа
vshaldin
13.12.2017 12:15Со стороны JetBrains, создание своего языка — очень годный ход. Это определенная сфера влияния в бизнесе, которая напрямую ведет к обогащению. Я же не думаю, что есть люди, которые верят в утверждение «мы создали его, чтобы вам было удобнее»? Тот же Oracle, не «так просто» скупает платформы, языки и системы.
vlad2711 Автор
13.12.2017 12:16JetBrains сделали Котлин в первую очередь для себя. Они активно юзают его внутри компании
Flux
13.12.2017 23:11Настолько «для себя» что этот котлин форсится так неистово, что даже не хочется к нему прикасаться.
На каждом втором русскоязычном бложеке по триста статей уровня «почему котлин в триллион раз лучше жавы, начинайте писать уже сейчас!!1», кликбейты про «новый основной язык разработки под ведроид» и просто откровенная реклама.
Когда тебе так настойчиво запихивают в рот какую-то «вкусняшку», непроизвольно возникает тошнота.Fesor
14.12.2017 13:10С другой стороны только так что-то может получить популярность, увы. Скил фильтрации информации подразумевает ее анализ а не игнорирование.
Flux
15.12.2017 19:20Не только.
Реклама может содержать описание качеств продукта и оставлять пользователю выбор использовать его или нет — если продукт хороший пользователь сам придет к «продавцу». Если бы во всех этих статьях было бы только описание особенностей языка и то какие проблемы он решает — я бы наверняка попробовал на нем писать. Это была бы хорошая реклама которая уважает пользователя.
Есть другая реклама — полные императивных посылов крики «покупай, пользуйся, делай!!11» без единых описаний почему я должен пользоваться чем-то. Это реклама стиральных порошков, бытовых товаров и прочьего ширпотрепа — попытка перекричать голос разума яркими метафорами и безудержным восхвалением. Вот такая реклама у котлина и такая реклама вызывает только тошноту, потому что авторы считают идиотом неспособным к критическому мышлению которого нужно подтолкнуть в сторону «правильного» продукта.
basnopisets
13.12.2017 22:22+1используя скалу тебе надо тащить весь язык со всеми его библиотеками. Котлин работает поверх Java, коллекции Котлин — это обычные коллекции из Java, например, и потому размер его стандартной библиотеки значительно меньше. Для Андроид, в частности, это очень важно
Space_Cowboy
14.12.2017 10:58Я не андроид разработчик, но всетаки поинтересуюсь:
Котлин работает поверх Java
Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM потом интерпретируется ведроид компилятором под DVM. Не очень понял что вы имеете ввиду?
тащить весь язык со всеми его библиотеками
Боюсь спрашивать, но куда и за какое место вы хотите тащить языки?vlad2711 Автор
14.12.2017 11:05Да, он работает поверх Джавы. Поэтому в Котлине можно юзать все что написано на Джаве. Еще он может компилиться в байт-код javascript
Space_Cowboy
14.12.2017 11:21-1работает поверх Джавы
Что вы все заладили, что в вашем понимании это означает? Я то думал это предусмотренная компилятором обратная совместимость с Java, в Scala тоже самое, потому что котлин это попытка JetBrains написать свою скалу, и что то мне подсказывает что писали они ее не с 0.
байт-код javascript
Что простите? (facepalm) В какой из множества вариаций javascript — bytecode, или они заставили все браузеры перейти на оди и тот же компилятор?
Складывается впечатление что у людей напрочь отсутствует понимание, того как работают языки вне красивых кнопочек и подсветок в их IDE…vlad2711 Автор
14.12.2017 11:24Честно говоря я это не проверял но в документации читал что он может компилиться в javaScript
Space_Cowboy
14.12.2017 11:44Да может, но не в javaScript Bytecode, У Scala тоже есть интерпритатор в js. ScalaJS называется вроде.
basnopisets
14.12.2017 11:13Kotlin, как и Scala, как и Java компилятся в JavaByteCode под JVM
Котлин написан поверх Java и в стандартной библиотеке, к примеру, не имеет своих коллекций, потому что он использует стандартные коллекции из Java. Если посмотреть к примеру ImmutableList — в байткоде это будет стандартный ArrayList из Java. И большая часть библиотеки Kotlin — это extension-функции над существующими классами Java. Поэтому рантайм и библиотека Котлин занимают в разы меньше места, чем аналогичный от Скалы.
Боюсь спрашивать, но куда и за какое место вы хотите тащить языки?
Юморок на троечку. Посмотрите структуру apk — основную часть занимает dex-файл(ы). А еще поищите про dex-limit, почитайте вопли юзеров в Play Market, недовольных лишним мегабайтом размера приложения, и вы поймете, что Скала существенно увеличит размер установочного файла.Space_Cowboy
14.12.2017 11:33-1Теперь ясно что и куда тащиться) Действительно в этом приемущество Kotlin.
iki
14.12.2017 11:05Ну что, вам листать не надоело?
Чтобы избежать бойлерплейта, можно использовать lombok: projectlombok.org/features/all
akryukov
Справедливости ради, стоит заметить, что в Java сеттеры и геттеры не обязательны. А в этом конкретном случае с ResponseItem от них не так уж много пользы.
Если потребуется описать только геттеры, то код модельки на Kotlin из кареты превратится в тыкву, сопоставимую с кодом на Java.
vlad2711 Автор
Тут вы безусловно правы. Но как я сказал ранее: адаптер на Джаве занял 80-90 строк, в то время как на котлине только 50
akryukov
А зачем там одновременно аннотации @Expose и @SerializedName("...")? Они не конфликтуют?
vlad2711 Автор
Да нет все ок. Просто pojo генератор так сгенерил, вот и все.
Serg_de_Adelantado
Завит от того, зачем нужны только лишь геттеры. Если для создания неизменяемой модели, то у Kotlin есть val:
Если же нужно поместить какую-то логику в геттер, то можно так:
qwert_ukg
Вот так описывается поле с геттером
domix32
А что с ситуацией когда одному только почитать, а другому еще и пописать? Два интерфейса?
jericho_code
Стоит отметить что data классы содержат реализации методов equals, hashcode, toString и componentN (для расщепления классов), так что на java ваш класс был бы еще больше. Что важно эти методы реализованы разумно, и разработчики языка учли множество подводных камней при их реализации.