Чому ці спроби залити Скалу разом із Xtend та Kotlin? [зачинено]


26

Отож Eclipse запропонував Xtend, а JetBrains пропонує Котлін - обидва вони, здається, поливають версії Scala. Моє запитання, чому? Я грав з Scala трохи , і це не що важко. Це лише реакція на притаманні труднощі переходу від імперативного до функціонального чи тут є щось інше на роботі?


EDIT: Вибачення. Перечитавши питання, коли я його спочатку розмістив, я бачу, де це трохи схоже на тролінг. Те, як я сформулював це питання, здавалося, є найкращим способом задати питання. Я бачив публікації в блозі про те, що "Скала занадто тверда / Скала занадто складна", а також "Котлін - це спроба зробити Скалу, але простіше". Я залишу фразу, як це було спочатку, але я, чесно кажучи, не намагався троліти.


20
Мені здається досить приборканим, щоб просто припустити, що нова мова, яка має певну схожість зі Скалою, повинна бути "поливаною версією Скали", написаною людьми, для яких Скала занадто важкий. Ви менше шансів отримати добре продумані відповіді, поставивши таке запитання.
Майкл Боргвардт

8
Збірка - це лише полита версія машинного коду, правда?
Бен Брокка

6
@BenBrocka: Ні, це машинний код ізоморфний;)

4
Скала чудова. Щодо мене, я вважаю, що люди повинні відмовитись від некромантування Java та переосмислення велосипедів (усі ці нові мови, згадані та не) та просто використовувати та вдосконалювати Scala. ІМХО.
Іван

2
@MichaelBogwardt справедлива точка. Я грунтуюся на твердженні на тому, що я бачив навколо блогосфери. "Скала занадто жорстка", а "Скала занадто складна", схоже, є відносно поширеними скаргами.
Оноріо Катенач

Відповіді:


39

ІМХО від когось, хто програмував на Java протягом останніх 7 років, і мою найсильнішу мову я вважаю Скалі досить чужою і мені важко звикати до неї.

Xtend відчуває себе більше як Java і був в змозі написати просте додаток з ним набагато швидше. Зрозуміло, я не приділяв себе достатньо часу зі Скалою, але я, безумовно, розумію, чому її можуть відключити.

Коли це буде сказано, люди оберуть знайомий пекло над незнайомим небом.


19
+1: "люди оберуть знайоме пекло над незнайомим небом".
Джорджіо

18

У JetBrains є вікі-сторінка, яка порівнює Скалу з Котліном, і, здається, є кілька речей, які робить Котлін, а Скала:

  • Нульова накладна безпека нуля. Scala має Option, який є синтаксичним та обертовим періодом часу
  • Розумні касти
  • Статичні функції розширення. Замість обгортки під час виконання
  • Функції Inline Kotlin полегшують нелокальні стрибки
  • Шаблони рядків. Існує плагін третьої сторони компілятора для scala з подібною функціональністю: ScalaEnhancedStrings
  • Делегація першого класу. Також реалізовано через плагін сторонніх розробників: Модулі автопроксі

Отже, називати Котліна водою вниз Скалою, мабуть, надмірне спрощення. Що стосується Xtend, я думаю, що він орієнтований переважно на користувачів Xtext, а не на широку аудиторію. Основна відмінність від Scala полягає в тому, що Xtend компілює на Java, а не в байт-код.

Ще одна мова "убивці Java", яку ви повинні додати до свого списку, - це Цейлон Red Hat's , хоча я не маю уявлення, чи можна порівняти його зі Скалою.


13
Автоматичні ролики звучать страшно.
Йонас

14
У галузі є ці циклічні обороти, де розробники будуть йти з однієї крайності і знову і знову. Мови кодерів, що мають сильну потужність, були хорошими, тоді ідіоти писали поганий код, і ми виявили небезпеку, тому люди стикалися до сприйнятої безпеки Java, тепер знову повертаючись до силових кодерів. Подивіться, як на основі JavaScript і браузера було добре, потім з'явилися аплети і RIA з плагінами браузера були хорошими, а Javascript поганими, потім з'явилися сучасні рамки AJAX, а плагіни були незахищеними і поганими, потім з'явився Silverlight, і люди сказали, що AJAX мертвий, ЗАРАЗ HTML5 мода і плагіни знову погані! :)
maple_shaft

3
@Jonas Я навіть не знаю, чи згоден я з цим, але це явище, яке я помітив. Безумовно, що з кожною революцією виходить більш досконале рішення, але все це завжди має ахілесову п’яту. Вирішення проблеми з п'ятою змушує деяких оглянутись назад на попередні рішення ідей, але з часом люди забувають, чому спочатку відмовилися від цих старих рішень. З часом, хоча з кожною революцією, Каблук стає все меншим. Java + XTend, безумовно, може бути не такою складною, як Scala, проте проблем менше, ніж інвестицій, щоб повністю перейти на нову мову.
maple_shaft

2
@Jonas Ну, тільки надзвичайно спрощений рівень технологічної еволюції на високому рівні може відповідати коментарям. Я згоден з maple_shaft, хоча технологічна еволюція має ітераційне відчуття .
янніс

3
@Jonas ці ролики не є автоматичними, а розумні ролики: якщо ви подивитесь, ви побачите, що це не те саме: kotlinlang.org/docs/reference/typecasts.html
cy6erGn0m

11

Я використовував Scala як свою основну мову протягом останнього року (з Java близько до другого, обидва у великій застарілій базі коду Java.) Я все одно повинен шукати досить основні функції, якщо я не використовував їх у поки. Звичайно, ви можете швидко написати якусь Скалу, але це надзвичайно насичена функціями мова, і її освоєння потребує багато часу.

Більше того, її складність є не лише проблемою для людини, а й для IDE та компіляторів. І Целіон, і Котлін збираються безпосередньо для досить чистого JavaScript. Scala може створювати JavaScript за допомогою GWT, хоча потрапляння там є складним, і вихід GWT не є ні розбірливим, ні розробленим для того, щоб чудово грати із зовнішнім JavaScript або HTML.

Я, безумовно, більш продуктивний у Scala, ніж Java, і код є більш компактним і розбірливим (раз ви трохи знаєте Scala.), Але його складність змушує мене вагатися, рекомендуючи його іншим. Мова з 20% складності, але 80% можливостей буде бажаною альтернативою.

[Відредаговано для видалення згадки про застарілий код, див. Коментар нижче.]

[Додаток 2017 року: Scala тепер підтримує JavaScript як ціль збірки, тоді як Котлін продовжує додавати функції, які мають сенс для заміни Java / Groovy / JavaScript, що нагадує Scala. Зараз вони є більш відмінними мовами, ніж коли я вперше писав це.]


Не могли б ви детальніше розробити "лагічну частину"? Наприклад, які методи ви маєте на увазі, що беруть Списки, а не Seqs?
kiritsuku

Я збираюся відредагувати це, оскільки, поміркувавши, стандартна бібліотека Scala насправді рідко робить це. JSONArray приймає список, але більшість конструкторів цього не робить. Незважаючи на те, в документації до списків все ще існує упередженість, тим більше, що програмування в Scala, 2-е видання, охоплює лише Scala 2.8, що передує векторам. І його приклади коду, як правило, мають конструктори, які беруть список там, де Seq було б краще.
Девід Леппік

Так, на 2,10 деякі речі краще (наприклад, +:витяжки). Я сподіваюся, що програмування в Scala буде оновлено найближчим часом. За 2.11 деякі речі покращуються далі. Stdlib вже звільнений від депресії і також трохи скоротиться. Можливо, scala.util.parsingбуде також переміщено поза stdlib. Ми побачимо ...
kiritsuku

1
Мені слід додати, що моя реальна проблема зі списками проти векторів полягає в тому, що додавання елементів до списку (тобто Seq у Scala) - дуже проста операція, і є занадто багато рівнозначних способів зробити це, все із смішними символами, які важко пам’ятати. Канонічний спосіб є ::, ::=або +:=який є передбачуваним, але більшість людей хочуть, :+=що додає, але це не ефективно для Списку.
Девід Леппік

10

JetBrains дуже чітко заявив про свої цілі Котліна :

Ми хочемо стати більш продуктивними, перейшовши на більш виразну мову. У той же час, ми не можемо приймати компроміси з точки зору інтероперабельності Java (нова мова буде впроваджуватися поступово, і їй потрібно безперебійно взаємодіяти з існуючою базою коду) або швидкості компіляції (наша база коду займає достатньо часу, щоб компілювати з javac, і ми не можемо дозволити собі зробити це повільніше). Наступне також досить просто: ми очікуємо, що Котлін сприятиме продажам IntelliJ IDEA.


8

Я використовував Scala кілька місяців у Eclipse з Play Framework. Мені подобається мова, але є і речі, які мені не подобаються.

Для мене причиною переходу з Java на іншу мову є більш продуктивна.

Поки що я не був більш продуктивним зі Scala. Однією з причин є відсутність хорошої підтримки для Scala в Eclipse, плагін Scala поганий (наприклад, відступ відмови) та ще не має багатьох функцій (наприклад, немає "Ієрархії відкритих викликів"). Компілятор Scala також повільний, це може не бути проблемою, але я використовую Scala з Play Framework, яка компілює код для кожного запиту, і там важлива швидкість компілятора.


2
Можливо, ви недостатньо вивчили ідіоми Scala. Я використовував Scala для невеликих проектів (інструментів), і я набагато продуктивніший у Scala, ніж у Java, хоча я маю набагато більше досвіду роботи в Java (> 10 років), ніж у Scala (<2 роки).
Джорджіо

4

Не знаєте про Котліна, але Скала і Xtend - це два дуже різні звірі.

Всупереч поширеним приказкам, Scala НЕ краща Java. У Scala набагато більше представлена ​​мова, ніж Java, зі своїм синтаксисом та семантикою та власним пакетом базових бібліотек.

Xtend - це краща Java. Він зберігає семантику Java та покращує її синтаксис. Кожен рядок коду Xtend може бути безпосередньо переведений на купу рядків коду Java. Немає жодного додаткового часу виконання.

Я думаю, що обидва підходи правильні, хоча й різні. Мені не подобається Scala (як мова), але мені не подобається додавання банок Scala до моїх проектів. Я не можу належним чином використовувати Scala в Android (це додає ваги та продуктивності). Xtend не настільки популярний, але для мене це нормально (варто використовувати його більше, ніж мова Java), і він працює на будь-якій платформі так, як ніби я писав безпосередньо на Java.

Я вважаю, що обидві мови охоплюють різні ніші і можуть співіснувати, не заважаючи одна одній. ІМХО, Scala просто занадто складний, нічого нового не додаючи. Якщо ви хочете працювати більш функціонально і менш OO, просто виберіть одну з багатьох більш простих функціональних мов, як Clojure або JHaskell. Якщо ви просто хочете, щоб Java мала кращий синтаксис і трохи функціонального програмування, Fantom був би таким же відмінним, як і Scala (він дуже нагадує C #).

Але я вважаю, що Xtend знаходиться в приємній точці між усіма цими мовами. Він додає всі ті синтаксичні структури, які я хотів для Java, зберігаючи хороші частини Яви (її семантику). Подумайте про це як Coffescript для Java.

І підтримка Eclipse чудова ...


… І підтримується лише в Eclipse. Правильно? І затемнення - це пекло ...
Сержант Борщ

Xtend має додатковий час виконання. Близько 3 Мб востаннє я перевірив.
мм2001

@ mm2001 Так, існують залежності: приблизно 300 Ko для xtend і 2 Mo для guava в моєму невеликому тестовому проекті ( github.com/pdemanget/examples/tree/master/xtend/message-send ) Але це не час виконання, це додаткові класи для таких речей, як InputOutput, додаткові анотації. Це не знімає головного моменту, що Scala і Xtend - це дві дуже різні мови, як сказано в цій відповіді.
pdem
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.