프로그래밍 언어 개발에 관심 있는 사람들의 모임입니다.
|
2008-07-24 14:36:55
|
아랫분 말씀처럼 각자 언어를 개발하시는 분들이 많으신듯한데.. 혹시 구글그룹이나 공동위키에 언어별 비교문서화하실 생각들이 있으신지 궁금합니다.. 만약 하게되면 문법부터 기초 함수명정도까지 다루었으면 하고요.. 어떤 간단한 함수내용이 제안되면 각자 언어로구현한 코드를 비교해보는 방법도 있겠고요.. 시작시 참여하실분이 계실지 모르겠지만 위키 제공자가 안계시면 제가 제공할 생각도 있습니다.. (도쿠위키로) |
트랙백 주소: http://langdev.net/post/trackback/110
언어마다 표현력이 같지 않습니다. 어떤 언어에서 한줄로 끝나는 일도 다른 언어에서 의미적으로 동일한 일을 하기 위해 몇 개의 파일이 필요할 수도 있습니다.
반대로, 의미적으로 거의 동일한 언어끼리의 비교라면 단지 문법의 차이만 있을 뿐입니다.
이 두 가지는 너무 극과 극이라 굳이 비교를 해서 정리해야할 필요가 있을까 싶습니다.
오히려 비슷한 라이브러리끼리 기능을 비교하는 것이 더 나을 듯 하지만 여기서 다룰 내용은 아닌 것 같습니다.
저도 위의 semmal 님 의견과 같습니다. Logo나 Prolog 같은 언어를 생각해보세요. 심지어 Subtext 같은 언어도 있습니다. Subtext는 일반적인 프로그래밍 언어들처럼 텍스트 표기법을 사용하지 않는 언어입니다. Visual Basic 같은 거 생각하시면 곤란합니다. 직접 보세요.
KLDP에서도 그렇고, 모든 프로그래밍 언어에서의 시멘틱이 1:1 맵핑 가능하다는 믿음을 가지고 계신 것 같은데, 세상에는 워낙 특이한 언어가 많아서 그런 게 불가능한 예외적인 경우도 무척 많습니다.
아, 그리고 그런 용도가 아니라, PL 관련 논문 등을 번역하거나 각자의 언어 스펙을 모아놓기 위한 용도로서의 위키는 현재 작업중입니다. 아직 IRC에 상주하시는 분들끼리만 정리 작업을 하고 있지만, 조만간 공개할 예정이니 기대해주세요~.
저는 각자 개발중인 언어 스펙을 모아놓기 위한 용도로서 제안한 것인데… 그리고 설령 일반언어 스펙을 문서화 한다 해서, 특이한 언어까지 모두 포함시켜가면서까지 무리하게 언어의 일반화를 추구해야할 필요가 있을까 싶고요.. (비주류의 특이한 언어를 문서화에서 포함시킬수 없다하여, 나머지 주류언어의 문서화를 포기하자는 말씀으로 들리고요..)
문법차이를 모아놓는게 불필요한 작업이라고 말씀하시다니, 언어 개발에 관심 있으신분의 말씀이신지 좀 의아스럽고요.. 말씀대로라면 이미 문법차이를 비교해둔 사람은 불필요한 작업을 한것이 되는걸까요..
안타깝게도 홍민희님은 역시 제가 잘못된 믿음을 가지고 있는것 같다고 생각하시는것 같군요..
저야 그저 의견을 들으려 한것 뿐이기 때문에 별 논의없이 그런줄 알겠고요.. 이미 작업중이시라니까 일단 기다려봐야겠네요..
비주류의 특이한 언어만 그런 게 아닙니다. 또, 시멘틱은 단순히 문법만을 말하는 것도 아닙니다.
문법 차이가 중요한 것이 아니라, 의미 차이가 중요하다는 말입니다.
문제는 언어의 도메인에 따라서 의미는 천차만별이고, 범용 언어라고 하더라도 그 패러다임이나 철학에 따라서 다른 방법으로 프로그래밍 해야합니다.
이런 것을 모두 정리하신다면 고맙게 보겠습니다만, 그렇게 굳이 정리하는 것이 논문을 쓰는 것이면 몰라도, 제 언어 만드는데 도움이 된다는 생각은 안드네요.
그리고 문법이 매우 특이하거나 다른 언어는 10%보다는 훨씬 많습니다.
궁금한게 있는데요.. 언어란 의미를 표현하는 방법일텐데요.. 문법보다 의미가 더 중요하다면서, 굳이 기존 문법과 다른 새로운 언어를 만드시려는 이유가 무엇인지요..?
문법은 별로 Haskell과 다르지 않을 것 같구요. 의미구조도 훨씬 단순합니다. 왜 만드냐고 말씀하시면 그냥 그러고 싶어서입니다. 이런 말을 하면 화내실 지도 모르겠는데, 저에게 있어서 언어를 만든다는 건 Hello World프로그램을 만드는 것과 다르지 않습니다. 별의미가 없다는 말입니다.
어떻게 동작할지 뻔하지만 진짜 그렇게 동작하는지 한번 확인해 보고 싶은 마음 정도랄까요? 뭐 이것 저것 만들다보니 다른 언어는 너무 크기만 하고, 맘대로 가지고 놀 수 있는 언어가 있었으면 좋겠다는 치기라고 할 수도 있겠지요.
어쨌든 저에게 있어서 언어를 만드는 것이 진지하고 숭고하고 크게 가치있는 일이 아닌 건 확실합니다. 맘에 안들면 언제든지 때려치울 의향으로 마음이 가득차 있으니까요.
어쩌면 가끔씩 기분 내킬 때 비교를 하고픈 맘이 들지도 모르겠습니다만, 개인적으로 “정식으로 비교를 해서 문서화”하는 것은 영 맘에 안듭니다. 귀찮은 건 질색입니다.
어떻게 노가다를 해서 만들더라도 제 언어가 상용 언어나 수많은 똑똑한 사람들이 달라붙어서 만드는 언어에 비해서 열등한 건 명약관화일테고, 제가 필요성도 못느끼면서 다른 언어의 기능을 넣으려거나 비교할 필요는 없을 것 같습니다.
화내긴요.. 말씀하시는 배경을 알았으니, 향후에는 일치하지 않는 가정으로 인한 쟁점이 줄어들겠지요.. ^^
위키백과에 프로그래밍 언어들을 비교하는 페이지가 있기는 합니다. 하지만 보시면 아실 것 같은데 너무 안 맞는 게 많습니다. 예컨대 많은 언어들은 “심볼”에 대한 개념이 보통 존재합니다만 그 심볼을 어떤 의미로 매핑하느냐는 셀 수 없을 정도로 제각각입니다. (그래서 이들 페이지들은 최대한 loose하게 비교하려고 노력을 해 놓긴 했던데, 많이 문제가 있더군요.)
언어 스펙을 모아 놓는 것이라면 현재 홍민희 님이 만들고 계신 위키로도 충분하다고 생각합니다. 그 이상의 작업은 위키가 아니라 사람들과의 소통을 통해 행해지는 게 더 좋다고 봅니다.
궁금한게 있는데 그럼 언어를 개발하시면서, 표현보다는 의미가 중요하기 때문에, 다른언어의 문법이나 철학은 참고 안하시는건가요..?
참고하신다면 다른언어의 철학은 (문법없이 혹은 비교행위없이) 어떤 방법으로 이해하시는지요..?
물론 굉장히 많이 참고합니다.
하지만, 누가 비교 정리 요약한 것만 보고 새로운 언어를 날로 먹으려고(이해하려들지) 않습니다. 그런 표면적인 것만으로 새로운 언어를 이해할 수 있을까요? 새로운 언어를 배울 때는 레퍼런스나 튜토리얼부터 차근차근 보면서 배웁니다. 언어 설계자의 의도와 철학을 이해하려 노력하면서요.
논지가 잘 이해가 안되는데.. 말씀하시고자하는 바가 참고하려는 모든언어의 레퍼런스를 차근차근 보는것은 이해가 잘되도록 비교정리가 잘 된 비교정리를 본적이 없으셔서 그런건가요.. 아니면 “날로 이해하는”것을 선호하지 않아서 인가요..?
그러고보니 비교정리하자고 했던 저를 아마 “날로 먹는 사람”쯤으로 보고 계신거였군요.. ㅠㅠ
비교 정리가 보통 불가능하거나 하더라도 무의미할 경우가 많다고 이해하시면 될 것이라고 생각합니다.
예전에 올리신 답글을 볼 때, 착한아이 님께서는 여기 계신 많은 분들보다는 덜 이질적인 언어들을 많이 다뤄 오신 것 같습니다. 혹은 이질적이더라도 이질적이지 않은 부분만을 취사 선택하셨을 수도 있고요. 아무래도 비교 정리가 가능하다고 생각하셨던 것은 그런 이질적이지 않은 사용례로부터 생각하신 것 같습니다만, 안 그런 것들이 훨씬 많습니다. ;)
말씀하신 “무의미”의 정의가 조금 다른듯한데, 말씀하신 “무의미”가 보편적인 “무의미”인지, 개인적인 “무의미”인지 명확히 해주셨으면 해서요..
또 “무의미”하다고 말씀하시는 비교정리라는 것이 비교항목이 적은 이질적인 언어간에도 비교항목이 많아야만 “의미”를 가지는 것인지, (비교항목이 적지만) 비교정리가 가능한 항목끼리만이라도 비교정리를 해두는게 “무의미”하다는 것인지요..?
비교정리된 문서가 그 언어의 철학을 이해하기 어렵다 하시니 어떤 매트릭스를 생각해보겠습니다..
C++ = ‘assign’, ‘function’, ….
Java = ‘assign’, ‘function’, ….
LISP = ‘assign’, ‘function’, ….
PHP = ‘assign’, ‘function’, ….
여기서 가로행은 홍민희님이 차근차근 보신다는 레퍼런스 입니다. 제가 정리하고자 했던 문서는 이 매트릭스에서 열방향으로 정리하는 것이었습니다.. 전체 매트릭스의 분량은 동일하지만 중복된 내용은 줄일수 있으므로 습득시간 역시 줄일수 있을겁니다. (“날로 먹는”거죠.) 아마 가로방향에서는 이런 비용을 줄이기 힘들겁니다. 동일한 레퍼런스 분량의 내용을 담고 있음에도, 이 열방향 습득이 홍민희님이 선호하시는 행방향 습득보다 해당 언어의 이해하는데 방해가 되거나 효과적이지 못하다고 홍민희님은 생각하시는 것으로 이해하겠습니다..
이 정도의 정리가 언어 학습 비용을 줄인다고 생각하지 않습니다;
가장 유명한 두 Lisp dialect인 Scheme과 CL만 봐도,
define과defun의 차이에 대해 말할 것이 많습니다. 만약 블로그 포스팅 하나 정도를 할애해서, 적은 수의 언어의 비슷한 기능에 대해 공통점과 차이점을 서술한다면, 그 정도의 분석에 대해서는 의미 있다고 생각합니다만…; (Lisp-1 vs Lisp-2 debate 같은)제글에서 분명히 레퍼런스 분량의 내용이라고 가정하고 있습니다. 학습비용을 줄이기에 부족하다는 “이 정도의 정리 “가 제가 가정한 레퍼런스 분량의 내용을 가리키시는 것으로 이해하겠습니다.. 참고로 이 답글에서 레퍼런스 수준의 예를 보여드릴수 없기 때문에, 개념적으로 레퍼런스를 1차원으로 나열했을 표현한것 입니다.
열방향으로 레퍼런스를 기술하다보면 예를 드신것처럼 상충되는 문서가 추가로 생길수도 있습니다. 이런 경우에는 이 경우의 학습비용이 증가할수도 있습니다. 저는 비용을 줄인다고 단정적으로 표현하지 않고 줄일수도 있다고 표현하였습니다. 중요한건 열방향 학습이 학습비용을 증가할수도 있기 때문이 아니라 열방향 학습이 언어 철학 이해에 불충분하다는 이유를 드셨습니다. 열방향 학습에서 학습비용이 증가할수도 있다는 점을 언급하실때는 비교과정에서 늘어난 문서가 애초에 말씀하셨던 해당언어를 이해하는데 과연 여전히 불충분하거나 방해가 되는지를 말씀해주셨어야 할것 같습니다.. 적은수의 포스팅은 의미가 있다고 하셨는데 그것은 문서작성자의 실현가능성이지, 포스팅의 분량에 따라 비교정리가 “의미”가 있고없고 하는것은 아니라고 생각합니다..
철학이란 어떤 것을 만든 사람이 그것으로 무엇을 어떻게 하려고 하는 가를 뜻합니다. 그래서 단순히 기능의 비교만으로는 그것을 알 수 없습니다.
OS로서 유닉스와 윈도즈, MacOSX는 대부분 같은 기능을 지녔다고 말할 수 있을지도 모릅니다. 하지만 같은 기능이라도 사용자가 OS를 다루는 방법이나 프로그램이 만들어지는 철학은 완전히 다릅니다.
windows의 최대화는 화면 최대화를 뜻하지만 맥에서는 컨텐츠 최대화를 뜻합니다. 유닉스 프로그램은 하나만 잘하자지만 윈도즈 프로그램은 여러개 다 잘하자에 가깝습니다.
그래서 기능이 있느냐 정도의 단순한 기능 비교만으로는 이런 철학을 결코 알 수 없다고 생각합니다.
저는 해당언어하나만 보는것이 아니라 해당 토픽별로 비교해 보는 대해 얘기하고 있지, “단순”비교를 가정한 적이 없습니다.. 철학이 다른지 같은지도 비교를 했을때나 알아차릴수 있을 것 같은데요.. (일반) 비교가 언어의 철학 이해에 불가능이거나 무의미하다는 점을 말씀하시려면 “단순비교”라는 단서를 달면 안되지 싶습니다. 왜냐면 단순을 가정하지 않은 제 의견이 불가능하거나 무의미하려면, “단순”이 아닐경우에도 여전히 불가능하거나 무의미해야 하기 때문입니다..
토론을 통해서 의견이 좀 더 구체적으로 나타나는 것 같아서 기쁘군요. 전체적으로 한꺼번에 단숨에 다룰 생각이 아니시라면 나쁘지 않은 것 같습니다. 그럼에도 불구하고 제 언어 만드는데 도움이 된다고 생각이 들지는 않습니다. 아직 저도 모르는 게 많다보니 정확히 설명할 수 없는 부분이네요. 아마 언어를 선택하거나 만들려고 하는 분들에게는 어느정도 도움이 되지 않을까 싶습니다.
이미 있던 의미라면 이전의 다른 언어에서 그와 비슷한 의미를 가진 문법을 선택하거나 그것을 보완하면 됩니다. 예전에는 없었던 의미라면 문법을 만들면 됩니다. 이렇게 문법을 만드는 스타일은 제작자가 좋아하는 모양대로 만들어지겠지요. 어떤 사람은 perl을 좋아하고 다른 사람은 lisp을 좋아하고 또 어떤 사람은 c를 좋아하는데 또 다른 사람은 haskell을 좋아합니다. 문법에 정답이 있을까요? 저는 없다고 봅니다.
하지만 어쩌면 의미에는 정답이 있을지도 모릅니다. 제가 가장 기본적으로 선택한 것은 lambda고 민희님이라면 아마도 object겠지요.
다른언어에서 비슷한 의미를 가진 문법을 선택할수 있는 것은 그런 여러언어를 이미 알고 있다는 가정하에 말씀하신것 같은데요.. 제가 여쭌건 그런 여러언어의 철학을 어떻게 이해해 나가는냐인것 같은데요.. 말씀하신 고견은 아마도 제 질문의 답은 아닌듯 싶습니다..
저번 글타래에서 착한아이님도 많은 언어를 접하신 걸로 봤습니다. 언어를 만드는데는 그정도 지식만으로도 충분합니다. 아는 만큼 만드는 것이죠.
지극히 주관적인 생각이지만 기업이 아닌 개인이 그냥 장난삼아 쓸 언어를 만들기 위해 다른 언어를 공부하는 것은 별 의미없는 짓이라고 생각합니다.
언어 공부는 그냥 꾸준히 해야하는 것이고, 꾸준히 이 언어 저 언어로 개발하다보면 도메인에 따라서 다른 언어의 필요성이 생기는 것일 뿐입니다. 그 때 아는 만큼 필요한 만큼 만들면 됩니다. 결론적으로 저는 언어를 만들기 위해서 언어를 공부하지는 않습니다.
그저 언어를 공부하는 방법을 물으신다면 민희님과 별 차이 없습니다. 문제를 풀어보고 꾸준히 계속 써보는 수 밖에요.
전에도 링크 걸었지만 PLEAC이 그런 거 아닌가요? 공동 편집을 할 수 없을 뿐이죠. 굳이 기능별로 비교할 필요 없이, 하나 택해서 읽으면 ‘맥락에 맞게’ ‘의미까지’ 알아볼 수 있으니까요.
PLEAC과 Syntax across languages 페이지를 소개해 드렸는데요, 이런 프로그래밍 언어를 비교하는 프로젝트들이 이미 있는데 새로운 프로젝트를 제안하시는 건 어떤 이유인가요?
저는 둘 모두 별로 설득력 있는 이유가 아니라고 생각합니다.
제가 제안하고자 했던것은 이미 PLEAC에 정리되어 있는 상태와 유사하게 기존 언어를 정리하자는 말이 아니라, 각자 개발하시는 언어들도 PLEAC처럼 정리해보는건 어떤가 하는것이었습니다.
흠. 이건 재밌겠는데요.
홍민희씨가 준비하고 있는 위키가 열리면 거기서 해보죠.
lifthrasiir님이 이미 비교 정리가 보통 불가능하거나, 하더라도 무의미할 경우가 많다는데요.. 그럼 홍민희님이 준비하는것은 무엇을 기대하고 정리하시는 건지 궁금합니다..
글쎄요. 저도 lifthrasiir님 말이 맞다고 생각하는데, 비교할 수 없는 건 비교할 수 없는 것이고, 비교할 수 있는 건 비교하면 되는 거죠.
서상현님의 비교가능한것까지하면 된다는 의견은 liftthrasiir님의 비교정리가 무의미하다는 의견과 상충되어 보이는데.. (비교가능한것까지만이라도 해보자는 오히려 제 입장인듯 싶은데..) liftthrasiir님의 말씀은 무의미하므로 비교정리 자체를 할필요없다이지, 비교가능한것까지만이라도 해보자라는 말씀은 아니지 싶은데요..
죄송하지만 제 별명은 lifthrasiir입니다. -_-; (아무도 한 번 듣고서는 제대로 못 쓰는…)
비슷한 언어들끼리 분명 비교가 가능하고, 좀 무리를 해서 어느 정도까지 비교하는 테이블을 만들 수는 있습니다. PLEAC나 그런 것들이 그런 노력의 산물이고요. 하지만 무리를 하는 건 개인적으로는 그다지 언어의 이해에 도움은 되지 않는 것 같고(예를 들어 PLEAC 같은 경우 Perl cookbook에 치중해 있기 때문에 펄에서 지원하지 않는 패러다임은 거의 없다시피하다는 문제가 있습니다), 비슷한 언어들이라면 굳이 비교 테이블을 볼 필요 없이 몸으로 부딪혀 보는 것만으로도 충분히 되지 않을까 하는 거에요. 이미 있는 비교 정리한 것들의 가치가 없다는 뜻은 아닙니다.
말이 나온 김에 그 별명의 기원은 뭐죠? ^_^
지금까지 이야기로 보건데 어쨌든 착한아이님은 비교정리 작업을 하고 싶으신 것 같고, 다른 분들은 자신에게 가치를 못 느끼는 것 같습니다. 현재까지 programmig 언어를 만들고 계신 분이 착한아이님에게 정리된 자료를 넘겨주는 것은 어떨까요?
앞으로도 계속 자료를 넘겨주는 것은 나중 문제이고 말입니다.
착한아이님과 거기에 동조하시는 분들이 정리한 비교결과에 대하여 언어제작자들이 인정하느냐는 또한 별도의 문제입니다.
“뭐, 난 그것에 동의하지 못하니까 그건 흑역사야!!!” 라고 해도 상관없지 않나 싶습니다.
아직 세상 빛도 보지 못한 자기가 기르고 있는 아이에게 그런 꼬인 역사를 주시기 싫다면 어쩔 수 없습니다만… 하여간 착한아이님의 욕구를 채워주기 위해 다른 분들이 조금은 도와줘도 괜찮지 않을까 싶습니다.
너무 스펙이 자주 바뀝니다. ;)
여러 말들이 많은데 그냥 착한아이 님께서 직접 적당한 분량의 샘플을 작성하셔서 보여주시면 다들 입을 다물 것 같습니다;;
물론 사람들이 그 결과에 관심을 가지느냐는 또 다른 얘기고요. (…ㄹ)
저는 얼마나 계신지 그냥 의향을 여쭌것이지, 설득하려고 시작한 글은 아닙니다. 제 의견의 핵심은 비교기록에 있음에도, “단순”비교기록라는 특수한 경우를 일반 비교기록로 일반화하시려는것 같아, 확인차 말이 길어졌을 뿐입니다. 왜냐하면 시작부터 “단순”이라는 명시하에 무의미를 말씀하신것은 아니었고, 객관적으로 비교기록에 관해서 평가해보기 보다는, 어떻게든 반대입장을 유지하기 위해 특별한 경우의 단서를 뒤늦게 슬그머니 추가하시는 것 같아 조금 안타까왔습니다.. 저는 스스로를 “날로 먹으려는” 사람으로 생각하지는 않는데, 이곳에서는 제 의견이 그런 시각으로 보여지는 (팔이 안으로 굽는듯한) 분위기인듯 싶어서, 앞으론 그런 시각으로 보여지지 않도록 좀 더 신중하게 의견을 내도록 하겠습니다..
굳이 그렇게 신중해 질 필요있나요? 제가 보건데 이곳 분위기는 아직 싸움이 잘 나는 곳은 아닙니다.
이번 글타래가 글들이 진중해서 ‘날로 먹으려는’이라는 단어에 민감하게 반응하신 것 같은데 사실 친한 사이들끼리 흔히 쓰는 말 아닙니까?
아… 이럴때 아겔님의 짤방이 필요한데 말이죠. ^_^
반대입장을 유지하기 위해 다른 단서를 추가하거나 하진 않았습니다; 제가 처음 이야기했던 것은 제안하신 언어 비교 위키가 언어를 “이해”하기에는 너무 얕은 부분만 알려준다는 말이었고, “학습 비용을 줄인다고 생각하지 않는다”는 것도 같은 뜻으로 이야기한 것입니다. 어쨌든 해당 표 형식(제가 글을 읽을 당시에는 표라고 이해했습니다)으로 된 비교 내용으로는 겉핥기엔 좋을지 몰라도 그 언어 내에서의 해당 시멘틱이 어떤지에 대해서는 이해할 수 없고, 오히려 오해하기 쉽기 때문에, 결국은 제대로 학습하기까지 좋은 튜토리얼과 레퍼런스는 필수적이라는 것이죠. 결국 그렇다보면 그 언어 비교표가 있다고 해서 학습 비용이 줄어들진 않을 것이라고 생각한 것입니다. 오히려 튜토리얼과 레퍼런스 정도로 충분한 학습 방법에 그다지 필요 없는 절차가 껴서 비용이 늘어난다고 생각했습니다.
이건 제가 그렇게 생각했으며, 그저 반대입장 유지를 위해 이것저것 구차하게 다른 이유를 덧붙였다는 오해를 풀기 위해 썼을 뿐이지, 뭐 실제 학습 비용이 이러쿵 저러쿵 어쩌다 하는 얘기로 쓴 게 아니라는 거 아시죠?
표 형식(혹은 이해에 부족할 정도로 간략한)은 제가 전제한것이 아니라 홍민희님이 스스로 (암묵적으로) 전제하신 것입니다. 제가 전제하지 않은 것을 반대의견을 지지하기위해 (뒤늦게) 전제하시면 반대를 위한 반대로 비쳐질수 있습니다.
네 그래서 “제가 글을 읽을 당시에는 표라고 이해했습니다”라서 썼죠.
네.. 제 의견이 표 수준일거라는 단서를 언급한 적도 없었는데도 불구하고 말이죠..
아마도 어짜피 이 작업에 긍정적일 생각이 없으시기 때문에, 비교정리라는 것이 표수준에 불과할것이라 이해하셨던 것 같습니다..