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)

개발자 채용을 진행하며

회사에서 개발자 채용을 진행 중이다.

우리 회사는 유명한 회사도 아니고 딱히 개발자에게 큰 메리트가 있는 회사라고도 할 순 없는 곳이다.  그래서 가끔 웹에 등장하는 어디어디처럼 무시무시한 시험을 보고 뽑을 사정이 되진 않는다 - 예전엔 해봤으나 그런다고 딱히 좋은 사람을 뽑을 수 있는 거 같지도 않았다.  그냥 입사지원서 보고 면접을 거쳐 뽑는다.

그래도 입사지원은 꽤 했다. 지금 입사지원서를 검토 중에 있다.

그런데 참 안타까운 생각이 든다.  입사지원한 사람들은 나름 사정이 다르겠지만 어쨌든 입사하기 전까진 절박한(?) 사정이라 할 터인데 - 더구나 지금과 같은 경기엔 말이다 - 입사 지원서를 잘 못 쓰는 사람이 너무 많다. 잘 쓰는 수준이 아니라 기본 수준 정도는 되길 바라는 건데 그 정도도 찾아보기 힘들다.  우리 회사가 허접한 편이니 찔러나 보자는 생각인가는 기분마저 들 정도이다.

그리고 상황은 신입이나 경력이나 별 차이가 나지 않는다.  신입은 미숙하니까라고 봐줄 수나 있지 경력자의 경우는 용서가 안 되는 거다.

이 글을 읽는 사람 중에 입사지원서를 쓰고 있는 사람이 있다면 다음 사항을 알아줬으면 한다. 다른 곳은 어떨지 모르겠지만 아마 크게 기준이 다르지는 않을 꺼라 생각한다.
  • 모집 공고를 확인하고 모집 공고에서 제시한 양식과 방식을 꼭 따라야 한다. 입사지원서 양식을 제시하였는데도 자신만의 양식으로 보내면 곤란하다.  입사지원서가 다운로드가 안 되어 자신의 양식으로 보낸다고 하는 사람도 있는데 이런 사람의 입사지원서는 바로 휴지통으로 들어가 버릴 것이다.
  • 격식을 갖춘 바른 표현을 쓰고 맞춤법과 문단 구성에 유의해야 한다. 개발자는 텍스트에 민감해야 한다.
  • 관련없는 자격증을 나열하지 말아라. 운전면허1종 자격증이 개발 능력과 무슨 관계가 있나? 워드프로세서 자격증 같은 것도 마찬가지다.
  • 뻔한 자기 소개는 하지 말아라. 자상하신 아버지 밑에서 자랐는지 관심없다. 군대에서 배우는 건 짱박히는 것 밖에 없다는 것도 모두 알고 있다.  '성장 과정', '성격상의 장단점', '학창 시절 및 사회 경험', '지원 동기 및 포부'와 같은 구성은 좀 그만 써라. 신입이면 직무와 관련하여 자신의 가능성을 알리는 데 집중해라.
  • 가능 기술을 나열할 때 너무 많이 나열하지 말아라.  어차피 신입은 채용 후 교육시킬 것을 생각하고 뽑는다. 나열한 기술을 잘 할 꺼라 별로 기대하지 않는다.  경력직인 경우는 더 조심해야 한다. 전문성이 없어 보이기 때문이다.
  • 또 기술을 나열할 때 범주는 제대로 맞춰라. 가능 언어로 Java, PHP, JSP, Servlet 이러면 곤란하지 않나? 해당 기술을 제대로 이해하고 있지 못하다는 평가를 내릴 수밖에 없다.
  • 그리고 제발 ... 다른 곳에 입사지원할 때 쓰던 거 그대로 보내지 마라. 우리 회사는 yyyy인데 'xxxx에 입사하며는'이라는 구절을 봤을 때 그 기분은 어떨까?
나는 위의 사항이 단지 나의 기분 또는 형식 준수의 문제가 아니라 지원자가 일을 대하는 태도, 일을 처리하는 방식과 관련되어 있다고 믿는다. 그래서 이것은 프로그래밍 지식보다 더 근본적인 채용 기준이라 생각한다.

PS. 글 올린 후 몇가지 사항을 추가하여 수정했습니다.

by Corund | 2009/06/17 16:21 | 트랙백 | 덧글(6)

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)

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