근 일주일 동안, 새로 만들어야 하는 도구 – 라 고는 해도 서버 바이너리 3개 – 의 proof-of-concept 구현을 했다. 일단 기억을 되살리는 의미로 C#으로 짜(려고 해)ㅆ다.
예전 기억 – 아직 학생이던 2000년대 초반의 일 – 으로는 C#은 꽤나 편안한 언어였다. 그 최신 버전(.net framework 4.0)으로 프로그래밍하는데 생각만큼 편하지 않더라. 이건 왤까? 일단 내가 생각하는 원인 두 가지.
우선 C++이 지난 몇 년간 매우 발전했다. 특히 요즘 추가된 C++ 0x의 closure — 그러니까 lambda 문법 — 와 auto 같은 몇 가지 syntactic sugar 가 매일매일의 작업에 매우 도움이 됐다. Closure는 프로그래밍하는 “방식”을 상당히 바꿔 놓는다. 직업이 직업인지라, 비동기적으로 처리하는 코드를 많이 짜게 되는데, closure가 있는 언어는 이런 작업을 “그런대로 직관적으로” 작성할 수 있다. auto 도 C++ template의 iterator처럼 긴 타입 선언을 매우 간략히 만들어주기에, 귀찮은 boiler-plate code를 줄여준다. 그런 점이 “일상적인 편리함”엔 큰 부분이다.
둘째로, 훨씬 더 고수준 언어인 python을 더 자주 쓰게 되었다는 것. 매일매일의 잡일이나 속도가 최우선이 아닌 부분은 거의 python으로 작성하고 있다. 복수 언어를 위한 코드 생성기나, 특정 바이너리를 서비스처럼 바꿔주는 기능이나 소스 저장소에 접근해서 뭔가 하는 작업 등등을 전부 python으로 짰다. 그리고 C++로 짜야 하는 것도, 프로토타이핑 수준에선 상당 부분 python을 쓰고 있다.
그러다 보니 타입 안정성 같이 정적으로 뭔가를 제약하는 C#이 좀 답답하게 느껴진다. 아예 C++처럼 unsafe한 것들도 “할 수 있는 범위 내에서” 하는 것도 아니다 보니, C#으로 토해내는 코드가 생각의 속도를 따라가지 못한다는 느낌. 차라리 duck typing으로 후딱 완성하고 테스트를 더 하는 쪽이 취향에 맞다.
이런 부분 때문에 중간부터는(…) python으로 후딱 짜고, C#으로 옮기면서 정리하는 작업을 했다(…). 그래도 예전에 불만이던 부분 – 그러니까 generic container 류가 없는 것 – 은 이미 해결되었고, 네트워크 코드가 나름대로 간결하게 나오는 것도 만족스럽기도 해서 일단 이번 작업은 최대한 C#으로 하기로 했다. 그렇게 하면서 좀 더 익숙해지면 나아지려나?
제가 잘 몰라서 그런지는 모르겠는데 덕타이핑이라면 c#의 dynamic으로도 처리할 수 있지 않나요?
안 될꺼라고 생각했던 IEnumerable도 된다는걸로 봐선 덕타이핑 처리될 듯. 확실히 내가 공부가 부족하긴 하군.
그렇지만 “할 수 있다”와 “편하다” 사이엔 간극이 있지. 저걸로 덕타이핑을 “구현해 내는 일”을 하는 건 자연스럽게 덕타이핑이 “되는 것”이랑은 좀 다른거 같다.
python에서 self.??? = None 이면 만들어질 property를 메서드 오버라이드해가면서 만드는 건 그다지 “편한 일”은 아닐 듯…
+ 이메일 주소는 “공개되지 않는다”라고 써 놨는데 — 그러니까 기계(스팸 필터)만 보는데 — comment 달 때마다 가짜인 주소로 바꿔서 스팸 처리되게 하는 이유는 무엇?;;;
이와 비슷한 의미로 자바도 요즘은 엔터프라이즈 업계에서는 장래성이 없는 언어라는 말을 심심찮게 듣게 되더군요. 처음 자바가 나올 때는 C++보다 간결하고 사용하기 쉽다는 것이 장점이었는데 자꾸 버전이 올라가면서 복잡하게 되어버려서 이제는 숙련된 개발자나 제대로 사용할 수 있는 언어가 되어서 그렇다고 하더군요. C#도 비슷한 것 같습니다.
C#도 너무 많은 기능이 있어서 아마 최신 버전인 C# 4.0까지의 기능을 능숙하게 사용할 수 있는 사람은 많지 않으리라 생각합니다(호환성 때문에 최신 버전을 사용하지 못해서 그럴 수도 있겠지만요).
더 오래된 C++은 좀 더 심했죠; 그래도 이번 드래프트는 “사용성”에도 적당한 방점을 찍어준 점에서 나아진 거지만…
Java, C#은 정말 이젠 *C++에 필적하는* 복잡성을 향해 나가고 있는 것 같네요. 그래도 두 언어 모두 (C#의 경우 프레임워크 자체) VM 자체가 자산이고, 이 위에서 돌아갈 “좀 더 간결한 언어”가 계속 나오니까 앞으로 한 세대는 계속 그 자리에 있을 것 같긴 하네요.
저도 요새 이와 비슷한 현상을 느끼고 있는데, 그나마 자바는 eclipse 라는 걸출한 툴이 많이 도와줘서 그나마 좀 쉬운거 같아요. 특히 저장만 하면 기본적인 문법 에러나 exception 이 필요한 곳, import 같은 것을 대부분 1~2번 클릭으로 해결해주고, 멋진 리팩토링 기능 때문에 정말 프로그래밍하는 즐거움을 주는듯 :)
그래서 sub language 를 C# 에서 Java 로 옮겨타는 중입니다…. 하지만 생각해보니 언젠가부터 sub language 는 C# 이 아니라 파이썬이었던듯…;;;
C#도 툴 자체는 훌륭하죠. Integration 된 수준만 보면 (편집/빌드/테스트/성능테스트/배포) 아직은 VS 쪽이 좀 더 좋은 것 같습니다(사실 실행 속도가…).
아무래도 (적어도 한 동안은) 편집->실행에 1초 이상 걸리는 언어는 쓰기 힘들듯합니다(…).
음.. auto나 closure는 C# 2.0 부터 같은 기능(var이나 anonymous function) 이 있지않나요? C++이 나아지긴 했지만, 아직 C# 만큼은 아닌거 같긴한데.
물론 언어의 관용어구를 모르니까 답답하긴 하겠지만, 언제 한 번 저도 C#으로 뭔가 시도해봐야겠네요.
C++이 C#보다 쉽다란게 아니라, C#이 예전 기억에는 C++보다 더 간편하게 쓸 수 있는 언어였는데 안 그렇다 정도?
예전에 delegate 봤을 때는 이거 참 짜기 편하네라고 생각했는데, 지금은 그게 당연한거라 없으면 “이뭥미” 란 느낌이라서?
예전 기억의 C#은 python에 준하게 편했던 거 같은데, 실상은 편의성 면에서 python보다 C++에 가깝다라고 느꼈다는거지…