Software Development

g++ 3.4도 아직 그다지 안정화 되어 있는 상태는 아닌 모양이다. 이 버그의 workaround 중 하난 멤버에 접근할 때 this->를 사용하는 것이다. 자세한 내용은 다음 링크를 참조.

http://lists.debian.org/debian-gcc/2004/05/msg00293.html

Description

어떤 멤버 함수로부터 같은 클래스의 템플릿 멤버 함수에 접근할 경우, gcc 2.95가 internal compiler error를 발생시킴.

Example

Workaround

템플릿 멤버 함수 (bar)를 멤버 함수(foo)보다 위쪽에 정의해주면 됩니다. 이 외에도 gcc 2.95는 template 관련 버그가 꽤 많죠. template을 많이 사용한다면 부득이 하지 않은 이상 3.x 이상을 사용할 것을 권장합니다.

Google의 VP of Engineering인 Adam Bosworth와의 토론.

현재 보편적으로 사용되는 관계형 데이터베이스(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"이란 글에서 다음과 같은 내용을 발견하였다.

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에 등장했던 프로그래밍 언어별 시장 점유율 그래프의 업데이트를 소개하고 있다.

Summer of Code에 지원했다. Project description은 아래와 같다. 크게 formal할 필요는 없을 것 같아서 대충 썼는데… 벌써 5700명이나 지원했다고 하니, 이 정도로는 뽑히기는 좀 힘들지 않을까 싶기도 하고… 구글의 application form의 Country 항목에는 South Korea가 위쪽에 올라와있는데, 의외로 우리나라의 지원자는 10명 뿐이다. PST로 14일이 마감이니 지원할 생각이 있으나 못하신 분들은 얼른 하시길.

Update: tj형의 의견에 따라 좀 더 formal하게 대폭 수정해서 다시 application 제출 했다.

전에 친구의 프로그래밍 숙제를 도와주다가 너무나 답답해서 든 생각이다. 프로그래머는 다음과 같은 능력을 필요로 한다. 좋은 프로그래머인지 아닌지는 언어를 하나 더 아느냐 기술을 하나 더 아느냐가 아니라, 이러한 능력을 지니고 있느냐 없느냐에서 드러난다.
Abstraction. Decomposition. Indirection.

Hatred for PHP

대부분의 사람들은 PHP가 표방하는 PHP의 철학에 동의한다. 그렇다면 무엇이 싫단 말인가? 웹 검색을 통해서 다음과 같은 글들을 발견할 수 있었다.

• I hate PHP
• Why PHP sucks (for large systems)
• PHP in contrast to Perl
• Experiences of Using PHP in Large Websites
• PHP annoyances
• PHP: A love and hate relationship
• PHP 5 Enterprise Edition?"

이 사람들은 PHP를 미워하고 있다. 그 이유는? 어느 정도 유효하고 중요한 내용들만 내 생각들과 함께 정리해보았다.

Language Syntax

• No namespaces: 어느 정도 복잡한 product를 만들 때, 불편한 점 중의 하나는 함수 이름이나 변수 이름이 중복되는 것이다. 이 문제에 대한 해결책으로, 모든 함수나 변수들의 이름에 prefix를 붙여서 namespace를 구분하거나, 클래스를 namespace의 대용으로 사용하는 방법이 있다. C와 같은 다른 언어들을 생각해보면, 분명히 namespace가 없이도 커다란 프로덕트를 만드는 것은 가능하다. 하지만, 최근에 나온 대부분의 언어가 namespace를 가지고 있음에도 불구하고 PHP 5에 namespace가 들어가지 않은 것은 상당히 아쉬운 부분이다.
• Arrays are ordered maps: PHP의 array는 기본적으로는 key, value pair의 집합인 ordered map이다. PHP의 array는 이러한 map의 용도 뿐만 아니라 여러 용도로 전용된다. integer를 key로 하는 전통적인 array를 비롯하여, list, queue, stack 등으로 사용될 수 있다. 이러한 사실은 array function들을 ë³´ë©´ 알 수 있다. 언어가 단순해지고, 여러가지 데이터형으로 활용함으로써 얻는 편리한 점도 있겠으나, 프로그래머가 array라는 데이터형에 대한 명확한 모델을 머리속에 그리지 못하게 하고, 또한 프로그래머가 실수를 할 가능성을 높힌다는 측면에서 그리 좋지 못하다고 생각된다. 많은 언어들이 array와 map을한다. 하지만, 그렇다고 string 만으로 array를 지원하는 언어들을 무시할 수는 없다. 어떤 데이터형을 지원하는가 하는 문제는 언어의 단순성과 프로그래머의 편이성 사이의 trade-off 문제라고 생각한다. 어떤 언어가 어떤 데이터형을 지원하느냐는 ê·¸ 언어의 철학에 달린 일이고, 정답이 있는 것은 아니다.
• Does not enforce the declaration of variables: PHP는 선언 또는 정의되지 않은 변수이더라도 참조가 가능하다. (물론 warning은 발생한다.) "<? print $undeclared_variable; ?>"라는 PHP 코드와 "print undeclared_variable"이라는 Ruby 코드를 실행해보라. PHP에서는 아무렇지 않은 듯이 조용히 실행되지만 Ruby에서는 "undefined local variable or method"라는 에러가 발생한다. 비교적 작은 프로그램, 모듈, 또는 함수에서는 큰 문제가 되지 않지만, 코드가 길어지고 복잡해질 수록 버그를 발생시킬 가능성이 높아지고, 이 버그를 발견하는 것도 힘들어진다. PHP에서는 옵션을 통해 정의되지 않은 변수 접근에 대한 경고를 켤 수 있다.
• No real references: reference가 아니라 name alias일 뿐이기 때문에 여러가지 문제가 발생한다. http://www.php.net/manual/en/language.references.php
• No chained method call: $foo->bar()->op() 같은 문법이 불가능했었다. PHP 5에서 가능해졌다.
• No closure, not even anonymous functions
• shortcut behavior: 다른 언어들과는 달리 shortcut의 결과값이 boolean 값이다.
• call-time pass-by-reference deprecation: PHP에서 reference를 사용하는 문법은 매우 이상했다. function을 정의할 때 파라미터에 reference임을 나타낼 수도 있고, 실제로 호출을 수행할 때도 reference임을 나타낼 수 있었다. 이 점은 기존 PHP 문법이 상당히 불완전함을 나타내는 증거라고 ë³¼ 수 있는 것 같다. (예를 들어, function 정의의 파라미터에도 reference라고 명시하고, 호출 시 아규먼트에도 reference라고 명시한다면 어떻게 될 것인가. reference의 reference? 답은, 그냥 reference다.) 결국은 호출 시 reference 명시는 deprecated 되었다. 문제는 이 deprecation으로 기존에 할 수 ì
  žˆì—ˆë˜ 일을 할 수 없게 되어버렸다는 것이다. PHP 5에서는 모든 variable을 reference semantic을 가지도록 바꾸었기 때문에 더이상 이런 문제는 없을 것이다.

Language Implementation

• Template: 대부분의 언어들은 templating을 언어의 구현과 분리해놓지만, PHP의 구현에는 완전히 합쳐져있다. 웹 어플리케이션의 규모가 커지면서 프리젠테이션과 로직의 분리가 중요해진 지금 시점에는 그다지 좋지 않은 방법이다.
• Register Globals: Register Globals는 CGI를 통해 들어오는 리퀘스트 변수들을 전역 변수로 만들어주는 기능이다. namespace를 가지지못한 PHP로서는 전역 namespace를 더럽히는 것은 엄청나게 해로운 일이다. 물론 여기에는 "웹 프로그래머의 편이"라는 언어가 만들어지던 당시의 고려가 담겨있다. 하지만, 웹 어플리케이션의 규모가 커지면서 이 기능은 PHP를 해치는 기능이 되어버렸다. 최근에는 이 기능을 켜고 끌 수있는 옵션의 기본 값이 "끄는 것"으로 바뀌었다.
• Bad recursion support: 스피드를 위해서 stack에 저장하는 데이터가 많기 때문에 recursion에 좋지 않다.
• Not thread-safe: 구현을 ë³´ë©´ thread safety를 위한 노력을 하고 있으나, 실제로 thread-safe 하지는 않다.
• Magic quotes: Magic quotes는 PHP가 사용하는 데이터에서 특정 문자들을 자동으로 escaping 해주는 기능이다. 프로그래머가 직접 하더라도 크게 불편하지 않은 작업을 굳이 자동으로 해주어서 복잡도를 증가시키는 것은 좋지 않은 기능인 것 같다.

Standard Library/3rd-party Library/Framework

• Inconsistency: PHP에서 기본으로 제공되는 라이브러리에 들어있는 함수들의 이름이나 파라미터들은 상당히 일관성이 없다. 다음 링크 참조.
• no crucial XXX library: html parser, MIME builder, WWW library, consistent database API, gd를 제외한 graphics library가 없다는 것을 불만스러워하고 있다. PEAR에서 어느 정도 해결되기를 기대해본다.
• no CPAN: 현재는 PEAR가 공식적인 extension repository가 되었으나, CPAN 처럼 사용하기에 편리한 것은 아니다.

People

• Knowledgeable people are in a serious minority: 외국의 PHP 커뮤너티조차도 수준이 낮다는 지적을 많이 받고 있는데, 내가 보기에는 국내의 PHP 커뮤너티ë
  „ 크게 다르지 않은 것 같다. 가장 유명하다는 PHPSCHOOL에 가보라.