Scala
akiliner
지난 주에는 루씬 삽질해서 붙여보고,
사전 작업이 순조롭게(?) 마무리 되서 실전 사이트 작업에 투입하려고 했는데,
Programming in Scala PDF 가 손에 들어왔습니다. =o=
Groovy 작업 초반에는 모든 것을 def 로 정의하고 써내려 갔는데,
몇 주후에 내 코드 내가 보기가 힘들고,
코드 어시스트도 동작 안하고,
Integer 같은 경우 int, Integer, def 섞어 쓰면 미묘하게 오작동해서,
SQL 리턴 결과 처럼 타입을 선언하기 어려운 부분 빼고는
모두 타입을 명시적으로 적는 방향으로 바꾸었습니다.
타입을 다시 써주기 시작하고 나니 편리한 점들이 많이 생겨서
무타입이 가능하다고 해서 너무 남발하는 것은 안 좋구나 생각이 들더군요.
무타입은 꼭 무타입일 수 밖에 없는 곳으로 한정.
이쯤되니 다시 스터틱 언어로 돌아가고 싶은 맘이 한구석에서 몽글거려서,
Java 이외에 다른 스터틱 언어 대안은 없을까 찾다가 Scala 를 다시 자세히 보게 되었습니다.
Groovy 의 SQL, Markup, DSL 기술 능력이 뛰어나서 그저 감사히 생각하고,
다른 언어나 Scala 까지 볼 생각은 하지 안았었는데,
Programming in Scala 첫 몇 장 내용이 참 인상적이네요.
속도 붙여가며 넘기고 있습니다.
F# 은 OOP 적인 문법 사용이 좀 껄끄러워서 웹 작업하기 좀 난감했었는데,
Scala 는 OOP 와 FP 를 아주 동등하게 지원해 주는 것 같습니다.
Groovy 가 코딩 편의성을 위해 가지가지 기능을 하드코딩해 놓은 반면,
Scala 는 기본 규칙만 정의해 놓고 그 룰에 따라 확장가능하게 해서
Java 보다 기능이 더 풍부하고 Java 관점에서 이것이 좀 추상적으로 보일 수 있지만
Groovy 에 비해 보자면 추가되는 기능 각각의 예외 상황이 많이 주는 장점이 있어 보이네요.
한가득인 Groovy 추가 기능이 사실 좀 난잡해 보이는 면이 있는데,
Scala 는 기능 확장 과정의 기본 룰이 딱 잡혀 있습니다.
Groovy 의 다이나믹성, 그러니까 오브젝트에 접근하는데 불필요한 타이핑을 줄여주는 것을
타입 언어인 Scala 에서 어느정도나 해결하고 있을까 걱정이 되었는데,
타이핑 한번 정도 더 해주면 다이나믹 프로퍼티 명도 대충 넘길 수 있네요.
SQL 까진 아직 모르겠습니다.
Immutable 하고 Functional 하고,
생각지도 못한 확장 기능을 가진 스터틱 언어라 문서 재밋게 보고 있습니다.
근데, 검색해 보니 Scala 한국 사용자는 Groovy 보다 훨씬 더 적은 것 같습니다. =o=
박성철
에는 "관심만" 많이 받고 특별히 쓰이는 곳은 없었던....
트위터의 메세징 엔진을 스칼라로 만든다고 해서 좀 관심을 많이 받았던 것 같습니다만...
그런데 groovy도 static type이 가능하지 않나요? 저도 dynamic typing보다 static이 좋아서
groovy에서도 static을 주로 쓰려고 하는데 의외로 groovy 코드를 보면 dynamic을 많이 쓰는 듯 합니다.
akiliner
여러 가지 문제를 피하는데 도움이 되었습니다.
첫글에서 스터틱 언어로 돌아가고 싶다고 언급한 부분은
컴파일 타임에 에러를 잡아주거나 하는 등의 스터틱 언어 특징을
염두에 둔 것이었습니다.
제가 유닛 테스트를 전혀 안 하고 있어서 더 그랬는지도 모르겠습니다.
그러나 유닛 테스트를 한다고 해도 컴파일러가 잡을 수 있는 문제를
유닛테스트로 넘겨야 한다는 부담은 없어지지 않을 것 같습니다.
Scala 가 좋으면 얼마나 좋겠나 싶었는데,
아주 잘 디자인 된 언어 같습니다.
상상하지 못했던 방식으로 스터틱 언어의 문제점들을 해결하고 있네요.
작지만 인상적이었던 부분은,
인자없는 펑션호출에 () 를 빼버려도 됩니다.
그러니 필드 접근과 무인자 펑션 접근에 문법이 같아집니다.
아주 이뿌네요.
필드를 나중에 펑션으로 리펙터링해도 다른 소스를 고칠일이 없어집니다.
import 를 하는데 클래스 단위가 아니라, 클래스의 메서드 단위로 임포트 할 수 있습니다.
무슨 말인가 하면, Element 의 elem 이란 메서드가 있을 때
import mydomain.Element.elem 이라 적을 수 있습니다.
이러면 소스코드에서 클래스명 없이 elem 메서드를 이름만 가지고 호출 할 수 있습니다.
코드가 매우 이뻐지는군요.
Groovy 처럼 마지막 인자를 { } 로 받을 수 있습니다.
메카니즘은 많이 다릅니다.
Groovy 볼 때는 다양한 기능들이 인상적이었는데,
Scala 는 언어 디자인 하신분이 경험이 매우 많은 것 같고,
공부도 많이하신 것 같고,
먼가 내공이 많이 느껴집니다.
명품 언어 같습니다.
akiliner
아, 아름답습니다.
이렇게 일관적인 언어도 첨인 것 같네요.
첨엔 F 적인 언어로 생각하고 들어갔는데,
Java, C# 보다도 훨씬 OO 특성이 강합니다.
F 적인 설계도 물론 들어있는데,
F# 처럼 OO 쪽에서 온 사람들에게 불편할 정도로 만들지 않고 있습니다.
매우 안락합니다.
더 나아가서 F 적인 수식을 쓰는 사람들을 위해
클로저 콜 체인이 복잡해지는 상황을 for 수식이 놀랍게 해결해주고 있습니다.
모든 것이 첨부터 끝까지 엄청나게 일관적입니다.
쌩필드 접근이 없습니다.
모든 것은 메서드를 통합니다.
이러닌까 아예 여러가지 문세가 싹 없어졌습니다.
모든 메서드 콜은 버추얼 콜입니다.
스터틱 메서드나 필드도 없고, 대신 싱클턴 오브젝트가 있는데,
클래스 계승을 할 수가 있습니다.
스터틱 클래스 쓰시다가 계승이 안되서 머리 쥐어잡은 적이 한번씩들 있으실 겁니다.
어레이나 리스트 초기화 구문등
다른 언어에서는 보통 언어차원에서 지원되는 기능들이 라이브러리로 지원되는데,
언어의 기본 규칙만 따르면 가능하게 되어 있어서 확장성이 매우 좋을 것 같습니다.
보통 그루비에서 언어 수준에 들어간 기능들이
스칼라에서는 더 아래 기본 룰만 규정하고 대부분 라이브러리로 처리하고 있습니다.
근데 매우 효과적입니다.
100 페이지 정도 남았는데, 마저 읽고 LINT 문서 좀 보고,
쓰기 불편하면 그루비판 웹 루틴들을 스칼라로 옮겨봐야 겠습니다.
직접 써보면 단점들이 또 보이겠지요.
아직 SQL 을 어떻게 효율적으로 쓸 수 있는지는 찾아보지 안았는데,
요부분이 살짝 걱정이됩니다. ^^
아무래도 그루비 만큼 편하게는 안 될듯하니.
Jay Park
---------------
http://groovy.pe.kr/30
http://jinto.pe.kr
--
"한국 Groovy & Grails 사용자 그룹" 에 가입하셨기에 이 메시지를 보내드립니다
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
KG...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
KGGUG+un...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/KGGUG?hl=ko의 그룹을
방문하세요.
akiliner
언어 리뷰 끝나고 좀 써볼까하고 API Doc 여는 순간, 썰렁.~ ^^
언어가 돌아가기 위한 기본 클래스들만 있고,
추가 서비스가 하나도 없습니다.
어떻게 보면 바람직하기도 한 것 같지만,
Groovy 에 기본으로 따라오는 그 풍부한 라이브러리 생각하면,
도구는 주어졌는데 요리는 모두 직접해야하는 그런 상황. ^^
Groovy 정도로 라이브러리 풍부해 지려면 몇 년 걸릴 것 같습니다.
아니면 그냥 기존 Java 에서 하던 수준의 작업을 해야할 것 같구요.
try / catch, open / close 같은.
프로젝트 진행하면서 Groovy 라이브러리 코드 좀씩 떼다 붙여야 할 것 같습니다. ^^
LIFT 는, Rails / Grails 처럼 디텍로티 각 잡고 시작하길레 열었다 바로 덮었습니다.
그거 이해하는 시간에 꼭 필요한 정도만 망치질 하는 것이 빠를 것 같아서. =,=
SQL 은 iBATIS 나 하이버네이트를 끌고 들어와야하나 다시 고민이 시작되었습니다. =o=
akiliner
val l = List(1,2,3)
for(x <- l) {
println(x.abs)
}
val l2 = List("Apple", "Pine", "Banana")
for(y <- l2) {
println(y)
}
위 같은 수식에서 x, y 타입 인퍼런스 정확하게 해줍니다.
y 다음에 점찍으면 타입이 뭔지 딱 보여주고 Int, String 관련 메서드까지 쭉.
Eclipse Scala Plugin 은 버그 땜에 에디팅/코드 실행도 불가능한 상태고.
IDEA 에서는 타입 직접 안 적어주는 애들 인퍼런스 아직 안 됩니다.
IDEA 에서 코드 컴플리션 없이 까막눈으로 더듬 더듬 누르다가
넷빈에서 풀다운 떨어지는 것 보닌까 갑자기 급 NetBeans 쪽으로 다시. =,=
왠 삽질인가 모르겠습니다. ^^
Jay Park
스칼라는.. 타이핑이 많은 것 같기도하고.. 적게 할 수 있는 것 같기도 하고..
def printArgs(args: Array[String]): Unit = {
for (arg <args)
println(arg)
}
이런 코드에서 ": Unit =" 같은 부분은 정이 잘 안가는군요. 눈에 익혀보려
노력중이긴 합니다만.
뒤쪽에 타입을 적거나 생략한다는 정책도 그럴싸하지만, 그루비처럼 def 로
처리하는 것도 괜찮았을텐데 말입니다.
공부하다보면 넘어야할 개념들이 몇가지 있는 것 같은데, 이런 부분들이
대중적인 언어가 되는 길을 가로막고 있는 것 처럼 보입니다. 저는 그루비
다음 공부할 언어로.. Clojure를 잡고 있었는데.. 너무 많아요.. 배울것들이 ㅎㅎ
akiliner
아래 처럼 적어도 컴파일이 될 겁니다.
(근데 이미 아시고 계실 것 같네요)
def printArgs(args: Array[String]) = {
...
}
또 특히하게 Unit 리턴 함수는 = 도 빼도 되서
아래 처럼 축약해도 되겠구요.
def printArgs(args: Array[String]) {
...
}
저도 처음 봤을 때 F 언어들 메서드 정의할 때 = 쓰는 것이 이상해 보였는데,
= 한번 타이핑으로 { } 를 다 안써도 되는 경우가 많아서
실제적으로는 타이핑 양이나 줄 수가 더 많이 줄어드는 경향이 있습니다.
*
NetBeans Scala Plugin 에 문제가 있군요. =,=
여러 모듈로 분해한 경우,
다른 모듈의 업데이트 내용을 다른 모듈에서 인식을 못합니다. =,=
예를 들어 라이브러리 모듈에 어떤 메서드의 인자가 하나 늘어난 경우,
메인 모듈에서 인식을 못하고 붉을 줄을 그어버립니다.
문서 찾아보니 원래 그렇다고, 왠지 당장 고쳐줄 분위기가 아닌 것 같습니다.
넷빈을 재시동 해야 업데이트 됩니다. =,=
반대로 IDEA 9.0 정식 나온거 설치해 보니 Scala Plugin 이 좋아졌군요. =,=
NetBeans 처럼 타입 인퍼런스 능력이 좋아졌습니다.
좀 느리긴 한데 for 문의 x 타입을 찾아주네요.
다행히 NetBeans 로 이주 안 해도 되게 되었습니다. =o=
drypot
프로그래밍 40 년 하셨다는 분인데,
2008 년도에 스칼라에 대해서 좋은 분석글을 써주셨습니다.
스칼라에 대해 굉장히 안티한 글로 시작을 하셨는데,
애증의 관계 였는지 꽤 세세하게 분석한 글들이 이어졌습니다.
근데, 2009 년도에 프로그래밍 계를 써나셨네요.
takeone
takeone
못진분이네요 40년이라... 그정도면 근대 프로그래밍의 역사정도 되겠네요 와아;;
On 2월16일, 오후8시59분, drypot <dry...@gmail.com> wrote:
Lee Dongwook
2009년 12월 17일 오전 12:40, akiliner <dry...@gmail.com>님의 말:
2 주째 Programming in Scala 읽고 있습니다.
--