Language Author Beard Pattern

Tags:

Language Author Beard Pattern

프로그래밍 언어와 턱수염의 상관관계;;;; 수염이 있어야 성공한단거죠. ㅋㅋ

링크를 보실분을 위해.. 일단 beard – 턱수염, mustache – 코밑 수염 입니다. 제 생각엔 어쨌든 수염 기른 것과 안기른 것으로 나누어야하는게 아닌가 싶어서 이 규칙에 맞는 수염 기른 사람을 정리하자면,

– BrianKernighan and DennisRitchie: C
– BjarneStroustrup: C++
– JamesGosling: Java
– LarryWall: Perl
– GuidoVanRossum: Python
– YukihiroMatsumoto: Ruby

반례도 있습니다.

– GraceHopper: Cobol
– JohnBackus: Fortran
– DrCodd E. F.: SQL
– RasmusLerdorf: PHP

이 글을 쓰면서 느낀점은, 1) 뭐 이런 걸 다 패턴으로 만드는 센스가 ㅎㅎ, 2) 각 언어를 만든 사람의 이름을 저도 참 많이도 아는군요.. 위의 총 10명중 6명을 알고 있네요;;

Matz 아저씨는 c2.com 글을 보고 수염기른 사진을 보내줬다는군요. 으허허.
http://redhanded.hobix.com/cult/santaMatz.html

Comments

10 responses to “Language Author Beard Pattern”

  1. abraxsus Avatar

    음냐..
    루비에 빠져버렸다-_-;;
    elegant한걸.. 클래스도 객체라니..흥미진진한걸..
    이정도는 되야 OOP라 불러주지.. smalltalk의 우아함이 배어나온다.
    앞으로 한참은 들여다볼것같구나.. 책을 지를뻔했으나..재고가 없다네..컹-_-
    OOP가 interpreter에 더 어울리는것 같다는 생각이 드네.
    scripting과 OOP가 잘 어울리는구나 싶다..ㅎㅎ

  2. 공성식 Avatar
    공성식

    abraxsus님, 루비를 좋아하게 되셨다니 저도 기쁘네요.
    말씀하신 대로 루비는 스몰토크로부터 아주 많은 영향을 받았습니다.
    다만 스몰토크가 골수 객체지향인 반면, 루비는 실용적 객체지향의 노선을 밟았다고나 할까요?
    일례로, 가장 흔하게 사용되는 Integer(Fixnum)는 객체이면서도 reference 타입이 아닌 value 타입으로 구현했습니다.

    ##클래스도 객체라니..흥미진진한걸..

    루비에 입문하게 되면 우선적으로 Object is a class and Class is an object. 라는 말을 이해해야만 합니다.
    클래스는 특이한 형태의 객체라는 사실에 처음에는 약간 혼란스러워집니다만 나중에는 그런 사실들이 아주 자연스러워지죠.

    또한 클래스가 아닌 특정 객체에 메소드를 추가할 수 있다는 사실도 특이합니다.
    이점은 활용하기에 따라 JavaScript처럼 Prototype-based OOP처럼 쓰일 수도 있습니다.

    ##scripting과 OOP가 잘 어울리는구나 싶다..

    그렇습니다. 사실 루비는 OOP가 주는 잇점 이상의 것을 줄 수 있습니다.
    정적 타입 언어에서는 불가능한 것들이 루비에서는 가능하죠.
    우선 duck typing이 그렇습니다.
    또한 mixin도 자바의 interface 이상의 기능을 발휘하구요.
    최근 들어 더욱 각광을 받고 있는 메타프로그래밍도 동적 언어이기 때문에 가능합니다.

    ##책을 지를뻔했으나..재고가 없다네..

    책은 당분간은 굳이 사실 필요가 없습니다.
    영어로 돼 있다는 점이 약간 불편하지만 아주 훌륭한 책이 무료로 공개돼 있습니다.
    PickAxe1을 다운받아서 보시기 바랍니다.(PickAxe2는 유료)
    저는 대략 열 권 정도의 루비 관련 책을 가지고 있습니다만 PickAxe가 역시 가장 훌륭하더라구요.
    기타 온라인 자료도 많으니 참고하시기 바랍니다.

    Happy rubying!!!

  3. abraxsus Avatar

    ^^; 감사합니다. 클래스가 아닌 객체에 메소드를 추가할수 있다는것은 어떤건가요?
    간단한 예를 볼수 있을런지요..^^;
    그 PickAxe1을 보고 있는데, 이거 전체가 다 있는거 맞나요? extracted from…이라고
    되어있어서요.. 그래도 역시 좋은 책인것같습니다.

  4. 공성식 Avatar
    공성식

    간단한 예를 하나 보여드리겠습니다.

    class C
    def f
    “C.f”
    end
    end

    o1 = C.new
    o2 = C.new

    def o2.f
    “o2.f”
    end

    puts o1.f #=> C.f
    puts o2.f #=> o2.f

    메소드가 클래스가 아닌 객체에 소속될 수 있다는 점은 왠지 객체지향과 어긋나는 것 같죠?
    내부적으로는 메소드가 객체에 직접 붙어있다기보다는 o2라는 객체의 singleton class 가 하나 생성되고 이 클래스에 메소드가 만들어집니다.
    그러므로 엄밀히는 o2와 C 사이에 새로운 클래스가 하나 더 개입되는 것이죠.
    그렇지만 이건 어디까지나 내부적 구현의 문제이고 겉보기엔 o2는 C의 객체입니다.

    저는 처음에 이게 객체지향 원리를 깨는 것이라고 생각했었습니다.
    그런데 오히려 이게 더 현실에 가까운 것 같아요.
    예를 들어 “사람”이라는 클래스가 있고 그 객체로서의 실제 사람들이 있잖아요.
    그런데 태어날 때는 비슷한 기능을 가지고 태어나지만 살면서 각각 다른 기능들을 터득해 가죠.
    결국 객체가 자신만의 메소드를 갖게 되는 것입니다.

    자바스크립트는 이런 원리를 아주 본격적으로 적용한 언어입니다.
    어떤 객체를 만들 때 특별히 클래스를 지정하지 않고(사실 클래스란 개념도 없죠),
    일반 오브젝트로 만든 후에 데이터나 메소드를 추가합니다(이걸 슬롯이라고 합니다만).
    다만 비슷한 오브젝트들을 묶어서 관리하기 위해 프로토타입 객체를 지정합니다.
    즉, 모든 객체가 각자 모든 것을 다 알아서 하려면 귀찮으니까(자원 낭비) 공통적인 responsibility는 대표자(프로토타입)를 지정해 놓고 그 대표자에게 위임하는 것이죠.

    비교하자면 다음과 같습니다.

    class-based OOP: 붕어빵 틀을 만든 후에 똑같은 모양의 붕어빵을 찍어낸다.
    prototype-based OOP: 밀가루 반죽만 각자에게 나눠 준 후 그걸로 붕어빵 모양도 만들고, 호빵 모양도 만든다. 즉 객체가 생성될 때 타입이 결정되는 것이 아니라 생성 후에 어떤 과정을 거치는가에 따라 역할이 결정된다.

    그럼 루비의 이런 특성이 어떤 점에서 유용할가요?
    제가 생각해 볼 수 있는 것은 GUI에서의 이벤트 핸들링이 아닐까 생각합니다.
    예를 들어서 어떤 폼 위에 버튼이 있고 그 버튼을 누르면 어떤 메시지를 보여준다고 해보죠.
    보통 이런 경우 두 가지 중의 하나를 사용합니다.
    1. Inheritance Model
    일반 버튼으로부터 상속을 받아 새로운 버튼 클래스를 만들고 그 클래스에 클릭 메소드를 정의합니다.
    2. Delegation Model
    그냥 일반 버튼을 폼에 올려놓고 폼에 메소드를 만들어 준 후 이 메소드 포인터를 버튼에게 데이터로 넘겨줍니다.

    만약 루비처럼 객체가 자신만의 메소드를 정의할 수 있다면 위와 같은 경우에 새로운 버튼 클래스를 정의할 필요도 없고 폼에 메소드를 넣어 delegate할 필요도 없이 그냥 버튼 객체에 메소드를 만들면 됩니다.

    뭐 이처럼 거창한 예가 아니더라도, 루비의 클래스는 모두 객체라는 사실만 상기한다면 객체에 직접 수정을 가하는 것은, 루비에서는 예외가 아닌 일반적인 현상입니다.
    모든 클래스는 Class라는 클래스의 객체이거든요.
    만약 어떤 클래스에 클래스 메소드를 추가한다면 이것은 사실상 객체에 메소드를 추가하는 것과 같거든요.
    다만, 클래스의 경우엔 객체의 경우와 구분해서 Singleton-class를 Meta-class라고도 합니다.
    이는 스몰토크에서의 메타클래스와 동일한 의미를 갖습니다.

    이야기가 장황해졌네요.
    혹시 더 설명이 필요한 부분이 있으면 말씀해 주세요.

    아마 말씀하신 PickAxe1이 제가 말씀드린 책 맞을 겁니다.
    전체가 다 공개돼 있거든요.
    목차부터 부록까지 다 있나만 확인해 보세요…ㅎㅎ

  5. 만박 Avatar

    (민구님 블로그에서 이상한 댓글 남겨서 죄송하지만)
    공성식님, 혹시 대삼모의 공성식님이신지요?
    저는 대삼모의 박수만입니다. 메일 하나 주세요.
    sumanpark@gmail.com http://www.sumanpark.com

  6. MKSeo Avatar
    MKSeo

    하이 ㅋㅋㅋ 클래스가 객체인 것은 자바도 그렇습니다.
    Class 란 클래스가 있죠.
    Integer i = new Integer(0);
    i.getClass() // returns an instance of Class

    RDF의 Class라는 것도 또 클래스의 인스턴스죠.
    그래서 최상위 클래스를 RDF에선 메타 클래스라하죠……

    글 남겨주셔서 다들 감사 ^^

  7. 공성식 Avatar
    공성식

    자바나 C#, 델파이 등에서 클래스를 객체라고 할 때는 그 클래스의 TypeInfo로서의 객체를 의미하는 것이지 그 클래스 자체가 객체라고 보긴 어려울 것 같습니다.
    사실 이건 매우 미묘한 차이라 자세히 설명하기도 좀 어렵습니다만…
    자바에선, Integer 가 Class 라는 클래스에 의해 만들어진 객체라기보다는 Integer라는 클래스가 존재하고 이것의 타입정보를 표현해 주는 객체가 있는데 그것의 클래스는 Class다 라는 좀 선문답식의 표현밖에는…

    다음을 참고하시기 바랍니다.
    http://onestepback.org/articles/depinj/page046.html

    이에 관해서는 더 깊이 들어가면 머리가 돌 것 같아서…
    사실 루비도 코어쪽 구현은 애매모호하게 돼 있어서 모순 없이 설명이 좀 곤란한 측면이 있습니다.
    Object와 Class 중 어떤 게 먼저 존재해야 하는가의 질문은 달걀과 닭의 문제와 동일하거든요.

  8. MKSeo Avatar
    MKSeo

    흠 그렇군요. 그런데 TypeInfo 로서의 Class가 존재하는 자바와 Class의 인스턴스로서 Foo클래스가 존재하는 루비간의 차이가 어떤 차이를 불러올까요?

    루비에서 클래스가 쉽게 수정가능하다는 것이 그런 기본 아이디어(?)의 차이점에서 유래한다고 보시나요? 혹은 단지 루비의 경우엔 완전한 dynamic typing 을 지원하기 때문일까요. 전 후자 같아요.

  9. 공성식 Avatar
    공성식

    ##TypeInfo 로서의 Class가 존재하는 자바와 Class의 인스턴스로서 Foo클래스가 존재하는 루비간의 차이가 어떤 차이를 불러올까요?

    글쎄요, 좀 어렵고 방대한 문제네요.
    제 생각에 말씀하신 위의 *차이*가 어떤 다른 큰 차이를 불어온다기보다는 워낙에 근원적인 차이가 있어서 그 결과적으로 위의 *차이*가 생긴 것이 아닌가 생각합니다.
    즉 위에서 제기한 차이는 근원적이라기보다는 그냥 하나의 많은 다른 점 중 하나인 것이죠.
    가장 근원적인 문제는 정적인 언어와 동적인 언어라는 것이겠죠.
    코드라는 것을 일단 로드되고 나면 변경할 수 없는 것으로 취급하느냐, 아니면 코드도 데이터의 일종이어서 런타임시 언제든 수정이 가능한 것으로 취급하느냐의 문제죠.

    사실 dynamic typing이라고 말할 땐 좀 범위가 좁아집니다.
    (일례로, 닷넷의 다음 버전에선 type inference라는 게 추가 되어 dynamic typing과 비슷한 효과를 낼 것도 같아요.)
    그래서 저는 아예 dynamic language라는 표현을 쓰고 싶습니다.
    Lisp로부터 시작된 이런 dynamic language의 경향은 확실히 C나 자바 등 정적 언어와는 다른 접근방식을 취하고 있습니다.
    이러한 근원적 차이 때문에 클래스를 순수한 객체로 취급하느냐 마느냐의 차이도 발생하는 것이죠.

    음… 저는 랭귀지 자체의 전문가는 아니라서…
    그냥 루비가 좋아서 (Just for Fun) 하는 것이기 때문에
    여기까지밖에 설명이 안 되네요.

    민구님 블로그 덕분에 재밌는 얘기 많이 나눌 수 있어서 감사합니다.

  10. abraxsus Avatar

    전 자바Class와 루비Class의 차이는 컴파일러vs인터프리터의 차이라고 봅니다. 자바Class와 루비Class는 두 언어가 static/dynamic하다는것을 극적으로 보여주는 예라고 생각되네요. 이 차이는 곧 컴파일러/인터프리터의 차이인거죠. 바로 공성식님이 말씀하시는 dynamic language라는거죠. 인터프리터가 제공하는 mahcine으로부터의 자유죠. OOP라는 dynamic한 패러다임은 역시 그 dynamic함을 제대로 보여줄수 있는 즉 runtime의 자유가 충분한 인터프리터에게 적격인듯싶습니다. C++이나 자바가 OOP를 억지로 static한 컴파일러위에서 구현하려고 하다보니 무리한 typing이 나오고, 자바Class같은 보조적인 기능들이 포함되는거겠죠. 루비에서 클래스명이 객체에 붙어있는 전역상수에 불과하다는것등은 컴파일러로는 제대로 구현하기 어려운 철학이죠. C++이나 자바에서 클래스명이 심볼인것에 비교해본다면 근본적인 차이가 있죠. performance와의 타협을 한 결과겠죠.

    따라서 TypeInfo 로서의 Class가 존재하는 자바와 Class의 인스턴스로서 Foo클래스가 존재하는 루비간의 차이가 어떤 차이를 불러올까…가 아니라 반대로 자바와 루비라는 철학의 차이가 어쩔수 없이 TypeInfo로서의 자바Class와 인스턴스로서의 루비Class로 귀결되어진다고 생각되네요..

    루비에서 클래스의 변형이 자유롭다는것 역시 인터프리터에서 가능한 상황으로, 클래스는 하나의 객체에 불과하기에 가능한 상황. 따라서 이런 모든 상황이 OOP에 충실하다는 루비의 철학에서 기원한다고 생각되네요. 물론 dynamic typing이 이 모든 상황의 키를 쥐고있기는 하지만 엄밀히 dynamic typing은 루비철학에서,(혹은 OOP에서) 당연히 가지게될 특성이라고 생각됩니다. C++이나 자바에서 type과 object의 실제type의 차이로 인한 골치아픈 상황들을 생각해본다면 말이죠. OOP에서 클래스는 클래스일뿐 type과는 다르다는것을 보여준다고 할수 있겠읍니다. 따라서 제 생각에는 OOP에선 무타입이 당연히 따라올 특성이라고 보여집니다.

    p.s. Class와 Object중 뭐가 먼저 존재할까.. 저도 이게 궁금했읍니다. 이건 어쩔수 없이 루비 임플멘테이션이 static하게 시작점을 제공해야할것 같은데요. 실제로 그렇게 되어있겠죠? 아님 방법이 없을것같아서요..

Leave a Reply

Your email address will not be published. Required fields are marked *