프로그래밍 언어들을 한문장으로 소개

Perl

Perl is a language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. ((man perl))
펄은 텍스트를 다루는데 최적화된 언어다.

Python

Python is an interpreted, interactive, object-oriented programming language  that  combines  remarkable power with very clear syntax. ((man python))
파이썬은 매우 간결한 문법이 특징.
동의한표. 내가 써 본 언어 중에서 가장 문법이 간결했다. 물론 lisp 계열은 제외하고.

Ruby

Ruby is an interpreted scripting language for quick and easy object-oriented programming. ((man ruby))
루비는 빠르고 쉬운 OOP를 위한 스크립트 언어다.
여기서 빠르다는건 성능이 아니라 생산성을 의미하는 것이겠지. 확실히 파이썬보다 코드를 짧게 작성할 수 있다.

PHP

PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. ((man php))
PHP는 원래 HTML에 끼워넣는 것에 특화된 언어다.
언어가 좀 엉성해 보이고 빈약해서 난 항상 불만이긴 한데, 어찌보면 그런 점도 이런 지향점을 고려하면 타당한 것일 수 있다.

C++

C++ is a general purpose programming language with a bias towards systems programming that
* is a better C
* supports data abstraction
* supports object-oriented programming
* supports generic programming. ((http://www2.research.att.com/~bs/C++.html))
C++은 C보다 좋은 언어라고 한다.
잘못하면 싸움나겠네.

J

J is a modern, high-level, general-purpose, high-performance programming language. ((http://www.jsoftware.com/))
현대적 고수준 다목적 고성능 언어.
그리고 C++ 보다도 어려운 것 같아.

Lisp

Lisp is a programmable programming language. ((책 <On Lisp>의 서문에서. Paul Graham은 “It’s difficult to convey the essence of a programming language in one sentence, but John Foderaro has come close:” 라고 말하며 이 정의를 소개한다.))
정말 멋진 정의다!

Java?

자바는 공신력 있고 설득력 있는 한문장 소개를 찾지 못했다. C++ 보다도 정체성이 불분명한 녀석이다.
광고

코딩 20년

올해는 2011년.

내가 코드를 처음으로 작성해 본 것이 초등학교 4학년때인 91년이니, 올해로 코딩을 20년째 했다는 얘기가 된다.

그렇게 열심히 한 건 아니지만, 어쨌든 꾸준히 하긴 했다.

초등학교때 컴퓨터를 사자마자 베이직을 배우면서 코딩하고, 중학교때 간단한 퍼즐 게임 만든다고 코딩하고, 고등학교때 전산반 들어가서 코딩하고, 대학교때 전자공학부로 입학했지만 컴퓨터공학도 복수전공하면서 코딩하고, 게임제작동아리 들어가서 또 코딩하고, 군대갔을 때는 휴가나와서 코딩하고, 3년전 입사해서 회사에서 코딩하고, 친구와 만나서 취미로 코딩하고, 베이직으로 코딩하고, C/C++로 코딩하고, 자바로 코딩하고, 파이썬으로 코딩하고, 루비로 코딩하고, PHP로 코딩하고, 아주 조금씩이었지만 Scheme, Prolog 등의 언어로도 코딩을 했다.

20년이나 했지만 실력은 별로 안 늘었다. 아마도 내가 공부하는 걸 안 좋아해서 그런 것 같다. 진득히 앉아서 공부하는 능력이 있었다면 지금보다 훨씬 나은 실력을 갖고 있을텐데 참 안타깝다. 뭐 그렇긴 한데 내가 지금 과거로 돌아간다고 해도 어차피 공부 안할 것 같다. 공부하기 귀찮아 하는 건 지금도 마찬가지라서.

실력은 그닥 못 얻었어도 대신 알게 된 건 내가 코드를 작성하는 일을 좋아한다는 것 정도다.

40년 넘게 코딩을 계속해오고 있는 켄 톰슨, 롭 파이크, 론 제프리즈 처럼, 앞으로 20년, 대략 정년에 달하는 그날까지 코드를 작성하는 일을 계속 할 수 있으면 좋겠다. 마음같아선 백살까지 했으면 좋겠다. 90년간 코딩을 해왔다고 하면 정말 무시무시할 정도로 굉장할 것 같다.

우리나라도 장인 개발자가 나올 수 있는 환경이 되었으면 좋겠다. 그런 환경을 만드는데 뭔가 보탬이 되는 일을 해보고 싶기도 하다.

npcode.com/blog/2010/11

오늘 코딩중 변수명을 지으려다 의문이 하나 생겼다.

path에서 /과 같은 separator로 구분되는 단어 하나하나를 뭐라고 부르지?

npcode.com/blog/2010/11 <= blog, 2010, 11 요런거 라던지,

/home/nori/hello.txt <= home, nori, hello.txt 이런거 라던지.

파일이름이라고 할 수도 없고 디렉토리라고 할 수도 없어서 고민하다가, 이런 문제는 운영체제 관련 책에 나와있지 않을까 싶어서 책장에 꽂혀있던 ‘리눅스 커널의 이해’를 펼쳐서 경로명 탐색에 대한 부분을 읽어보았다. 그리고 저런 것을 ‘구성요소’ 라고 부르고 있는 것을 확인했다. ‘구성요소’라니 좀 어색한데 영어로는 뭔가 하고 그 책의 원서를 뒤져보았다.

pathname component

‘pathname component’라는 표현을 쓰고 있는 것을 확인.

정말로 리눅스 커널에서 저렇게 부르는지 궁금해서 리눅스 커널 소스(linux-2.6.32.8)를 들여다보았다. 파일시스템 관련 코드 등에서 ‘pathname component’라는 표현을 7번 사용한 것을 확인했다.

아, 이건가 보다 하며 안심하고 변수이름을 pathname_component로 하여 커밋. 그런데…

path component

문득 pathname component가 정말 널리 쓰이는 용어인지 의문이 들어 구글링을 좀 해봤다. 그런데 파이썬 문서에서 pathname component보다 path component라는 용어를 더 많이 사용하는 것을 발견했다.

어라? 해서 리눅스 커널 소스를 다시 뒤져보니 path component가 28회나 사용되고 있었다. pathname component 보다 4배나 많잖아?

URI를 정의한 RFC 3986에서 path component로 검색해보니…

We use the generic term "path component" to describe the URI substring
matched by the parser to one of these rules.

      path          = path-abempty    ; begins with "/" or is empty
                    / path-absolute   ; begins with "/" but not "//"
                    / path-noscheme   ; begins with a non-colon segment
                    / path-rootless   ; begins with a segment
                    / path-empty      ; zero characters

      path-abempty  = *( "/" segment )
      path-absolute = "/" [ segment-nz *( "/" segment ) ]
      path-noscheme = segment-nz-nc *( "/" segment )
      path-rootless = segment-nz *( "/" segment )
      path-empty    = 0<pchar>
      segment       = *pchar
      segment-nz    = 1*pchar
      segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                    ; non-zero-length segment without any colon ":"

      pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

대충만 보고 path component가 내가 찾던 정답이 맞다고 생각했다 그러나,

path segment

수일 후, HTTP: The definitive guide를 읽다가 path segment라는 단어를 내가 원하는 바로 그 의미로 사용하고 있는 것을 보았다. 깜짝 놀라 RFC 3986에서 이 단어를 찾아보고 다음과 같은 설명을 발견했다.

A path consists of a sequence of path segments separated by a slash (“/”) character.

내가 완전히 잘못 이해하고 있었다. path component는 URL에서의 path 부분 전체를 의미하는 것이었고,  /로 나뉘는 요소 하나하나는 path segment라고 불러야 맞는 것이었다. 답을 알고 난 뒤 위의 인용문을 다시 읽어보니, 역시 path component는 path 전체를 의미하는 것이 맞다.

이 글도 뒤늦게 고쳤다.

결론

path segment가 맞다. (적어도 URI에서 쓰는거라면)

교훈

IETF의 RFC 문서들은 BNF스러운 문법(ABNF라고 한다)으로 개념을 정의하기 때문에 용어 정의는 굉장히 잘 되어있다. 인터넷 관련 용어에 대해 궁금한 것이 생겼을 때는 역시 RFC.