IDE 선택
글쓴이: player224451 / 작성시간: 일, 2009/11/22 - 12:40오전
툴 선택 문제때문에 글 올립니다.
윈도우 환경에서만 계속 개발하다가 QT를 접하면서 크로스 플랫폼 프로그래밍에 도전해보려고 합니다.
그래서 크로스 플랫폼 C++ 개발 IDE를 찾고 있습니다.
비주얼 스튜디오를 제외한 환경에서의 개발은 첨인지라 잘 모르겠네요.
eclipse,codeblocks,kdevelop등등이 있는것 같고..
qt creator도 괜찮아 보이는 군요.
툴 선택이야 개인적인 취향이긴 하겠지만..
처음 시작하는 입장에서는 이것도 어렵네요..
개인적으로는 eclipse쪽을 선택하려고 합니다만
리눅스쪽 개발하시는 분들의 조언 부탁드립니다.
Forums:
언제나 고민하고,
언제나 고민하고, 지금도 고민하는 문제중에 하나입니다. 선택하기에는 너무나도 좋은 툴이 많고, 선택하고서도 유혹(저게 더 좋을까 하는...)이 너무나 많죠. 만약 윈도에서 개발을 하시는 동안 VS가 무엇을 해주었는가를 어느정도 이해하고 계시다면, 개발 편의성 환경에 초점을 두고 IDE 선택에 고민하시기 보다는 editing 작업 자체에 초점을 두고 editor 선택을 신중히 고려하시는 것이 좋다고 조언드리고 싶습니다.
많은 사람들이 개발환경을 언급할 때, 말씀하신 eclipse, codeblock 등과 더불어, IDE 같아 보이지 않는(원칙적으로는 IDE가 아니죠) emacs, vi등을 언급하는 이유가 있습니다. 보통 IDE를 생각할 때, 프로젝트 관리, 디버깅, 버전컨트롤 등의 수많은 기능들을 담고 있는 툴을 생각하게 되는데, 결국 이러한 작업 모두 독립적(예: Autotool, gdb, svn)으로 수행 가능한 작업입니다. 말 그대로 IDE 툴로 묶여 있는 것이지요. 심지어 각각의 독립적 작업을 각자 편하게 할 수 있도록 도와주는 툴들도 존재하는데, 이것을 바꿔말하자면, 이러한 다양한 작업을 해주는 툴 역시 확장이 용이한 훌륭한 에디터들에서 묶일 수 있다는 것입니다.
저도 역시 그랬고, 많은 분들이 IDE를 선택할 때, 이런 기능은 되나? 저런 기능은 되나? 하는 것을 판단으로 선택하는데, 결국 저의 경우 선택의 종착점은 에디터였습니다. 작업의 목적이 프로젝트를 관리하거나 디버깅하거나 버전컨트롤하는데 있는 것이 아니라, 코드를 작성하는데 있기 때문입니다. 그럼에도 불구하고 놀라운 사실은, 훌륭한 에디터들 모두 해당 작업을 편이하게 해주도록 확장이 가능하다는 것입니다. 저의 경우 vi를 약 5년 정도 사용하다가 지금은 emacs를 사용하고 있는데, 이 프로그램들이 과연 에디터인가 하는 의심이 들더군요. :)
두 에디터 모두 맘에드는 IDE까지 구축(확장)하여 개발할 수 있게 되기까지 장벽이 어느정도 있다는 사실은 피할 수 없습니다. 하지만 장기적으로 볼 때, 그것이 상당히 매력있는 투자라는 생각에는 확신이 있습니다. 도움이 되셨으면 합니다.
vi -> emacs를 넘어가게된 계기가 어떤 일이셨나요?
최근에 들어야 vi를 자주 쓰고 있는 개발자 입니다.
저에게는 10가지 정도의 플러그인을 사용해서, 원하는 사용성까지 끌어올려 쓰고 있습니다.
vi 사용 5년 정도후, emacs로 넘어가는 계기가 있으실것 같은데 어떤 장점이나 계기가 되었나요?
우연한 계기로 저와
우연한 계기로 저와 비슷하게 vim을 수년간 사용하다가 emacs로 넘어온 한 개발자(?)의 글을 읽게 되었습니다. 파트1과 파트2로 서술된 다소 긴 내용입니다. 한 번 참고하시는 것도 좋을 듯 합니다. 링크입니다:
http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/
링크한 글의 내용 중, 몇몇은 동의하고, 몇몇은 그렇지 않지만, 상당수가 저도 vi를 쓰면서 느꼈던 것들이었고, 이를 해결하고자 반신반의로 emacs를 사용해 보기 시작했었습니다. 지금 돌이켜보면 vi를 썼을 때 못 느꼈던 여러 매력을 느끼고 있으며, 역시 vi에서 느꼈던 매력을 못느끼는 반대의 경우도 있습니다. 어느 정도 emacs를 수월하게 사용하고 있는 요즘, 다시 vi로 돌아가지않고 emacs를 계속 애용하는 이유가 무엇일까를 자문했을때, 확실한 이유가 나오네요. Consistency. 일관성입니다.
에디터로써의 기능을 모두 제쳐두고 생각할 때, emacs가 제게 상당히 매력적인 것은 에디터 자체가 갖고있는 일관성 철학입니다. 구체적인 내용을 하나 언급하자면, "M-x 함수콜"로 모든 기능을 수행할 수 있다는 것이 있습니다. 이 얘기는, 사용자가 굳이 에디터의 단축키, 기능 등을 일일이 기억하고 있지 않아도, emacs의 동작은 위와 같은 함수 호출로 수행된다라는 것을 인지하는 순간 모든 기능을 사용해 볼 수 있다는 것입니다. 심지어 커서를 오른쪽으로 옮기는 "오른쪽 화살표키를 누른다"는 동작조차 "M-x forward-char"로 수행할 수 있죠. 별거 아닌 것 처럼 느껴질 수 있지만, 이것은 엄청난 사실입니다.
어떤 어플리케이션의 조작법에서건, 어떤 프로그래밍 언어의 문법에서건, 일관성이라는 철학이 갖고 있는 파워는 실로 엄청납니다. 얼마만큼 직관적으로 혹은 유용하게 기능을 확장 및 응용할 수 있는가와도 직결되는 문제이지요. 이에 emacs의 응용을 위한 elisp이 결합되면 emacs는 이미 editor의 제한을 넘게 됩니다. 역시 이 결합조차 일관성을 최대한 해치지 않는 철학을 내포하고 있습니다. 물론 이 이야기가, 다른 editor는 이것이 불가능하다는 얘기가 아닙니다. vi로도 원하는 모든 것을 할 수 있습니다. 다만 vi에서도 스크립트를 사용해봤고, 원하는 기능들을 만들어 써 봤지만, emacs에서의 일관성 철학이 제게는 더 매력적으로 다가왔다는 것입니다.
좋은 editor는 많습니다. vi는 이미 역사적으로도, 사용자수로도 그 명성을 입증했습니다. emacs역시 그 명성을 입증했죠. 이러한 에디터들의 명성이 괜히 입증되는 것이 아니라는 것에는 모두 동의하실 것입니다. 만약 이런 훌륭한 에디터들을 사용해보지 않으셨다면 처음 진입하는데 장벽이 좀 있더라도 한번쯤 배워볼만하다는 것을 강조하며 답글을 마치겠습니다.
댓글 달기