JVM에 갇혀, Java가 아프다… 어디로 가야합니까?

https://stackoverflow.com/questions/1473242

16-09-2019
|

문제

향후 3 년간 매우 구체적인 제 3 자 API를 사용하여 JVM (프로젝트 요구 사항)과 협력해야합니다. 그들은 Java를 원하지만 나는 Java에서 멀어 지도록 여유를 받았습니다. 나는 우리가 .NET 프레임 워크로 돌아가서 OCAML과 절대적으로 사랑에 빠진 코드를 개발할 수 있기를 바랐다. .NET 개발은 고객에 의해 무너졌습니다. 그것은 지나가지 않습니다.

나는 스칼라 또는 클로 주어 등 어떤 언어가 나에게 더 호소 할 수 있는지를 이해하려고 블로그/포럼을 프로그래밍하고, 읽고, 찌르기 위해 돌아섰습니다. 그것들은 가장 큰 커뮤니티/팬 기반을 가진 것 같습니다. ML 언어를 경험 한 나는 Scala를 ML과 비교하는 많은 사람들을 봅니다. 그러나이 비교를 할 때는 실제 naysayers가 있습니다. Scala가 ML에 가까운 경우 생산성과 학습 곡선 이이 스위치를 만드는 데 도움이 될 것입니다.

인터넷은 잘못된 정보로 가득 차 있으며 내가 그런 고통을 겪고 있는지 궁금합니다. 나는 LISP의 구문이 마음에 들지 않지만 (나를 해치지 마십시오!) Scala가 내가 읽고있는 사마귀가 있다면 (IDE 지원, 플럭스 장치 테스트 프레임 워크, 성능 문제) Clojure가 더 나은지 궁금합니다. 옵션. 기능을 일류 대상으로 사용하고 동시성 통증을 최소화하고 게이트 밖으로 생산적이기를 원합니다.

어쨌든, 인터넷에서 너무 많은 시간을 보내고 일하지 않기 전에 ... JVM에 갇혀 Java가 아프고 어디로 가야할지 궁금합니다.

해결책

그루비를 고려해 보셨습니까? 나는 그것이 Scala/Clojure만큼 기능적이라고 생각하지 않지만 Java보다 훨씬 더 기능적입니다. 일반적으로, 나는 Groovy에서 동일한 작업을 수행 할 수 있습니다.

Groovy는 Java와 구문 적으로 유사하고 JDK 라이브러리에 완벽하게 액세스 할 수 있지만 많은 언어 기능 (클로저, 메타 프로그래밍, 속성) 및 동적 타이핑이 추가되면 Java 프로그램과 관련된 거의 모든 보일러 플레이트를 제거하기 때문입니다.

** 나는 '올바르게 작동하는 것이 아니라'기능적 프로그래밍 '의 의미에서 기능적을 의미합니다.

다른 팁

제 생각에는 Clojure와 Scala는 모두 중요한 IDE 지원을받지 못합니다. 즉, 여기 내 독서 및 경험에서 수집 할 수있는 것이 있습니다.

스칼라의 전문가

Clojure보다 빠릅니다 보다 정적 인 타이핑 덕분에
ML에 더 가깝습니다 (구문, 유형 지향 프로그래밍)
더 큰 표준 API (Clojure의 API는 공개하기 전에 최고의 관용구를 찾기를 원하기 때문에 매우 느리게 성장합니다. Clojure는 여전히 반 공동 보충 API를 가지고 있습니다).
더 나은 통합 관행 일반적인 Java Toolset을 사용하면 (Clojure는 여전히 일부 선택을하고 있으므로, 이와 관련하여 확고히 확정되지 않았습니다)
Clojure보다 나이가 많습니다 (그러나 Clojure는 매우 오래되고 입증 된 핵심 위에 지어졌습니다 : LISP)
사람들은 주류에 도달 할 기회가 있다고 말합니다, 그들은 Clojure에 대해 똑같이 말하지는 않지만

Clojure의 전문가

엄청나게 쉽고 빠르며 올바른 동시성 MVCC 기반 STM에 감사드립니다 그리고 다른 동시성 메커니즘
기본적으로 불변성 먼저 올바른 일을하는 데 도움이됩니다
보다 안정적인 표준 API
- 상황이 바뀌면 일반적으로 기존 코드를 다시 작성할 필요가 없습니다.
- (Scala의 컬렉션은 다시 2.8로 다시 재건되고 있습니다)
- (나는 또한 Scala의 배우 구현이 재고하고 다시 작성해야한다는 것이 일반적인 지식이라는 것을 어딘가에서 읽었습니다.)
배우기가 더 쉽습니다 (작은 언어, (매우 세련된) LISP)
다른 것을 배우면서 성장할 수있는 기회
Clojure의 성능은 시간이 지남에 따라 더 나아질 것입니다. 컴파일러의 멋진 최적화를위한 여지가 여전히 있습니다.
Scala의 Java에 묶는 것은 Clojure (Scala와 Java의 정적 유형 시스템 간의 상호 작용)보다 더 제한적이라고 느낍니다. 때때로 Clojure에 대해 똑같이 말할 수 있습니다 (객체 지향의 지원은 1 : 1 적합하지는 않지만 이에 대한 지원은 곧 나아질 것입니다).
Rich Hickey는 Clojure가 수십 년 동안 다른 언어가 채택 할 기술적 선행 기능을 갖춘 위치에있는 선택을위한 선물을 제공합니다. 그리고 그는 또한 선물을 가지고 있습니다 그들을 설명합니다. 따라서 오늘날 Clojure에서 사용하거나 몇 년 안에 다른 언어로 사용하기를 기다립니다. :)

분산 동시성

동시 요구가 배포 된 경우, Clojure는 테라코타 위에 실행하거나 유사한 것으로 실행하지 않으면 아직 이에 대한 것이 없습니다.이 경우 모든 동시성 기능을 사용할 수 있습니다. 그렇게한다면 Scala의 배우 IMO보다 더 나은 분산 동시성 경험을 얻게됩니다.

결론

IMO Scala는 모든 것을하려고 시도하고 대부분의 일을 성공적으로 수행합니다. Clojure는 같은 것을 시도하지는 않지만, 그것이 초점을 맞추는 것은 충분하고 성공하기 때문에 Clojure가 정말로 알고있는 대부분의 사람들이 다른 것으로 되돌아 가고 싶지 않을 것입니다. 폭로: 내 개인적인 취향은 물론 Clojure에갑니다. 나는 내가 쓴 내용에 객관적이 될 수 있기를 바랍니다.

나는 당신이 스칼라에 대해 제기 한 포인트를 다룰 것입니다.

IDE 지원:

Scala는 Java가 보유한 동일한 수준 또는 IDE 지원을 가지고 있지 않습니다.

즉, 최고 중 하나가 있습니다 (아마도 그만큼 BEST?) IDE는 JVM, Java 외부에서 지원합니다. 지금은 NetBeans가 충분히 좋으며 사람들은 일관되게 아이디어가 여전히 더 좋다고 말했습니다 (청각). Eclipse 플러그인은 불안정합니다.

그러나 3 년 범위를 언급했으며 Scala 2.8이 나오면 Scala에 대한 IDE 지원은 IDE에 대한 컴파일러 지원을 제공하기 때문에 크게 향상되어야합니다. 릴리스 날짜는 정의되지 않았지만 향후 6 개월 이내에 3 개일 수 있습니다. Eclipse 플러그인은 바로 업데이트됩니다.
플럭스 장치 테스트 프레임 워크에서:

그렇습니다. 만약 당신이 그것이 정체되고 버려진 대신 활기차고 진화하며 잘 지원된다는 것을 의미한다면. Scalatest, Specs 및 Scalacheck은 최고 품질의 프레임 워크이며 자체와 호환되며 Junit 및 Jmock과 같은 다른 Java 프레임 워크 및 라이브러리와 호환됩니다.

실제로 테스트 프레임 워크는 거의 스칼라로 가능한 어린이 포스터입니다.

편집하다: Scala는 표준 라이브러리 (scala.testing.sunit)에 기본 단위 테스트 지원이 있습니다. 그러나 많은 우수하고 적극적으로 지원되고 무료 대안이 나타 났을 때, 이는 더 이상 사용되지 않았으며 Scala 2.8과 함께 배송 된 도서관의 일부가 아닐 것입니다.
성능 문제:

나는 다른 언어와 마찬가지로 당신이 거친 코드를 쓸 수 있다는 사실을 제외하고는 아무것도 모릅니다. 기능적 프로그래밍에 익숙하지 않은 사람들은 종종 꼬리 재귀를 사용하지 않거나 목록을 연결하지 않는 등 효율적이지 않은 일을하며 Scala가이를 향상시킬 수있는 패러다임 전환이이를 빛으로 가져옵니다.

어쨌든, 당신은 Java 코드만큼 빠른 스칼라 코드를 작성할 수 있습니다 (다가오는 기능에서도 더 빠릅니다). 또한 Java 코드만큼 빠른 기능 기능으로 Scala 코드를 작성할 수 있습니다.

솔직히 다른 직업을 얻으십시오.

다음 3 년 동안 자신이하고있는 일에 불편 함을 느끼면 더 매력적인 대안을 찾는 것을 고려해야합니다.

당신이 좋아하는 언어를 얻을 수 있더라도, 팀의 일원이라면 (당신이 생각하는지) 팀의 나머지는 그 언어를 좋아하지 않을 수 있습니다. 나머지 사람들이 Java로 코딩하고 당신은 "빈칸을 채우세요"프로그래밍 언어, 문제가 발생할 수 있습니다.

결국 그렇게 나쁘지 않습니다.

당신의 상사와 이야기하고, 당신이 어떻게 느끼는지 알려주십시오. 대안을 찾기 시작하고 멋지고 전문적인 "휴가"를 갖습니다.

현재 상사와 여전히 좋은 관계를 가질 수없는 이유는 없습니다. 결국 .net을위한 새로운 프로젝트가 있으면 돌아올 수 있습니다. 그들과 함께 이야기하십시오. 문을 열어 두십시오.

실제로 제로 합계 게임이 아닙니다. 모두 배우십시오!
추신 : 투표합니다 Clojure, 나는 그것이 가장 재미 있다고 생각합니다!

JVM이 Java보다 대체 프로그래밍 언어에 대해 점점 더 인기를 얻고 있기 때문에 JVM을 사용할 수 있다는 것이 운이 좋다고 생각해야합니다.

Java 외에도 있습니다 그루비, 스칼라, Clojure (JVM의 LISP 방언), Jruby (JVM의 루비), Jython (JVM의 파이썬), Jaskell (JVM의 Haskell), 팬 (.NET CLR뿐만 아니라 JVM에서도 실행). Ocaml-Java, JVM에서 실행되는 OCAML.

따라서 순수한 기능에서 간단한 스크립팅 및 밸런스 된 OO 언어에 이르기까지 JVM의 프로그래밍 언어로 많은 선택이 있습니다.

Scala 및 Clojure에 대한 도구 지원은 미숙 할 수 있지만 꾸준히 개선되고 있습니다.

당신은 f#을 좋아하기 때문에 스칼라가 가장 좋은 방법 일 것입니다. 나는 그것을 시도하고 당신 자신의 의견을 형성한다고 말합니다. 사람들이 좋아하는 것은 당신에게 중요하지 않은 것, 또는 당신이 일할 수있는 것들이라는 것을 알 수 있습니다.

Jruby를 잊지 말고 IDE는 비 Java의 선택 사항입니다.

나는 당신이 좋은 상황이 있다고 생각합니다. 구현 언어를 선택할 수있는 사람은 몇 명입니까? 환경을 선택할 수있는 JVM이 이용할 수있는 모든 것은 그다지 제한이 아닙니다.

덜 장악 한 언어에서 큰 IDE 지원이 필요하지 않습니다.
유형 선언이없는 루비만큼 강력한 언어로는 전혀 IDE가 필요하지 않습니다.
Scala는 구체적으로 Verbose-Java-Blues를 치료하기 위해 개발되었습니다
3 년간의 작업이 줄을 서서 운이 좋다 :-)
Clojure는 재미있을 수 있으며 기능적 동시성-안전 디자인 패턴을 제공합니다.

노프? http://code.google.com/p/noop/ (실험)

IDE 지원과 다른 의심의 관점에서 Clojure는 Scala보다 더 나은 일을하지 않습니다. 그리고 ML/F# 배경을 가진 사람 (또는 일반적으로 정적으로 입력 한 FP 언어)의 경우, 스칼라가 익숙한 것보다 훨씬 더 가깝게 알 수 있습니다.

당신이 ML을 좋아한다면 당신은 좋아할 것입니다 칼 JVM의 경우 더 많은 Haskell 98입니다.

그것은 고품질과 매우 안정적이며 Eclipse에 대한 IDE 지원이 좋지만 슬프게도 더 이상 적극적인 발전을받지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow