Срач, который не начался...

[Garik]

Всё! Кина не будет!

 

[Oldestkon]

Этот спор можно продолжать бесконечно, а мне этого не хочется. Так что это конец)

Фууууу, слился. Никудышный какой-то из тебя инициатор срачей.

 

[JustAGod]

Ну так сам подключайся он мне нафиг не сдался))

 

[Oldestkon]

Мне кажется срач между 3 людьми, которые придерживаются примерно общей позиции, будет выглядеть слегка странно)
Да и ты на предложенные контр-аргументы всё ещё не ответил.

 

[JustAGod]

Ладно последний раз

Отсутствие необходимости куда-то конвертировать коллекции на интеропе с жабакодом - это плюс настолько очевидный и необходимый для проектов, которые не могут позволить себе быть завязанными на другой язык, что спорить с этим абсолютно невозможно. Если ты делаешь приложение с самого начала на скале и юзаешь скала-библиотеки, то тебе это безразлично, конечно, но мы-то тут модиками на майнкампф зарабатываем на хлеб.

val scalaList = javaList.asScala вот так происходит преорбразование)) Довольно просто, не так ли? Проведя бенчмарки я выяснил что в среднем конвертация занимает 90 миллисекунд. При том создание жава коллекции через Lists занимает 762 миллисекунд. Так что я думаю конвертация это не сильно большая проблема. При этом скала коллекции поддерживают ФП в полной мере и со всеми удобствами. В отличии от Котлина взаимодействие идет на уровне синтаксиса. Например for {i <- list; if i < 0} {} преобразуется в list.withFilter(_ < 0).foreach() на map есть тоже своя фишка) Так же например могу написать что то типа list forEach println и он выведет все элементы в консоль. И это все прям внутри класса в то время как в Котлине это где-то сбоку.

Я уже понял что ты за неделю не разобрался, не аргумент, нормальные люди разобрались))0

Где то может и есть такие гении, но это ни ты ни я))

А реальные примеры есть? Эти - куски лютого говнокода какие-то, без значимых причин так делать убил бы за такое. Первое выглядит как технический онанизм; подобное второму часто приводят в пример адепты скалы, но часто у вас в одной переменной Int и String могут быть? Бтв, второй пример почти один в один переписывается на котлин, так что ты опять подтвердил что тебе мало недели на пролистывание коротенького референса языка и немножко экспериментов с ним

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

 for (y <- 256 to 3 by -1) {
            val block = world.getBlock(x, y, z)
            block match {
                case Blocks.lava | Blocks.water => return -1
                case some: Block if some.getMaterial != Material.air => return y + 1
                case _ => ()
            }
        }

Или например у меня в модели есть вершины с костями и без. Вот такими будут классы:

sealed class Vertex protected()

case class SimpleVertex(x: Float,
                        y: Float,
                        z: Float)

case class BoneVertex(x: Float,
                      y: Float,
                      z: Float,
                      bone: Int,
                      influence: Float) extends Vertex

Тогда можно делать следующим образом

def processVertex(vertex: Vertex): Unit = {
        vertex match {
            case SimpleVertex(x, y, z) => // Чо-нить тут делаем
            case BoneVertex(x, y, z, bone, influence) => // Делаем тут чо-нить другое
        }
    }

Удобно и практично. Можешь отрицать, но это так

Нативная поддержка - это не когда плагин ставится за секунду, а когда плагин делают плюс-минус те же люди, что делали основной функционал IDE, и он в целом сделан на том же уровне.

Плагин как бы от JetBrains и как бы он тоже не плох. Соглашусь что немного послабее чем для котлина, но я предпочитаю думать что это из-за сложности языка)

Зато я уже говорил про скорость компиляции, и упоминание тут hohserg'ом инкрементального компилятора как будто это какой-то успех - не аргумент, он есть у всех. Надеюсь сам свяжешь скалаимплиситы с ее скоростью компиляции))

Ты же не компилируешь код каждые 20 секунд, максимум при дебаге. А там как бы инкрементально. Какие проблемы? Но вот код ты пишешь много и часто. И вот писать один и тот же параметр 200 раз в разные функции как то не хочется. И вот тут выходят неявные параметры)) Так же неявными параметрами могут считаться сингельтоны (object). Так же удобны неявные функции с помощью которых я могу писать код вплоть до такого:

val input = new InputStream()
val age: Int = input

А зачем её инлайнить-то? Работает как любое другое delegated property, никаких лишних временных объектов на повторном доступе не создается. С точки зрения перформанса инлайнить в jvm-байткоде есть смысл только там, где за счет этого получается избавиться от лишнего мусора в куче, остальное jit и так заинлайнит как ему надо. Видел бенчмарк на тему перформанаса делегатов, там как раз было про ленивую инициализацию, стоимость доступа получалась +10% относительно обычной проперти. Не вижу ничего криминального, наоборот вытащить фичу из компилятора в стдлибу - это же прекрасно, нет?

Лишний класс!11!! + несколько байт!!11! Вас это обычно волнует

 

[CumingSoon]

Ты такой же жирный тролль как ... Кхем. Если прочитать доки по Котлину, то можно понять, что данное поведение не случайно. Поэтому иди читай.
Кстати, если руки кривые (а они кривые, если доки не удосужился открыть), то что скала, что Котлин, что супер-пупер-пишущий-код-по-заказу-язык -- говно.

 

[Dahaka]

Или например у меня в модели есть вершины с костями и без.

Убил бы за такое.

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

Чета такой себе пример. Тут и обычный иф нормально зайдет.

val mat = block.material
if (mat !== Material.air && mat !== Material.water && mat !== Material.lava) {
    return y + 1
}

 

[hohserg]

if менее читабелен

 

[Dahaka]

В данном случае прекрасно читабелен. И вообще не об этом речь была.

 

[JustAGod]

Чета такой себе пример. Тут и обычный иф нормально зайдет.

Знаешь, можно вообще любой case/match/when записать ифами. Так что вообще не аргумент))

Убил бы за такое.

Не сможешь хех)) И вообще давай обоснуй чего тут столь зашкварного?

 

[hohserg]

Наверное, жирно держать отдельный объект для каждой вершины

 

[JustAGod]

Ну да конечно. А что мне прикажете делать? Хранить массив байтов? Где первый байт это 0 или 1. Где 0 с костью 1 без. Далее идут 12 байт x, y, z а после опционально 8 байт bone, influence. Так как у меня инты я конечно же буду класть их в байт буффер, флипать, сортировать, и достовать как флоаты. Хотя о боже нет! Лишний объект! Я буду вручную находить мантису, порядок и знак. 0 лишних объектов. Хотя стоило бы подумать про 1 байт. Там же целых 7 лишних бит! Что ж вариантов нет. Придется идти к JNI и писать все на C. Лишние 7 бит в куче позволить себе никак нельзя.

 

[Oldestkon]

Тебе, вообще-то, всё абсолютно правильно сказали, и про жирно, и про убить.

Вершин в моделях на практике может быть очень и очень много, и если для каждой создавать объект, который к тому же не имеет практического смысла кроме "ой мне так нравится" - это диагноз. Более того, вершины можно вовсе не хранить в ОЗУ, а загружать их на видеокарту и хранить только там. Грамотная скелетная анимация реализуется полностью на GPU, кроме сборки скелета, который, как правило, хранится отдельно.

Пока из всего бреда, который ты пишешь, складывается впечатление что ты сидишь и дрочишь на максимально меньшее количество написанных символов и максимально большее количество синтаксического сахара на квадратный метр кода.

 

[hohserg]

максимально меньшее количество написанных символов и максимально большее количество синтаксического сахара на квадратный метр кода.

Почему бы и нет? Чем меньше кода(без ущерба читаемости и понятности) - тем лучше.

 

[CumingSoon]

Это так, но ты код пишешь для компьютера. Маленькие потери аккумулируются в большие, программа тормозит из-за чистки памяти. Оно нужно?