태그 : scala

scala 언어를 전면적으로 사용하기에는 아직 이른 듯하다.

scala는 여러가지 좋은 특징을 가지고 있고 자바에 비해 코드도 간결한 편이다. 자바 이후 또는 보조 언어로 우리 팀에 도입해 볼까 생각하며 공부해 봤지만 아래의 이유로 아직 전면적으로 쓰기에는 이른 듯 하다.

첫째로는 기존 자바 프로그래머가 scala에 익숙해지려면 공부해야 할 께 꽤 많다는 점이다. 함수형 패러다임과 용례에 익숙해지는 것부터가 만만치 않으며, 자바보다 복잡한 타입 시스템도 알아야 하고 여러가지 함축적 표현도 익혀야 한다.

둘째 IDE 지원에 문제가 있다. scala 이클립스 플러그인이 있긴 하지만 Syntax Highlighting 정도만 되는 수준이다.  자동 완성과 리팩토링 지원 정도는 되어야 한다. 이것이 안 되는 환경에서 코드를 작성하려니 갑자기 석기 시대로 이동한 기분이다.

세째 웹 개발의 경우 scala 웹 개발 프레임워크인 Lift가 꽤 난해(?)하다는 점이다. 서블릿 API 또는 JSP를 가지고 Front Controller 스타일 위주로 개발하는 것과는 사못 다른 방식을 취하고 있어서 개념을 잡기가 쉽지 않다. 더구나 환경 구성에 maven을 이용하는 법만 제시하고 있어서 maven을 모르는 경우 진입 장벽이 만만치 않다. 한 권밖에 없는 해설서도 난해한 편이어서 프레임워크를 이해하기가 쉽지 않다.

첫째 문제는 scala의 본질적인 문제라서 어찌 해결할 방법이 없다.  다만 scala 언어가 담고 있는 여러 개념들은 더 나은 개발자가 되려면 알아야 할 것들이라는 협박(?)으로 해결하는 수밖에 없다.

둘째와 세째 문제는 시간이 지나면 나아질 거라 기대해 본다. scala는 정적 타입 언어이기 때문에 동적 타입 언어보다 자동 완성과 리팩토링 지원 기능 구현이 상대적으로 쉽다 - 하지만 scala 언어가 상당히 복잡해서 구현이 쉽지는 않다 - 고 한다.  scala 커뮤니티에서도 IDE 지원 문제가 꽤 논의되는 거 같다. 웹 프레임워크 문제도 시간이 지나면 좀더 많은 프레임워크가 등장하리라 기대한다.

능력과 시간이 되는 팀이라면 둘째, 세째 문제는 자체적으로 해결할 수도 있을 것이다. 우리 팀은 그럴 능력이 되지 못해서 거인의 어깨를 기다릴 수밖에 없다.

by Corund | 2009/07/30 14:27 | 트랙백 | 덧글(0)

scala에서 Lazy Evaluation - by-name Parameter

scala에는 by-name 파라미터(parameter)라는 것이 있다. 메서드의 파라미터를 Lazy Evaluation 할 수 있는 기능이다. 즉 파라미터를 by-name으로 정의하면 메서드로 넘겨질 때 값이 평가되지 않고 메서드 내부에서 실제 필요로 할 때 평가된다.

by-name 파라미터라는 말이 생소하게 들렸는데 찾아보니 Algol 60에 구현되었던 기능이며 Lazy Evaluatoin을 구현하는 여러 전략 중 하나라고 한다.(Wikipedia 설명)

scala에서는 => T 형식으로 파라미터 타입을 지정하면 by-name 파라미터가 된다. 실제로는 인자없는 함수로 구현되어 있는데 메서드 호출시 인자를 간단하게 쓸 수 있게 한 거라 보면 된다.

그러면 어떤 경우에 이런 기능을 사용하면 좋을까? 대표적인 예로 로깅(logging) 기능이 있겠다.

log4j와 같은 로그 라이브러리에는 로그 레벨이라는 것이 있어서 로깅할 레벨을 지정하면 그 레벨보다 낮은 단계의 로그는 하지 않고 무시된다. 그런데 메서드가 호출될 때 파라미터는 반드시 평가되므로 로그 메서드에 넘기는 파라미터 값을 구성하기 위한 비용이 만만치가 않을 경우 성능상 문제가 된다. 이를 방지하기 위해 log4j를 이용할 때는 다음과 같이 코드를 작성하기도 한다.


if (logger.isDebugEnabled()) {
    logger.debug(some.expensiveMethod());
}

이 코드는 잘 동작하지만 코드 작성이 너무 번거롭다할 수 있다. 이런 경우에 Lazy Evaluation이 필요하다. 이 경우는 scala로 쉽게 해결할 수 있다. 다음과 같이 log4j를 감싸면 된다(개념만 간단히 보이기 위해 코드에 일부러 중복을 놔두었다).

//Logger.scala:
package corund.logger

import org.apache.log4j.Level

class Logger(cat: String) {
    val payload = org.apache.log4j.Logger.getLogger(cat)

    def debug(msg: => String) {
        if (payload.isDebugEnabled()) {
            debug(msg)
        }
    }

    def info(msg: => String) {
        if (payload.isInfoEnabled()) {
            info(msg)
        }
    }

    def warn(msg: => String) {
        if (payload.isEnabledFor(Level.WARN)) {
            warn(msg)
        }
    }
    // error 메서드 등 생략 ....
}

object Logger {
    def apply(cat: String): Logger = new Logger(cat)
}

이 Logger 클래스를 다음과 같이 실행해 보면

//Logging.scala
package corund.run

import org.apache.log4j.BasicConfigurator
import org.apache.log4j.Level
import corund.logger.Logger

object Logging {
    def main(args: Array[String]) {
        BasicConfigurator.configure()
        org.apache.log4j.Logger.getRootLogger().setLevel(Level.WARN)
        val logger = Logger("corund.run.Logging")

        class Data(str: String) {
            def expensive() = {
                println("Invoked! - " + str)
                str
            }
        }

        val data = new Data("expensive object")

        logger.debug("debug: " + data.expensive())
        logger.info("info: " + data.expensive())
        logger.warn("warn: " + data.expensive())
        logger.error("error: " + data.expensive())
    }
}

결과는 아래와 같다. warn 레벨 아래에서는 data.expensive() 메서드가 실행되지 않음을 알 수 있다.

test를 작성할 때 많이 사용하는 assert 함수도 by-name 파라미터로 구현되어 있다고 한다. 코드의 실행 순서를 제어할 수 있기 때문에 직접 제어 구조를 만들 때 유용하게 쓸 수 있는 기능이다.

by Corund | 2009/07/08 08:43 | 트랙백 | 덧글(0)

Mr. Groovy scala를 javac의 유력한 대체 후보로 꼽다?

groovy의 창시자 중 한 명인 James Strachan이 그의 블로그(Scala as the long term replacement for java/javac?)에서 scala 언어를 높게 평가했습니다. 특히 이번에 나온 책 "Programming in Scala" 관련해서 만약 2003년에 그 책을 봤더라면 아마 groovy를 개발하지 않았을 꺼라고까지 했네요.

I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

마지막으로 Mr. Java, Mr. JRuby도 scala를 java의 대체 언어(Javac's long term replacement)로 거론했다는 점을 상기시키며 scala를 공부하라고 권하고 있습니다.

Conclusion:
Given that MrJava, MrJRuby and MrGroovy are all tipping Scala as javac's long term replacement, there might be something in it. So what are you waiting for; get the Programming Scala book or the O'Reilly Scala book and start having fun :)

그간 scala 자료를 찾다 groovy와 비교하는 글을 종종 보면 scala가 groovy 보다 성능은 앞설지 몰라도 생산성은 groovy가 더 낫다는 평을 하는 것을 자주 보았습니다.  그러나 저는 scala는 groovy 보다 학습 비용이 높고 아직 커뮤니티가 적다는 점 외에는 모든 점에서 더 낫다고 생각합니다. Mr. Groovy도 그렇게 생각하는 것 같군요.

by Corund | 2009/07/07 11:05 | 트랙백(1) | 덧글(0)

Scala를 공부하며

요즘 Scala 언어를 공부하고 있다. Programming in Scala를 읽었는데 책을 잘 샀다는 생각이 든다. 700 페이지가 넘는 상당한 두께인데, 온라인에서 구할 수 있는 간단한 문서만 보아서는 알기 힘든 여러가지 면을 잘 설명하고 있는 거 같다. 

Scala는 상당히 복잡한 언어다. 객체 지향과 함수형 개념이 섞여 있으니 원래 만만하지 않겠지만 강력한 표현력을 만들어 내기 위해 컴파일러가 처리하는 일이 많기 때문에 더 그러한 거 같다.  복잡하기로는 C++와도 견줄 수 있다하니 말 다한 셈이다. 너무 강력하기에 남용하기 쉬워 오히려 코드를 알아보기 힘들게 만들 수 있는 면도 여럿 있다.

하지만 그 개념은 아주 매력적이다. 순수 객체 구조에 가까우며 - 모든 데이타가 객체이며 연산자 또한 객체의 메서드로 구현된다 - 거기에 함수형 개념도 융합되어 있다. 정적 타입 시스템이면서도 동적 언어가 가지고 있는 간결함도 갖추고 있다. 각종 언어 구문들도 확장할 수 있게 되어 있다. DSL 만들기에 딱 좋은 언어다.

Scala가 인기를 끌 수 있을까? 그건 모르겠다. Twitter에서 백엔드 시스템을 개발할 때 사용했다는 것이 알려지며 관심이 증가했지만 벌써부터 복잡하다는 얘기도 나오고 있다. 어떤 언어의 성공은 기술적 수준만으로 이루어지는 것이 아니니 쉽사리 예측할 수 없다.  Lift 프레임워크까지는 살펴 본 후 사용을 결정하려 한다.

by Corund | 2009/06/26 10:05 | 트랙백(1) | 덧글(0)

Scala와 Lift framework 책이 왔다.


Programming in ScalaThe Definitive Guide to Lift가 도착했다.  Scala 책은 생각보다 두껍고(700페이지가 넘는다) Lift framework 책은 생각보다 얇다(230페이지 정도 된다).  Scala와 Lift라는 새 세계는 어떤지 궁금하다.

그나저나 언제 다 읽냐?

by Corund | 2009/06/17 15:08 | 트랙백 | 덧글(1)

◀ 이전 페이지다음 페이지 ▶