Даже Борисов постоянно говорит, что в первую очередь теперь Spark ориентирован на поддержку Java, потому, что с выходом восьмерки, скала потеряла хайп.

Какого сахара то?:) кроме паттерн матчинга и кейз классов, ну и 2x Pair, Function классов не знаю ничего чем бы она разительно отличалась :) ну и имплиситов, которые из кода делают хардкор

Пропертей, экстеншен методов.

Какого сахара то?:) кроме паттерн матчинга и кейз классов, ну и 2x Pair, Function классов не знаю ничего чем бы она разительно отличалась :) ну и имплиситов, которые из кода делают хардкор

Переопределение операторов, аргументов по умолчанию, именованных аргументов.

Это уже не мало.

Даже Борисов постоянно говорит, что в первую очередь теперь Spark ориентирован на поддержку Java, потому, что с выходом восьмерки, скала потеряла хайп.

1) он за это деньги получает, "даже" тут неуместно, он один-единственный такое и говорит :) 2) скала хайп потеряла лет 5 назад

Переопределение операторов, аргументов по умолчанию, именованных аргументов.

Это все, конечно, прикольно. Но не убедительно.

Это все, конечно, прикольно. Но не убедительно.

Эм? Что убедительно должно быть? Это то, что облегчает, упрощает код.

или усложняет

ну и вообще, у спарка очень классный (на мой взгляд) кодстайл, минимум колдунств

или усложняет

Как это усложняет код?

Вот простой пример: билдер паттерн. Такое уродство из-за бедноты языка.

Как это усложняет код?

ну переопределил ты оператор, а новый человек на проекте не знает об этом

Эм? Что убедительно должно быть? Это то, что облегчает, упрощает код.

Это не упрощает код. Это его усложняет. Особенно переопределение операторов

да не только переопределение

ну переопределил ты оператор, а новый человек на проекте не знает об этом

Вот изменил ты метод, а человек на проекте об этом не знает.

в смысле не знает?

Это не упрощает код. Это его усложняет. Особенно переопределение операторов

Чем? Писать + вместо add всяко удобнее. И понятнее, чем городить цепочки методов.

да не только переопределение

А что ещё?

имплиситы

имплиситы

Нужна ли неявность - это спорно. Всё же код должен быть понятным. + в случае имплиситов нет инструмента, который помогает тебе.

Чем? Писать + вместо add всяко удобнее. И понятнее, чем городить цепочки методов.

Это спорно, если ты работаешь всю жизнь с этим языком - это ок. А представь себе пришёл к тебе на проект тот чувак, которому насоветовали скалы вагон и две тележки. А он джавист в прошлом, взял и начал хуячить переопределенный твой +, который на самом деле может непонятно что делать. Плюс он ещё будет год тупить и разбираться с имплиситами, паттерн матчингами. Язык прикольный не спорю, но порог вхождения на него явно выше, следовательно спецов меньше, следовательно это невыгодно.

Это спорно, если ты работаешь всю жизнь с этим языком - это ок. А представь себе пришёл к тебе на проект тот чувак, которому насоветовали скалы вагон и две тележки. А он джавист в прошлом, взял и начал хуячить переопределенный твой +, который на самом деле может непонятно что делать. Плюс он ещё будет год тупить и разбираться с имплиситами, паттерн матчингами. Язык прикольный не спорю, но порог вхождения на него явно выше, следовательно спецов меньше, следовательно это невыгодно.

Я не за скалу, я говорю, что джава - бедный язык и ему очень не хватает сахара.

Джава нормальный язык и без сахара хорошо обходились и обходимся. А через n лет, может, и сахар будет

В тему :) но это не хейтинга спич :)

о, старые песни о главном

Васильев как всегда песенку сисярпа запевает

главное, чтобы у языка было крутое коммьюнити, опенсорс и отсутствие безальтернативного проприетарного говна

поэтому дотнет - дно

Васильев как всегда песенку сисярпа запевает

У всего есть минусы. И минусы джавки решить гораздо проще, чем сисярпа)

где купить?

главное, чтобы у языка было крутое коммьюнити, опенсорс и отсутствие безальтернативного проприетарного говна

У сисярпа есть что-то из этого?)

Если и есть говно, то оно опенсорсное)

опенсорс

Да ладно, каждый жавист тайно мечтает прогать на сисярпе

Не, серьёзно. Чего джаву слаще делать не хотят?

Мб как язык сисярп лучше, но платформа пока не очень

Мне на котлин норм

А на си++ никто не хочет ?

С++ это некрофилия

Ура, я некрофил

А на си++ никто не хочет ?

Он очень гибкий) Даже скала по сравнению с ним сосёт.

Я с++ только, чтобы с алгоритмами побаловаться беру.

Не, серьёзно. Чего джаву слаще делать не хотят?

Священная корова

Но сахарок чутка вкидывают вроде, маааленькими дозами

Что мало верю то. В сисярпе полно фич которые жаба погромисты хотят. Я говорю именно о языке, не о дотнете

Более того, там есть фичи которых в жаве просто никогда не будет

Даже при условии что сахар будет добавляться

есть кОтлин

Более того, там есть фичи которых в жаве просто никогда не будет

Например?

есть кОтлин

И что?

Например?

Проперти

есть кОтлин

Да, потому котлин и молодец

Проперти

Почему проперти не могут оказаться в джаве?

Почему проперти не могут оказаться в джаве?

Потому что священная корова

Добавление пропертей поломает обратную совместимость много где

Добавление пропертей поломает обратную совместимость много где

Блин, я думал над этим, но не смог придумать. Где проперти обратную совместимость поломают?

Гётс тоже сказал, проперти - забудьте

Блин, я думал над этим, но не смог придумать. Где проперти обратную совместимость поломают?

Ну как сейчас происходит доступ к полю класса — getfield, putfield

Если расширить семантику инструкции, вызывать геттер на месте где стоит getfield, то невозможно предсказать, сохранится ли поведение

короче, учите скалу, чуваки

запомните этот твит

Ну есть конечно способ - ввести новые байткоды, но это делают коайне нежелательно. На indy надежда, развн что. Но работать это тогда будет только для нового кода. Я так понимаю к такому тоже относятся крайне осторожно

короче, учите скалу, чуваки

Груви наше всё :p

Если расширить семантику инструкции, вызывать геттер на месте где стоит getfield, то невозможно предсказать, сохранится ли поведение

Проперти - это же задача компилятора, а не jvm. Причём тут опкоды?

Проперти - это же задача компилятора, а не jvm. Причём тут опкоды?

Кто опкоды делает? Компилятор.

ERROR: S client not available

Кто опкоды делает? Компилятор.

Я про то, почему нельзя сделать так, можно было кратко записать переменную, геттер для неё и сеттер. А не как сейчас генерировать лапшу.

Я про то, почему нельзя сделать так, можно было кратко записать переменную, геттер для неё и сеттер. А не как сейчас генерировать лапшу.

Тайна покыратая мраком.

а чем плох вариант "если есть явный метод get/set, то использовать его, иначе -- доступ напрямую" ?

а чем плох вариант "если есть явный метод get/set, то использовать его, иначе -- доступ напрямую" ?

Это и есть изменение поведения

а чем плох вариант "если есть явный метод get/set, то использовать его, иначе -- доступ напрямую" ?

Тащить в компилятор поведение для совместимости - очень плохо.

У тебя может код и написан так что ты не хочешь чтоб там геттер вызывался, а тут бац, и ввзвался

Более того, даже в стандартноц библиотеке есть примеры когда геттер по названию нефига не геттнр по поведению

можно сделать "метод, который надо определить, чтобы он считался геттером" не getX

У тебя может код и написан так что ты не хочешь чтоб там геттер вызывался, а тут бац, и ввзвался

Эм, геттер в текущем понимании или как?

можно сделать "метод, который надо определить, чтобы он считался геттером" не getX

Вон в сисярпе сделан такой метод - нет имени, нет проблем)

Вон в сисярпе сделан такой метод - нет имени, нет проблем)

ну и в скале тоже :) согласен с тем, что методы getX/setX часто ни разу не просто геттеры с сеттерами, но это обходится

Эм, геттер в текущем понимании или как?

Делает чтото более чем возвращает поле. Например, это поле инициализирует

Я помню пробовал первые версии цейлона так пробовал и он изза этого на совместимости с жавой ломался просто

Сейчас уже примера api не помню но ребус был порядочный

Делает чтото более чем возвращает поле. Например, это поле инициализирует

Смотри. В геттеры в виде методов пусть остаются для совместимости. А почему не добавить гет-сет как это сделано в сисярпе. Бинарная совместимость?

Хотя бинарная совместимость в плохом коде да, может сломаться.

Хотя бинарная совместимость в плохом коде да, может сломаться.

Может. Ну может они после жигсо и смелости наберутся :) один раз поломают дофига всего, может понравится :)

Груви наше всё :p

А что вы пишите на груви и чем так нравится?

А что вы пишите на груви и чем так нравится?

Лично я использую груви для скриптов - написать и выкинуть. Для боевого кода в бизнес приложение я бы груви не понёс. Разве что для очень специфичной задачи

DSL - вполне себе задача в бизнес приложении и не только

А так это засахаренная джава - что не так?

А так это засахаренная джава - что не так?

Груви - засахаренная джава?

Ну да, интероп достаточно прозрачный

Делегаты, замыкания, моп, неявно приведение типов и тд сахар?

Похоже что все, что запускаться на жвм, тогда будет жавой с сахаром

Даже руби

Тут главное интероп. Чтобы из джавы в груви и наоборот ходить - без использования многих фичей можно писать код. Только замыкания поперек лямбд (пока что).

Тут главное интероп. Чтобы из джавы в груви и наоборот ходить - без использования многих фичей можно писать код. Только замыкания поперек лямбд (пока что).

Есть интероп с джавой => джава с сахаром?

Правильно я понял мысль?

Правильно я понял мысль?

Нет, чем ждать сахара в джяве, проще подключить груви и все. Скала и котлин нинужны.

Нет, чем ждать сахара в джяве, проще подключить груви и все. Скала и котлин нинужны.

Нельзя так просто взять и подключить груви. У груви своя семантика для некоторых вещей, груви - динамически типизированный язык, ну и перфоманс