Kotlin vs Scala вкратце

[lex_kravetski]

Прочитал официальную документацию к Котлин. Написана, кстати, очень хорошо - больше похоже на увлекательную книгу, чем на формальный мануал.

Однако выводы, если вкратце:

1. Kotlin бодро развивался все последние годы, поэтому фич в нём нормально уже так. Уже не слегка подрихтованная Java.


2. Однако он всё ещё «половина от Scala», увы. Правда, половина

Comments

[zimopisec]

А я так и не осознал, чем итераторы лучше старого доброго цикла for и while.

[lex_kravetski]

Записывается в несколько раз короче и не зависит от типа контейнера.

[dargot]

Приветствую!

Итераторы, как и все абстракции, лучше тем, что позволяют программисту, используя стандартные конструкции языка, писать более лаконичный код - а другой программист, глядя на эти стандартные конструкции, сразу понимает, что имел в виду автор. Без заглядывания в тело цикла.
Представьте себе, что вы ставите кому-то задачу: отобрать из массива элементы больше 5, умножить их на два, отсортировать, положить в другой массив. Как вы ее формулируете, так ведь и формулируете?
Или пишете: введи переменную idx, присвой ей значение 0. Проверь, не равно ли значение idx размеру массива, если нет, то возьми элемент массива с индексом idx. Если он больше пяти...
Неудобно и больше возможностей для ошибки. Если язык позволяет формулировать задачи в первом виде, а не во втором - это удобно.

С уважением, Dargot.

[lipkalapka]

Но в принципе это не требует какой-то феноменальной переработки языка, фор в форич автозаменой переделывается, точнее наоборот.

[lipkalapka]

Футуры и корутины - это всё-таки идейно разные штуки, так что хотелось бы их всех иметь.

[lex_kravetski]

Реально, в плане использования не особо-то и разные.

[redneck_prm]

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

Гошечка. Полыхает.
Не, для слайсов и мап foreach есть, хоть и страшненький.
А вот для container/list уже прямо в доке предлагают такое:

for e := l.Front(); e != nil; e = e.Next() {
// do something with e.Value
}

[poxu]

> А вот для container/list уже прямо в доке предлагают такое:
> for e := l.Front(); e != nil; e = e.Next() {

Это, кстати, каноничный пример испльзования итератора. А мап и форич - это вообще не про итераторы

[redneck_prm]

>> Это, кстати, каноничный пример испльзования итератора.

Времен мезозоя. На синтаксическо-сахарном уровне итератор - это в первую очередь способ единообразно пробежаться по любой коллекции.

[poxu]

А скажи ещё что-нибудь на синтаксическо-сахарном! )))

[ext_5488036]

Как один из писавших "интересно посмотреть Scala в сравнении с Kotlin".

Критерием сравнения выглядит: "больше возможностей - лучше".
Но ведь Scala дизайнилась, как "максимально гибкий язык", а Kotlin как "максимально прогматичный" (если верить https://www.youtube.com/watch?v=xH-RZ9YlxH0 - то намерение было включить только то, что действительно нужно).

Исходя из этого хотелось бы критики: "вот авторы Kotlin посчитали, что фичи X, Y и Z будут программистам не нужны, а они _реально нужны_ ". Сколько таких ситуаций на практике возникает?

Мне вот (когда смотрел Kotlin - может уже исправили) ровно одна нужная попалась:
- отсутствие нативных исключений в асинхронном коде
- невозможность реализовать Either
В итоге получается, что нормальной обработки ошибок в асинхронном коде нет. Используйте коды возвратов.

[lex_kravetski]

Нужность зависит от предметной области. Если, например, чел программирует некую «универсальную» математику, то ему нужно одно, а если графический редактор - другое. Первый будет рвать на себе волосы по поводу отсутствия в Kotlin возможности оперировать тайпклассами, а второй, напротив, переживать по поводу сильно урезанного на фоне Scala множественного наследования

[ext_5488036]

1

[lex_kravetski]

> Почему бы не написать статью с, не знаю скажем 10 или 20 примерами,

«Подумываю написать сравнение прямо по разделам документации с примерами.»

> Если второй вариант не является "де-факто стандартом", то он несёт свои проблемы.

Стандартом является не использовать null.

> В Хаскеле - "что угодно можно написать самому или взять в уже написанной библиотеке" превратилось в 100500-libraries-hell в любом проекте уже на пару тысяч строк кода.

В данном случае это не про то: тут нет объектов, которые кто-то должен или не должен использовать. Тут только что-то типа макроса, который разворачивается в проверку на null.

> Я как раз прошу показать, где лишняя гибкость полезна, а не повторять это ещё раз.

Ну вот, например, удобно написать вот так:

x match {
case Person(Name(first, _, "Пупкин"), _) => println(s"Имя Пупкина - $first")
…
}

А сначала проверять тип, потом брать поля и сравнивать их вручную - длиннее и хуже читается.