Буде Scala хорошим вибором замість Java?


11

Ми розпочинаємо новий проект, який передбачає підготовку всіх розробників .net на Java (фреймворк / система ECO тощо). У нас багато коду, написаного на C #, і, здається, все це буде марно, оскільки нам доведеться переписати все на Java. Проблема, яку я бачу, полягає в тому, що перший рік або близько того (можливо, 2 роки) нам не доведеться нічого доставляти, оскільки ми витратим більшу частину часу на відтворення того, що було раніше, але зараз на Java.

Оскільки наша команда розповсюджується в різних офісах по всьому світу і у нас є велика кількість розробників java (від 20 до 30) та 10 розробників, що використовують .net, ми хочемо отримати всіх розробників, що використовують ту саму мову / платформу, щоб ми могли почати повторне використання компонентів / модулів. Тож я можу зрозуміти точку зору управління.

Вчора я натрапив на Scala і поцікавився, чи краще використовувати це з поточним продуктом (який написаний на C #), і тоді принаймні у нас буде робочий продукт через рік. Також через рік у нас є модулі, які можна використовувати в світі Java, коли ми переміщуємо інші частини продукту.

Буде Scala кращим вибором, ніж Java, враховуючи те, що ми намагаємось досягти?


2
Переписувати все іншою мовою? І 2 роки без нічого доставити? Здається, що це жахливе рішення керівництва і, як вам може знадобитися нова робота через півроку;)
zvrba

Так, це було враховано. Не впевнений, з чого я повинен почати шукати зараз, і дотримуватися C # :)
JD01

1
Це звучить, як ви збираєтеся
back2dos

Відповіді:


15

Деякі моменти, які слід врахувати:

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

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

З точки зору управління це має багато переваг:

  • Ви все ще можете поділитися всіма бібліотеками, щоб ваші інвестиції були безпечними
  • Ваші менш досвідчені розробники зможуть перенести C # -> Java досить швидко
  • Ваші досвідченіші розробники можуть повністю скористатися передовими можливостями Scala
  • Усі інструменти сумісні / можуть бути спільними (можна створити системи, IDE, засоби розгортання тощо)
  • Ви отримуєте безкоштовний доступ до дуже широкої екосистеми бібліотек з відкритим кодом на JVM (поряд з переносності платформ, це, мабуть, найкраща причина бути на платформі JVM)
  • Ваші розробники використовують мову, яка робить їх найпродуктивнішими, враховуючи їхні навички / завдання, що знаходиться під рукою (Java в деяких випадках, Scala в інших, можливо, інші мови, як Clojure в майбутньому)

Мінус полягає в тому, що ви все ще маєте дві основні мови для підтримки. Але ви, мабуть, насправді вже маєте багато більше, ніж просто два (сценарії оболонки? Формати XML, що стосуються домену? Конфігураційні файли? Системи управління? HTML? Javascript?), Тож ви можете стверджувати, що насправді це не велика справа.


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

1
Радий допомогти! Варто усвідомлювати, що Scala - це скоріше багатомовна парадигма / OOP. Хоча ви, звичайно, можете робити FP у Scala, якщо ви хочете, щоб мови, які є більш чітко функціональними у фокусі, то Haskell або Clojure, ймовірно, ближче до позначки.
mikera

Що стосується повторного використання коду, якщо я використовував Clojure або Scala з першого дня або навіть, як ви сказали, у змішаній стратегії, чи можу я використати повторно Clojure / Scala код як у .net, так і в Java? Мені цікаво, чи це хороший пункт продажу для менеджменту. Таким чином, ми все-таки зможемо випустити продукт (старий продукт з новими можливостями), а також будемо на шляху до повторного написання наявного коду на Java з повторним використанням коду модулів clojure / scala. Чи я тут правильний, чи це відкриває інші проблеми?
JD01

1
Ви можете розкрити функцію Clojure / Scala як веб-сервіс або інтерфейс REST, якщо вам це подобається. Це дещо вище, ніж просто побудова бібліотеки (що було б найкращим варіантом, якщо ви хочете зателефонувати на функціональність з Java / іншої мови JVM), але це, безумовно, дасть можливість виклику коду від будь-якого клієнта, який вам сподобався (. Net, Java, Ruby тощо)
mikera

Спасибі Майку. Я думаю, що шлях повторного використання коду, принаймні, покаже керівництву, що повне перезапис не потрібно за допомогою параметра Scala / Clojure. Я не хочу, щоб ми закінчилися як Netscape :). Повернувшись до створення бібліотеки, я міг би просто не використовувати її у .net та Java без веб-служб?
JD01

15

Я додам 3-й варіант. Хтось із вашої організації переглянув інтероп між вашими модулями C # та Java? Як ви відкриваєте функціонал C #? Чи доступний веб-сервіс SOAP або RESTFul?

Переписування на два роки може бути смертю для організації (просто запитайте Netscape). Однак поступова міграція, хоча існуючий код добре грає один з одним, має потенційно менший вплив на бізнес.


3

Переписування C # в Scala буде настільки ж важким, як переписування на Java. Щодо того, яка мова "краща", ця точка є суперечкою, у кожної мови є свій плюс і мінус бали.

Я не знаю, наскільки велика ваша кодова база, але 2 роки для 30 розробників здаються величезними для простого переписування. Підбирати Java, коли ви знаєте, що C # легко. Мені знадобилося день чи два, щоб з цим заспокоїтися.

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


Лише близько 10 розробників працюватимуть над новим продуктом. Я просто намагаюся з’ясувати, які плюси та мінуси матимуть Scala.
JD01

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

Ви можете мати рацію. Я думав про це з точки зору виходу продукту через рік або близько того, в той же час, коли можна було повторно використовувати код у .net та Java. Ваші бали добре помічені :)
JD01

1

Я думаю, що простішим варіантом було б дозволити розробникам Java вивчити C #. Обидві мови багато в чому схожі, і розробник Java не потребує багато часу, щоб забрати C #. Я працював з багатьма розробниками Java, які вивчали C #, і зазвичай це плавний перехід. Єдиною областю, де вони можуть застрягти на деякий час, є модель програмування WebForms. Розробники Java краще адаптуються до парадигми MVC. Таким чином, вам не потрібно чекати рік, перш ніж ви почнете розробляти нові функції. Що стосується Scala, то, я боюся, це створить зовсім нову проблему з усіма 30 розробниками, які намагаються вивчити нову мову.


На Java написано так багато продуктів, тож отримати їх для вивчення C # буде складно. Я сподівався на Scala, щойно у нас з'явиться новий продукт, розробники Java зможуть використовувати бібліотеки так, як це не потрібно вивчати Scala.
JD01

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

Це було запропоновано раніше, але було вирішено відмовитися від .net.
JD01

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