어떤 멤버 함수로부터 같은 클래스의 템플릿 멤버 함수에 접근할 경우, gcc 2.95가 internal compiler error를 발생시킴.
템플릿 멤버 함수 (bar)를 멤버 함수(foo)보다 위쪽에 정의해주면 됩니다. 이 외에도 gcc 2.95는 template 관련 버그가 꽤 많죠. template을 많이 사용한다면 부득이 하지 않은 이상 3.x 이상을 사용할 것을 권장합니다.
Google의 VP of Engineering인 Adam Bosworth와의 토론.
컴퓨팅의 거장, Adam Bosworth는 ITConversations에서 이제 웹의 도래로 인해서 DB는 SQL을 통해서 정해진 문법으로만 access가 가능한 단순한 backend relational DB에서 웹을 통해서 원하는 데이터를 언제든지 더 큰 문맥에서 access할 수 있는 구조를 제안한 다. 구글과 같은 검색엔진이 보여주는 것은 이러한 구조의 일부분이라고 하면서. 좀더 역할을 세분화 시키면서 Bosworth는 사실 데이터를 처리/조작/통합하는 역할을 클라이언트에서 모두 하기에는 시간이 너무 오래 걸릴 수 있는 가능성이 높기 때문에 (예를 들어 프루나나 당나귀같은 p2p 네트워크에서 어떠한 파일 하나를 찾기 위해서 얼마나 오랜 시간이 걸리는지 생각해보면 된다), 이러한 역할을 전담하는 data router라는 개념을 제안한다. 정확한 구조는 알 수 없지만 대략 이러한 방향으로 가는 것이 옳지 않을까 한다. (from 태우’s log)
현재 보편적으로 사용되는 관계형 데이터베이스(Relational Database)들은 주어진 값과 일치하거나 특정 함수에 맞는 결과를 보여주는 데 집중하고 있으나, 검색 엔진들을 보면 실제로 우리가 요구하는 것은 특별한 문맥 상에서 무언가와 관련성을 가지는 결과다. Adam Bosworth는 이를 현재 관계형 데이터베이스들의 한계라고 지적한다. 그가 쓴 데이터베이스에 관한 글도 읽어봄 직하다.
그리고, 데이터의 양이 많아지면서 scalability라는 어려운 문제에 부딪힐텐데, 이를 위한 해결책으로, divide-and-conquer architecture를 제안하고 있다. data router가 query를 특정 back-end 서버군으로 중재해주는 방식을 설명하고 있다. 며칠 전에 철호군과 검색 엔진에서 사용되는 크롤러(crawler)의 network bandwidth bottleneck에 대해서 얘기를 나눈 적이 있다. 분명히 웹의 규모는 앞으로 order of magnitude로 커질 것이고, network bandwidth 이외의 resource에 대해서도 scalability 문제가 발생할 것이다. 이 문제에 대해서 나는 왜 검색엔진이 조금 더 작은 여러 검색엔진의 분산된 구조로 구성되지 않는가에 대해서 의문을 제기했다. 하지만, 철호군은 검색엔진에서의 중복 페이지 제거 등의 이유를 들어주었고, 아마도 그가 옳으리라고 생각한다. 그럼에도 불구하고, 검색 엔진 그리고, 모든 정보 처리 방식에 있어서의 scalability 문제는 좀 더 고민해 볼 필요가 있으리라고 생각된다.
그는 personalization에 대해서도 언급하고 있는데, 그건 이 글을 읽어보도록 하자.
덧붙여, 내 영어 실력에 관한 딴 얘기를 좀 해보자. 이 토론은 무려 1시간짜리에다가, 잘 들리지 않아서, 엄청난 집중력을 요구했다. 결국 30분 가량 듣다가 말았는데, 또렷한 영어 발음을 벗어나면 바로 헤메는 나를 보니, 좀 더 열심히 해야겠다는 생각이 들었다. 전길남 교수님이 수업시간에 했던 얘기가 생각났다. 그런 종류(?)의 토론에서 사람들은 자신의 의견을 빠르게 피력하기 위해 엄청나게 빠르게 말하는 것이 보통이고, non-native-speaker의 입장에서는 "Sorry"라고 말할 겨를은 없다는 것이다. 결국 거기에 걸맞는 능력을 갖출 수밖에 없다는 것이다.
Supernova는 기술, 비즈니스와 사회관계는 물론 우리의 삶 전반에 걸쳐 나타나고 있는 decentralization이라는 현상에 관한 컨퍼런스다. 태우님의 글를 통해서 Thomas Malone 교수가 Supernova 2004에서 Perspective로 발표한 내용을 접할 수 있었다. 이 발표가 새롭고 인상적인 생각들을 보여주는 것은 아니라고 하더라도, decentralization 경향에 대한 일반적인 생각을 체계적으로 잘 정리하고 있다고 보여진다. 그렇지 않아도 Complex system연구와 최근의 Social software들을 접하고 나서, 최근 기술과 비즈니스의 decentralization 경향에 대해서 고민을 하고 있었기 때문에 더욱 흥미로운 내용이었다.
그는 정보기술(information technology)이 커뮤니케이션의 비용을 줄임으로써 많은 수의 사람들이 그들 자신의 결정을 위한 충분한 정보를 얻을 수 있게 되었고, 이로 인해 비즈니스에서의 인간의 자유(human freedom)가 증가했을 뿐만 아니라 중요해졌다고 얘기하고 있다. 이러한 현상의 예로 Wikipedia와 eBay를 들고 있다.
또한, 인간의 역사를 돌아보면 문자나 인쇄술, 전화, 인터넷을 통해서 커뮤니케이션의 비용은 계속해서 줄어드는 경향을 보이고 있고, 그러한 경향은 민주주의와 현재 시작되고 있는 decentralized decison-making의 현상을 낳았다. 커뮤니케이션의 비용을 줄여주는 기술이 발전한다는 것이 사람들이 decentralized decison-making을 원한다는 것을 의미하지는 않는다. 하지만, 현재와 같이 지식과 혁신에 기반한 경제(knowledge-based and innovation-driven economy)에서 그것은 동기(motivation), 창조성(creativity), 혁신(innovation), 즐거움(enjoyment) 등의 이익을 사람들에게 제공해주기 때문에 앞으로 점점 더 중요한 현상이 될 것이라고 그는 얘기한다.
그는 이러한 decentralization의 방향을 세가지로 제시하고 있다. 바로 loose hierarchy, democracy, market이다. Thomas는 이들에 대해 예를 들어 잘 설명하고 있으므로 여기서는 설명하지 않겠다. 직접 내용을 참고하기 바란다.
그는 앞으로의 비즈니스에서는 각각의 개인들이 우주의 중심에서서 자신들의 결정을 내리기 위한 모든 종류의 정보에 접근할 수 있을 것이라고 얘기한다. 또한 위에서 언급한 세가지의 방향들을 위한 새로운 어플리케이션들(하드웨어, 네트워크, 소프트웨어)이 탄생할 것이라고 예측하고 있다. 그리고 무엇보다도 그러한 어플리케이션에 적합한 비즈니스 조직에 대한 고민이 필요해질 것이라고 얘기하고 있다.
"On the Criteria To Be Used in Decomposing Systems into Modules"는 Information Hiding에 관해 얘기할 때 항상 인용되는 David Parnas의 paper다. 전에 읽을 때는 그저 Information Hiding의 개념을 처음으로 도입한 논문이구나 하고 생각했는데, Original wiki의 Information Hiding 엔트리를 살펴보다가 링크가 걸린 "Abstraction, Encapsulation, and Information Hiding"이란 글에서 다음과 같은 내용을 발견하였다.
"Hiding information", in and of itself, was not new. For that matter, the isolation of difficult and/or likely-to-change design decisions in modules was also not new. (Dijkstra had done this earlier in his implementation of the "THE"-Multiprogramming System.) The significance of Parnas’s 1972 article on software module specification lay in two areas:
– His advocation and specification of the (then innovative) technique of basing system modularization on design decisions. (You would have to say that the article presented a significantly different view of Dijkstra’s "levels of abstraction" approach.)
– His use of the term "information hiding". Virtually every article which mentions the topic traces its origin to [Parnas, 1972b].
Obviously, Parnas did not say all information hiding is good, nor did he say that all information hiding techniques are equally useful. He was identifying a particularly pragmatic approach to information hiding.
On the Criteria To Be Used in Decomposing Systems into Modules 더 읽기"
Domain Specific Language (DSL) 개발의 부담을 덜어주는 Language Workbenches 개념에 대해 소개하는 Martin Fowler의 글. DSL에 관심이 있다면 읽어보길 바란다. DSL 자체에 대해서도 예를 들어 잘 설명하고 있으므로, DSL에 대해서 잘 모르더라도 읽는데에는 별 문제가 없다. Martin Fowler의 쉽게 풀어쓰는 글솜씨에도 놀랐지만, 링크되어 있는 수많은 Further Reading들을 보면 새삼 공부할 거리가 많다는 것을 느낀다.
http://martinfowler.com/articles/languageWorkbench.html
http://martinfowler.com/bliki/LanguageWorkbenchReadings.html
키워드들.
Domain Specific Langauge, Language Oriented Programming, Language Workbench, concrete syntax, abstract syntax, External DSL, Internal DSL, Intentional Software, Meta-Programming System, Software Factories, Model Driven Architecture, schema, editor, generator, abstract representation, projectional editor, COBOL inference, graphical DSL, lay programmer, domain expert.
하나의 이슈에 대해서 격렬한 논쟁을 하다가 시간이 지나거나 다른 이슈가 발생하면 까맣게 잊어버린 듯한 행동을 보여주는 여론 현상을 이른바 “냄비”라고 경멸적으로 이른다. 하지만, 세상에는 너무도 많은 이슈가 있고, 밥벌이를 하면서 그러한 이슈들을 일일이 다 신경써주기는 힘든 면이 있다. 다시 말하면 “모든” 사람이 “모든” 이슈에 대한 여론을 지속적으로 조성하는 것은 힘들다는 것이다. 사회적인 합의를 도출할만큼 충분한 수의 사람들이 특정 이슈에 대한 여론을 지속적으로 조성하는 정도면 충분하다. 그렇다면, 이런 정도조차 되지 않는다는 비판인가? 냄비를 언급하는 사람들은 두가지를 혼동하고 있는 듯하다.
The Rise of Open Source Java (via LtU)
작년의 OScon에서 발표했던 What Book Sales Tell Us About the State of the Tech Industry에 등장했던 프로그래밍 언어별 시장 점유율 그래프의 업데이트를 소개하고 있다.
삶이 무료하고 지겨운 사람이라면 여기를 방문해보기를 권한다. 이 사람은 대한민국에서 소위 "우익"이라고 자처하는 사람들의 전형을 보여주는 듯 하다. 군사쿠데타 세력 옹호 + 반공 + 기독교. (오해의 소지가 있어서 언급하자면, 이 말은 대한민국의 우익 사상가들이나 기독교인들을 싸잡아서 비난할 뜻으로 적은 말이 아니다.)
그들의 논리는 일견 타당하게 보이지만, 사실(史實)을 약간씩 왜곡하거나 비상식적인 해석을 함으로써 자신들이 원하는 결론을 내리고 있다. 그러한 해석 하나하나는 반론이 가능하지만, 비록 잘못된 근거와 논리라고 하더라도 그것들이 하나의 글을 만들어내면, 대중들에게는 설득력이 발생한다는 것은 신기할 뿐만 아니라 절망스럽기도 하다.
예를 들어, 5.18 광주민중항쟁 당시 문화방송국 방화 사진에 대한 설명글인 "문화방송국에 방화하는 폭도들. 폭도들은 광주시민의 눈과 귀를 막기 위해 먼저 문화방송국에 방화하였다."라는 말을 보자. 당시 보안사와 중정을 장악한 전두환 세력이 언론통제를 하고 있었고, 광주의 현실은 제대로 보도되지 않았다. 오히려 전화 등을 끊음으로써 광주를 다른 지역과 격리하려고 시도한 전두환 세력이 국민의 눈과 귀를 막으려는 의도를 가지고 있었다는 것이 상식적으로 받아들일 수 있는 해석이다. 그리고, 이는 광주에서만 일어난 것이 아니었다. 한국의 현대사만 보더라도 권력을 가지고 있는 세력이 언론을 통제하여 민중항쟁을 탄압하려는 사례는 쉽게 찾아볼 수 있다.
이러한 현상은 근현대사 과목의 과제를 위해서 친일파 처리 관련 논쟁을 조사할 때도 마찬가지로 발견할 수 있었다. 이를테면, 해방 이후에 친일파 청산을 제대로 수행하지 못한 이유는 민족의 구성원 모두가 친일 행위의 공범이었기 때문이었다는 논리가 있다. 분명히 일제 치하 당시 일제의 앞잡이를 하던 순사나 면서기 같은 사람들의 착취 행위가 있었고 그들은 친일파였다. 하지만 경제 인구의 대부분을 차지하는 피지배층인 소작/반소작 농민들도 과연 친일파라고 부를 수 있을까?
매우 단편적인 사실만을 들어 그들의 입맛에 맞는 결론을 끌어내고 대중울 호도하는 현실은 매우 우려할만한 것이다. 정보가 흘러 넘치는 인터넷 시대에도 여전히 먹혀들어간다는 사실이 더욱더 절망스러울 뿐이다.
물론, 그들이 가지는 이해와 내가 가지는 이해가 다르다는 것은 역사적 사실의 해석에도 영향을 미칠것이다. 즉, 위에서 나는 "비상식적인" 해석이라는 말을 사용했지만, 그들이 말하는 해석들은 적어도 그들에게는 "상식적"일지도 모르는 것이다. 하지만, 어떤 사회에도 그 구성원들이 합의하고 있는 가치들의 집합이 있게 마련이고, 그들이 공유하고 있는 과거의 역사들이 있다. "상식"이란 공유되는 가치와 역사적 경험으로부터 나와야하는 것이다. 따라서, 상식은 시대나 상황에 따라 변하게 마련이고, 역사적 사실의 해석 또한 마찬가지다. 귀족 사회에서는 귀족들의 이해가 역사의 이해에 영향을 미치고, 시민 사회에서는 시민들의 이해가 역사의 이해를 주도할 것이다.
한편, 역사가 변화하는 것이라면 과연 역사의 해석 자체가 의미는 있을까. 역사의 해석은 끊임없이 변하지만은 않는다. 상식과 마찬가지로 역사 해석은 어느 정도 지속성을 가지고 있고, 그러한 지속 기간동안 계속 그 해석이 살아남는다면, 그것은 그 시대에 있어서는 상식적이고 의미가 있는 것이 아닐까.
광주민중항쟁과 친일파에 관한 해석도 마찬가지다. 그러한 역사적 사실에 대한 현재의 해석은 분명히 5공 시절이나 일제 시대의 해석과는 다르다. 그리고 현재의 해석이 수천년 후의 해석과 같으리라는 법도 없다. (물론 그 때까지 역사적 사실로 취급될지 조차 의문스럽지만.) 하지만, 우리가 짐작할 수 있는 것도 있다. 현재의 상식에 비추어볼 때, 이들의 역사 해석이 적어도 앞으로 수십년간은 헛소리 이상은 되지 않으리란 것이 나의 생각이다.
Summer of Code에 지원했다. Project description은 아래와 같다. 크게 formal할 필요는 없을 것 같아서 대충 썼는데… 벌써 5700명이나 지원했다고 하니, 이 정도로는 뽑히기는 좀 힘들지 않을까 싶기도 하고… 구글의 application form의 Country 항목에는 South Korea가 위쪽에 올라와있는데, 의외로 우리나라의 지원자는 10명 뿐이다. PST로 14일이 마감이니 지원할 생각이 있으나 못하신 분들은 얼른 하시길.
Ruby .NET – Ruby compiler on .NET platform.
INTRODUCTION
Ruby .NET is an Ruby compiler implementation on Microsoft .NET platform. Not just adding another .NET language, but Ruby developers could interop with .NET platform easily. Besides, we can expect some performance boost.
Project Page (temporary): http://lastmind.net/twiki/bin/view/Main/RubyDotNet
APPROACH
Now I’m considering IronPython approach: Iron Python (http://www.ironpython.com/) is a C# implementation of Python interpreter and works on CLR. It shows better performance than original Python interpreter implementation. I’ve investigate IronPython code and found that it just parse Python code, build AST, and translate to CLI code using .NET reflection. I believe I can take same appraoch in Ruby .NET.
ISSUES
– There’s no authentic Ruby syntax reference except the original Ruby compiler implementation.
"I’m afraid, the only complete reference for Ruby’s grammar is the YACC input file "parse.y" from the ruby source distribution."
(from http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/15608)
– Semantics for Ruby statements is just hardwired into Ruby compiler implementation.
RELATED PRODUCTS
Of course, I’ve seen around several efforts to develop Ruby .NET, but I believe no production-quality project is available so that It’s worth to trying.
IronPython: http://www.ironpython.com/
JRuby: http://jruby.sourceforge.net/
rubydotnet: http://rubydotnet.sourceforge.net/
NetRuby: http://www.geocities.co.jp/SiliconValley-PaloAlto/9251/ruby/nrb.html
Ruby .NET Compiler: http://www.asakawa.net/ruby/rubynet_memo.html
Ruby – Perl Parse::RecDescent grammar: http://cpan.uwinnipeg.ca/htdocs/parrot/Ruby.html
RubySharp: http://www.pronovomundo.com/htu/theses2004/rubysharp_hedstrom_thesis_final_040526.pdf
EXPERIENCE
Compiler theory is a crucial skill to develop Ruby .NET. I’ve finished compiler course for undergraduate in KAIST and I believe I have. I have 3.5 year C/C++ system/network programming experience in POSIX platform as an alternative job to military service. I am specially interested in distributed computing technologies in enterprise environment like several RPC technologies, CORBA, DCOM, .NET Remoting, Indigo, and Web Services. I love to learn programming languages like C/C++, Java, C#, Perl, Python, Ruby. Ruby is my favorite one these days.
Update: tj형의 의견에 따라 좀 더 formal하게 대폭 수정해서 다시 application 제출 했다.