Java 개발자는 Scala에 대해 어떻게 생각합니까? [닫은]

IDE 지원은 그다지 좋은 수준은 아니지만 언어 자체가 기능 프로그래밍 관용구를 훨씬 더 깨끗하게 지원합니다.

나는 지금 1 년 이상 스칼라를 프로그래밍 해 왔으므로이 질문에 답하기 위해 1 년을 다시 설정하려고 노력할 것이다.

• 스칼라 코드는 Java 코드보다 간결합니다 (세터 나 게터가 없으며 많은 유형 정보가 유추 될 수 있음)
• XML 리터럴에 대한 내장 지원은 매우 매력적입니다.
• 자바 라이브러리 호환성과 상호 운용성
• 특정 기능 관용구에 대한 지원이 새로 고침됩니다 (이해, 폐쇄, 람다 함수,지도, 접기, 축소)
• 언어 작성자가 포함하고 싶지 않은 멋진 기능은없는 것 같습니다

위의 요점은 배우기 전에 스칼라에 대해 생각한 것입니다.

1 년 동안 내가 알게 된 것은 다음과 같습니다.

• 계단 책 을 구입하는 것은 큰 투자였으며 저만의 학습 시간을 절약했습니다.
• 구문에는 몇 가지 단점이 있으며 때로는 왜 무언가가 유효하지 않은지에 대해 의아해했습니다. 일단 익숙해지면 코드가 덜 어려워지고 읽기 쉽습니다. 코드를 작성하지 않고 읽는 경우에는 실제로 문제가되지 않습니다.
• 2.8의 콜렉션 라이브러리는 사용하기에 좋습니다. Java로 돌아 가기가 어렵습니다.
• XML 리터럴은 훌륭하지만 몇 가지 기본 사항을 넘어 Java 라이브러리 에코 시스템에 접근해야했습니다. 그래도 편리합니다.
• Scala에서 Java 라이브러리를 사용하는 것은 매우 쉽고 편리합니다. Java에서 Scala 클래스를 사용하는 것은 조금 까다 롭지 만 작동합니다.
• IntelliJ IDEA 커뮤니티 에디션으로 전환했으며 완벽하지는 않지만 충분합니다.
• 언어 작성자는 실제로 기능 세트에 대해 생각했으며 모든 기능이 실제로 잘 작동했습니다. 객체 지향 지원은 Java보다 (특성이있는)보다 우수하며 함수형 프로그래밍을 수행 할 수 있습니다.
• 분명히 일부 Java 개발자는 열정으로 싫어하는 언어입니다. 나를 위해, 그것은 프로그래밍의 기쁨을 다시 가져 왔습니다.

스칼라가 너무 복잡하다고 생각합니다. C ++과 같은 느낌이 들며 다양한 방식으로 작업을 수행합니다. 어떤 사람들은 이것을 "풍부함", "표현성"또는 "힘"이라고 부르지 만 마일리지는 다를 수 있습니다. 많은 실제 프로젝트에서 사용하려는 언어 기능과 사용하지 않을 언어를 인위적으로 제한하여 관련된 모든 개발자가 언어의 동일한 하위 집합을 말할 수 있도록해야합니다.

함수형 프로그래밍에서는 Clojure를 선호합니다 보다 훨씬 간단한 .

거룩한 전쟁을 시작하자 ;-)

약 1 년 전, Java를 계속 사용하면 스타트 업 제품의 미래에 대해 점점 더 좌절감을 느끼면서 스칼라를 시험해보기로 결정했습니다. 나는 이미 JavaScript와 Python으로 프로그래밍하고 있었지만 Ruby도 좋은 대안 이었지만 정적으로 유형이 지정된 언어, 바람직하게는 JVM에서 실행할 수있는 언어를 찾고있었습니다.

나는 정말로 스칼라를 좋아하려고 노력했지만 실제로 그렇게했지만 코드가 완전히 추악하고 이해하기 어렵다는 것을 알았습니다. Scala가 Java에 대한 최선의 대답이라면 분명히 마음에 들지 않았고 결국 마음에 들지 않는 언어로 계속 작업하기로 결정했습니다 ...

다행히도 얼마 지나지 않아서 Fantom 에 대해 알게되었습니다 . 오, 내가 좋아 했어! 저에게는 독일 관료주의에 대한 미국의 화려한 답변과 같았습니다! 그것은 스칼라에서 찾고 있던 요구 사항과 일치하지만 훨씬 더 우아 합니다. 그것은했다 빔 , 이클립스 와 넷빈즈의 통합, 멋진 웹 프레임 워크 , 성숙 제품을 함께 실행하는, 작지만 매우 도움이 커뮤니티 ... 동적 및 정적 타이핑을! 나는 기뻐했다!

(계속할 수는 있지만이 게시물은 Fantom이 아니라 Scala에 관한 것이므로 여기서 멈춰야합니다. 그럼에도 불구하고 선호하는 것은 분명합니다 . 그럼에도 불구하고 두 게시물을 비교 한이 게시물 이 있습니다. 나는 Fantom이 Scala와 비교했을 때 그다지 주목을받지 못하는 이유를 이해할 수 없었습니다. 하지만 끝까지이 팟 캐스트 [ mp3 ] 를 들으면 분명히 나만이 아닙니다 .)

2 년 전 처음으로 스칼라를 만났을 때, 그것은 외계인이었고 저를 위협했습니다. 어떤 시점에서 핵심 언어가 실제로 Java보다 훨씬 간단하다는 것을 알았지 만 구문과 의미가 너무 유연하여 매크로 기능이 없어도 새로운 언어 구성을 만들 수 있습니다. 나는 모든 상용 Java 프로젝트에 대해 Scala로 완전히 전환했습니다. 보일러 플레이트 코드를 너무 많이 쓰지 않고도 작성할 수 있기 때문입니다.

Clojure를 좋아하지만 플랫폼에서 정적 바이트 코드 (Android, applet 등)로 컴파일 해야하는 상황이 있으며 스칼라에서는 가능합니다.

스칼라는 기능적으로 많은 문제를 해결할 수 있지만 클래스 사용이 더 자연스러운 문제를 종종 발견합니다. 그것은 조금 더 복잡하지만 C ++의 복잡성과 고통 근처에는 없습니다.

언어를 실제로 배우기 시작했을 때 가장 큰 장점은 잡음없이 (Groovy를 시작할 때와 거의 비슷하게) Java로 프로그래밍 할 수 있다는 것이었지만 결국에는 더 깊이 들어 가려고 노력했습니다. 언어의-그것은 당신과 함께 성장합니다.

IDE 질문에 관하여 : 모든 것에 Emacs를 사용한 후, 모든 IDE 문제가 사라졌습니다 :-)

나는 여러 가지 이유로 스칼라를 좋아하지만 간과되는 경우가 종종 있습니다.

스칼라는 오베론처럼 간단하지는 않지만 다른 언어보다 훨씬 간단합니다. 스칼라 언어 사양은 ~ 160 페이지, Java 언어 사양은 ~ 600 (JVM 또는 라이브러리가 아닌 언어)입니다. ECMA-334 C # 언어 사양 (AFAIK는 Visual C # 2.0의 하위 집합에 해당)입니다. ~ 440 페이지 (LINQ 쿼리 이해, 람다 식, 확장 방법, 일반 공존 및 대 분산, dynamic기본값이있는 선택적 인수, 키워드 인수 등 var)가 없습니다. ECMAScript 5.1의 현재 초안조차 ~ 210 페이지에서 더 큽니다. 물론 현재 ISO 초안의 무게가 ~ 310 페이지 인 루비 (Ruby)는 루비 1.8.6, 1.9.1 및 1.9.2의 교차점 중 거의 사용할 수없는 부분 집합 만 지정합니다.

스칼라의 장점은 다음과 같습니다.

• 널 포인터는 시작하기에는 아주 나쁜 생각이었습니다. Hoare는 그것을 "십억 달러의 실수"라고 불렀지 만 Scala는 더욱 악화되었습니다. 여기에는 null, Null, None 및 Nil이라는 개체가 있습니다. null은 Java와의 상호 운용성을위한 것입니다. Null은 W3C DOM 사양의 Null 포인터이고, Null은 Null이 대체 된 것입니다. Nil은 비어있는 것입니다.

• 언어 구조가 해킹 된 것으로 판명 될 때, 언어를 비난하는 것은 프로그래머가 아닙니다. 그러나 스칼라의 핵심 언어에는 이미 문서화 된 동작이 "This is a hack"인 라이브러리 클래스가 포함되어 있습니다. 믿지 않습니까? scaladoc에서 scala.xml.Group을 검색하십시오.

• 마지막으로 스칼라는 잘못 문서화되어 있습니다. 공식 문서의 스칼라 클래스는 예제 코드와 함께 제공되지 않습니다. 스칼라는 Java보다 배우기가 훨씬 어렵고 컴퓨터 과학에 대한 깊은 지식이 필요합니다.

스칼라 증오로 착각하지 않기 위해 여기에 내가 좋아하는 것이 있습니다.

• 나는 더 적은 예외가 있습니다. Java와 상호 작용할 때 ClassCastException과 NullPointerExceptions가 거의 없었습니다.
• 코드는 Java보다 훨씬 짧고 간결합니다.
• 지적 도전입니다. 자바는 비교할 때 아기 언어처럼 느껴집니다.

스칼라 입니다 복잡합니다. 그 주위에 방법이 없습니다! 구문은 매우 유연하며 다양한 방법으로 모든 연산자 / 접두사 표기법을 통해 사용자 정의 할 수 있으며 유형 시스템에는 내가 알고있는 다른 언어와 다른 기능이 있습니다.

따라서 Haskell : Typeclasses와 같이 모든 것을 다루는 것은 똑 바르지 않습니다.

스칼라는 기능적 프로그래밍, OO, 절차 적 프로그래밍 및 자바 라이브러리를 자체 아이디어와 함께 모 으려고 시도함에 따라 결국 "같은 방향으로"가는 것처럼 보이는 많은 개념 으로 끝납니다 .

• 암시 적 값
• 암시 적 함수
• 존재
• 와일드 카드
• 특성
• 인터페이스
• 추상 수업
• 사례 클래스
• 구조 유형
• 일반 제약
• 경계보기
• 익명 유형

그중에서 선택하는 것은 처음에는 어려워 보이며 어떤 문제에 대한 올바른 해결책을 찾았는지 쉽게 알 수 있습니다 . implicits 를 악용하여 해키를 만드는 것도 가능합니다 .

그러나 흥미로운 것은 스칼라가 작동한다는 것입니다. 이유를 이해하기가 어려운 경우가 있습니다 (특히 암시 적 변환 + 상속 + ...X ) 대부분의 경우 신경 쓰지 않아도됩니다.

Scala를 가능한 한 간단하게 작성하면 효과가 있습니다. 가능한 모든 것에 혼동하지 말고 필요한 것을 사용하십시오. 그리고 무언가가 필요하다면 어떻게 든 스칼라가 그것을 가지고 있음을 확신 할 수 있습니다.)

그리고 더 잘 얻을수록 연산자, 암시 적, 모나드, 펑키 구문으로 스칼라를 더 많이 사용자 정의 할 수 있으며, 문제를 완벽하게 해결하는 DSL에 가까운 것을 얻을 수 있습니다.

결국, Scala를 더 깨끗하고 쉬운 구문, 형식 유추 및 일부 기능적 기능을 통해 훨씬 더 나은 Java로 사용할 수 있습니다.

여러 가지면에서 Java보다 간단한 우수한 언어입니다.

대부분의 사람들은 자바 프로그래머를 좋아하거나 싫어합니다. 대부분의 사람들, 프로그래머가 아니든간에 새로운 프로그래밍 언어를 배우는 것을 좋아하지 않는 것과 같은 이유로. 나는 프로그래밍 언어를 배운 대부분의 사람들이 그것을 배우는 것을 좋아하지 않았다고 생각합니다.

C ++만큼 복잡한 언어가 걱정된다면 전염병처럼 Clojure를 피할 것입니다. 스칼라가 클로저보다 더 복잡하다고해서 하나 또는 두 언어에 대해 완전히 무지한 사람들에게는 대체 논거가되었습니다.

Clojure에는 매크로가 있습니다. 즉, 언어 구문을 원하는만큼 변경할 수 있으므로 "수많은 다양한 방식으로 작업을 수행하는 것"뿐만 아니라 거의 무한한 방식으로 작업을 수행 할 수 있습니다. 그리고 매크로를 사용하여 프로그래머가 생성하는이 새로운 구문은 언어 사양의 어느 곳에 나 문서화되지 않습니다.

"하지만 매크로 사용을 피하거나 코드에서 허용되는 매크로를 조절할 수 있습니다." 축하합니다. 이제 "사용할 언어 기능과 사용하지 않는 언어를 인위적으로 제한"했습니다. Scala의 Clojure를 사용하는 멍청이 바보가 Scala를 피하기위한 이유로 사용한 것입니다.

나는 Scala 라이브러리의 더 세분화 된 유형을 정말로 좋아합니다. 새로운 컬렉션 라이브러리는 잘 생각 된 것 같습니다. 또한 간단한 클래스에 필요한 코드 양과 기능 개념을 줄이는 방법이 마음에 듭니다. 형식 유추도 매우 유용합니다. 훈련 바퀴가없는 Java처럼 느껴집니다. 잠시 동안 C #을 사용한 후 Scala는 실제로 경쟁자처럼 느껴지지만 Java는 여전히 유용하지만 남겨두고 있습니다.

Java 프로그래머로서, 나는 처음에 Scala가 흥미로웠다는 것을 알았습니다. 그러나 잠시 동안 그것에 손을 대고 (그리고 이미 다른 사람들이 이미 열거 한 거의 모든 긍정적 / 부정적 결과에 부딪친 후), 나는 그것에 대해 매우 "meh"라고 느끼게되었습니다. 언어 개선은 툴셋의 가용성이 낮아서 상쇄됩니다. 전환해야 할 명확한 이유를 찾지 못했습니다. 좋지만 전환 사례를 만들기에는 "충분히"충분하지 않습니다. Clojure처럼 주관적인 흥분 요인이 없습니다.