Що думають розробники Java про Scala? [зачинено]


19

Я зазначав, що підтримка IDE ніде не є такою хорошою, але сама мова підтримує функціональні ідіоми програмування набагато чіткіше.


3
Пітон - моя релігія, тому мені цікаво лише те, що Гвідо думає про Скалу. neopythonic.blogspot.com/2008/11/scala.html
Робота

7
Скала є такою чудовою мовою, що вона не тільки приваблює всіх цих чудових розумів, якими володіє спільнота Скала, але, на жаль, також багато заздрісних ненависників, які намагаються знайти в основному що- небудь, щоб напасти на мову та людей, які її використовують.
soc

@soc: Просто, щоб було зрозуміло: я не ненавиджу Scala, і люди, які її використовують, напевно, не могли (не повинні!) менше дбати про те, що я думаю про це. Я думаю, що це занадто складно. Це все. Складність може бути в порядку для тих, у кого великий мозок. Я не :-)
Joonas Pulakka

3
Вибачте, мене просто дратують, коли люди продовжують повторювати міфи, не підкріплюючи свої претензії.
soc

2
@soc: Ну, все це питання цілком суб'єктивне, тому будь-яка відповідь правильна, будь то міф чи ні.
Joonas Pulakaka

Відповіді:


18

Я програмую Scala вже не один рік, тому спробую повернути себе на рік, щоб відповісти на це питання.

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

Наведені вище точки були більш-менш те, що я думав про Скалу, перш ніж почати її вивчати.

Протягом року я дізнався ось що:

  • Купівля східної книги була чудовою інвестицією і врятувала мені години на вивчення речей самостійно
  • У синтаксисі є деякі химерності, і іноді там, де я був справді спантеличений, чому щось не вірно. Щойно ви знайдете компроміс, ви знайдете менше коду і його легше читати. Зауважте, що це насправді не проблема, якщо ви читаєте, а не пишете код.
  • Бібліотекою колекції в 2.8 приємно користуватися. Важко повернутися до Java.
  • XML буквальний приємно, але поза деякими основними речами мені довелося звернутися до екосистеми бібліотеки Java. Це зручно, хоча.
  • Використовувати бібліотеки Java від Scala - це дуже просто та зручно. Використання класів Scala від Java трохи складніше, але це працює.
  • Я перейшов на видання спільноти IntelliJ IDEA, і хоча це не ідеально, це більш ніж добре.
  • Творець мови дійсно подумав про набір функцій і всі дуже добре працюють разом. Об'єктно-орієнтована підтримка краща, ніж у Java (з ознаками), і ви можете робити функціональне програмування.
  • Це мова, яку, очевидно, деякі розробники Java ненавиджу з пристрастю. Для мене це повернуло радість програмування.

21

Ну, я вважаю, Скала занадто складна. C ++ відчуває себе таким, що має безліч різноманітних способів робити речі. Дехто би назвав це "багатством", "виразністю" або "силою", але ваш пробіг може відрізнятися. У багатьох реальних проектах вам доведеться штучно обмежувати, які мовні функції ви збираєтесь використовувати, а які ні, щоб усі розробники могли говорити однаковою мовою.

Для функціонального програмування я віддаю перевагу Clojure , який простіше, ніж Scala.

Нехай почнеться свята війна ;-)


2
Якби тільки Річ Хікі так сильно піклувався про. Net, як і про JVM ...
робота

Було б корисно, якби ви трохи більше пояснили, які речі ви вважаєте занадто складними.
Річард Уорбуртон

4
@ Richard Warburton: Питання складності Скали (або, як зазначає Мартін Одерський, "сила і проблема Скали: її розширюваність") широко обговорювалися на багатьох форумах. Одне таке обговорення тут . Я не кажу, що складний == поганий сам по собі . Проблема полягає в тому, що хоча найяскравіші 1% програмістів можуть робити чудеса з Scala, переважна більшість просто не збирається «дістати її», і це проблема для використання в реальному світі. Це як автомобіль Формули-1: переважна більшість людей просто не зможе загнати такого звіра.
Joonas Pulakka

2
+1 Зазначення Clojure як дійсної альтернативи (якщо мова йде про функціональне програмування).
Олівер Вайлер

Clojure - це чудово, але чи він настільки витончений, як Scala? Чи так легко переробляти без цього статичного набору тексту? (Рефакторинг Python досить важкий, наприклад - я для цього писав рефакторинг.)
9000

13

Приблизно рік тому, коли я все більше і більше засмучувався щодо майбутнього продуктів мого стартапу, якщо я продовжую використовувати Java, я вирішив спробувати Scala. Я вже програмував на JavaScript і Python у той час, Ruby також була гарною альтернативою, але я шукав статично введений мову, бажано той, який міг би працювати на JVM.

Мені справді було спробувати подобатися Скала, мені це справді вдалося, але я виявив, що це код абсолютно некрасивий і важкий для розуміння. Я різко замислився, що якщо Скала була нашою найкращою відповіддю на Яву, то мене, безумовно, накрутили і засудили продовжувати працювати з мовою, яка мені не сподобалася зрештою ...

На щастя, не надто довго після цього я дізнався про Fantom . О людино, я любив це! Для мене це було як пишна відповідь американця німецькій бюрократії! Це відповідало вимогам, які я шукав у Scala, але набагато елегантніше . Він мав інтеграцію Vim , Eclipse та Netbeans , хороший веб-фреймворк , зрілі продукти, що працюють з ним, невелике, але неймовірно корисне співтовариство ... Динамічне та статичне введення тексту! Я зрадів!

(Я міг би продовжувати, але ця публікація має на увазі про Скалу, а не про Фантом, тому я зупиняюся тут. Мої переваги зрозумілі , все-таки є цей пост, порівнюючи обидва. Я ніколи не міг зрозуміти, чому Фантому приділяється так мало уваги в порівнянні зі Скалою. Але, мабуть, я не єдиний, якщо ви слухаєте цей подкаст [ mp3 ] до кінця.)


9

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

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

Хоча Scala дозволяє вам вирішувати багато проблем у функціональний спосіб, я часто знаходжу проблеми, коли використання класів відчуває себе більш природним. Це робить речі дещо складнішими, але ніде не буває складнощів і болю C ++.

Найбільше для мене, коли я справді почав вивчати мову, - це те, що я міг програмувати саме на Java, просто без шуму (трішки, як коли ти починаєш Groovy), але врешті ти хочеш спробувати зануритися глибше у владу мови - з вами росте.

Про питання IDE: Після використання Emacs для всіх, всі мої проблеми IDE пішли :-)


9

Мені подобається Скала з багатьох причин, але є одна, яку часто не помічають: її простота.

Скала може бути не такою простою, як, скажімо, Оберон, але вона набагато простіша, ніж деякі інші мови. Специфікація мови Scala становить ~ 160 сторінок, специфікація мови Java становить ~ 600 (лише мова, а не JVM або бібліотеки!), Специфікація мови ECMA-334 C # (якій AFAIK відповідає підмножині Visual C # 2.0): ~ 440 сторінок (це не такі речі, як розуміння запитів LINQ, лямбда-вирази, методи розширення, загальне спів- та протиріччя dynamic, необов'язкові аргументи зі значеннями за замовчуванням, аргументи ключових слів var). Навіть поточний проект для ECMAScript 5.1 є більшим на ~ 210 сторінок. І звичайно моя власна мова "за замовчуванням", Ruby, чия нинішня чернетка ISO важить приблизно ~ 310 сторінок, де лише вказано майже неприйнятно крихітний підмножина перетину Ruby 1.8.6, 1.9.1 та 1.9.2.


6
Кількість сторінок у мовній специфікації є цікавим показником її складності. Дивно, як Скала ділиться думками з цього приводу. Ніхто не сказав би, що Python є складним, або C ++ є простим, але Scala, здається, і те і інше :-), наприклад, scala-lang.org/node/7431
Joonas Pulakka

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

2
Кількість сторінок у мовній специфікації - ГОТОВИЙ спосіб порівняння складності двох мов. Наведемо лише два приклади: специфікація Java написана майже підручником, тоді як специфікація Scala написана дуже лаконічно. Або інший приклад, C # 2.0 насправді був приблизно таким же складним, як сьогодні Java, або, можливо, трохи складніший з огляду на "небезпечну" техніку, делегати та prpoerties. Але, як ви зазначаєте, специфікація C # 2.0 менша, ніж JLS.
Джеймс Ірі

1
Тепер Мартін Одерський порівняв розміри формальних граматик мов. Це розумна міра одного аспекту складності. Але це розумно лише тому, що граматики не такі гнучкі, як англійська. Вже тоді треба бути обережним. Як і у звичайних програмах, ви можете легко розтягувати або стискати граматики з різним вибором про те, як розкласти їх, скільки різних виробництв включити, які базові класи персонажів припустити тощо.
Джеймс Ірі

3
чекати, що ? Чому б ви намагалися виміряти складність за розміром характеристики? Це жахлива ідея.
smartnut007

9

Ось, що гарно про Scala:

  • Нульовий покажчик був для цього досить поганою ідеєю. Хоар назвав це своєю "помилкою в мільярд доларів", але у Скали ще гірше. У ньому є об'єкти з ім'ям null, Null, None та Nil. null призначений для сумісності з Java. Null є нульовим покажчиком специфікації W3C DOM, None - це те, що null повинно було бути замінено, а Nil - це порожнє щось.

  • Коли мовні конструкції виявляються хиткими, зазвичай винен програміст, а не мова. Однак у Scala основна мова вже містить бібліотечні класи, єдиною документально підтвердженою поведінкою є "Це хакер". Не вірите? Шукайте у scaladoc для scala.xml.Group.

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

Щоб не помилитися з ненависником Скали, ось що я люблю в цьому:

  • У мене менше винятків. У мене ніколи не було ClassCastException і дуже мало NullPointerExceptions при взаємодії з Java.
  • Код набагато коротший і коротший, ніж Java
  • Це інтелектуально складно. Ява відчуває себе дитячою мовою в порівнянні.

10
nullє нульовим покажчиком Java, Nullє його "типом". Noneє одним із можливих "станів" Option[T]колекції з одним або нульовими елементами. Nilце порожній список. Хоча ви хочете, щоб це звучало страшно, це не так. Ці типи не є замінними або взаємозамінними один з одним і поводяться так, як слід робити.
соц

9

Скала є складною. Ніякого шляху! Його синтаксис є надзвичайно гнучким і може бути налаштований різними способами (перш за все операторами / інфіксацією) - і система типів має більше різних можливостей, ніж будь-яка інша мова, яку я знаю.

Тому все не так прямо, як, наприклад, у Haskell: Typeclasses, щоб охопити їх усіх.

Коли Scala намагається зібрати функціональне програмування, OO, процедурне програмування та бібліотеки java, а також власні ідеї, ми нарешті закінчуємо безліччю концепцій, які так чи інакше йдуть "в тому ж напрямку":

  • Неявні значення
  • Неявні функції
  • Екзистенціалі
  • Уайлдкард
  • Риси
  • Інтерфейси
  • Абстрактні заняття
  • Класи кейсів
  • Структурні типи
  • Загальні обмеження
  • Перегляд меж
  • Анонімні типи

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

Але цікаве: Скала працює. Іноді важко зрозуміти, чому (особливо з'ясовувати, через які неявні перетворення + успадкування + ... якийсь об'єкт має функціональністьX ), але вам не доведеться турбуватися про це більшість разів.

Напишіть Scala максимально прямо, і це спрацює. Не плутайте все можливе, а просто використовуйте те, що вам потрібно. І якщо вам щось потрібно, ви можете бути впевнені, що у Скали це якось є;)

І чим краще ви отримаєте, тим більше зможете налаштувати Scala за допомогою операторів, імпліцитів, монад, фанк-синтаксису ... і нарешті отримати щось наближене до DSL, що чудово вирішить вашу проблему.

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


1
"вище всіх операторів / інфіксації" - саме цього масштабу не вистачає операторів. :) Це просто методи.
користувач невідомий

6

Це відмінна мова, яка багато в чому простіша, ніж Java.

Більшість людей не сподобається, програміст Java чи ні, з тих самих причин, що більшість людей, програмістів чи ні, не люблять вивчати нові мови програмування. Я підозрюю, що більшість людей, які вивчали мову програмування, навіть не любили цього вивчати.

Якщо ви турбуєтесь про те, щоб мова була такою складною, як C ++, я б уникнув Clojure, як чума. Хоча, що Скала є складнішим, ніж Clojure, став аргументом для людей, які абсолютно неосвічені щодо однієї або обох мов.

У Clojure є макроси, а це означає, що ви можете змінити синтаксис мови скільки завгодно, даючи вам не просто "безліч різних способів робити речі", а майже нескінченну кількість способів робити речі. І жоден із цього нового синтаксису, який створюють програмісти за допомогою макросів, не буде задокументовано в будь-якому місці мовної специфікації.

"Але ми можемо уникати використання макросів або регулювати, які з них дозволені в нашому коді", - ви кажете. Вітаємо, тепер у вас є "штучно обмежувати мовні функції, які ви збираєтеся використовувати, а що ні", саме це лелекаючі ідіоти, які використовують Clojure of Scala, стали причиною того, щоб уникнути Scala для початку.


6
Дякую за ваш внесок Scala vs Clojure, але це те, про що я справді запитую?
Мартін Вікман

Цікавий момент re: макроси. Трохи хвилюючись, також. Чи доступні макроси чи подібні в Scala, або це все, що "штучно обмежено", відволікає увагу?
Арман

1
Це, здається, є коментарем до моєї відповіді, а не відповіддю на початкове запитання. Я погоджуюся, макроси дають вам нескінченну силу, тому при неправильному використанні вони смокчуть. Отже, вам слід правильно їх використовувати (лише за потреби). Це не змінює того факту, що мова Clojure - одна з найпростіших. Скала точно не є.
Joonas Pulakka

> Це не змінює того факту, що мова Clojure є однією з найпростіших з них. <Це також абсолютно неправдиво, якщо ви не використовуєте якусь метрику на кшталт "кількість мовних конструкцій". Якщо ви використовуєте щось корисне, наприклад, як легко читати та писати програми мовою, то Clojure - це не один із найпростіших.
Джош

Тож, будь ласка, продовжуйте і дайте нам хороший показник мовної складності. "Як легко читати та писати програми мовою" є абсолютно суб'єктивним , тому це насправді не допомагає. Зрозуміло, розробити корисну та об'єктивну метрику може бути практично неможливо. (Наприклад, Йорг W Міттаг нижче використовує кількість сторінок у мовній специфікації як міру складності. Хоча об'єктивний, я не впевнений, що це дуже корисно.)
Joonas Pulakka

4

Мені дуже подобаються більш деталізовані типи бібліотеки Scala. Схоже, нова бібліотека колекцій була продумана. Мені також подобається, як це зменшує кількість коду, необхідного для простих класів, та функціональні концепції, які він додає. Його корисний висновок також дуже корисний. Відчувається, що Java без навчальних коліс. Після використання C # деякий час, Scala насправді відчуває себе конкурентом, а Java все ще корисна, але залишається позаду.


2

Як Java-програміст, я спочатку вважав Скалу цікавою. Однак, після того, як на деякий час поспілкувався з цим (і натрапив на майже всі позитиви / негативи, які вже перераховані іншими), я залишився відчувати себе дуже "мех" щодо цього. Мовні вдосконалення компенсуються меншою доступністю наборів інструментів. Я просто не міг придумати жодної чіткої причини переключитися. Це добре, але це не "краще", щоб зробити справу для перемикання. Не має і цього суб'єктивного чинника збудження (як, здається, Clojure).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.