Kotlin in Action : 코틀린 컴파일러 개발자가 직접 알려주는 코틀린 언어 핵심

이 책은 좀 마음에 든다. 그래도 돈이 없어서 사진 않겠다.

개념설명과 예시가 잘 나와있고 번역도 걸리는거 없이 자연스럽게 읽힌다.
책의 수준은 자바를 어느정도 알아야 제대로 볼 수 있을 것 같다.
람다까지는 어느정도 할 줄 알아야…

본인쨩은 자바도 할 줄 알고 코틀린도 튜토리얼보면서 대강 익힌 후에 책을 봐서 좀 더 편하게 본것같기도 하다.

자바 특징

자바를 소개하는 책에는 자바가 간결하고 쉽다고 했지만… 그건 C,C++하던 사람들 얘기고
본인쨩은 C#을 먼저 하고 자바를 시작해서 그런지
처음에 자바 문법 극혐스러웠다. 

코틀린 써본 느낌

코틀린은 완성된 자바같다.
자바의 혐오스러운 부분을 배제해서 간결하고 직관적이다.

자바와의 호환성을 유지하기 위해 많은 부분을 희생한 것 같다.
자바코드 가져올 때 null타입 체크를 포기한거나 …
그런거나…또 뭐가 있더라
패키지 구조에서 인터널 스코프, sealed도 뭔가 문제가 있었던 것같은데, immutableCollection이 바이트코드에선 퍼블릭이라거나

몇 가지 문제 때문에 코틀린에서 만든 라이브러리를 자바에서 쓰면 좀 불편할 것 같다.

자바도 8에서 람다, 9에서 모듈을 적용하면서 열심히 따라오고는 있는데
자바19정도 되면 코틀린처럼 변하지 않을까

no-java kotlin 버전???

레거시 지원도 좋지만 가끔은 과감하게 포기하면서 발전 해 가면 좋겠다.

Error:

에러로그

mvn test 실행시 ..라기보단 메이븐 빌드 자체가 안되는데

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on project sb-tools-core: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :sb-tools-core

원인

모름

영문을 모르겠네.. 의존성 문제 아닌 것 같은게 노트북에서는 잘되니까

둘다 ubuntu 18.04, openjdk1.8, sdkman 이용 환경설치

노트북은 i5 8th. ram 8G sdd512 ubuntu 18.04 lenovo ideapad 320s

문제의 테스크탑은 amd ryzen 2700x? ram 32g 128ssd ubuntu 18.04

하드웨어 사양을 왜 썼냐면… 멀티코어 때문에 생기는 문제가 아닌가 싶어서

해결

못함

스파크 – 새로운 자바 웹 프레임워크

http://sparkjava.com/

스프링의 어노테이션 범벅 구조에 좀 질려있는 상황에서

간단히 메서드 체인 형태로 구성할 수 있는 프레임워크가 나와서 조금 반갑다.

그레일즈와 비슷한 구조?

다른건 제대로 써본게 없어서 정확히 비교를 못 하겠다.

아직은 초기라서 많은 기능지원이 없을 것 같다. 직접구현해도 나쁠것은 없지만….

회사일을 하다보면 그게 쉽지 않으니

추가적인 것은 나중에 확인.

JVM기반 언어들, 쓸만한 녀석들을 골라보면

JVM은 버추어 머신으로 자바만을 돌리기 위한 플랫폼?이 아니고

자바는 컴파일시에 바이트코드를 생산하기 때문에 다른 언어들도 바이트코드로 변환할 수 있게 만들면 JVM위에서 돌릴 수 있다.

자바 처음 공부할 때 이런 내용을 본 것 같은데
그때는 뭐 컨셉만 잡아놓고 말겠지~라고 했는데

하나씩 나왔다.
jRuby, jython, … 이정도?

사실 여기까지는 쓸모없다고 느꼈었다.
네이티브로 돌리면 되는걸 왜 jvm으로 돌려~
그리고 같은 언어라고 하긴하지만… 세부 문법까지 똑같지는 않을거고
이거 복사해서 붙여넣는다고 cruby, cpython에서 돌아가는것도 아니잖아~’라고 생각했었고 지금도 그렇다.

그런데.. groovy, scala, clojure 등의 언어가 나오면서 상황이 좀 바뀐 것 같다.

groovy, scala는 spring에서도 지원하고 있고

playframework는 scala 전용프레임워크 정도로 자리를 잡은 것 같다.

이중 clojure는 … 지구의 90%이상 프로그래머가 모언어로 섬기는 C언어에 짓눌려 기를 못 펴고 있다.

scala함수형, groovy스크립트 정도로 이해하고 있는데.. 그래도 문법 자체가 c계열에서 크게 벗어난다는 느낌은 없었는데

lisp계열인 scala는… 정말 다르다.

언어의 너무 다른 컨셉때문에라도 한번 익혀놓는게 좋지 않을까 싶을정도…
그래서 clojure도 한번 해보려고 한다.

 

내 경험상… 언어를 잘 익히려면 뭔가를 만들어봐야 하는데.. clojure을 이용해서 만들만한게 뭐가 있을까 모르겠다. 언어의 특성에 따라 만들기 좋은 작품이 있는데…

몇몇 클로저 라이브러리를 보고 느낀건데… 가독성은 상당히 좋은 것 같다.
줄바꿈도 잘 지켜지고..
자바나 파이썬에서 많이 보이는 변태적인 문법도 오히려 더 적어보인다.

일단 자바기반 프로젝트에 라이브러리를 클로저로 심는 정도로 하는게 좋을 것 같다.