자신이 가장 좋아하는 언어, 가장 싫어하는 언어

2008-06-09 12:02:24

요즘 심한 정전이 이어지고 있어서, 억지로(?) 떡밥 하나를 던집니다. 별거 아닌데요. 각자 가장 좋아하는, 자신의 이상에 가까운 언어가 있을 거라고 생각합니다. 꼭 이상에 들어맞지는 않더라도요. 그런 언어에 대해서는 “사랑한다”는 표현이 가능하겠죠. 그래서 그 언어의 좋은 점을 꼽으라면 말이 너무 많아집니다.

그렇다면 자신이 가장 좋아하는 언어의 나쁜 점, 싫어하는 점을 얘기해봤으면 합니다. 예를 들어 저는 Io 언어를 가장 좋아하는데, 모든 메서드들이 부수 효과(side effect)를 가지고, 객체들이 상태(state)를 가지게 디자인되어 있다는 점, 함수형 프로그래밍을 제대로 지원하지 않는 점, 매크로 작성이 귀찮은 것 등등이 싫습니다.

반대로 각자 가장 싫어하는 언어—가장은 아니더라도 꽤나 싫어하는 언어가 있을 거라고 봅니다. 그럼 그런 언어에서 그래도 좋은 점이 무엇이 있는지에 대해서도 얘기해봅시다. 이를테면, 저는 Java를 싫어하는데, 때로는 언어가 지니고 있는 그 제약이 크게 와닿기도 합니다.

월척은 아니라도, 어느 정도 반응은 있길 기대해봅니다. 흐흐;

홍민희 님이 2008-06-09 12:03:01에 고쳤습니다.

트랙백 주소: http://langdev.net/post/trackback/79

semmal 2008-06-09 12:37:18

좋아하는 언어는 Haskell : 그저 보기만해도 코드가 너무나도 아름답죠. 싫어하는 언어는 Basic : 쉽다고 하지만 실제로는 사람들을 바보로 만드는 언어라고 생각해요.
아겔-_- 2008-06-09 17:43:09
부끄러움을 이겨내고, 무식한 편견을 여과없이 드러내보면…
- scheme : 심플. 아름다울 정도의 정제됨. 투명함. 그러면서도 실용적인 확장의 여지를 열어둬서 무한한 가능성. 하지만 은근히 외면 받는 현실
- commonlisp : 덕지덕지. 하지만 묘하게 편리;;; universe의 또 다른 표현;;;
- haskell : 멋진 코드. 의도를 나타낼 수 있는 코드. 거기에 멋진 컴파일러(ghc) :-)
- 자바 : 은근히 넓은 커버리지. 한때는 oop계의 희망. 이제는 저주.
- c : 아무짝에도 못쓸거 같은데 은근히 평균치를 하게 만드는. 하지만 강제노역하는 기분이 드는;;; 그래도 사랑스러운. 이제는 까먹어가는;;;
- c++ : c의 superset이라고도 하지만, c의 멋진 부분을 상당부분 까먹은거 같은 느낌.(심플함, 직교성, 분할작업의 미학…) 가끔은 오만함으로의 유혹. 멋진 API(Qt등…)을 만나야 사는게 편하다능;;;
- python : 배터리포함! ‘import this’… 가끔 제어문이 정말 몇개 없어서 코드가 단조로워지기도;;; (그건 제잘못;;;)
- ruby : 아기자기하고 은근히 생각한거 표현하기 편함. 기존문법에 자기 api을 연동하거나(do…end등)하는 부분도 편리. 실행시간magic이 많아서 가끔 설명하거나 어디서 튀어나온건지 어리둥절하게 만드는 우울함도;;;
- perl : ;;;… 아.나.키… 종종 cpan에서 사용하고 싶은 모듈을 고를때 방대함에 놀라고, 괜찮은 모듈을 선택해서 사용할때 그 강력함에 놀라고, 작성한 스크립트를 한달뒤 봤을때 그 난감함에 심장이 멎는다;;;
- erlang : 확고한 목표와 구현. 그리고 class가 없어도 인생은 충분히 아름답다는 자기자신을 통한 증명;;;
- Io : 기억하시나요?;;; 지금 생각해보면 헤어진 옛날 여자친구처럼 어차피 걔는 뭘해도 안될애였어’;;;라는 생각이 드네요;;; 그땐 그렇게 좋아했었는데. 농담이구, 잘 정리된, 통합된 개념들을 통해서 이렇게도 확장을 해나가고 변용해나갈수있다는걸 재밌게 느꼈던거 같아요.
- javascript : 안타까움? dom에 묶인 슬픔;;; standalone distribution으로 잘 다듬어도 꽤 재밌을거 같은 언어.
- factor : 가끔 changelog 뉴스피드에 올라오는거 보면 정말 열심히 하는구나라는 생각이 절로;;; 나름 실용적이면서도 코딩하고, 개발도구 안에서 블럭 쌓아올리는 재미가 쏠쏠. 블럭의 암수 구분이 어려우면 참 피곤하긴 하지만;;;
특별히 좋아하거나 싫어하는 언어는 별로 없네요. 굳이 니맘대로 쓰라면 스킴을 선택할거 같고, 굳이 남이 강요한다면 c++, perl, cl만은 피할거 같애요;;;

오랬만에 와봤는데 정말 정전이 심하군요;
김우승 2008-06-10 17:28:47

사실 이건 뭐 비교의 대상은 안되겠습니다만… C vs. C++ 의 느낌이 Scheme vs. Common Lisp 정도인가요? Scheme은 Lisp에서 나왔습니다만 청출어람?

마지막에 피하고 싶은 것으로 cl을 쓰셨는데 Common Lisp이 맞는지요.?
아겔-_- 2008-06-10 17:41:44

말씀하신대로 청출어람일까요^^;

그냥 제 개인적인 선호도는 스킴이 좋네요. 제 취향이 newlisp(http://www.newlisp.org/)이나 librep(http://librep.sourceforge.net/)같은 아기자기한 리습을 좋아하는것 같아요. ^^;

예, cl은 커먼리습.

비슷하달까요, 어떻다할까요^^; 저는 cl을 공부하면서 재미있던것도, 정말 실용적이고 편리하다고 느끼던 부분(언어적인 부분은 물론이고, asdf나 slime 같은것들까지 몽땅 포함해서)도 많은데요. 굳이 스킴을 멋진 개발환경도 없고 그렇게 통일된 방향을 제시하는것도 없는데 좋아하는건 어디까지나 개인적인 취향인거 같애요. ^^; 그냥 그래도 꼽아보라면 커먼리습도 그런 부분이 많지만, 스킴은 조금 짜다보면 가끔 디자인의 묘(!)를 느낀적이 있어서 그런지도 모르겠네요.

c vs. c++은 글쎄요… 저따위가 어떻게 뭐라 하겠습니까. ^^; 그냥 제가 감당하기에 c++은 너무 버겁더라구요.
디토 2008-06-09 22:52:36

제가 다룰 줄 아는 녀석들만 나열하겠어요.

가장 좋아하는 언어는 파이썬입니다. 단순 명료한 문법 때문에 좋아해요. 또 웬만한 모듈은 이미 포함하고 있어서 참 편합니다. 다만 API에 일관성이 조금 부족한 것은 단점이라고 하겠습니다. Python 3000은 어떨지? :)

그 다음으로는 자바스크립트입니다. 아무래도 제가 C 스타일 문법 (좀 더 거슬러 올라가자면 알골 계열)을 좋아해서 그런 것 같아요. 스크립팅 언어로는 제격이고, 프로토타입 기반 객체 시스템도 꽤 편리합니다.

C는 단순하다고 할 수는 없지만 많은 부분을 직접 조종할 수 있는 힘을 넘겨주는 게 가장 큰 장점인 듯 합니다. 이 힘을 잘 쓸 지 어떨지는 언어 사용자의 책임입니다. 으흐흐…

PHP는 가장 싫어하지만 도저히 애착을 버릴 수가 없군요. PHP 5에서 괜히 어설픈 진보를 해서 오히려 더 복잡해졌어요. PHP는 스크립팅 언어이기도 하지만 하나의 웹 프레임워크로도 볼 수 있을텐데, 이 쪽에 좀 더 무게를 실어 강력한 기능을 제공하면 좋겠어요. PHP가 가진 장점은 쉽고 간편한 것이라 생각합니다. 이건 동시에 단점이기도 한 것 같네요. 할 말이 엄청나게 많지만 생략!

어쨌든, 마음에 드는 언어는 없는데 새로운 언어를 만들자니 너무 오랜 세월이 걸릴 것 같고, 능력도 없고… 참 고민입니다.
까막 2008-06-10 01:56:17

가장 좋아하는 언어는 C++입니다. 이유는 돈을 버는 도구라서.. (농담입니다.) STL/Boost을 만나기 전의 C++과 만난 후의 C++의 괴리감은 잊을 수 없는 추억입니다. C++을 좋아하는 이유는 “모국어가 가장 편한 이유”와 같다고 생각합니다. 가장 오래 써왔고, 가장 익숙하며, 제 능력하에서 가장 강력하기 때문이지요. 다중상속이 주는 매력도 빼놓을 수 없습니다. 하하. 디토님이 언어 사용자의 책임을 C에서 이야기하셨는데, 전 C++에서 이야기하고 싶군요. :)

파이썬과 루비 역시 좋아하는 언어입니다. 파이썬의 간결한 문법은 언급하지 않아도 매력적이죠. 루비는 될거 같다라고 생각되는 표현이 되는 것이 참 마음에 들었습니다. 파이썬과 루비의 라이브러리도 마음에 들지요. 다만… STL로 자료를 다루다가 두 언어로 다룰때는 난감할때도 많습니다. 후… (물론 반대의 상황도 많습니다. OTL)

자료를 다루는 상황을 이야기하니 SQL도 떠오르네요. Relational Algebra에 기반한 데이터 다루기는 언제 해도 즐거운 작업. :)

싫어하는 언어는 자바와 펄입니다. 자바는 될듯 안될듯 은근히 불편한 그 꺼림칙함이 불편합니다. 하지만, eclipse와 jdbc driver라는 놓칠수 없는 메리트때문에 “가까이하기엔 너무 불편한 당신” 이랄까요. 펄은 간단합니다. 제가 다뤄본 언어 중 유지보수가 가장 어려운 언어… 대학교 1학년때 크게 데이고 나서는 쳐다보지도 않습니다. :( 대안은 많으니까요.
홍민희 2008-06-10 09:23:01

아; 좋아하는 언어의 싫어하는 점, 싫어하는 언어의 (그나마) 좋아하는 점을 얘기하자고 했는데, 왠지 좀 다른 것들을 적어주신 듯해요.
아겔-_- 2008-06-10 10:16:42

쿨럭;;; 그런 방향의 일축을 담당해서 죄송스럽;;;
아겔-_- 2008-06-10 10:20:36

갑자기 지나가는 말이지만 이왕 말 나온김에 화제를 풍성하게 하기 위해서 ‘빠가 만드는 언어나 스타일’(이른바 brain-damage;;;)에 대해서 주절거려보는건 어떠세요?;;

전 자바의 ‘뭐든지 클래스로 하악하악…’이랑 모든걸 디자인의 탓으로 만드는 풍조가 가끔 그렇다고 생각해요. 자바 개발자분들이랑 플렉스, 액션스크립트 가끔 하다보면 함수객체를 이용해서 훨씬 편하고 재사용성도 높게 짤수있는데 이상한 자바스러운 코드를 만드시거나;;; for-for-for;;; 그럴때 우울;;;
semmal 2008-06-10 10:36:10

보통 ‘빠’는 분명 지식과 경험이 부족함에도 스스로를 똑똑하다고 생각하는 사람들에게서 생기는 것 같습니다. 문제는 ‘빠’들은 기술을 학문으로 보지않고, 종교처럼 본다는데에 있습니다. 이성적이고 논리적으로 진행되는 생각이 아니라, 독실한 믿음에 기반합니다. 언어마다 패러다임마다 사람마다 ‘빠’가 천차만별이라서 스타일이라는 것이 있는지는 잘모르겠습니다. 어쨌든 ‘빠’와 같이 일하는건 상당히 피곤할 때가 많다는걸 느낍니다. 고집도 센데다 다른 사람말을 들으려고 하지를 않으니… 하지만, 사실 저도 ‘빠’였고, 지금도 어쩌면 ‘빠’일지도 모르지요. 언제나 문제는 ‘빠’는 스스로 ‘빠’인지 모르기 때문에 ‘빠’인거니까요.

개인적인 경험으로는 언어로 C++와 Java를 쓰면서도 OO하면서 어떤 경우에도 캐스팅을 쓰면 안된다라고 하는 사람(OO빠)과 디자인 패턴과 UML이 만능이다라고 하는 사람(디자인패턴빠, UML빠)이 제일 싫었습니다. 이번 회사에서는, Doxygen만 달랑 만들어놓고 인수인계 다 했다고 떳떳하게 머리 꼿꼿이 세우는 사람(Doxygen빠)이 싫었군요.
아겔-_- 2008-06-10 11:12:28

저도 엄청 빠돌인데;;;
홍민희 2008-06-10 11:21:32

저는 왠지 FP빠가 아닌가 하는 생각이 들면서 반성하게 되네요;
디토 2008-06-10 15:09:10

혹시 아겔님이 쓰신 건 ‘빠’가 아니라 ‘빠가’ 아닐까요? ㅎㅎ…
아겔-_- 2008-06-10 15:28:25

비~밀~
홍민희 2008-06-10 15:31:31

아 그런 거였군요;
semmal 2008-06-10 15:37:00

그렇군요.
아겔-_- 2008-06-10 16:05:04

그랬구나…;;; (본인도 모르고있었;;;)
까막 2008-06-15 17:19:53

C++ 메타프로그래밍의 빠가 되어버린 저는… 직장 동료들을 괴롭히고 있습니다.

“이해해서 수정하란 말이닷~ 찰싹~ 찰싹~”

요즘은 자제하는 중입니다. ( ”)

특히 StateMachine과 Dispatcher를 난해해하더군요.. 으음;
wookay 2008-07-01 01:06:54
각 언어마다 장점이 있다고 생각해요
- ruby: 문자열 처리할 때, 메타 프로그래밍 할 때
- haskell : 함수형 프로그래밍 개념이 필요할 때
- erlang : 궁극의 패턴매칭을 맛보고 싶을 때, 분산 네트워크 개념 탑재할 때
- J : 매트릭스를 다룰 때
- scratch : 갖고 놀게 부족할 때
대체 언어는
- python : 루비로 안되는 것이 이걸로 있을 때
- java : 함수형 개념이 필요한 이유를 알고 싶을 때
- c++ : 회사에서 이걸 쓰고 있을 때
- squeak : 스크래치로 갖고 노는 것에서 객체지향을 신경 쓸 때
김광영/코에이 2008-07-04 01:00:07

ㅋㅋ 대체 언어 부분이 무척이나 공감이 가네요. java c++을 보고는 낄낄 웃었습니다.
홍민희 2008-07-04 09:23:01

회사에서 이걸 쓰고 있을 때

ㅋㅋㅋㅋㅋㅋㅋ
김광영/코에이 2008-07-04 01:08:21

많이 부족하지만 편승해서 올려봅니다.

제일 좋아하는 언어는 ruby입니다. 아직 언어를 많이 못 느끼긴 했지만, 이제까지 써본 몇몇 언어중에는 가장 “생각대로~ 되고” 라는 느낌이 드는 언어였습니다. 머랄까 특징적인걸 말해야하는데 그게 잘 안 됩니다. 정말 묘하게 이건 말이야. 하면 생각대로 나와요. 라고 표현을 하게 되네요. 간단한 것들만 짜봤지만, 프로토타이핑을 할 땐 여전히 루비가 사랑스럽습니다. 그리고 의외로 처음 보는 사람들이 보기에도 그리 어렵지 않다는게 좋습니다. C++은 노가다하면서도 가끔은 즐겁지만 커뮤니케이션하긴 어려울때가 많습니다. Ruby 쓰면서 싫은 점을 꼽자면 역시 수행시간이 묘하다는거를 꼽네요.

가장 싫어하는 언어는 최근에 겪은 경험때문인데 COBOL입니다. 모든게 전역이고 모듈간에 변수 전달 방법등이 아주 싫습니다. 역시나 제일 싫은 건 모든게 전역변수라는 점이 싫습니다. 위에 아겔님이 얘기하셨던 빠가만드는 언어에 전 코볼을 꼽고 싶습니다. 15만줄 정도되는 코볼 소스 포팅하면서 했던 노가다를 생각하면 아직도 토나옵니다. 그걸 하면서 좋은 점이라고는 덕분에 vim 공부를 열심히 해서 이제는 COBOL같은 수준의 언어는 전역적으로 생각해줄 수 있다? 정도 입니다. 문법 자체는 어찌보면 상당히 사람이 이해하기 좋은 구조라는 생각이 듭니디만.. 제가 본 코볼 코드를 짠 사람의 수준에 따라 달라지겠지만 (이게 첫 만남이라) 자료구조의 지원이 아쉬운 것이랑, 모든게 전역이라는 점이 아쉬웠습니다. (물론 적절한 표기법에 따라 달라지긴 하겠지만요..)

FP에 대한 가슴으로 느끼는 무언가가 없는 것이 아직까지 언어관에 많은 영향을 주는 것 같습니다. lisp, scheme, haskell, erlang, ml을 가슴으로 느낄 수 있을때 다시 생각해보면 잼있는 주제일꺼 같네요.
아겔-_- 2008-07-04 11:14:11

토 나오죠;;;

저도 루비로 뭔가 프로토타이핑하기가 정말 쉬운거 같아요. 테스트케이스 작성하기도 편하고 적당히 TC작성하고 그에 맞춰서 코딩하고 몇번 굴려보고 그러면 생각한거에 크게 다르지 않게 거의 생각을 직접적으로 코딩할수있다는 느낌이 강하죠. (사실 기본객체들의 api들이 ‘아마 이런건 이렇게 쓰면 될거야’스럽게 잘 만들어진게 많아서 그런것 같아요. 성능은 그닥이지만-,.-;;;)
세라비 2008-07-04 08:32:57
생각해보니, ‘싫어하는 언어’라고 말할 만한게 별로 없네요. PHP 정도? 어느 정도 많이 써보지 않은 이상은 진정한 장단점을 알기는 좀 힘들 것 같아요.

일단 좋아하는(자주 쓰는) 언어의 단점.

C++
- 표준화 되어있고 거기에 묶인 컴파일러 벤더들이 많아서 그런지, 언어의 발전이 다른 언어들에 비해서 느리다.
- reflection이 없어서 어쩔 수 없이 code generation을 해야하는 경우가…
- namespace를 넘어서는 operator resolving의 개념이라든가, 복잡한 implicit construction 등을 이해하려면 언어에 대한 상당한 지식이 필요함. 어렵지만 그래서 재미있는(?) 면도 있음.
Java
- C++을 쓰다가 본격적으로 Java를 쓰기 시작할 때 느꼈던 답답함은 역시 RAII의 부재. Java를 오래 쓰다보면 그다지 불편하진 않은데… 그래도 RAII가 없기 때문에 삽스러운 코드를 매번 써야한다. (A a = null; try { a = new A();… } catch { if (a != null) a.close(); a = null; };)
- operator overloading의 부재. 사실 사칙 연산(+,-,*,/,%) 및 비교 연산자(<,>,==) 정도로 제한해서 operator overloading 지원해주면 좋지 않았을까. BigNum 같은 걸 보면…안습. 그래도 만들/쓸 일은 별로 없으니, 역시 그다지 불편하지는 않다.
- GC에 의존하면 편하긴 하지만, 메모리를 효율적으로 쓰려면 어렵다. 일단 메모리 사용량부터가 예측하기 힘들고, 제어하기도 힘들다. 게다가 주어진 메모리는 다 쓰고 보자는 철학이 OS의 메모리 관리 철학이랑은 정면 배치 되기 때문에, VM instance 마다 메모리를 한정해줄 수 밖에 없다. 결국은 여러 VM을 써야한다든가 하는 상황에서 메모리를 비효율적으로 쓸 수 밖에 없다.
댓글 창이 너무 좁아서 여기까지.
홍민희 2008-07-04 09:26:11

확실히 C++의 RAII는 좋은 문화(컨벤션? 규칙? 뭐라 해야 할지)인 것 같습니다. Java에 연산자 재정의가 불가능해서 불편하다는 것은 저도 참 공감하는 부분입니다. 그나저나 댓글 창을 넓혀야겠군요;
착한아이 2008-07-16 09:54:34

이것은 제 주관적인 평가이고, 깊이있게 다룬 소감은 아닙니다. 주로 개발편의성, 벡터연산, 문자열처리, Plotting, 2D 이미지, 3D Modeling, UI 능력 정도로 생각해보았습니다.

[Digram형 Interpreter 언어] ====================================================

실행속도 느림.

[Simulink] ————————-

철학 : 함수위주의 다이어그램을 실행한다.

라이브러리 명칭 : mdl, 대소무구분

언어기반 : 자체표현

지원 : C언어

플랫폼 : Matlab과 동일

개발편의성 : 구성보다는 마우스 클릭질로 시간낭비가 발생함. 함수의 정체를 알기가 어려움. 디버깅 어려움. 화면이 복잡해짐.

벡터연산 : 불편. m파일로 대체함

문자열처리 : 불편. m파일로 대체함

Plotting: 단순.

2D 이미지 : 간단.

3D Modeling : VRML로 연결함

UI : 원시적.

[LabVIEW] —————————

철학 : 장치위주의 다이어그램을 실행한다.

특징 : 알고리즘 개발 자체보다는 장치관련 보조 프로그램 작성.

라이브러리 명칭 : vi, 대소무구분

언어기반 : 자체표현

지원 : C언어, matlab

플랫폼 : Windows, Lynux, Unix, Mac 유료 (번들)

개발편의성 : 구성보다는 마우스 클릭질로 시간낭비가 발생함. 비교적 편리한 디버깅. 상당히 시각적이지만 화면이 복잡해짐.

벡터연산 : 불편

문자열처리 : 불편.

Plotting: 편리.

2D 이미지 : 지원

3D Modeling : ?

UI : 비교적 풍부.

[Workspace Interpreter 형 언어] ====================================================

데이터형 자동지정, 무선언. workspace를 사용하기 때문에, 원하는 라인만 실행 가능함. 컴파일과정이 없기 때문에, 실행결과를 확인하고 다음 작업으로 넘어가는데 신속할수 있음. 실행속도는 상대적으로 느린편. 함수와 실행파일(프로젝트파일)의 구분이 없어 간혹 불편함.

[Matlab]————————————————————

철학 : 가급적 짧은 표현과 디폴트를 지원한다.

특징 : 텍스트파일. 대학교에서 많이 사용. 수치만 연산함.

라이브러리 명칭 : Toolbox, 빌트인 함수명은 주로 약어로 구성. 대소구분

문서화 : HTML,

언어기반 : 변형 C언어.

지원 : structure, 계층형 벡터, 매트릭스, 함수내 함수, 1줄함수, exe 생성 지원

플랫폼 : Windows, Lynux, Mac, Unix, 유료

개발편의성 : 언어적으로 매우 간단한 표현만을 사용하기 때문에, 여러언어중 가장 배우기 쉬움. 상당히 친절한 도움말.

문자열처리 : 벡터로 처리함. 빈약함.

Plotting: 다양한 Plotting을 지원하므로, 디버깅중 값추적이 용이함.

2D 이미지 : 영상처리 툴박스에서 매우 다양한 함수를 제공.

3D Modeling : 비시각적 Properties.

UI : 기본적 컨트롤만 지원. 좀 느림. UI 용 코드가 복잡한 편.

[R]————————————————————

철학 : 가급적 짧은 표현과 디폴트를 지원한다.

특징 : 텍스트파일. 통계과에서 많이 사용. 수치만 연산함.

라이브러리 명칭 : Pakage

언어기반 : C언어.

지원 : 매트릭스,

플랫폼 : Windows, Mac, Unix, 무료 공개소스

개발편의성 : 비교적 배우기 쉬움.

문자열처리 : 빈약함.

Plotting: 비교적 다양한 Plotting을 지원.

2D 이미지 : 지원

3D Modeling :

UI :

[Maple]————————————————————

철학 : 가급적 수학기호를 그대로 표현한다.

특징 : 전용파일. 고교용,수학과용 함수 풍부. 기호연산지원, 현존 계산기중 가장 많은 소수연산을 지원하므로 가장 정확하다고 함. 기호 미적분, 식유도시 편리

라이브러리 명칭 : Package. 대소구분

문서화 : 자체 IDE, 도움말 자체가 커널

언어기반 : Pascal

지원 : 186개의 데이터형, 1줄함수, C,Fortran Export

플랫폼 : Windows, Lynux, Mac, 유료

개발편의성 : 상당수의 연산을 함수로만 처리하므로 가독성이 떨어지고, 알고 있어야할 함수가 너무 많아 배우기 어려움. 너무 방대한 도움말. (습득을 포기하게 만듬)

문자열처리 : 상당히 빈약함.

Plotting: 다양한 편.

2D 이미지 : 지원.

3D Modeling : 지원.

UI : 빈약.

[Mathematica]————————————————————

철학 : 기호의 일관성을 추구한다.

특징 : 전용파일. 고교수학용. 기호연산지원, 기호 미적분, 식유도시 편리

라이브러리 명칭 : Notebook. 대소구분

문서화 : 자체 IDE, 도움말 자체가 커널

언어기반 : 자체언어

지원 : 클래수없음. 계층형 벡터, 1줄함수, C,Java

플랫폼 : Windows, Lynux, Mac, 유료

개발편의성 : 알고 있어야할 연산자가 많은편.

문자열처리 : 상당히 빈약함.

Plotting: 꽤 다양한 편.

2D 이미지 : 지원.

3D Modeling : 지원.

UI : 빈약.

[MathCAD]————————————————————

철학 : 문서화를 추구한다.

특징 : 전용파일. 보고서 숙제 작성용. 기호연산지원, 도량형 지원

라이브러리 명칭 : 대소구분

문서화 : 자체 IDE,

언어기반 : 자체언어

지원 : 1줄함수,

플랫폼 : Windows, 유료

개발편의성 : 비주얼한 편집으로 비교적 쉬운편, 제공함수가 빈약한 편. 도량형이 자동계산되므로 물리량 계산시 편리. 구성보다는 마우스 클릭질로 시간낭비가 발생함.

벡터 : 불편

문자열처리 : 상당히 빈약함.

Plotting: 단순.

2D 이미지 : 간신히 지원.

3D Modeling :

UI : 빈약.

[기타언어]———————————————————— CemTool, Maxima, Derive, Axiom, MuPAD …

[non-Workspace Interpreter형 언어] ====================================================

데이터형 자동지정. 무선언. 컴파일을 하지는 않으나 Workspace가 없기 때문에 항상 처음부터 실행함. 수치연산만 지원. 텍스트파일

[php]————————————————————

철학 : 짧은 표현.

특징 : 웹서버용.

라이브러리 명칭 : Library, 대소구분

언어기반 : C언어

지원 : 계층형 해쉬벡터

플랫폼 : Windows, Lynux 무료

개발편의성 : 단순하고 친절한 도움말로 비교적 배우기 쉬운편,

문자열처리 : 풍부.

2D 이미지 : GD

3D Modeling : 3D Live (mathematica)

UI : JavaScript, HTML 기반

[Python]————————————————————

철학 : 다양한 플랫폼과 온갖 장르에 구분없이 활동한다.

라이브러리 명칭 : Library,

언어기반 : 자체언어

지원 : 계층형 해쉬벡터

플랫폼 : Windows, Lynux, Unix, Mac 무료

개발편의성 :

벡터연산 : 불편

문자열처리 : 보통.

2D 이미지 : OpenCV

3D Modeling :

[Ruby]————————————————————

철학 : 일편단심 클래스. 상수도 클래스다.

언어기반 : 자체언어

지원 : 계층형 해쉬벡터

플랫폼 : Windows, Lynux, Unix, Mac 무료

개발편의성 :

벡터연산 : 불편

문자열처리 : 보통.

2D 이미지 :

3D Modeling :

[CLISP] ———————————————————

철학 : 일편단심 계층형트리구조. 코드도 데이터다.

언어기반 : LISP

지원 : 계층형 해쉬벡터

플랫폼 : Windows, Lynux, Unix, Mac 무료

개발편의성 : 문법구조가 간단. 괄호가 너무 많아져서 가독성이 그닥 좋지는 않음.

벡터연산 : 불편.

문자열처리 : 불편.

[가상머신형]====================================================

선언. 이진코드 생성. 런타임 환경(VM) 필요. 프로젝트 파일

[Java]————————————————————

철학 : 일편단심 클래스. 장치에 의존하지 않는다.

언어기반 : C언어

지원 : 계층형 해쉬벡터

플랫폼 : Windows, Lynux, Unix, Mac 무료

개발편의성 :

벡터연산 : 불편

문자열처리 : 보통

2D 이미지 :

3D Modeling :

UI : 지원

[Visual C# (.NET)]————————————————————

철학 : Java의 시장점유율을 공략한다.

언어기반 : Java

지원 : 계층형 해쉬벡터

플랫폼 : Windows, 유료

개발편의성 : UI 제작시 비주얼한 편집으로 비교적 편리. 예쁜 콘트롤

벡터연산 : 불편

문자열처리 : 보통

2D 이미지 :

3D Modeling :

UI : 지원

[Compiler형 언어] ====================================================

선언. 기계어 코드 생성. 실행때마다 컴파일을 수행함. 프로젝트 파일,

[Delphi]————————————————————

철학 : 무조건 빨리 만들고 본다. (RAD)

특징 : 이벤트로만 동작. 데이터베이스,웹서비스용으로 많이 사용. 현존 가장 빠른 Navtive 컴파일속도.

라이브러리 명칭 : Unit, 대소무구분

언어기반 : Pascal

지원 : 함수내 함수, 계층형 해쉬벡터, 클래스, 포인터

플랫폼 : Windows유료 (2006 Turbo, 무료), Lynux(Kylix) 유료, Lazarus(Windows, WinCE, Lynux, Mac) 무료

개발편의성 : UI 제작시 비주얼한 편집으로 상당히 편리. 타인소스 가독성 우수. 소스파일은 단 3개 (*.dpr, *.pas, *.dfm). 컴파일시 소스파일을 저장하지 않음. 즉 새 프로젝트 시작시 저장없이 초간단 테스트 가능. Watch에 함수를 쓸수없음. 비어있는 이벤트함수 자동제거.

벡터연산 : 불편

문자열처리 : 보통

Plotting: 불편.

2D 이미지 : Graph32 (VCL) 편하지만 풍부하지는 않음

3D Modeling : GLScene (VCL) 편함, 풍부

UI : 엄청나게 풍부한 VCL

[C++ Builder]————————————————————

철학 : MFC뿐 아니라 델파이도 컴파일한다.

특징 : 유일한 RAD Native C++ 컴파일러. UI를 가지는 장치관련 SW. 정통 ANSI C++ (키워드 4개 추가). 느린 컴파일 속도.

언어기반 : Boland C++

지원 : 계층형 해쉬벡터, 클래스, 포인터

플랫폼 : Windows, 유료 (2006 Turbo, 무료)

개발편의성 : UI 제작시 비주얼한 편집으로 비교적 편리. 타인소스 가독성 우수. 소스파일은 단 4개 (*.prj, *.cpp, *.h, *.dfm). 컴파일시 소스파일을 저장하지 않음. 일부 mfc로 만든 lib 파일의 비호환성으로 간혹 rebuild 해야함. 비어있는 이벤트함수 자동제거.

예 : 타이틀바에 글자넣기 : caption=”My Window Title”;

벡터연산 : 불편

문자열처리 : 보통.

Plotting: 불편

2D 이미지 : OpenCV (VCL로 전환) 보통

3D Modeling : GLScene (VCL) 편함

UI : VCL 기반

[Visual C++ (MFC)]————————————————————

철학 : M$의 패권을 추구한다.

특징 : Non-Visual IDE, 엔진,장치관련 드라이버용, 외부 라이브러리 풍부. 정통 ANSI C++를 지키지 않음. 이전보다 비교적 빨라진 컴파일속도.

라이브러리 : MFC

지원 : 클래스, 포인터

플랫폼 : Windows, 유료 (시장점유를 위해 학교등에 무료로 제공)

개발편의성 : UI 제작시 Non-비주얼에다 예제없는 도움말, 이해할수 없는 에러메시지, 알고 있어야 할 지식이 많이 필요하는 등 적응하기 매우 어려운 편. 컨트롤 변수 수동매핑. 생성된 매핑 코드와 사용자가 작성한 코드가 섞여 가독성 나쁨, 타인소스는 물론이고 자신의 코드조차 나중에 이해하기 어려움. 다른사람의 프로젝트 파일을 컴파일하기까지 난관많음. 설정의 복잡성. 강력한 디버깅 능력. 파일이전시 폴더를 통째로 이동해야함. 컴파일시 소스파일을 항상 저장함. 즉 새 프로젝트 시작시 항상 폴더를 지정해야함. 복잡한 새 프로젝트 위자드.

예 : 타이틀바에 글자넣기 : AfxGetApp()->m_pMainWnd->SetWindowText(“My Window Title”);

벡터연산 : 불편

문자열처리 : 불편.

Plotting: 불편.

2D 이미지 : OpenCV (불편)

3D Modeling : OpenGL (불편)

UI : 불편, 빈약.

=====================================================================

툴에 대한 도움이 되는 글.. http://kldp.org/node/67741
홍민희 2008-07-16 09:56:14

서식이 난잡해서 눈에 잘 들어오지가 않습니다. 이 게시판에서는 Markdown을 사용하고 있으니, Markdown 서식을 사용해주시면 좋을 것 같습니다.
착한아이 2008-07-16 10:04:08

여기 사용법을 잘 몰라서.. 모조리 엔터를 넣었더니 무쟈게 늘어났네요.. ^^;; 줄바꾸기를 어케 써야할까요?
홍민희 2008-07-16 10:15:06

Markdown은 꽤나 유명한 포맷입니다. 구글에서도 검색하면 바로 나오고, 위키백과에도 올라가 있습니다. 공식 사이트의 문법 설명을 참고하세요~
민군 2008-07-21 20:36:44

좋아하는 : 루비 싫어하는 : 마땅히 없지만 그래도 별로 호감이 안가는건……………….. ASM

목록보기

← 이런거 재미있을텐데… | 가입하게됬습니다.. →

LangDev

자신이 가장 좋아하는 언어, 가장 싫어하는 언어