실사용에 있어 스칼라의 문제와 코틀린

스칼라의 사용상 문제점이라고 느꼈던 부분은 사실 여러가지가 있다. 

일단 안드로이드 대표 JVM 언어인 코틀린과 비교하면, 더욱더 유연한 편이지만 전체적으로는 가독성이 떨어지는 경우가 있다고 느낀다.

메서드 호출

메서드 호출은 ()없이 가능한데, 이는 사실은 가끔은 코드의 비일관성을 불러온다. 대부분의 언어는 변수에 있어, 혹은 함수자체를 일등시민으로 인자로 넘길때 그 명칭만을 써준다. 그리고 실제로 메서드 콜을 할때는 ( ) 를 통해 호출한다. 스칼라는 나름 규칙은 있지만, 메서드 콜에 있어 뭔가 일관적이지 않은 느낌을 준다.

물론 유연한 호출은 DSL 을 파생시킬때 유용할수있다는 느낌은 오지만, 일단은 갖가지 코드가 혼재될수있다.

장황함

물론 스칼라는 장황한 언어를 지양한다.  심지어는 변수명조차 컨벤션과 다르게 f, b 이런식으로 축약할 정도이다. 하지만 가끔은 장황함을 지향한다. 때때로 중요한 부분에서 좀 시끄럽다. Optional과 같은 부분은 null처리등에 있어 상당히 요긴하게 자주 쓰일수 있는 부분인데 사실 작성해보면 상당히 시끄러운 코드가 나온다. 스위프트에서는 !와 ?을 적절히 이용해 가면서 null처리를 하며, 이에 영향을 받은것으로 보이는 코틀린도 이러한 처리를 제공한다. NPE를 100% 피할수는 없지만, 어느정도 경각심을 가지게 한다.

괄호

괄호의 경우 상당히 실수가 있을수 있는 부분인데, 단순히 열고 닫는 문제가 아니라 { } 와 ( ) 을 너무나도 혼용해서 쓴다는 느낌을 준다는 것이다. 철학이 있는건 알겠지만 그래도 헷갈리는 부분은 분명 존재한다.

new

이부분도 사실은 코틀린보다는 살짝 일관성이 떨어져보인다. 코틀린은 new를 극도로 싫어해서 모든 코드에서 new를 지워버렸다. 의존성 주입과 TDD의 입장에서 봤을때는 new에 경기를 일으키는 것도 이해가 간다. 반면 스칼라는 new가 먹힌다. 그런데, 각각의 companion object에서 정의해놓은 기본 apply( )메서드가 constructor처럼 작동하게 되는데, 이는 살짝 이용할때마다 무엇인지 들여다봐야한다는것이다. 코틀린에서는 newArrayOf()라는 메서드 등으로 새로운 배열을 선언할수 있게 한다면 스칼라는 Array(인자)로 새로운 배열을 생성하기도 하는데, new Array(길이)로 텅빈 특정길이의 배열을 만들어 낸다. apply()의 용도를 살펴보는 시간이 추가적으로 드는것은 어쩔수가 없다. 상식과 히스토리를 따르지만, 일관성이 조금 떨어지게 느껴진다.

현실적인 구조적 귀찮음.

여러 스칼라 코드를 보면 한 파일안에 다양한 class와 companion object가 산재해 있는것을 볼수있는데, 이는 분명 개발시 생산성을 낮추는 부분이다. 차라리 자바처럼 파일하나는 하나의 public class와 매핑되게끔 하는것이 파일을 뒤지는 행위를 덜하게 만든다.

문제는, 코틀린은 companion object를 class안에 구현하도록 하여 이런 문제를 우회하지만 스칼라는 오히려 스크립트처럼 나열하다보니 계층정리가 잘 안될수가 있다. 추가적으로 기본인덴트는 2칸이다. 가끔보면 minify가 된 자바스크립트 같은 느낌도 든다.

몇가지 네이밍

보통의 dto역할을 하는 case class라는 네이밍은 코틀린의 data class보다는 직관성이 떨어진다. 물론 이경우는 코틀린도 마찬가지지만, case class가 여기저기 코드안에 섞여들여간 코드는 좀 헷갈린다.

기타

안드로이드에서 스칼라는 이용하지 않아야한다. 몇가지 기본 동작이 아예 호환되지 않는다. 스칼라가 그렇게 장점이라고 외치는 비동기로직을 짤때 특히 어려움을 느낄것이다. 편의성에서도 천국과 지옥이니, 선택의 여지없이 일순위를 코틀린으로 가고 이순위를 자바 1.8 이상으로 가야하며 스칼라는 선택지에서 지워야한다.