왜 이러한 시도가 Xtend와 Kotlin으로 Scala에 물을 줄이려고합니까? [닫은]

이제 Eclipse는 Xtend를 제공했으며 JetBrains는 Kotlin을 제공합니다. 둘 다 스칼라 버전에 물을 뿌린 것 ​​같습니다. 내 질문은 왜? 나는 스칼라와 조금 놀았는데 그렇게 어렵지 않습니다 . 이것은 명령에서 기능으로의 도약의 본질적인 어려움에 대한 반응일까요, 아니면 다른 일이 있습니까?

편집 : 사과. 내가 처음 게시 한대로 질문을 다시 읽으면 트롤링 같은 소리가 나는 곳을 볼 수 있습니다. 내가 질문을 표현한 방식은 질문을하는 가장 좋은 방법 인 것 같습니다. 나는 "Scala가 너무 어렵다 / Scala가 너무 복잡하다"는 효과와 "Kotlin은 스칼라를 시도하지만 더 단순하다"는 효과에 대한 블로그 게시물을 보았습니다. 원래대로 문구를 그대로 두겠습니다. 그러나 나는 정직하게 트롤을 시도하지 않았습니다.

지난 7 년간 Java로 프로그래밍 한 누군가의 IMHO와 나의 가장 강력한 언어 인 스칼라는 꽤 외계인이며 익숙해지기가 힘들다.

Xtend 는 Java처럼 느껴지고 훨씬 빠른 응용 프로그램을 작성할 수있었습니다. 스칼라와 함께 충분한 시간을 보내지 못했지만 왜 일부가 꺼져 있는지 이해할 수 있습니다.

그렇게 말하면, 사람들은 익숙하지 않은 천국에서 친숙한 지옥을 선택할 것입니다.

JetBrains에는 Scala와 Kotlin을 비교 하는 Wiki 페이지 가 있으며 Kotlin은 수행하지만 Scala는 그렇지 않은 몇 가지 사항이 있습니다.

• 오버 헤드 제로 안전 스칼라는 구문과 런타임 래퍼 인 옵션을 가지고 있습니다.
• 스마트 캐스트
• 정적 확장 기능. 런타임에 줄 바꿈 대신
• 코 틀린의 인라인 기능으로 비 로컬 점프 가능
• 문자열 템플릿. 비슷한 기능을 가진 스칼라 용 타사 컴파일러 플러그인이 있습니다 : ScalaEnhancedStrings
• 일류 대표단. 타사 플러그인을 통해 구현 됨 : 자동 프록시 모듈

그래서 코 틀린을 물로 스칼라라고 부르는 것은 아마도 지나치게 단순화 된 것일 것입니다. Xtend는 더 많은 사람들이 아닌 대부분의 Xtext 사용자를 대상으로합니다. 스칼라와의 주요 차이점은 Xtend가 바이트 코드가 아닌 Java로 컴파일한다는 것입니다.

목록에 추가해야 할 또 다른 "자바 킬러"언어는 Red Hat 's Ceylon입니다 . 비록 스칼라와 비교해 볼지 모르겠습니다.

내가 작년에 내 기본 언어로 스칼라를 사용하고 (가까운 두번째로 자바, 큰 기존 자바 코드베이스에서 모두.) 나는 아직 내가 그들을 사용하지 않은 경우 매우 기본 기능을보고있다 동안. 물론 스칼라를 빨리 쓸 수 는 있지만 기능이 매우 풍부한 언어이므로 숙달하는 데 시간이 오래 걸립니다.

또한 복잡성은 인간뿐만 아니라 IDE 및 컴파일러에도 문제가됩니다. Celyon과 Kotlin은 모두 상당히 깨끗한 JavaScript로 직접 컴파일합니다. Scala는 GWT를 통해 JavaScript를 생성 할 수 있지만 GWT 출력이 복잡하고 외부 JavaScript 또는 HTML과 잘 어울리도록 설계되지는 않습니다.

나는 스칼라에서 Java보다 확실히 생산성이 높으며 코드는 더 작고 읽기 쉽습니다 (한 번 스칼라를 알게되면). 복잡성이 20 %이지만 기능이 80 % 인 언어는 환영 할만한 대안이 될 것입니다.

[레거시 코드에 대한 언급을 제거하도록 편집되었습니다 (아래 주석 참조).

[2017 부록 : Scala는 이제 빌드 대상으로 JavaScript를 지원하는 반면 Kotlin은 Scala와 유사한 Java / Groovy / JavaScript 대체에 적합한 기능을 계속 추가했습니다. 그들은 내가 이것을 처음 쓸 때보 다 더 독특한 언어입니다.]

JetBrains는 Kotlin에 대한 목표를 매우 명확하게 밝혔습니다 .

보다 표현력있는 언어로 전환하여 생산성을 높이고 싶습니다. 동시에 Java 상호 운용성 (새로운 언어가 점진적으로 도입 될 예정이며 기존 코드베이스와 원활하게 상호 운용되어야 함) 또는 컴파일 속도 (코드베이스가 javac, 우리는 그것을 더 느리게 만들 여유가 없습니다). 다음은 상당히 간단합니다. Kotlin은 IntelliJ IDEA의 판매를 주도 할 것으로 기대합니다.

Play Framework와 함께 Eclipse에서 몇 달 동안 Scala를 사용했습니다. 나는 언어를 좋아하지만 내가 싫어하는 것들도 있습니다.

저에게는 Java에서 다른 언어로 전환해야하는 이유가 더 생산적입니다.

지금까지 나는 스칼라로 더 생산적이지 않았습니다. 한 가지 이유는 Eclipse에서 Scala에 대한 지원이 부족하기 때문입니다. Scala 플러그인은 나쁘고 (예 : 들여 쓰기 실패) 아직 많은 기능이 없습니다 (예 : "Open Call Hierarchy"없음). 스칼라 컴파일러는 느리지 만 문제가되지는 않지만 모든 요청에 ​​대해 코드를 컴파일하는 플레이 프레임 워크와 함께 스칼라를 사용하며 컴파일러 속도가 중요합니다.

Kotlin에 대해 모르지만 Scala와 Xtend는 매우 다른 두 가지 짐승입니다.

일반적인 말과 달리 스칼라는 더 나은 Java가 아닙니다. 스칼라는 자체 구문과 의미, 자체 기본 라이브러리 팩을 갖춘 Java보다 훨씬 더 많은 기능을 갖춘 언어입니다.

Xtend는 더 나은 Java입니다. Java 의미를 유지하고 구문을 향상시킵니다. 모든 Xtend 코드 라인은 Java 코드 라인으로 직접 변환 될 수 있습니다. 추가 런타임도 없습니다.

나는 다르지만 두 가지 접근법이 모두 옳다고 생각합니다. 나는 스칼라 (언어로서)를 싫어하지 않지만 프로젝트에 스칼라 병을 추가하는 것을 좋아하지 않습니다. Android에서 Scala를 올바르게 사용할 수 없으며 무게와 성능 문제가 추가됩니다. Xtend는 그다지 특색이 없지만 Java 언어보다 훨씬 가치가 있으며 Java로 직접 쓰는 것처럼 모든 플랫폼에서 작동합니다.

두 언어 모두 서로 다른 틈새를 다루고 있으며 서로 간섭하지 않고 공존 할 수 있다고 생각합니다. IMHO, Scala는 너무 복잡해서 새로운 것을 추가하지 않습니다. 보다 기능적이고 OO를 줄이고 싶다면 Clojure 또는 JHaskell과 같은 더 간단한 기능 언어 중 하나를 선택하십시오. 더 나은 구문과 약간의 기능적 프로그래밍으로 Java를 원한다면 Fantom은 Scala와 비슷합니다 (C #과 많이 유사 함).

그러나 나는 Xtend가 그 모든 언어 사이에서 달콤한 지점에 있음을 발견했습니다. Java에 필요한 모든 구문 패턴을 추가하여 Java의 좋은 부분 (시맨틱)을 유지합니다. 이를 Coffescript for Java로 생각하십시오.

그리고 Eclipse 지원은 훌륭합니다 ...