Comments 113
Сначала пройдемся по тому, что убрали за ненужностью.
- XML-вставки в код
Это что означает?
Что теперь я не смогу написать: val s = Text?
Парсер съел теги
val s = <html>Text</html>
// было
def x() {}
// стало
def x(): Unit = {}
// или
def x() = {}
- На CLR есть F#, который по духу и идеям очень близок к Scala.
- JVM работает под виндой, непонятно зачем нужен тогда CLR, который ни под чем другим не запускается.
- При разработке возникало множество проблем из-за различий внутреннего устройства виртуальных машин и различий в стандартной библиотеки.
- Одним из главных плюсов разработки на Scala является все-таки возможность использовать любую из миллионов Java-библиотек.
простите, хорошие библиотеки пишут только под Java?
Помню, пробовал я как-то на скалу перейти. И все было хорошо, пока не пришлось использовать одну стороннюю библиотеку для парсинга JSON'а. И во всем методах этой библиотеке скала мне говорила: «Type mismatch: expected _$1». До сих пор не знаю, что это было, но знакомство со скалой на этом для меня закончилось, библиотека была нужнее
Скорее всего ошибка в синтаксисе. Любой Java код можно вызвать из scala без проблем.
Потом уже, на проверку оказалось, что скале не нравится, когда используют наследуемые методы get и put от чего-то, реализующего Map. То есть таких вот:
class A extends HashMap
При этом, если написать
class A extends HashMap<Object, Object>
То все уже будет скалой воспринято нормально. Почему так — фиг его знает. Может, сейчас уже все нормально работает, проверять лень :)
<console>:15: error: type mismatch;
found : String("a")
required: Nothing
a.put("a", "b")
^
Причина простая: в scala данная строчка
class A extends HashMap
class A extends HashMap<Object, Object>
class A extends HashMap<Nothing, Nothing>
Тут вопрос не в совместимости scala с java, а в базовых знаниях scala.
Вот только это все равно не полная совместимость — библиотека-то лежит где-то в .jar спокойно, никто не будет лезть и пересобирать, меняя везде
class A extends HashMap
class A extends HashMap<Object, Object>
Тут проблема не в наследовании и не в Nothing.
Тут все еще проще и сообщение об ошибке именно такое, какое должно быть: тип аргумента метода put не совпадает с типом параметра. Тип параметра не указан, так что он выдается по номеру (_$1).
В java этот ужас — для совместимости с темными до-generic временами. Scala же просто требует явного каста в этом случае. Если у вас это часто встречалось, то достаточно было написать обертку в 3 строчки 1 раз.
Спасибо за ответ, загадка решена. Хорошо бы еще об этом писалось где-то явно — а то ведь куча всего работает с подобными классами, а гугл в поиске значения ошибки не особо помогает
public static void test(HashMap<?,?> hm){
hm.put("a", "b");
}
// Main.java:16: error: no suitable method found for put(String,String)
// hm.put("a", "b");
// ^
Сообщение от javac как-то не лучше.
Здравствуйте, ситуация значит такая.)
Вам другой участник дискуссии все объяснил, почему возникает ошибка и что компилятор выдаёт разумное сообщение, и почему оно разумное. Новы все же не желаете это понимать и стоите на своём что все дело в сложности языка. Да я не спорю скала язык сложный, относительно джавы. Но и джава будет сущим адом для любого начинающего, и все замечательные подсказки который даёт компилятор джавы, как вы заметили в сравнении с компилятором скалы, будут не понятными до ужаса для этого начинающего. Вы так же можете пообщаться с любой бабкой у подъезда, она вам так же будет доказывать что все эти компьютеры не понятные, ужасны для понимания и лучше старый добры телефон, конечно если бабуля прогрессивная, если нет то просто крик что бы на соседнем участок услышали.
По этому все ваши нарекания на непонятную скалу это ничто иное как обычная дремучесть и не желание разобраться в вопросе.
Абсолютно любой инструмент требует его изучения перед использованием, и чем он сложнее тем сложнее процесс изучения.
Но в случае скалы на выходе вы имеете мощное средство для на написаны современных, лаконично выраженных и высоко производительных систем.
Нарекания же были на, читай, отсутствующие сообщения об ошибках, при этом при работе с одной из самых рекламируемых фич языка. Без объясняния senia я бы так и не узнал, вероятно, в чем было дело, так как гугл ответ на вопрос не знает, а в документации конкретно эта фича не изложена (как минимум не была полгода назад)
Достаточно бы было посмотреть тип переменной с точки зрения scala (в REPL или у Idea спросить) и все бы стало понятно.
Как минимум, некоторое время нельзя было использовать slf4j 1.7.x из-за несколько другой обработки перегруженных операторов:
import org.slf4j.LoggerFactory
object Main {
val log = LoggerFactory.getLogger(getClass)
def main(args: Array[String]) = {
val a = 1
log.info("test {}, {}, {}", a, "b", "c")
}
}Выдаст ошибку компиляции на scala 2.11.8 (openjdk 8u122, slf4j 1.7.10), идентичный же код на java выполнит boxing и выполнится корректно.
Так что не любой код на java можно вызвать из scala.
CLR, который ни под чем другим не запускается.
Простите, но тут вы неправы. CLR официально поддерживается и запускается под другими ОС: https://www.microsoft.com/net/download/core
Ну, вообще говоря, пока что виноват тулинг, который подводит. Собственно, тулинг для .NET Core сейчас в состоянии preview и находится, и его переделывают. А вот сам по себе рантайм и библиотеки в полном порядке, у меня работают в продакшене.
Но вы, конечно же, правы, это не то качество продукта, к которому мы привыкли. Пока что в полной комплектации он и не рекомендуется для полноценного использования (потому что инструменты сборки в preview).
И тем не менее, утверждение, которое я опровергаю, строго неверно. CLR сегодня запускается под основными платформами, будь то альфа-качество или нет. И, да, я осознаю, что в те времена, когда принималось решение о прекращении поддержки ScalaCLR, состояние дел было несколько иным. Более того — если это позволило перекинуть больше ресурсов на основную ветку разработки Scala, то я этому даже рад.
вы отстали от жизни, CLR теперь запускается на всех основных платформах. )
А вот вы не сведомы в хронологии событий, конечно проще вырвать фразу из контекста, но не стоит.
CLR, стал запускаться на всех платформах недавно. А прекращение его поддержки намного раньше.
Вы даже не удосужились прочитать комментарий написанный Optik от — " 27 ноября 2016 в 23:10" тогда как ваш, написан "28 ноября 2016 в 08:23". А он на текущий момент, на строчку выше вашего.
Я не ввожу в заблуждение, я не автор изначального сообщения.
Но как мне видится автор предполагал что общается со сведущим в теме человеком. Который понимает когда произошел отказ от CLR. А так да, если объяснять тому кто не знает хронологию событий нужно это уточнять. Напишите автору может он как-то эту не точность исправит.
Недавно вышел Scala Native — компилятор в нативный бинарник, основанный на LLVM. Это позволяет писать на Scala сверхбыстрый мгновенно запускающийся код и использовать низкоуровневые структуры данных.
Что, таки быстрее чем JIT? А тесты есть?
Ну тогда автору стоит яснее выражать свои мысли, сейчас это звучит так, будто магическим образом этот код становится сверхбыстрым, да еще и запускается мнгновенно.
И что странного в том что AOT компиляция может выдавать намного более оптимальный выхлоп, не будучи ограниченной по времени?
А вот старт — быстрее, несомненно. Ради быстрого старта и под java есть AOT компиляторы.
Во вторых — PGO нужен для линейной раскладки бинаря. Но главное что AOT может увидеть и размотать что нибудь, или векторизовать, чего JIT точно не будет делать.
Не забывайте, что профиль может меняться во времени, так что если вы заморочились и собрали профиль на тестовом стенде, то вам никто не гарантирует, что он актуален для боя.
Какая-то векторизация в jvm есть. Хоть и не уверен насколько мощная.
runtime, пока он прогреется. Вам нужен мгновенный запуск и чтобы все было быстро сразу.
Scala Native — это что-то уровня C. Оно может использовать низкоуровневые структуры данных, указатели, дергать функции из C и компилируется в честный бинарник.
На сайте есть примеры использования структур и объявления интерфейса к malloc, и получения указателя. То есть по сути вы пишете со Scala синтаксисом на C.
то вы не можете ждать пока у вас поднимется java runtime, пока он прогреется
т.е. питон мы подождем, а джаву нет?
time python Test.py
Hello!
real 0m0.030s
user 0m0.020s
sys 0m0.008s
time java Test
Hello!
real 0m0.111s
user 0m0.088s
sys 0m0.020s
Или вы визуально научились отличать 0.1s от 0.03s?
Если что это не основное использование (Scala|Kotlin) Native и тут их сложность совершенно излишняя. И уберите фразу про "сверхбыстрый", т.к. она вводит в заблуждение
Если у вас есть груви на машине предлагаю привести конкретные цифры. Думаю что время запуска увеличится почти на порядок по сравнению с джавой, ведь груви, как известно, тормозит.
Скрипт в моем случае — это измерялка параметров производительности приложения, для Nagios. Т.е. он подключается к определенному JMX Mbean другой JVM, достает его свойства, выполняет немножко простых расчетов, пишет результаты в файл, завершается.
Собствено, я хотел просто продемонстрировать, что время запуска JVM давно уже не ограничивает применение java для написания консольных утилит. Для человека это вполне быстро.
Немного возражу. Безусловно, вы не увидите разницы на единичном запуске. Зато прекрасно увидите, если данная утилита запускается раз эдак 200 подряд каким-то управляющим скриптом.
На проекте был случай — запускался набор тестов с использованием NodeJS. На каждый тест запускался отдельный инстанс. После того, как эту мини-утилитку переделали в примитивный сервер, которому все данные скармливаются через банальный сокет, время прогона уменьшилось раза в три. Просто за счёт толстого инита при запуске, который нельзя было обрезать никак.
Или вы визуально научились отличать 0.1s от 0.03s?
Во-первых ну да, отличу. Особенно если нужно запускать 100 раз подряд. Во-вторых почему вы сравниваете с питоном?
$ gcc in.c && time ./a.out
Hello world
real 0m0.002s
Под CLR существуют два главных языка — это C# и F#, которые соответствуют Java и Scala в JVM-мире. F# как и Scala развивается очень быстро, экспериментирует в слиянии различных парадигм и подходов. Все, что достаточно обкаталось на F# через пару лет появляется в C#. Так в новых C# появились кортежи, линк и вся остальная функциональщина.
Проблемой же Java в данном случае является маниакальный принцип совместимости с кодом 20 летней давности. И все новые идеи из Scala она в себя либо интегрирует очень медленно, либо не интегрирует вовсе. С интегрированным тоже есть проблема. Если вы посмотрите историю Java, то увидите, что многие решения интегрируются крайне криво из-за принципа полной совместимости. И каждая выходящая фича получается defective by design. Например, дженерики в Java, которые можно взорвать в три строчки. Объявление ко/контравариантности в месте вызова, а не объявления. Stream API из Java 8 тоже вышло очень сильно кривеньким и не таким удобным как в Scala.
А людям хочется программировать уже на чем-то более удобном, чем Java. Так и появился Kotlin, который, если вы посмотрите поближе, является смесью Scala и C#. И людям он понравился, потому что удобнее и красивее Java. Ну неприятно людям в 2016 году не иметь таких базовых удобств, как type inference например.
Несмотря на все вышенописанное все же хочу отметить, что Scala и F# — не являются просто песочницами для экспериментирования, а являются полноценными языками с собственной философией и парадигмой.
Kotlin выглядит привлекательнее только в очень ограниченном кол-ве случаев. И я, знаю только один, но точно объективный — разработка под андроид, т.к. у языка нет толстой стандартной библиотеки и окружения как у Scala. Которая попросту может занимать значительную часть размера приложения, что для Android недопустимо. Но для разработки ПО работающего на сервере это не играет роли.
По мимо этого Scala в противовес другим языкам, за исключением Clojure(из известных), язык с самостоятельной идей т.е. отрывающийся полностью от Java. К тому же с развитой экосистемой, которая имеет — мощную стандартную библиотеку и д.р. библиотеки, невероятно мощные фреймворки — как Akka, Play, Slick и д.р.
Получается что, Scala это не простая попытка чуть улучшить синтаксис, потому что синтаксис Java приелся. Scala это новая парадигма — мощная комбинация ООП и ФП, с множеством других особенностей принципиально отличающихся от Java. И это другой качественный уровень.
Более того языки как Kotlin, вредны потому что давят на экосистему Scala, в частности по средствам того что утверждают себя как альтернативу, что не так. Оттягивая ресурсы и людей от, лучшего на сегодня выбора — именно лучшего, я так говорю не из-за фанатическое веры в Scala, а потому что Scala это новые мощные абстракции, мощные библиотеки, мощные фреймворки, т.е. в целом инфраструктура. И все это в то время когда такие отсталый язык как Java и подход к разработке ПО как JavaEE проталкивают — именно проталкивают, используя огромные финансовые и административные возможности компаний их разрабатывающих. Но конечно только по этому вакансий на Java больше. Большинству это не нужно осваивать что-то, получку получил и доволен, даже в такой казалось бы высокоинтеллектуальной среде как разработка ПО. Такая комбинация факторов и привод к тому что Java до сих под доминирует.
Я с вам согласен что большинство "не очень". Если вы пишите какой ни будь типовой, crud для документооборота вашей команде возможно в принципе не нужна не то что Scala, но и сильные разработчики. Выгоднее нанять с десяток обычных. Но если у все серьёзное приложение, много данных, много операций, много пользователей. Вам скорее все придётся нанимать сильную команду и хорошенько продумывать архитектуру. Со Scala сильные специалисты справятся, а вся её инфраструктура им поможет написать отличный проект. Всякой задаче свой инструмент.
Но вот беда, когда начальство говорит что нет используйте javaEE(или аналоги), просто потому что это считается стандартом и у все на слуху или главный разработчик|архитектор говорит только javaEE!(или аналоги) потому что он больше ничего не знает, тут кстати вопрос как все они занимают свои должности. Становится грустно.
Касаемо магии, это не оправдание, компьютер сам по себе магия для большинства людей, но это не значит что от него нужно отказываться. Так же и со Scala, а уж если ты стал на путь разработчика, будь добр постоянно развиваться в этой теме, и система должна от тебя этого требовать, а не подходить с позиции если трудно то сразу отказываемся. Все изучаемо и доступно для понимания, в том числе Scala. Это не какие то невероятные требования, потому что все описано, все нюансы разжеваны, просто садись и читай в свободное время. Как и поступают все хорошие специалисты.
Касаемо «не значит что от него нужно отказываться. все изучаемо и доступно», как вроде бы говорил тов. Сталин: «Других писателей у меня для вас нет» :) Т.е. конечно все изучаемо и доступно, но в средней команде это не найдёт понимания, индустриальные решения тем и отличаются, что работают на больших массах средних юзеров/разработчиков и т.д.
Я вам предложу, возможность изменить ваше видение. Прочитайте первую главу "Akka in Action", она в свободном доступе на сайте издательства: 1. Introducting Akka.
Со Spring я очень хорошо знаком и по этому написал "javaEE(или аналоги)". Разумеется Spring намного лучше документирован и с его помощью проще создать систему чем используя JavaEE. Но все не же Spring это система старого поколения, относительно Play и Akka, со всем вытекающими, когда то он безусловно был самым лучшим выбором. Так же я вам предлагаю посмотреть этот твит: Modern comfortable programming language.
Далее, по порядку какие мифы в вашей голове может развеять 1я глава из Akka In Action.
Если у вас есть серьезная команда, то она и на яве напишет не хуже, чем на скале.
Можно написать на любом инструменте, вплоть до машинных кодов, но долго и сложно. Там вы найдете прямой ответ. Вопрос формулируется так же как ваш.)
А вероятность собрать серьезную команду скалистов очень небольшая.
Вероятность на самом деле такая же как найти хороших специалистов на Java, другими словами — хороших программистов.
Ну и про j2ee вы зря напираете, сейчас везде в бочке затычка уже спринг, и со схожими последствиями.
Spring имеет целую кучу проблем, которые по сути и обсуждает эта глава. Но она не о Spring vs Akka, конкретно. Она об стандартном подходе и о лучшем чем он подходе. Но нужно понимать что нет серебряной пули, просто для большинства современных систем нужно использовать адекватный, современный инструмент и он есть.
Касаемо «не значит что от него нужно отказываться. все изучаемо и доступно», как вроде бы говорил тов. Сталин: «Других писателей у меня для вас нет» :)
Касаемо данного тезиса, он не что иное как "Подмена понятий", потому что это не аналогичные ситуации. Когда у вас нет выбора и когда вам предлагают следующее поколение в подходах к разработке. Можете найти альтернативу из доступных сейчас, если вы сможете показать что она такого же качества, в возможности писать понятный лаконичный код и наборе средств разработки — библиотек /фреймворков, мы её обсудим и может быть я соглашусь что предложенная вами альтернатива лучше.
>Так же я вам предлагаю посмотреть этот твит: Modern comfortable programming language.
и? вы же не хотите сказать, что в скале сильно лучше со стектрейсами? :)) я могу ведь и накидать примеров из своих проектов, где вообще не видно собственной бизнес-логики, исключительно библиотечный код
>Вероятность на самом деле такая же как найти хороших специалистов на Java, другими словами — хороших программистов.
вы из какой-то чудесной страны, видимо
например, большинство разработчиков, которых я собеседовал в течение нескольких лет, ни разу в жизни не создавали sql индекс. просто тот объем данных, и те примеры использования, которые были в их проектах, не позволяли заметить разницы.
Более того языки как Kotlin, вредны потому что давят на экосистему Scala, в частности по средствам того что утверждают себя как альтернативу, что не так. Оттягивая ресурсы и людей от, лучшего на сегодня выбора — именно лучшего, я так говорю не из-за фанатическое веры в Scala, а потому что Scala это новые мощные абстракции, мощные библиотеки, мощные фреймворки, т.е. в целом инфраструктура
Никогда не бывает ничего абсолютно лучшего, как и абсолютно худшего.
А по делу, Kotlin очень «мягко» интегрируется с java, поэтому для java разработчиков переход на Kotlin занимает от нескольких часов до недели. Причем переход вместе со всем «experience», наработками, либами и т.п. Scala же это отдельный свой мир. Мое мнение что существующий проект на java легче переписать на scala с нуля, чем частично использовать и то и то. А Kotlin можно легко использовать в существующем, без излишнего пригорания пятой точки. К тому же Kotlin позволяет писать красивый и лаконичный код, близкий к scala.
И что немаловажно, скомпилированный код в Kotlin очень близок к коду java. Тут проще, как мне кажется, понять как его лучше оптимизировать, и скорее всего JIT его лучше оптимизирует (поправьте если ошибаюсь)
Ну а какой язык использовать в новом проекте, это спорный вопрос. Поставьте себя на место тех. дира, и подумайте, из кого вы бы набрали команду? С учетом поиска людей в команду, его поддержки и т.п.
Никогда не бывает ничего абсолютно лучшего, как и абсолютно худшего. Только Ситхи возводят все в абсолют
Я ничего не возводил в абсолю, это вы придумали. Даже описал один случай когда Kotlin объективно лучше Scala — это разработка под андроид.
А по делу,…, близкий к scala.
Я писал выше почему незначительное синтаксическое улучшение это не то же самое что прорывная Scala.
Тут проще, как мне кажется, понять как его лучше оптимизировать, и скорее всего JIT его лучше оптимизирует (поправьте если ошибаюсь).
Код на любом языке оптимизируется одинаково — уменьшается потребление ресурсов: памяти, процессора, io. JVM оптимизирует выполнение байт кода а не высокоуровневых конструкций языка, а на низком уровне все есть байт-код который создается любым компилятором для JVM. И вообще если вы не уверены не пишите то что может быть глупостью, а проверяйте.
Ну а какой язык использовать в новом проекте, это спорный вопрос. Поставьте себя на место тех. дира, и подумайте, из кого вы бы набрали команду? С учетом поиска людей в команду, его поддержки и т.п.
Тогда можно до конца дней человеческих, сидеть на Java и вообще ничего нового не разрабатывать. Только ныть когда проект разрастется, что все тормозит, невозможно рефакторить потому-то код ужасен и т.д. Зато в начале сэкономили чуть бюджета и не парились с этими новыми технологиями и хорошими специалистами.
Код на любом языке оптимизируется одинаково — уменьшается потребление ресурсов: памяти, процессора, io. JVM оптимизирует выполнение байт кода а не высокоуровневых конструкций языка, а на низком уровне все есть байт-код который создается любым компилятором для JVM. И вообще если вы не уверены не пишите то что может быть глупостью, а проверяйте.
Тут вы неправы. JIT может оптимизировать одну последовательность байт-кодов, а не оптимизировать другую. Просто потому что для первой написали пару веток в коде JIT-компилятора, а для второй не успели, не хватило ресурсов. Если одну последовательность байткодов часто генерирует javac, а другую javac не генерирует, а scalac генерирует, и у разработчиков JVM не хватает времени, то какую оптимизацию они впилят в первую очередь? Разумеется, ту, которая встречается в джаве.
Это не абстрактные умозаключения. Скажем, конкатенация строки и числа javac'ом превращается в конкретную последовательность действий: создать StringBuilder, засунуть туда строку, засунуть число, вызвать StringBuilder.toString(). Конкретно эта последовательность в HotSpot JVM специально обработана: StringBuilder вообще создаваться не будет, сгенерированный ассемблерный код вместо этого подсчитает, сколько символов займёт число после конвертации, добавит длину строки, выделит результирующий массив точного размера и туда запишет результат конкатенации, а потом создаст объект String. Если отступить от последовательности, генерируемой javac'ом, шаг влево или шаг вправо, HotSpot не распознает паттерн и оптимизацию не сделает.
Код на любом языке оптимизируется одинаково — уменьшается потребление ресурсов: памяти, процессора, io.
Мне кажется тут вы согласны, но если нет уточните.
JVM оптимизирует выполнение байт кода а не высокоуровневых конструкций языка
Это я так же считаю правильным.
а на низком уровне все есть байт-код который создается любым компилятором для JVM
Это утверждение тоже верно.
Каждое выражение истина следовательно и истинно их объединение. Т.е. писать что я не прав на основании только этого нельзя; нужно как-то уточнить где, в другом месте, я был не прав. Потому что иначе не понятно, что вас смущает.
Насколько я вижу вы считаете, что я не полностью раскрыл тему. И по этому пишите о том что важные отличия в перечисленных вами деталях.
Хорошо, давайте разберемся:
IT может оптимизировать одну последовательность байт-кодов, а не оптимизировать другую.
Согласен с вами, и это не противоречит моим словам.
Если одну последовательность байткодов часто генерирует javac, а другую javac не генерирует, а scalac генерирует, и у разработчиков JVM не хватает времени, то какую оптимизацию они впилят в первую очередь?
Вот тут я хотел бы от вас получить конкретные ссылки на источники, которые доказывают что javac байт код как-то отличается от scalac — таким образом что JVM лучше оптимизирует код первого(т.е. что байт код генерируемы scalac не попадает по какое то кол-во шаблонов оптимизации). Иначе это просто пустые слова.
Так же хочу уточнить что синтаксис и семантика Scala сильно отлична. По этому сравнивать можно как минимум только идентичные конструкции. И ниже об этом.
Могу согласится с тем что команда занимающаяся JVM, в первую очередь изучают результаты компиляции самого массового языка, но почем вы считаете что к коду scalac не будут применены какие-то из оптимизации?
Это не абстрактные умозаключения. Скажем,… результирующий массив точного размера и туда запишет результат конкатенации, а потом создаст объект String.
Scala использует тот же Java.lang.String, почему вы считаете что в scalac нет этой очевидной оптимизации, в точно той же форме которую требует шаблон в JVM, и на выходе будет что-то не оптимальное? Пожалуйста ссылку как аргумент, потому что иначе это и есть абстрактные умозаключения.
Так же получается Kotlin эту про обработку сделает, но если вы не защищает мысль выраженную комментатором с которым я не согласился, то вы в целом вырвали фразу из контекста.
Подытоживаю.
Вы не исправили мою ошибку, а уточнили сказанное мной и не во всем корректны сами.
Не раскрыли тему почему байт код на одном языке не будет соответствовать шаблонам оптимизации а на другом будет. Пожалуйста приведите ссылки, на авторитетный источник.
О-о-о, ничего себе вы демагог. Удаляюсь.
Хорошо, можем не вести диалог. А я надеюсь это был диалог а не спор. Я во всяком случае старался аргументировать.
От вас же прошу напоследок простое. Приведите источник на основании которого можно понят что ваши утверждения о том что scalac генерирует плохо оптимизируемый JVM код, в сравнении с javac. И на этом разойдемся.)
Потому что если вы не можете как то подтвердить свои слова, получается вы пытаетесь утверждать о работе того что сами не понимаете.
Я писал выше почему незначительное синтаксическое улучшение это не то же самое что прорывная Scala.
Хотел было с вами согласиться, что скала претендует на что-то прорывное и заметить, что в реальной жизни часто удобно уметь продолжать разрабатывать проект в который уже вложили кучу денег и сил, а не переписывать его «с нуля» в новой «прорывной» парадигме. Но потом увидел высказывание про «незначительное синтаксическое улучшение» и понял, что вы не разбирались серьезно с котлином и что ваши слова это просто голословное сотрясение воздуха. И смысл общения для меня сразу пропал.
Здравствуйте, я не утверждал что нужно нужно переписывать проект с нуля как только появилась новая лучшая технология. Это вы сами додумали. Используйте новые лучшие технологии для новых проектов/сервисов/микросервисов или в случае если вы уперлись в стену с текущими технологиями.
Если вы не согласны с тем что Kotlin по большому счету это просто синтаксический сахар, объясните пожалуйста свою позицию. Возможно я с вами соглашусь.
Я же вам как аргумент моим словам приведу ключевые утверждение о "Why Kotlin?", официальная доктрина разработчиков перечислена на главной странице сайта о языке:
Радикально уменьшить количество шаблонного кода, который необходимо написать.
Исключительно синтаксический сахар.
Избегает целого класса ошибок таких как NPE
Избегает это когда нет такого понятия как NULL, а elvis даже в Java не попал можно в интренте найти обсуждения почему. Но в общих чертах это лишь делает код более не понятным, в отличии скажем от монады Options. Тем более что в java уже давно можно использовть Optional, недавно он напряму вошел в JDK. В чем провыв Kotlin'а по в данном случая мне не ясно.
Позволяет писать приложения под разые целевые платформы.
Это 'приимущество' вообще не понятно, уже очень давно существуют технологии позволющие все тоже делать и на Java и на многих других языках. Но что-то так и ни одна не взлетела либо быстро умерла. GWT как пример.
100% со всеми существующими библиотеками для JVM
Это попросту а отсутсвие недостатка. Scala, Clojure и т.д. все они поддерживают такую возможность.
Теперь о Scala. Две ключевые концепции:
- Scala полностью объектно ориентированный язык, в том смысле что — все является объектом, в т.ч. и примитивы.
- Scala полностью функциональный языке, в том смысле что — любая функция объект первого рода. Так же Scala включает в себя много важных концепций из мира ФП.
А так же в Scala есть: Pattern Matching. Язык богат важными примитивами для разработки конкурентных и распределенных систем. Сотственная мощная STD lib. Интерполяция строк. Объекты компанъены. Можная поддержка обощенного программирования. Макросы. И ещё мное другое.
Но главное отличие это две фундаментальных концепии которые я кратко описал выше.
И ещё одно ключевое понятие, Scala это — "A Scalable language". Я пожалуй не смогу вам объяснить все лучше чем написано на www.scala-lang.org. Зайдите прочитайте, убедитесь.
Ко всему Scala, не экспериментальный язы "For Fun", а полностью готовый для промышленной разрабтки язык и платформа, т.е. обладающее достаточным набором библиотек и фреймворков для построения приложения любого уровня сложности.
SBT — мощная система сборки, реализует как деларативный(богатая встроенная система команд) так и императивый подход(можно описать процесс напрямую на scala).
Play Framework — разработка веб приложений, компактная документация, компактный фрейморк в сравнени с монстрами — javaEE и Spring. Имеет полный спект необходимых встоеных средст для современной Web разработки.
Akka Framework — разработка конкурентных и распределенных системы потребляющие минимум ресурсов, радикально уменьшающая сложность построение таких систем.
Slick — аналог LINQ, почитайте сами что это если не знаете.
и д.р. смотртите Lightbend Reactive Platform
Жду от ваc пояснения почему я не прав говоря так о Kotlin в стравнении со Scala.
я не утверждал что нужно нужно переписывать проект с нуля как только появилась новая лучшая технология. Это вы сами додумали.
Заметьте, я тоже этого не утверждал, перечитайте комментарий — я писал лишь о том, что каждый силен в своем: котлин, к примеру, хорош в том, что бесшовно интегрируется в java-проект. На скале же это намного сложнее, на ней лучше писать «с нуля».
Радикально уменьшить количество шаблонного кода, который необходимо написать — Исключительно синтаксический сахар.
Вот так вот вы цель языка разом записали в исключительный синтаксический сахар? Даже не важно каким образом этот шаблонный код будет сокращен? Может быть он сокращается за счет применения практик функционального подхода, а вы вот так взяли и разом это в сахар записали? Честно говоря, я не думаю, что этот список — это хороший фичлист для того, чтобы смотреть на возможности котлина.
Избегает это когда нет такого понятия как NULL, а elvis даже в Java не попал можно в интренте найти обсуждения почему.
Как вы к такому логическому выводу пришли, что «избегает — это когда нет такого понятия»? Т.е. вы искреннее считаете, что другого способа решить проблемы null-ов кроме как отменить null-ы нет? И да, я не очень понял, причем тут Элвис?
Но в общих чертах это лишь делает код более не понятным, в отличии скажем от монады Options. Тем более что в java уже давно можно использовть Optional, недавно он напряму вошел в JDK.
Конечно можно, только использование монады не бесплатно, а если проблема решена компилятором, то это почти ничего не стоит. Утверждение же, что Optional удобнее подхода реализованного в котлине — более чем спорно, но нет смысла об этом спорить, потому что у каждого могут быть свои предпочтения.
В чем провыв Kotlin'а по в данном случая мне не ясно.
Обратите внимание, я не говорил ни о какой «прорывной» сущности котлина, даже где-то наоборот. Однако, эту фичу — решающую на этапе компиляции очень неприятную проблему — я для себя считаю очень важной.
существуют технологии позволющие все тоже делать и на Java и на многих других языках
Суть этого профита в том, что изучая один язык, вы можете писать и под jvm и для браузера и насколько я знаю сейчас активно разрабатывается компилятор в llvm. Это просто удобно, там же не написано, что такого больше нигде нет — но если вы выбираете котлин и он вам нравится, то это приятный бонус — возможность на этом же языке делать и другие решения.
Это попросту а отсутсвие недостатка. Scala, Clojure и т.д. все они поддерживают такую возможность.
Если быть совсем честным и начать например со стандартной библиотеки (как часть всех), то например инструменты scala работают с коллекциями java через адаптеры, что удобства не добавляет. А если вы например вдруг решите, что вам для спринга нужно написать аннотацию, то со скалой про такую возможность лучше вообще забыть. И таких несовместимостей существует не так мало как хотелось бы. Котлин же изначально ориентировался на совместимость, что означает не только, что можно абсолютно без проблем использовать java-библиотеки, но и что из java скомпилированный котлин будет выглядеть неплохо.
Scala полностью объектно ориентированный язык, в том смысле что — все является объектом, в т.ч. и примитивы.
Если бы чуть более внимательно посмотрели документацию, то вы бы знали, что в котлине это тоже так. Если быть точным, то выглядит как будто это именно так, хотя по факту примитивы всё-таки есть в реализации.
Scala полностью функциональный языке, в том смысле что — любая функция объект первого рода. Так же Scala включает в себя много важных концепций из мира ФП.
Опять же этим никого не удивишь. Например в котлине это тоже так. Да и возможностей для функционального подхода у котлина много, хотя безусловно нужно признать, что в этом смысле со скалой соревноваться не стоит, да и нет смысла, потому что котлин не претендует на глубочайшую проработку функциональных нюансов, оно и понятно — ведь котлин делался в первую очередь, чтобы на нем код писать — а количество реализованных фич не так важно, если их или не используют или используют 1% разработчиков, а за это приходится платить не высокой скоростью компиляции и сложностью анализа такого кода со стороны ide.
А так же в Scala есть: Pattern Matching.
Полноценного патерн-матчинга в колтине нет, это факт, но не будете же вы утвреждать, что это киллер-фича за которую можно всё простить.
Язык богат важными примитивами для разработки конкурентных и распределенных систем.
Назовите несколько примитивов, которых нет в котлине?
Сотственная мощная STD lib.
Мощная, это правда, но действительно ли она стоит того, чтобы изучать целую библиотеку? может быть неплохо подошла бы и java std lib с необходимыми расширениями? А остальное можно было бы и внешней библиотекой добавить.
Интерполяция строк. Объекты компанъены. Можная поддержка обощенного программирования.
Опять же в котлине это всё есть.
Макросы.
Макросов в котлине нет, но есть некоторые инструменты (вроде inline-функций), которые в ключевых моментах макросы заменяют, а для сложных случаев всегда можно использовать инструментирование. Небольшая цена за быструю ide.
И ещё одно ключевое понятие, Scala это — «A Scalable language». Я пожалуй не смогу вам объяснить все лучше чем написано на www.scala-lang.org. Зайдите прочитайте, убедитесь.
Я не первый день пишу на скале, я отлично представляю себе, что означает «Scalable» в названии.
Ко всему Scala, не экспериментальный язы «For Fun», а полностью готовый для промышленной разрабтки язык и платформа, т.е. обладающее достаточным набором библиотек и фреймворков для построения приложения любого уровня сложности.
Однако, начинался язык как эксперементальный — в то время как котлин сразу проектировался под вполне конкретные нужды и не усложнялся без нужды.
SBT — мощная система сборки
Ох. Вы сами её использовали или просто об этом слышали?
…
Причем здесь вообще библиотеки? Их точно так же можно использовать и из java или kotlin-а.
Жду от ваc пояснения почему я не прав говоря так о Kotlin в стравнении со Scala.
В первую очередь, потому что эти сравнения достаточно бессмысленны. У каждого из этих языков есть свой стиль, подход и концепция. И именно разнообразие языков делает возможным выбор язык по себе. А самое главное — это то, что мы начали эту дискуссию с вашего посыла о том, что котлин — это «незначительное синтаксическое улучшение», что очевидно не так — потому что котлин это очень хорошо продуманный мощный и имеющий свои уникальные решения язык, делающие его не просто сахаром для java, а серьезным взрослым языком для реальной жизни. В этом не сложно убедиться, если почитать документацию. Ваши же попытки расписать привлекальности scala выглядит несколько натужно, потому что я достаточно неплохо знаю её сильные места по сравнению с тем же котлином и вы ни одного не назвали.
а потому что Scala это новые мощные абстракции, мощные библиотеки, мощные фреймворки, т.е. в целом инфраструктура>
И никто не мешает вам использовать библиотеки и фреймворки, написанные на Scala, в Kotlin…
Большинству это не нужно осваивать что-то, получку получил и доволен, даже в такой казалось бы высокоинтеллектуальной среде как разработка ПО.
Прочёл — и представил, как торговые сети бросились строить в местах концентрации Java-программистов "перехватывающие" вино-водочные магазины...
["10", "10", "10", "10"].map(parseInt) ->
-> [10, NaN, 2, 3] // What???
Хоть статья и не об этом, но зануда внутри меня не успокоится пока не отпишусь :)
Вторым аргументом используя parseInt в map передается позиция элемента в массиве, что для parseInt означает систему счисления.
То есть,
parseInt(«10», 0), 0 = false = не задана система счисления, используем десятичную
(«10», 1) — единичная система счисления? NaN
(«10», 2) — двоичная (0, 1), 10 -> 2
(«10», 3) — троичная (0, 1, 2), 10 -> 3
используем десятичную
Если повезет, лучше указывать явно radix
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt
javascript> ["10", "10", "10", "10"].map(parseInt)
[10, NaN, 2, 3] // What???
— в первой строчке с JS — поведение JS корректное и оно вовсе не связано с " динамическим и «странным» JS", результат выполнения связан с тем что:
а) в callback array.map приходят три значения (currentValue, index, array)
б) Функция parseInt принимает 2 значения (string, radix) где radix — это основание
Почитали бы доку что ли прежде чем написать…
И вот тут совсем непонятно почему «Если бы JavaScript имел полноценную статическую типизацию, в функцию map нельзя было бы передать функцию parseInt» — как статическая типизация налагает ограничения на количество параметров функций?
Компиляцией в высокопроизводительный Javascript код уже никого не удивить. а вот "interactive programming" штука интересная, ее умеют например elm и clojurescript как с этим дела у ScalaJS?
но-но. Если вы не используете, это не значит, что их не использует кто-то другой. Это как кнопки из файерфокса выкидывают при каждом новом апдейте. Видимо проводят голосование, и самое слабое звено покидает браузер. Большинство пользователей не замечает, а меньшинство, которое их на самом деле использовало, обижается.
Но вы бы составили полный список фич, помеченных как устаревшие — тогда возникло больше бы вопросов. Например, как жить без implicit conversion? А без абстрактных типов?
Когда мне понадобился pattern matching по xml (встроенный ужасен — ни атрибутов ни неймспейсов) я его просто взял и сам написал. На макросах и строковой интерполяции. Заняло часа 4, не больше. Понадобится просто xml — напишу быстрее. Хотя скорее и до меня напишут.
implicit conversion никто не выкидывает. Просто импорт требуется.
Что не так с абстрактными типами?
scalatest — это набор DSL. Он наполовину про собственно алгоритм тестирование, а наполовину, чтобы всё было красиво. Как раз эти DSL и посыпятся. Хотя, я не прав, там же ленивые параметры, а не процедурный синтаксис, потому знаков равно и нет.
> Что не так с абстрактными типами?
Обещали, что больше не будет путаницы тип-параметр, который generic, против абстрактного типа, который член класса. Что-то одно удалят нафиг, забыл правда что.
Хотя, я не правВот и я смотрю, что странное что-то пишете. Никто scalatest не сломает.
забыл правда чтоТут как в анекдоте про "… и не выиграл, а проиграл, и не запорожец, а 5 рублей..."
Вы с dotty путаете. И не удалят, а обобщат. То есть синтаксически все останется почти как раньше, но с точки зрения языка типовые параметры превратятся в синтаксический сахар над типовыми членами класса.
Хотя, если запилят частичное применение типов, то ничего страшного не случится.
Мне гораздо интереснее как сочетать scala.meta со строковой интерполяцией, особенно с pattern matching. Это же явный whitebox макрос.
val a : A | B
Хочу! Почему до такого раньше не додумались за столько лет развития программирования?
Есть, например, в ceylon.
А вот чего нет в ceylon, так это вот такого:
trait A { def f: RA }
trait B { def f: RB }
val a: A | B
val x: RA | RB = a.f
В тайпкрипте сто раз так делал.
Немножко оффтоп, конечно, но я такую конструкцию видел в другом языке под JVM: в языке Frege (на Haskell похожий).
Прекрасное настоящее и светлое будущее Scala