Java vs OCaml
저는 한 소프트웨어 회사의 대표입니다.
소프트웨어 회사의 특성상 제품의 연구, 개발 및 유지보수가 회사의 운영에 큰 부분을 차지 하고 있습니다만, 여러가지 어려움을 겪고 있어 여러분들에게 자문을 구하고자 합니다.
저희 회사는 PDF 관련 제품들을 만들고 있으며, 대부분의 제품들이 하나의 라이브러리(엔진)에 의존하고 있습니다. 이 엔진은 PDF 문서를 읽고, 객체를 조작할 수 있으며, 렌더링을 할 수 있게 해줍니다.
4년전 처음 개발을 시작했으며, 1년6개월후 부터 실제 제품화되어 사용하고 있으며 계속 유지보수해 오고 있습니다.
이식성과 성능을 고려하여 ANSI C로 개발되었다 유지보수의 편의를 위해 2년전 경 C++로 리뱀핑을 했습니다. 코드 규모는 15만 라인 정도 되며, PDF 파서, 자료구조, 트리 옵티마이저, 렌더러로 구성됩니다. 이 외에도 여러개의 압축 코덱(JBIG2, JPEG2000, LZW 등)과 자바스크립트 인터프리터, PostScript 인터프리터, 칼라매니지먼트등 여러 모듈들이 있습니다.
문제는 C++로 만들어진 현재의 엔진의 유지보수가 매우 힘들다는 것입니다. 리팩토링을 해 가면서 유지보수를 해 오고는 있지만, 앞으로 1년 정도가 경과하면 유지보수가 더 이상 불가능해질만큼 코드가 복잡해지고 품질이 낮아지고 있습니다. 벌써 새로운 기능을 추가하는데 필요한 시간이 예전에 비해 현저히 늦어졌습니다.
이식성을 염두에 두고 시작한 프로젝트임에도 불구하고, C++로 전향하고 template의 의존이 늘어나면서 점점 더 이식성이 떨어져가고 있습니다. (여전히 쓸만한 C++ 컴파일러가 없는 플랫폼이 많더군요.)
또 C/C++는 프로그래머의 역량에 따라 결과물의 편차가 매우 큽니다. 아닌것이 어디 있겠습니까만 단순한 생산성의 차이가 아니라, 제품의 안정성까지 심하게 영향을 받습니다. 그리고 경영자의 입장에서 C/C++ 프로그래머의 수급이 매우 부족합니다.
제 계획은 2년 후 정도부터 쓸수 있는 새로운 엔진을 준비하는 것입니다.
이 엔진은 유지보수가 쉬워야 하며, 엔지니어를 확보하기 쉽고, 안정성, 확장성이 높고, 이식성이 좋아야 하며, 높은 성능을 요구합니다. (좋은건 다 필요하네요 ㅎㅎ)
이러한 요구를 만족시키기 위해 두개의 프로그래밍 언어를 염두에 두고 있습니다. Java와 OCaml입니다.
2년 후 실용화를 염두에 두고 있기 때문에 컴파일러, 플랫폼의 발전도 감안하자면 성능은 큰 문제가 아니라고 봅니다. 이미 Numerical code의 성능도 인텔 하드웨어에서 Java가 C++에 비해 20% 정도밖에 느리지 않을 정도라니 2년후의 하드웨어와 VM의 성능을 생각하면 별다른 문제가 없을 테고(http://www.idiom.com/~zilla/Computer/javaCbenchmark.html), ocaml의 성능은 익히 알려져 있으니까요 (http://dada.perl.it/shootout/craps.html).
OCaml의 안정성은 C++과 비교할 바가 못되고, 두 언어 모두 유지보수, 안정성, 확장성에는 최소한 C++ 보다 좋다고 생각합니다. 이식성의 경우 Java야 문제가 안되겠지만 OCaml의 이식성이 어떤지 궁금합니다. ARM이라던가 임베디드 환경에서 (휴대폰 같은) 문제없이 사용할 수 있을까요?
가장 큰 걱정과 문제는 엔지니어 확보입니다.
Java 프로그래머들은 상대적으로 많습니다만, 제 경험상 저희 제품을 개발하고 유지보수할 수 있는 프로그래머들을 확보하는 것은 쉽지 않았습니다. Java 프로그래머가 C++ 보다 많다는 점을 빼고는 유지보수가 딱히 C++ 보다 쉽워 보이지는 않고요. 그렇다 해도 Java 프로그래머가 많고 또 배우는 학생이 많다는 점은 큰 매력으로 보입니다.
OCaml을 경험한 프로그래머가 드물다는 것이 큰 문제입니다. 아무래도 복잡하지 않은 언어라서 한달 정도면 배울 수 있기 때문에 회사에서 익히는 것도 가능하지 않을까 생각이 들기도 하고, 또 배우는데 시간이 걸리더라도 생산성 향상의 효과가 크다고 생각이 들지만, 프로그래머들이 새롭게 익혀서 일을 하기 까지 얼마나 걸릴지가 걱정입니다.
과연 여러분들은 저희회사를 위해 어떤 프로그래밍 언어를 추천해 주시겠습니까? 고견을 부탁드립니다.
ps. 아.. 중요한것을 빼 먹었네요. OCaml의 전망도 꽤 중요하네요. 사용자층도요. 여기에 대한 코멘트도 부탁드립니다. 갑자기 OCaml 컴파일러가 maintain 되지 않는다면 낭패니까요. ㅎ
그냥 한 마디 남깁니다...
쓰신 글을 보다 보니 어느 정도는 스스로 답을 써놓으신 것 같은데요...
저라면 개발자를 뽑아 OCalm이라는 언어를 사용하도록 한 달간 교육을
시키는 것 보다는 자바 개발자를 채용하고 그 시간동안 기존 제품에
적응할 수 있는 시간으로 확보하는 쪽을 택하겠습니다. 그리고 쓰신
내용을 보니 기존 제품의 구조를 재설계하는 쪽을 생각해보심도 그다지
나쁘지는 않을 것 같아 보이는데요... 구체적인 상황을 모르니 더
세세한 참견을 할 수는 없겠지만 -,.-;; 유지보수의 효율성과 어느 정도
수준의 개발자 확보에 중점을 두신다면 그다지 고민할 이유도 없어
보입니다만...
---------------------------------------------------------------
- The best is yet to come, and there's always hope. -
---------------------------------------------------------------
---------------------------------------------------------------
- The best is yet to come, and there's always hope. -
---------------------------------------------------------------
개발자 확보가 가장 큰 문제네요...
C/C++을 포기하려했던 가장 큰 이유는 프로그래머 확보입니다. 또 생산성 문제도 있고요.
처음에는 자바로 옮겨가려 했습니다. 일단 C++ 보다는 생산성이 높을 것이라 보고, 또 프로그래머 확보 역시 C++ 보다는 훨씬 쉬우니까요. 그리고 현재의 C++ 프로그래머들은 어렵지 않게 자바로 넘어 갈 수 있다는 점도 좋고요. 이식성은 덤이네요.
그런데 OCaml 역시 매력적이네요. 당장 프로그래머를 구하기는 어렵지만, 한두달만 배우면 자바/C++ 보다 훨씬 생산성이 높아질 테니까요. 아무래도 같은 수준의 프로그래머라면 OCaml이 훨씬 더 좋은 품질의 코드를 빠르게 만들 수 있으니까요.
생산성을 강조하다 보니 악덕 기업주 같네요. ㅎㅎ 그렇지만 생산성은 매우 중요합니다. 저는 매일 야근하고, 제대로 취미생활도 할 수 없는 현실에는 생산성의 문제가 크다고 봅니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
답변은 아니고...
PDF-Pro를 개인이 무료로 쓸 수 있게 해 주셔서 2년째 잘 쓰고 있습니다.
HFT 폰트 변환 품질이 좋아서 더욱 만족스럽습니다.
회사의 개발 체계가 더욱 튼튼히 갖춰지길 바랍니다.
써 주셔서 감사합니다.
공식적인 자리가 아니라 아무래도 편하게 이야기 할 수 있어 좋네요.
회사 입장에서 개인 무료 버전은 꼭 베푼다는 의미는 아닙니다.
제 개인적인 생각은 소프트웨어는 제공하는 편익만큼 대가를 받아야 한다는 것입니다.
그래서 개인에 비해 훨씬 더 큰 편익을 얻는 기업 고객들에 대가를 받는 것이고요.
그 대신 저희가 개인 고객들에게 바라는 것이 있습니다. 모든 제품이 다 그렇겠지만, 소비자와 생산자는 서로 도움을 주고 받아야 합니다. 제품을 써 보시고 불편하거나 마음에 안드는 것이 있으면, 꼭 저희에게 알려주셔서 제품 개발에 함께 참여해 주시길 바랍니다. 그렇다면 계속해서 저희가 좋은 제품을 개인에게 무료로 공급할 수 있을 것입니다.
감사합니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
관련하여 리포팅을
관련하여 리포팅을 하였는데 답이 없더라구요 @..@;;;
xp 에서는 문제가 없는데 2003 server std, ent 에서는 기존 프린터가 설치가 되어 있으면 정상적으로 설치가 안되는 문제가 있습니다.
열댓번 정도 OS 까지 재설치하며 리포팅을 했는데 답이 없더라구요 ^^;;;
지금은 잘 설치해서 잘 쓰고 있습니다.
좋은 프로그램 무료로 배포해 주셔서 감사합니다.~
나름데로 열심히
나름데로 열심히 하고 있습니다만, 부족했네요.
10번씩이나 OS를 재설치하셨다니 -_-;; 고생 너무 많으셨습니다.
죄송합니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
흥미 있는 내용이라
흥미 있는 내용이라 생각해서 몇자 적어봅니다.
프로그래밍 언어에 따른 생산성 차이 분명 존재합니다. 생산성 높은 언어일수록 해당 프로그래밍 언어의 기능을 충분히 사용할 줄 아는 프로그래머 구하기 어렵거나 보수가 높은 것이 일반적입니다.
예를들면, 제가 있는 회사는 생산성 높은 프로그래머 4명(많을 적엔 최대 8명)이 개발 및 유지보수 다 처리합니다(제품과 서비스는 글로벌 기업들에 납품합니다). 보수는 프로그래머 각각 연봉 1억 - 1억 5천 정도입니다. 위에 언급하신 ocaml처럼 제대로 된 프로그래머라면 매우 높은 생산성을 꾀할 수 있는 프로그래밍 언어 사용합니다 - 경우에 따라 C++, Javascript, SQL, Java, PHP, C#, Matlab 등도 사용합니다. 사업확장으로 새로 경력직 구하려 하는데, 마땅한 사람 구하기가 어렵습니다.
제 생각에는 어떤 일이냐에 따라 결정하시는 것이 맞을 것 같습니다. 즉, 제가 현재 하는 일을 Java,C,C++ 등으로 했다면 아마 오늘날의 제품과 서비스는 불가능했을 겁니다. 불가능을 가능케 한 대신 프로그래머 보수 및 인력수급문제를 대가로 치룬 것이죠. 어떤 일들은 주로 노동력에만 의지하면 되는 일들이 분명 존재합니다. 그런 경우라면 적은 보수를 주고 비교적 쉽게대치 인력을 구할 수 있는 Java,C,C++ 등이 맞지 않나 생각합니다.
또, 프로그래밍 언어 implementation 선택시 상업적으로 서포트 받을 수 있는 것을 선택하시는 것이 좋습니다 - 어느정도 수준 이상의 프로그래머라면 분명 언어 자체에 있는 버그를 발견하게 될 것인데, 그런 것들이 빠른 시일내(늦어도 1주일)에 고쳐질 수 있어야 할 겁니다. 오픈소스의 경우 간혹 이런 부분에서 문제가 될 수 있습니다(상업용도 오래 걸리면 마찬가지죠)
생산성
>프로그래밍 언어에 따른 생산성 차이 분명 존재합니다. 생산성 높은 언어일수록 해당 프로그래밍 언어의 기능을 충분히 사용할 줄 아는 프로그래머 구하기 어렵거나 보수가 높은 것이 일반적입니다.
이 부분이 많이 걸리네요. 제 아이디어의 출발은 "똑같은 프로그래머라도 생산성이 높은 프로그래밍 언어를 사용하면, 생산성이 높아질 것이다" 였습니다. 특히 functional language들은 기존의 언어들 보다는 학습 시간이 짧은 편이라는 믿음도 있고요. 그래서 C++/Java 프로그래머라면 쉽게 OCaml을 배우고, 생산성도 높아질 것이라는...
>제 생각에는 어떤 일이냐에 따라 결정하시는 것이 맞을 것 같습니다. 즉, 제가 현재 하는 일을 Java,C,C++ 등으로 했다면 아마 오늘날의 제품과 서비스는 불가능했을 겁니다. 불가능을 가능케 한 대신 프로그래머 보수 및 인력수급문제를 대가로 치룬 것이죠.
OCaml로 프로젝트를 한다면, 제가 계획하는 선교육 후업무가 동작하지 않으리라고 보시는지요? 보수 문제는 생산성 향상에 따라 당연히 새롭게 조정될 수 있는 문제라 생각하지만, johan님의 이야기는 OCaml을 알고 있거나 가르칠 수 있는 프로그래머들을 확보하는 것 자체가 큰 문제라 느껴져서요.
어떤 일이냐라는 문제는 저희 프로젝트는 OCaml과 같은 functional language가 잘 먹힐 수 있는 분야로 보입니다. 일단 내부적으로 PDF 파서, PostScript 파서 등과 같은 것들이 있고, 디스플레이 트리, 렌더러, 코덱 등등 대부분 함수형 언어로 훨씬 쉽게 구현할 수 있는 일이거든요.
>예를들면, 제가 있는 회사는 생산성 높은 프로그래머 4명(많을 적엔 최대 8명)이 개발 및 유지보수 다 처리합니다(제품과 서비스는 글로벌 기업들에 납품합니다). 보수는 프로그래머 각각 연봉 1억 - 1억 5천 정도입니다.
혹시 국내에 있는 회사인가요? 제가 꽤 관심가지고 있는 테마가 프로그래머들의 연봉인지라. 억대 연봉을 받는 프로그래머가 4명이나 있다면 매우 고무적인 일이군요. 혹시 어느 분야인지라도 알려주실 수 있을까요? 이런 회사와 프로그래머들이 있다는 사실은 널리 알려야 한다고 생각합니다. 그래야 "프로그래머는 노가다"라는 믿고 싶지 않고, 인정할 수 없는 등식이 깨질테니까요. 그리고 저를 포함한 다른 소프트웨어 회사 경영자들을 자극할 수도 있고요. ㅎㅎ 저는 프로그래머들의 처우, 인식 개선과 같은 전반적인 문제들이 연봉 향상을 통해 풀어질 수 있다고 믿고 있습니다. ( 억대 연봉의 프로그래머: http://www.pdfpro.co.kr/blog/jeong/16 )
>프로그래밍 언어 implementation 선택시 상업적으로 서포트 받을 수 있는 것을 선택하시는 것이 좋습니다
이 부분이 고민스럽기는 합니다. Java야 문제 없겠지만, OCaml 어떨까요?
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
처음 말씀하신
처음 말씀하신 이식성이 C++ 의 template 구현에 영향받을정도의 환경이면
(정말 일부 CPU 빼고는 C++ 표준안을 대부분 만족합니다. boost 까진 몰라도 적어도 STL 정도는 전부 되는 걸로 알고 있습니다. )
OCaml 의 이식성은 더욱 걱정이 되는 상황이 아닐까 생각합니다.
C++ 의 바이너리 사이즈나 vtable 등등이 임베디드에선 상당히 무거운건 사실이고, 그런거 때문에 피하는거라면 상관없지만
template 의 이식성을 걱정하실정도의 환경에서 Ocalm을 바라는 것은 무리가 아닐까 생각합니다.
아마 이식성을 걱정하실 부분이 생기는건 거의 C로 작성하시는수밖에 없을것 같습니다. ( Java 도 저는 C++ 과 비슷할것이라고 생각합니다.. 제가 틀릴수도 있겠지만 )
조합을 하십시오. 처음부터 C로 만든것을 다시 C++로 고쳐가면서 확장성을 잃으신게 아닌가 생각합니다.
C++ 의 확장성이 부족해서 버리겠다라는 의견은 선뜻 동의하기가 힘듭니다.
C++ 로 처음부터 작성된 프로젝트였으면 확장성이 그렇게 나쁘지는 않았겠지요... 다만 프로그래머의 역량이
워낙 출중해야 확장성이 잘 생기므로 C/C++ 프로그래머수급이 힘들다는 가정하에서는 C++의 확장성에 문제삼으실 수는 있겠습니다만..
제 생각은 C로 core를 짜고 다른 함수형 언어나 Script 언어로 그 위를 다듬으시는게 정석이 아닐까 생각합니다.
특히 문서엔진은 이미 어느정도 디자인패턴이 정해져있는것으로 알고 있습니다.
더불에 기존 코드를 몽땅 낡았다 라는 생각으로 버리는 우를 범하시지 않기를 빌겠습니다.
조엘 온 소프트웨어에 참고할 만한 이야기가 있습니다. 코드가 너덜해 보이고 길어지고 기능추가하기가 힘들다는건
그만큼 코드가 안정성을 어느정도 지녔다는 이야기와 일맥상통합니다. ( 예외처리가 상당히 강해져있는것이죠 )
코드 유지보수가 힘들어서 버리고 다른 언어로 깔끔하게 짜보겠다 라는게 개발자의 환상중에 환상임을 경영자분은
반드시 알고 계셔야 할 것입니다. 결국 예외처리를 붙이고 붙이다 보면 코드란건 늘어지게 마련이고, 이제 그 예외를 잘
피해가면서 새로운 기능을 덧붙여야 하기 때문에 초반보다 기능 붙이기가 느려보이는것 뿐입니다.
개발자들을 잘 관리하는것중에 중요한건 반드시 기능을 누가 작성했고 어떤 내용을 작성을 어떻게 했나 전부 최소한
SVN log 에 라도 잘 남겨놓는것입니다. 이런게 잘 되어있으면 신입을 뽑던 새로운 프로젝트를 브랜치하던 기존코드를
계속 잘 활용하실 수 있을껍니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
> 다만 프로그래머의
> 다만 프로그래머의 역량이 워낙 출중해야 확장성이 잘 생기므로 C/C++ 프로그래머수급이 힘들다는 가정하에서는 C++의 확장성에 문제삼으실 수는 있겠습니다만
이게 가장 큰 문제네요. ㅎㅎ
원글에 말씀드렸듯이 프로그래머 수급이 제일 큰 고민입니다.
그래서 Java로 바꿀 생각을 맨 처음에 했고요. 아무래도 C++ 프로그래머보다 많더군요.
그 다음에 착안한 것이, 차라리 배우기 쉽고 생산성도 좋은 언어가 있으니 뽑아서 가르칠 수는 없을까로 생각이 바뀌면서 OCaml을 생각한 것입니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
배우기 쉽고 생산성
배우기 쉽고 생산성 좋다라는게 상품개발 전체까지 영향을 주는 경우가 아닐 수 있다는 이야기도 드리고 싶습니다.
결국 상품을 만들기 위해선 손을 더럽힐 곳이 필요하고( 피할 수 없습니다. ) 그렇게 되면 저렇게 개발층이 넓지 않았던 언어는
반드시 상상하기 힘든 문제를 야기합니다. ( 반드시 라고 할 수 있습니다. )
JAVA 쯤은 되어야 그런 문제를 피할 수 있겠지요.
그리고 임베디드하시는 쪽이시니까 잘 아시겠지만, CPU 파워 아무리 강해져도 '전력 소모량 더 줄이고 싶다. CPU파워 줄여서도라도!'
라는 논리가 통하기 때문에 오히려 가벼운 라이브러리 일수록 사용 선택의 폭이 훨씬 넓어져서 '확장하거나 고치거나 사용하기가
너무 복잡해서 이식성이 떨어지는거 같지만 결국은 역으로 이식성이 강하다' 라고 부를 수 있을껍니다. ( 요즘 배우고 있지만 정말 그렇더군요. ) 진정한 확장성은 나중에 어떤 플랫폼이 오더라도 또 어떤 프로젝트에서라도 포함 되거나 사용 될 수 있어야 진정한 확장성이라고생각합니다.
그런걸 고민하신다면 기존 방식에서 크게 바뀔 게 없어질 것입니다. ( 결국에 가면... )
아예 새로운 엔진을 짜서 새로운곳에만 쓰지.. 라고 하시면 코드가 분기가 나서 두군데를 열심히 동시에 유지보수할 ( 그것도 언어가 다르므로 알고리즘이 즉시 적용되기 힘든때도 많을것입니다 ) 자신이 있으실 경우에만 새로운 엔진을 시작하십시오.
기존 제품이 잘 돌아가고 있는데 프로그래머 수급이 어렵다는게 언뜻 이해가 안갑니다. 충분히 역량 있는 프로그래머들이 일하고 있음에도 관리가 잘 안되어서 유지보수가 힘들게 느껴지는게 아닌가 생각해보세요. 코드관리나 유지보수를 주로 전담할 프로그래머 자체를 따로 뽑아서 시도해보시는 것도 나쁘지 않을 것 같습니다. ( 이것도 아마 뽑아서 가르친다고 생각하셔야겠죠 )
그 프로젝트에 쓰인 코드 자체에 대한 분석을 마친 프로그래머가 늘어나면 늘어날 수록 오히려 기능 추가나 유지보수 비용이 내려간다고 생각하십시오.( 즉 기존 업무자를 복사 하신다고 생각하시면 될껍니다 -ㅅ- 물론 설계능력까지 복사는 ... 무리죠 )
새로운 엔진 개발 성공이 반드시 생산성 향상으로 이어지지 않습니다. 그 엔진 자체를 깊이 이해하고 쓸 수 있는 프로그래머가
얼마나 많냐 자체가 중요합니다. 즉 어떤 언어 생산성이 높고 그 언어 아는 사람이 많으니까 그 언어로 하자, 라는건 기존 프로젝트가 없을때 이야기에 가깝습니다. 새로운 엔진을 다시 만들면서 이 엔진의 이해도를 새롭게 높이자! 라는 취지라면 새로 만드는게 좋은 선택이겠지만, 그 언어만 알고 그 엔진을 모르는 프로그래머가 만약 추가적인 부분을 작성하기 시작하는 순간이 오면, 결국 어떤 언어로 짜던 마찬가지의 결과만 낳을것입니다. 확장성이 급속도로 하향그래프를 그리기 시작할것입니다.
문제의 근본은, 코드작성에만 비용이 드는게 아니라 그 코드를 다시 가르치는 비용이 들고 그 비용을 낮추려면 기존 프로그래머가 힘겹더라도 문서화를 잘 해둬야 한다는 겁니다. 그리고 그 코드를 가르치는 비용이 낮을 수록 부담없이 신입을 뽑아서 가르친뒤 일을 시킬 수 있을겁니다. 어떤 언어로 짜시더라도 결국 그 기존 코드를 가르치는 비용은 피하실 수 없으며, 그 비용을 피해버리려고 하는 순간 왠만한 똑똑한 개발자가 아닌이상 확장성 문제는 또다시 고개를 들것입니다. 아무쪼록 현명하신 판단이 있길 빌고, 귀사의 높은 발전을 기원하겠습니다. 그리고 새로운 엔진 개발에 도전하시게 되시면 저의 이 편견에 가까운 생각을 박살낼 결과물이 생기시길 빌겠습니다. 또한 Ocaml 이나 Java로 저런 개발을 했을때 어떻더라 하는 내용을 KLDP에 올려주신다면 많은 소프트웨어 회사의 발전이 있을 것으로 생각됩니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
정성껏 답변을 해
정성껏 답변을 해 주셔서 감사합니다.
>저렇게 개발층이 넓지 않았던 언어는 반드시 상상하기 힘든 문제를 야기합니다. ( 반드시 라고 할 수 있습니다. )
동감합니다. 저역시 알고 있습니다만, 유혹이 만만치 않네요. ㅎㅎ
>그리고 임베디드하시는 쪽이시니까 잘 아시겠지만
아 사실은 이쪽 잘 모릅니다. :-) 저희는 현재까지 윈도우 플랫폼만 지원하고 있습니다. 물론 개발 과정에서는 맥이라던가 리눅스 기계를 쓰기도 하지만요. 이식성을 거론한 이유는, 우리 비즈니스의 유연성과 엔진의 이식성이 높은 상관 관계를 가질 것이라는 점 때문입니다. PMP용 PDF리더가 필요하거나, 또는 ActiveX가 갑자기 세상에서 사라지는 경우 등등이 머리에 떠오르네요.
>그런걸 고민하신다면 기존 방식에서 크게 바뀔 게 없어질 것입니다. ( 결국에 가면... )
아예 새로운 엔진을 짜서 새로운곳에만 쓰지.. 라고 하시면 코드가 분기가 나서 두군데를 열심히 동시에 유지보수할 ( 그것도 언어가 다르므로 알고리즘이 즉시 적용되기 힘든때도 많을것입니다 ) 자신이 있으실 경우에만 새로운 엔진을 시작하십시오.
새로운 엔진을 하지 말라는 말씀이네요. ㅎㅎ 저희 입장에서 두 개의 다른 언어로 된 엔진을 유지하는 것은 오히려 문제만 키우는 셈이 될 것 같아요.
>기존 제품이 잘 돌아가고 있는데 프로그래머 수급이 어렵다는게 언뜻 이해가 안갑니다.
이 문제는 대부분의 소프트웨어 회사들이 경험하는 문제라고 생각됩니다. 하이테크 업계의 특성상 회사가 빠른 속도로 성장하게 되고, 제품의 포트폴리오, 기능이 늘어나면서 자연스럽게 프로그래머의 수요가 급증할 수 밖에 없습니다.
>충분히 역량 있는 프로그래머들이 일하고 있음에도 관리가 잘 안되어서 유지보수가 힘들게 느껴지는게 아닌가 생각해보세요. 코드관리나 유지보수를 주로 전담할 프로그래머 자체를 따로 뽑아서 시도해보시는 것도 나쁘지 않을 것 같습니다. ( 이것도 아마 뽑아서 가르친다고 생각하셔야겠죠 )
가장 관심가지고 있는 문제가 회사 구성원들의 리텐션임에도 불구하고 이런 지적을 받으면 언제나 자신이 없습니다. 말씀하신 것을 계기로 다시 한번 돌아보겠습니다. 네오지오님은 게임 업계에서 일하고 계신 것 같은데, 비즈니스 소프트웨어쪽에서는 언제나 게임 업계가 사람들 다 데려 간다고 불평하고 있답니다. ㅎㅎ
이래저래 고민이 커져가네요. ㅎ 역시 휴가가 문제인가 봅니다. 놀다보니 별 생각이 다 드네요.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
아;; 정성스러운건
아;; 정성스러운건 아니었고 저도 비슷한 고민을 많이 해 본 입장이라서요.
그냥 말씀드리다 보니 저도 제 생각의 논리가 정리되는 느낌이랄까.. 그런거여서 답글을 열심히 달았습니다.
C++의 이식성을 걱정하시기에 전 임베디드 환경을 생각했습니다. 임베디드 이외엔 C++ 이식성을 고민하실필요는 전혀 없습니다.
표준화가 된지 얼마 안되었을때에나 ( 한 4년전.. ) 템플릿 이식성 운운할 수 있었죠. ( VS는 2003의 경우였습니다. )
저 역시 이미 PMP나 소형기기의 PDF 리더 상품을 이미개발하신거 같아 지례짐작해서 말씀드렸는데, 틀렸군요...
정작 게임쪽도 C/C++ 프로그래머가 부족해서 난리입니다. 전 한국을 떠나서 반쯤 게임에 걸친 일로 바뀌었습니다만...
어디나 프로그래머가 결국 기능만들기에는 핵심이 되어있다보니, 그럼에도 불구하고 한국의 이공계 대우나 프로그래머 대우가 워낙
안좋은케이스가 많다보니... 이러한 대우가 결국 인력 부족을 가져오지 않았나 합니다. ( 저도 한국을 떠났지요.. )
C/C++ 은 정말 제대로 하기 어려운 언어라고 생각합니다. 게임쪽도 이제 C# ( XNA ) , JAVA 로 눈을 많이 돌리거나,
core 는 C/C++ 로 짜고 Lua , python 으로 control하는 케이스도 많이 있습니다.
여하튼 어떤 언어가 중요한게 아니라 프로그래머의 자질은 수학 , 논리적 사고력 , 커뮤니케이션 능력으로 결정된다고
믿고 있습니다. 따라서 가르쳐서 뽑으면 된다라고 생각하고 좋은 대우를 해주면 똑똑한 사람이 많이 모일것이라고
생각합니다. 어느 산업이던 어차피 뽑아놓으면 가르쳐야 겨우 쓸만해지기 때문에, 잘 가르치고 대우를 잘 해서 쉽게
다른 곳으로 이직하지 않게 관리하는게 중요하다고 생각합니다. C/C++ 은 그 기간이 최소 1년인게 문제지만...
경영자들이 lovu77님 같은 고민을 주로 하면서 회사를 경영했으면 아마 한국에서도 충분히 구글에 버금가는 소프트웨어
회사가 나왔을 것 같네요. 우리나라 소프트웨어 업계 경영자들은 다른 고민에 더 빠지기 쉬운 거 같습니다.
꼭 사람 탓 보단 환경을 탓하고 싶습니다만.... 아무리 어려운환경에서도 올바른 생각을 하는 사람이 있기는 있군요...
Neogeo - Future is Now.
Neogeo - Future is Now.
임베디드가 아니라도
임베디드가 아니라도 기업에 엔진을 납품하다 보면 C++ 컴파일러의 이식성을 고려해야 합니다.
gcc 3.x 대 컴파일러는 물론이고 오래 전 상용 유닉스 C++ 컴파일러가 있는 시스템도 있기 때문입니다.
이럴 때는 아싸리 C++을 C로 컴파일하고 그 C를 컴파일하는 게 낫습니다. (실제로 이런 상용 컴파일러도 있습니다.)
OCaml도 C백엔드를 써서 컴파일할 수 있기 때문에 이식성이 C++보다 떨어진다는 선입견은 옳지 않다고 봅니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
C++을 C로
C++을 C로 컴파일하는건 일부케이스에서나 돌뿐이고 도는 녀석도 어차피 손으로 다 다시 만져줘야 합니다.
( template 부분 특수화를 제대로 지원하는 녀석도 없고, template 인자를 이용한 상속만 사용해도 거의 포기해야 합니다. 그러나 C++ 에선 이미 필수적인 Modern Design Pattern 이지요. operator overloadig 같은 런타임에 타입을 체킹하여 집어넣는 여러가지 행동도 포기해야할 수 있습니다. )
gcc 3.x 대나 상용유닉스 C++ 컴파일러가 있는 환경을 고려할 필요는 없습니다. 그 머신에 맞는 바이너리를 만들어줄 cross 컴파일 환경을 얼마든지 구축할 수 있으니까요. ( 아예 그냥 컴파일러 깔아도 될텐데 gcc 가 안깔리는 유닉스는 이제 거의 없는것으로 압니다. 여하튼 깔기 힘들어도 최소한 cross 컴파일로 target cpu 바이너리를 만들 수 있습니다. )
혹은 오래된 소스와 혼합해서 사용해야 하는경우는 어떻게 하냐라고 해도 C 함수로 wrapping 해서 lib 형태로 바꾸어 사용하면 될 뿐입니다.
( 다만 template 은 헤더에 구현되므로 손이 많이 가는 상황이 오겠지요. ) 이런이유로 C++ 이식성은 다른 언어에 비해선 당연히 훌륭하다고 생각합니다.
( 절대적으로 컴파일러 지원이 훌륭하니까요. 표준외인 boost 조차도 arm 에 올리셨다고 kldp 에 어느분이 제 잘못된 지식을 잡아주신적도 있습니다. )
또한 Ocaml 이 C 백엔드로 컴파일 가능하다는 이유만으로 이식성이 결코 올라가지 않습니다. ( 실질적으로 가능한건 일부 케이스 뿐입니다. )
( 실질적으로 되나 자체도 좀 의문입니다만... )
따라서 C++이 이식성이 더 높다라는것은 선입견이 아니라 사실이지요. ( 예를들어 Sh C++ 컴파일러는 있어도 Sh Ocaml 컴파일러는 없으니까요. )
arm정도가 되어도 ocaml 컴파일러는 암울합니다. ( 100% 다 되진 않는걸로 알고 그나마 나오는 바이너리의 최적화도 형편없다고 들었습니다.
floating point 문제 조차도 해결 중인걸로 알고 있구요. )
언어의 저변에 해당하는 이식성은 오래 널리 사용된 언어가 아무래도 유리할 확률이 높지요.
Neogeo - Future is Now.
Neogeo - Future is Now.
엉뚱한 말씀을
엉뚱한 말씀을 드려서 죄송합니다.
여쭤보고 싶은게 있는데요.
C/C++ 개발자가 구하기 어렵다고 하십니다만
어느 정도 수준의 C/C++ 개발자를 말씀하시는 건지요?
C/C++ 개발자의 수준을 어떻게 평가하시는지
예를 들어 몇년동안 써왔다 이런저런 기능이나 라이브러리를 쓰고 있다
그렇게 평가하시는 기준이 있으신지 궁금합니다.
----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
http://www.asmlove.co.kr
http://blog.naver.com/gurugio
일단 제 맘대로의
일단 제 맘대로의 기준이 있습니다. 일반 상식과는 전혀 무관하오니 일반 평가기준으로 생각하진 마시고 참고하세요.
C++ 의 경우입니다.
1.C++ 문법 언어책을 봤다 - 입문 초기 상태
2.Effective C++ , Design Pattern 책을 보았다. - 입문 중기 상태
3.STL ref. 를 보면서 원하는 알고리즘을 STL을 사용하여 구현해 보았다 - 입문 후기 상태
4.More Effective C++ 을 보고 완전히 이해했다 - 중급
5.Modern C++ Design 을 보고 완전히 이해했다 - 고급 초기
6.Exceptional C++ 스리즈를 다 보고 완전히 이해했다 - 고급 중기
7.Boost 에 능숙하여 여러곳에 사용하며 template meta programming의 개념에 익숙하다 - 초고수 -ㅅ-
정도로 생각하고 있습니다. 책 본 순서가 마음대로일수도 있으니 뭐 뒤섞일수도 있지만 저정도를 갖추면 C++ 초고수 반열이라고
생각합니다.
C의 경우입니다.
1.C 문법을 봤다 - 입문 초기 상태
2.ABC(A book on C)를 이해하고 algorithm 을 어느정도 구현해봤다. Pointer를 완벽히 이해한다. - 입문 중~후기 상태
3.function pointer 를 자유자재로 활용하며 최적화의 개념이 있다. - 중급
4.inline ASM 조차 자유로우며 C compiler 를 어느정도 작성 할 수 있다. - 중급 후기
5.OS kernel 소스를 어느정도 디볐으며 각종 컴파일러나 메모리 조작 , 기계 이해도가 높다. - 고급
6.low level 에서 kernel 을 만들어 올려보았으며, multi thread 로 된 OS 나 RT OS 를 작성해 보았다 - 초고수
C++ 에 비해 언어의 공부에 포커스가 아니라 이것저것 다른것에 맞추어진게 아니냐 라고 보이지만
C 언어를 쓰는분은 PC 플랫폼 보다 다른 플랫폼을 고려할 경우가 현재는 많아보여서 나름 이렇게 기준을 정했습니다.
(-ㅅ- ) 참고로 저의 위치는 아직 낮은단계입니다 =3=3=3=3=3
Neogeo - Future is Now.
Neogeo - Future is Now.
개인적인
개인적인 기준이라고는 하셨지만...
C++은 책을 공부하는 걸로 고급 중기까지 이를 수 있는데 C는 인라인 어셈부터 커널 소스까지 봐야 고수의 반열에 오를 수 있다는 건 좀 unfair 하군요 ^^
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
The C++ Programming Language책을 보고 감동먹은 저는 아직 초보'도' 아니군요.
The C++ Programming Language책을 막 보고 감동먹은 저는 아직 초보도 아닙니다-_-;
---
"내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라."(빌립보서 4:13)
---
“내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라.”(빌립보서 4:13)
오!! 그래도 C를 10년
오!! 그래도 C를 10년 가까이 공부해왔는데 중급정도는 되네요.. 정말 기분 좋은데요~~
C 컴파일러는 쫌 난감한데요..
C++은 입문중기네요. 객체지향설계에 관해 공부하고 있는데
C로 삽질하던 저에게 완전 해머로 뒤통수를 갈기는 충격을 받고 있습니다.
C++을 중급정도까지 배워보고 리스프로 넘어갈까 했는데
중급단계를 보니 몇년 걸리겠는데요?
----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
http://www.asmlove.co.kr
http://blog.naver.com/gurugio
딴 얘기지만
결론 부터 말씀드리면, 위에서 언급된 대부분에 해당됩니다.
하지만, 제 맘에 드는 직장 구하기가 쉽지 않습니다.(물론 개인차가 있겠지만)
그래서, C/C++ 개발자가 구하기 어렵다는 말에는 동의하기 어렵네요.
본인이 위에
본인이 위에 해당하시는 분이라고 해도...
회사들에서 본인같은 분을 여럿 찾기는 어려울 수 있습니다. ( 하나도 찾기 힘들지도 모릅니다. 솔직히.. )
"본인이 원하는 직장을 찾지 못 했다고 해서 좋은 C/C++ 개발자 구하기 어렵지 않다"라는 말은 전혀 이치에 맞지 않는 논리이십니다.
실질적으로도 회사들 입장에선 여전히 좋은 C/C++ 개발자 찾기가 어렵습니다.
아주 좋은 대우를 해주려고 찾아보았습니다만 그래도 찾기 어려웠습니다.
위의 회사분과 관계는 없지만, 위의 회사 사장분은 어느정도 마인드를 가지신분 같은데 한 번 지원해보시는 것도 나쁘지 않겠네요 :)
Neogeo - Future is Now.
Neogeo - Future is Now.
위에서 neogeo님이
위에서 neogeo님이 말씀하신 "프로그래머의 자질은 수학 , 논리적 사고력 , 커뮤니케이션 능력으로 결정된다고 믿고 있습니다."를 철저히 신봉하는지라
지금까지 프로그래밍 언어 구사 능력에 대해서 크게 관심을 가졌던 적은 없습니다.
제가 특정 프로그래밍 언어의 구사 능력에 관심을 가진 것은 6개월 정도 밖에 되지 않아서 딱히 어느 수준이라고 드릴 말씀은 없습니다. 실제 자바 프로그래밍 밖에 해 본적이 없는 프로그래머가 1달도 되지 않아 C++를 자유롭게 구사하는 경우도 많이 봤거든요.
그래서 면접에서도 프로그래밍 언어 보다는 위에서 언급한 능력을 판단하기 위한 질문을 많이 하는 편입니다만, 프로그래밍 언어에 대해 주로 묻는 몇가지만 이야기 해 보겠습니다.
1. C와 C++의 가장 큰 차이점을 무엇이라고 생각하나요
2. 폴리모피즘에 대해 설명해 주세요
3. 가상 함수에 대해 설명해 주세요
4. 탭은 몇칸 쓰느냐 (ㅎㅎ 별거 아닌 것이지만, 자기가 쓰는 탭 크기에 대한 고민이 있는지를 묻기 위함 입니다. http://www.pdfpro.co.kr/blog/jeong/entry/8칸탭이-아니면-불합격 )
5. 사이드 이펙트에 대해 설명해주세요
월요일 오전이라 바쁘네요.. 대충 쓰고 이만 물러갑니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
저는 초보
저는 초보 개발자라서 감히 이런 말씀을 드리면 가증?스럽게 생각하시겠지만
쓰신 글이나 답변들에 답글 다신 것들을 보면
소프트웨어의 구조? 아키텍쳐라고 해야 하나요?
구현외에 큰 그림에 대한 고려를 언급을 안해주신 것이 느껴집니다.
물론 글로 안쓰신 것이지 고려를 하고 계시겠지요.
음.. 저는 대답할 수 있는 질문이 몇개 안되네요..
----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
http://www.asmlove.co.kr
http://blog.naver.com/gurugio
ㅎㅎ 아무래도
ㅎㅎ 아무래도 현재시점에서 말쓰하신 "큰 그림"에 대한 수요가 별로 없어서 그런가 봅니다.
저희가 하는 프로젝트들이 대부분 몇년은 지난 것들이다 보니 큰 그림이 이미 만들어져 있고, 지금 별다른 문제가 없어보여서 언급할 기회가 없었나 보네요.
개인적으로는 design만 좋으면 implementation은 아무래도 좋다 주의였었다, 최근에 implementation에 관심을 갖기 시작해서 더 그런것 같습니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
오라클 코딩
오라클 코딩 스타일인 OCCS나 GNU 스타일은 탭 2칸인걸로 아는데요 -_-
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
Ocaml 은 잘
Ocaml 은 잘 모르겠습니다만...
개발자 확보때문에 자바를 선택하는건 좀 아니라는 생각이 듭니다.
자바 개발자가 많기는 하지만,... 말씀하신것과 같은 기술을 구현해내는 자바 개발자는 쓸만한 C++ 개발자를
찾는것만큼 어렵다고 생각합니다.
대부분의 학원에서 뱉어내는 대부분의 자바 기술자들은 J2EE 관련 기술자들이 대부분이라..
파일 포맷이라던가 에 관련한 기술적 이해도가 상대적으로 낮습니다.
여기서 자바 개발자가 많다고 지적하신 매리트가 사라지는 것이지요...
도움이 안되는것 같습니만..
여러가지 리스크를 감내한느것보다는
저라면 잘 돌아가고 있는 소프트웨어를 더 개선하겠습니다.
동의합니다.
C는 시작한지 15년 정도(초등학교때 부터)됐고, Java는 3년 정도가 됐습니다.
Java에 대한 대부분의 장점은 환상이라고 할 수 있습니다.(보는 관점에 따라 견해차는 있겠지만, 특히 learning curve가 짧다는 것은 말그대로 환상)
요며칠 저는 c로 jni 라이브러리를 짜고 있습니다.
제가 지금 java를 하는 걸까요? 아니면 C를 하고 있는 걸까요?
저는 자바 개발자인데, 왜 Posix API를 쓸건지 SystemV API를 쓸지 고민하고 있을까요?
뭐 다른 입장에서;;;
먼저 전 개발자는 아닙니다... 헛소리 같아도 이해해주시길.
어떤 언어가 되었던 시간이 지나서 특정 솔루션에 유지보수에 문제가 생긴다고 하면, 그것은 초기 개발시 미래를 예측하지 못한 설계의 문제라고 봅니다.
개발자가 아니라서 그런 말을 하는지는 모르겠습니다만, 아무리 허접하다고 정평이 나있는 베이직도 잘짠 프로그램은 먹어줍니다..
그게 핵심이라고 보는데요,
물론 프로젝트에 알맞는 랭귀지를 선택하는 것도 중요하다고 생각됩니다만, 미래를 생각하고 requirement를 완벽히 수용, 그리고 미래를 예측하고 예측할 수 없는 부분을 모듈화할 수 있는 설계상의 지혜가 더욱 더 필요하다고 봅니다.(물론 아무리 그렇게 해도 3,4년 정도 되면 도루묵일 경우가 많습니다만,,,,1년 쓸 것이 2~3년으로 코드 주기가 늘어난다면 리소스 측면에 이득이 있겠지요.) 그리고 그런 언어적 기능은 요즘의 모던한 대부분의 랭귀지가 가지고 있는 기능이 아닌지요. 자바던 c++이던 말이죠.
그리고 지금 같이 일하시는 분들이 C++ 기반이라면 다시 c++로 더 좋은 설계로 재개발함이 어떨련지요. 전 언어의 우수성이나 뭐 그런것보다 사람의 우수성을 믿습니다. 코드를 다시 쓴다고 해도 자신이 직접 만든 코드의 문제점을 파악하여 다시쓰는 게 낫지, 아무것도 모르는 상태에서 언어를 공부하며 업무를 수행한다는 것도 만만치 않지요. 작업자가 익숙한 언어로 충분히 요구사항과 문제점을 이해한 상태에서 설계를 하는게 여러모로 나은 방법이 아닐까요?
걍.. 올만에 주저리거립니다. ㅋㅋ
힘없는자의 슬픔
힘없는자의 슬픔
좀 잘못 생각하고
좀 잘못 생각하고 계신듯합니다.
똑똑한 사람 손에는 뭘 쥐어주든 덜 똑똑한 사람보다 더 좋은 것을 만들어내기는 합니다만, 실세계에서의 경쟁은 같은 도구만을 사용하지는 않거든요.
저는 사람, 도구, 환경 세가지 조합이 performance(또는 throughput)을 결정한다고 봅니다.
간단히 레이싱에 비유해봅시다. (지난번에도 비슷한 글을 한번 썼던거같네요)
똑같이 100km정도를 누가 빨리 달리는지 측정한다고 합시다.
performance는 (슈마허, F1, 서킷) >> ... >> (나, 아반떼, 일반국도) 가 될것입니다.
그렇다면 생략된 "..." 중에서, (나, F1, 서킷)은 (슈마허, 아반떼, 국도)와 비교하면 어떨까요?
운전자가 아무리 뛰어나도 차량이나 환경조건이 최대 performance를 제한할 수 있습니다. 즉, 기량에 관계없는 한계가 존재한다는 거죠.
개발작업도 마찬가지입니다.
아무리 뛰어나다고 해도 한계요소가 있으면 그 한계요소에 지배를 받을 수밖에 없는 것입니다. 특히 개발 언어의 경우 표현력이나 생산성은 종류별로 엄청나게 차이가 납니다(언어 고유의 특성 및 문제 도메인의 특성 두가지 요소가 아마 지배적 요인인듯합니다).
또한 실제 개발 작업에서 미래를 예측한다는 것은 거의 불가능합니다. 예측해서 설계/구현하는 것은 자칫 과잉엔지니어링(over engineering)으로 자원낭비를 부를 수 있습니다. 기민하게 현재 시장에 반응하는 것이 최선이라 생각합니다.
그래서, Paul Graham은 Beating the Averages라는 글에서, 찾을 수 있는 것들 중 가장 좋은 도구를 써야만 한다고 주장했고, 실제로 그는 경쟁사가 새로운 기능을 발표하면 하루 이틀만에 자기 회사 제품에 동일한 기능을 추가하는 놀랄만큼 빠른 속도를 보여주었습니다.
예전에 읽은, 비슷한 비유지만 다른 내용의 글 : Lisp - The Ducati Of Programming Languages
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
확 땡기게
확 땡기게 만드시네요 ㅎㅎㅎ
예전에 12살에 PDP-1용 Lisp을 만들기도 했던 L. Peter Deutsch와 같은 회사에서 일했던 적이 있습니다. 이때의 영향으로 functional language에 대해 매우 호의적인 입장을 가지고 있으며, 좋은 툴의 중요성을 배운 것 같습니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
지금은 67세시군요...
할아버지일 듯.
지금 Design Patterns 책을 고전(?)이라는 느낌으로 읽고 있는데 참고문헌에 그의 Smalltalk 문헌이 있더군요.
능력 참 출중했던 듯...
그런데 어디서 일하신 거죠?
몇년전 은퇴하셔서
몇년전 은퇴하셔서 캐나다에서 살고 계십니다. 은퇴 직전까지 코딩을 하셨지요.
요즘은 고전음악 작곡을 취미로 하신다더군요 ㅎ
저는 Artifex Software에서 일했던 적이 있습니다. Ghostscript를 maintain하는 회사지요.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
재미난 주제군요...
몇자 적어봅니다.
> 문제는 C++로 만들어진 현재의 엔진의 유지보수가 매우 힘들다는 것입니다.
코드나 언어의 문제보다는 디자인, 설계상의 문제로 보여집니다.
혹 관심있으시면 product line, domain engineering, feature modeling 등의 소프트웨어 공법을
참고하시라고 권해드리고 싶습니다.
> C/C++는 프로그래머의 역량에 따라 결과물의 편차가 매우 큽니다.
> 아닌것이 어디 있겠습니까만
크, 정말로 아닌것이 어디있겠습니까만은 이런 편차를 줄이려는 노력이
소프트웨어 프로세스/방법론이겠지요. CMM 이나 Spice 등을 통해서 어느 정도는
결과물의 편차를 줄일 수 있으리라 생각됩니다.
> 이식성의 경우 Java야 문제가 안되겠지만 OCaml의 이식성이 어떤지 궁금합니다.
OCaml 사용층이 의외로 두텁기 때문에 생각보다는 많이 이식되어있으리라 생각합니다.
글타래에서처럼 현재의 프로그램이 윈도우 플랫폼 환경에서만 사용되고 있다면 큰 문제가 없을것입니다.
또한, OCaml을 ARM에서 쓰고 싶은데 어떻게 하냐는 질문을 본 적이 있는 것으로 보면
큰 문제가 없는한 ARM 등에서도 이미 사용되고 있지않을까 조심스럽게 예측해봅니다.
> 가장 큰 걱정과 문제는 엔지니어 확보입니다.
고급 자바 개발자라면 OCaml로 가는데 큰 문제가 없을 듯 싶군요.
또, 국내에서 OCaml 개발자라면 이미 중급 이상의 개발자일테고.
다만 문제는 OCaml로 큰 프로그램을 개발해본 경험이 있는 엔지니어를 구하신다면
몇년 기다리셔야 할 듯 싶군요. 그래도 국내 프로그래밍 언어 연구실 출신들 중에서
구하시면 상당한 실력자가 지금도 있을 듯 싶습니다.
서울대나 카이스트에선 nML 개발자나 사용자들이 있을터이고
포항공대에선 학부생 전산입문으로 OCaml을 사용하고 있고
MS의 F# 같은 경우엔 Visual Studio에서의 사용도 가능하다고 하니
개발환경도 좋아지고 있어서 저변 확대의 모든 준비는 갖추어져있다고 봅니다.
영 국내에서 힘드시면 유럽 쪽이나 일본 쪽에는 쓸만한 개발자들이 있지 싶지만
결국은 돈이 문제겠지요.
> 여러분들은 저희회사를 위해 어떤 프로그래밍 언어를 추천해 주시겠습니까?
저는 특정 언어보다는 일반적인 소프트웨어 방법론을 추천해 드리고 싶습니다.
현재의 시스템이 유지보수가 어렵다는 것은 언어의 문제보다는
방법론이나 아키텍쳐 수준의 문제로 보여집니다.
현재의 시스템 구조 등을 다시 분석하고
왜 자주 어떤 모듈에 변화가 가해지고 변경되는지
한 모듈의 변화가 다른 모듈엔 어떤 영향을 주는지 등이 분석된 연후에
그 특성에 맞는 프로그래밍 언어를 선택하셔도 늦지 않으리라 생각됩니다.
어차피 Java로 가시든 OCaml로 가시든 현재 프로그램을 분석하셔야 할테고
분석이 잘되어서 좋은 구조로 리모델링 되면 현재 사용하시는 언어로 계속
가실 수도 있으니 절대 손해보는 구조가 아니지요.
그리고 분석결과 만드시는 프로그램이 동적으로 변화되거나
인터넷을 통해서 수시로 업데이트가 되어야 한다든가
네트웍 통신 등의 요구사항이 있다면 Java로 가시는 것이 쉬울 것이고
모든 변동사항이나 유지보수 내용이 소스코드의 수정을 통하거나
정적으로 변하는 것이 대부분이면 OCaml로 가시면 더 수월하겠죠.
> 한두달만 배우면 자바/C++ 보다 훨씬 생산성이 높아질 테니까요.
> 아무래도 같은 수준의 프로그래머라면 OCaml이 훨씬 더 좋은 품질의 코드를 빠르게 만들 수 있으니까요.
OCaml 한두달 배워서 생산성이 자바/C++보다 높아졌다면 아마도 이미 SML/Haskell 전문가일 가능성이 높습니다.
사내에 OCaml 전문가가 수두룩해서 고급팁을 계속 해서 배울 수 있다면 가능하겠지만요.
적어도 module system이나 functor에 익숙해지기 전에는 어느 규모 이상의 프로그램을 작성하기
힘들 것입니다. 다만, 같은 수준의 프로그래머라면 OCaml이 더 좋은 품질의 코드를
빠르게 만들 수 있다는 데에는 전반적으로 동의합니다.
> 저희 프로젝트는 OCaml과 같은 functional language가 잘 먹힐 수 있는 분야로 보입니다.
120% 동의합니다. PDF 파서, 자료구조, 트리 옵티마이저 등에서는
OCaml같은 함수형언어가 제격일 것입니다.
이 부분에서만큼은 개발비용이나 유지보수 비용을 쉽게 줄일 수 .있을리라 기대해봅니다.
---
오랜만에 진지한 글을 읽어서 주저리주저리 해봤답니다.
결론적으로는 2년정도의 계획으로 새엔진을 준비하신다고 하시니
조그만 pilot 프로젝트를 만들어서 현재 프로그램의 subset을
Java나 OCaml로 만들어 보시는 것을 어떨지요.
팀내 인력이 부족하시면 공개 프로젝트로 KLDP에 게시하시거나
Code of Summer/Code of Winter 등에 제안하시는 것도 좋아보입니다.
참고로 OCaml로 개발하는 뉴욕의 한 회사는 여름마다
OCaml Summer Project (http://osp.janestcapital.com/wordpress/ )를 통해서
OCaml 언어자체에 발전에 기여하고 있답니다.
아니면, 프로그래밍을 연구하는 국내 연구실이나 대학원과
공동으로 간단한 프로젝트를 시작하시면 초기 교육비용을
줄일 수 있으면서 미래의 개발자 확보에도 도움이 되지 않을까 생각해봅니다.
또한, 함수형 언어 컴파일러에는 OCaml 말고도 SML/NJ, MLton, Haskell도 있고
F#, Scalar 등도 눈여겨 볼 만할 것입니다. 일본에서 만들고 있는 SML#도 있군요.
Scalar 의 경우엔 JVM 위에서 돌아가니 Java를 결정하신다고 해도 참고할 만하겠군요.
사족으로, 요즘의 시스템은 단일 언어로 개발하기 힘들어지고 있습니다.
또한, 서로 이종의 언어들이 연대해서 하나의 시스템으로 개발되는 사례가 늘고 있습니다.
개발하시는 시스템의 어떤 부분은 특정 언어가 유리하겠지만
전체 시스템을 하나의 언어로 개발하다보면 불리한 부분도 있을 것입니다.
그것을 어떻게 슬기롭게 하나의 언어로 개발할 것인가, 아니면
여러 언어를 지혜롭게 사용해서 하나의 시스템을 개발할 것인가,
그런 고민도 필요하지 않을까 생각봅니다.
>코드나 언어의
>코드나 언어의 문제보다는 디자인, 설계상의 문제로 보여집니다.
>혹 관심있으시면 product line, domain engineering, feature modeling 등의 소프트웨어 공법을
>참고하시라고 권해드리고 싶습니다.
>CMM 이나 Spice 등을 통해서 어느 정도는
>결과물의 편차를 줄일 수 있으리라 생각됩니다.
조언 감사합니다. 참고해보겠습니다.
그런데, 개발방법론에 대해 제가 잘 몰라서 그런 것인지 우리 프로젝트와 뭔가 잘 맞지 않는다는 느낌이었습니다.
*엔터프라이즈 어플리케이션*에나 적용될 수 있는 방법론이 아닌가 하는 의문이 늘 드는데, 어떻습니까?
>OCaml 한두달 배워서 생산성이 자바/C++보다 높아졌다면 아마도 이미 SML/Haskell 전문가일 가능성이 높습니다.
>사내에 OCaml 전문가가 수두룩해서 고급팁을 계속 해서 배울 수 있다면 가능하겠지만요.
>적어도 module system이나 functor에 익숙해지기 전에는 어느 규모 이상의 프로그램을 작성하기
>힘들 것입니다. 다만, 같은 수준의 프로그래머라면 OCaml이 더 좋은 품질의 코드를
>빠르게 만들 수 있다는 데에는 전반적으로 동의합니다.
현재 사내에 functional language에 대한 경험이 있는 프로그래머들은 없습니다.
학교에서 lisp이나 Scheme 프로그래밍을 배운 사람들은 있을지도 모르겠네요.
결국 한두달로는 어렵겠다는 말씀이군요. ㅎㅎ
엔지니어라면 업무시간의 절반은 실제 회사일을 하고, 나머지 절반정도는 공부를 해야한다고 믿습니다.
(아직 이 원칙이 잘 지켜지지는 않습니다만)
그런 관점에서 본다면 functional language에 대한 지식이 지금은 없다 하더라도, 길지 않은 시간 내에
생산성을 확보 할 수 있지 않을까요? 아무래도 OCaml 같은 언어들의 learning curve가 더 좋으니까요.
>팀내 인력이 부족하시면 공개 프로젝트로 KLDP에 게시하시거나
>Code of Summer/Code of Winter 등에 제안하시는 것도 좋아보입니다.
매력적인 아이디어입니다. 진지하게 고민해 보겠습니다. 만약에 저희 회사가 OSS로 PDF 엔진을 개발하게 된다면 많은 관심 부탁드립니다. ㅎㅎ
귀한 시간 들여서 해주신 좋은 조언 말씀들 감사합니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
대표이사님의 철학을
대표이사님의 철학을 보니
기회가 된다면 일해보고 싶어지는데요?
업무시간을 반으로 나누는게 아니라
삶 자체를 가족-공부-일로 3등분해야 한다고 생각을 하고 있었습니다.
예전에 CMM, SPICE에 대한 설명을 조금 들은 적이 있습니다.
CMM, SPICE는 임베디드 개발도 가능하다고 설명은 있었지만
개발 방법에 대한 논의보다는 개발 단계의 관리에 대한 내용이 더 많았다는 기억이 납니다.
그래서 더 자세히 들여다보지 않았었는데
어쨌든 개발 규모와는 상관이 없었던걸로 알고있습니다.
CMM, SPICE는 굉장히 방대한 내용이 있어서 개발 방법론도 있을것 같긴 합니다.
원래의 목적은 그 회사가 얼마나 프로세스를 가지고 있고 잘 준수하고 있는지 평가하는 것이라던데요.
----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
http://www.asmlove.co.kr
http://blog.naver.com/gurugio
>대표이사님의
>대표이사님의 철학을 보니
>기회가 된다면 일해보고 싶어지는데요?
고맙습니다. 문제는 생각하는데로 실천이 어렵다는 것 같아요. 실제로 보시면 말만 번지르 하다고 생각하실까 두렵습니다. ㅎㅎ
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
Scalar 가 아니라 Scala
Scalar 가 아니라 Scala 입니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
남의 회사에 개발
남의 회사에 개발 도구를 추천하는 것이 조심스럽기는 하지만,
저는 Common Lisp 또는 Erlang을 추천하고 싶군요.
OCaml은 안써봐서 잘 모르겠습니다. ^^;
정말로 하고싶은 이야기는, 제가 Paul Graham을 좋아하게 되었던 그의 글 중에 나오는 말인데...
위원회에서 만든 언어는 비추라는 것입니다.
즉, 위원회라는 그룹을 조직해서 점잔빼고 앉아서 그들의 생각에 저능(?)인 노동자를 쉽게 교육시켜 부려먹을 생각으로 만든 언어들(ada, java 등)은 몹쓸 것들 이라는 견해죠.
역사속에서 강력함을 증명했고 지금도 강력한 언어들(C, Lisp, Erlang 등)은 뛰어난 해커가 자기가 직접 쓰기위해서 만들었다는 공통점이 있다는 그런 주장입니다.
Paul Graham이 lisp이라는 도구로 성공을 한 사람이라 그런 주장을 하는 것일 수도 있겠지만, 저에게는 대단히 설득력있게 다가온 말이었습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
Erlang 코드가 좀더
Erlang 코드가 좀더 우아해 보이는 것 같더군요. ㅎㅎ
라이브러리라던가, 커뮤니티의 규모 같은 면에서도 Erlang을 추천하시는지요? 그리고 얼랑은 VM위에서 돌아가는걸로 아는데, 퍼포먼스 측면에서는 어떤지?
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
대충 생각나는 것만 써보자면...
라이브러리:
Programming Erlang의 부록에 있는 라이브러리 함수들을 보시면 많이 보던 함수들이 있을 겁니다. POSIX layer를 거의 지원하는 듯합니다. 그리고 OTP(Open Telecom Platform) library를 보시면 다양한 종류의 서버모델들이 기본으로 지원되는 것을 볼 수 있습니다.
커뮤니티:
솔직히 잘 모르겠습니다. 우리나라는 거의 없는듯하고, 외국에는 제법 활성화된 trapexit 같은 온라인 커뮤니티도 있는 것으로 압니다. 적용 사례는 통신사나 은행등에 (성공적으로) 적용된 사례가 있는 것으로압니다. 필요하면 상업적 지원도 가능할겁니다.
퍼포먼스:
HiPE라고, High Performance Erlang이라는 독립된 프로젝트가 있었는데 그것이 Erlang에 포함되었습니다. native code로 컴파일하는 것으로 압니다. 다만, 몇몇 플랫폼에서는 VM 모드로만 동작하는데 앞으로 플랫폼 지원은 늘어날것으로 압니다. 성능쪽에서 erlang이 매력적인 것은 별다른 코드 수정없이도 core가 늘어나면 성능향상을 기대할 수 있다는 점입니다. 앞으로 멀티코어가 대중화되면 지금보다 좀더 주목받을 것이라 생각합니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
Erlang은 병렬처리
Erlang은 병렬처리 성능은 몰라도 serial하게 batch로 돌리는 데는 성능이 다른 함수 중심 언어보다는 그렇게 좋지 않습니다. 그런 성능이 중요하다면 OCaml이 훨씬 좋습니다. HiPE 는 성능이 어떻나요?
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
개인적으로는, 예전에
개인적으로는,
예전에 java로 개발했던 것들을 erlang을 이용해서 재작성 하고 있는데,
HiPE에 관해서는 심도있는 테스트는 해보지 않았습니다.
지금까지는 erlang의 VM 모드로 돌려도 예전 java로 만든 시스템보다 조금더 빨라진듯해서 그냥 VM 모드로 개발 중입니다.
지금은 "make it right before you make it faster"에서 make it right의 단계라 속도에 관해서는 확답을 드릴 수가 없네요. make it faster의 단계가 정리되고, 기회가 되면 글을 한번 올리겠습니다.
current 쪽 관련해서는,
확실히 erlang이 놀라운 성능을 보여주는 것같습니다.
저의 테스트는 아니고, 이곳저곳에 많이 올라와있는데 두개만 링크하겠습니다.
Yaws vs. Apache
Erlang on the niagara - Programming Erlang을 읽기전에 접했던 글(메일)인데, 책에서도 비슷하게 언급이되더군요.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
그래도 표현이 좀 심한듯...
Ada, Java는 지금도 잘 쓰이잖아요.
Ada 위원회는 어떤지 모르겠습니다만 JCP도 나름대로 개방적인 것 같고...
표준화 위원회의 표준화 작업도 요새는 많이 공개되어 있는 것으로 압니다.
자기가 직접 쓰기 위해 만들 때는 남을 생각하지 않는 오류가 생길지도 모르겠는데...
뭐, Lisp은 역사 속에서 수많은 사람들의 손을 거쳤으니...
OSS의 옛 교훈인 '자신의 가려운 부분을 긁는다'은 정말 설득력 있다고 생각합니다.
위원회라고 불린 소위 윗사람이라고 생각하는 그룹에 대한 불신도 그렇구요. ^_^
Paul Graham이 약간 말을
Paul Graham이 약간 말을 심하게 합니다. 좀 잘난체도 있는 듯하고요. start-up 회사가 평균적인 도구를 쓰면 망한다는 논조의 글도 있습니다. 여기서 평균적인 도구에 해당하는 것이 언어로는 java 같은 것이지요.
JCP가 폐쇄적이거나 한 그런 거보다는 개발자 입장에서는 지금 당장 제품을 어떻게 만드느냐가 제일 관건이라고 봅니다.
Practical Common Lisp에 보면, JCP에서 새로운 문법하나를 추가하는데 1년 6개월이 걸렸다는 예를 들어서 설명하고 있습니다.
Lisp은? 필요한 문법이 있으면 그냥 만들어 쓰면됩니다(macro). 간단한건 생각에 1.6초, 타이핑에 16초정도?
말그대로 DSL을 만들어서, 종국에는 목표시스템에 적합한 언어를 가지게 되는 것입니다.
Paul Graham의 (심한) 표현 하나를 더 소개하자면,
경쟁사가 구인란에 "java, oracle" 이라고 써서 사람을 구하면 '이 회사는 별볼일없군(망할꺼야)'이라 생각했고,
"python, mysql/pgsql" 이라고 내면 좀 긴장됐었는데 "lisp"이 포함된 구인광고는 없어서 그나마 안심됐다고 회고 하는 글이 있었습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
파서를 만들 때는
파서를 만들 때는 타입 시스템이 제대로 된 언어를 쓰는 게 좋습니다.
심지어는 Smalltalk 책까지 쓴 스몰토크 구루조차도 파서같이 되도는 구조가 복잡한 자료를
다룰 때는 타입 시스템이 있는 것이 더 편한 것 같다고 하시더군요.
그런 점에서 Erlang이나 Lisp은 원글 쓰신 분의 목적에 부합하는 언어는 아닙니다.
OCaml이나 Haskell이 합리적인 선택이라고 생각합니다.
성능이 매우 중요하다면 OCaml 이겠지만 프로그램을 짜기에는 Haskell이 좀더 편하다고 생각합니다.
(복잡한 거 안따져도 일단 문법부터가 ...)
OCaml 컴파일러는 프랑스 컴퓨터 관련 학계와 산업계의 자존심을 상징하는 물건이라고 해도 과언이
아니므로 컴파일러 지원이나 유지보수 문제는 전혀 걱정하실 필요가 없습니다. 프랑스의 국가연구소인
INRIA 콧대높은 프랑스 넘들의 자존심을 걸고 만드는 물건인 만큼, INRIA 연구소 및 프랑스 주요
그랑제꼴이 갑자기 폭탄맞아서 그거 관련된 사람들이 다 죽지 않는 이상은 걱정하지 않으셔도 됩니다.
게다가 이미 연구 분야는 물론 산업에서도 널리 사용되고 있고 프랑스에서만 쓰는 게 아니라 다른
나라에서도 물론 쓰고, Java 보다 역사가 오래된 언어이니 언어 스펙 자체도 안정적이고요.
OCaml을 C컴파일러를 통해 컴파일할 수 있기 때문에 gcc크로스 컴파일러를 타면 gcc가 지원하는
환경으로 원론적으로는 컴파일을 할 수 있는 것으로 알고 있는데, 실제로 자세히 들어가면 런타임이나
라이브러리는 어떤 식으로 링크해야 하며 어떤 문제가 있을 수 있는지는 저도 잘 모릅니다.
Haskell은 아직도 떠오르는 별이므로 한번쯤 고려해 보세요. 비슷한 언어로 네덜란드에서
만드는 Clean이라는 놈도 있는데 이게 성능은 OCaml에 필적할 정도로 좋은데 사용자 층이
좀 적은 것 같더군요. 네덜란드를 좋아하신다면 (Concurrent) Clean도 한번 고려해 볼 만 합니다.
P.S. 우리나라의 이야기는 아니지만 미국의 어떤 리눅스 회사가 함수형 언어를 사용한다는
포지션으로 구직 공고를 메일링 리스트에 올렸더니 기한이 지나서도 문의가 계속해서
쇄도하는 바람에 더 이상 구직 공고를 올릴 필요도 없는 지경에 이르렀다는 이야기를 들었습니다.
OCaml을 사용한다는 것만으로도 함수 중심 언어를 다룰 줄 아는 개발자들의 이목을 집중시킬 겁니다.
서울대 포항공대 한양대 등의 컴퓨터 쪽 학과에 현재 OCaml 혹은 그와 매우 유사한 언어로
실습을 하는 과목이 열리는 것으로 알고 있습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
파서쪽이라면,
Erlang에는 LALR-1 Parser Generator인 yecc이 있습니다.
간단한 grammar + scanner로 특정 기호표기법을 파싱하는 것을 만들어본적이 있는데 편하고 좋더군요.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
타입 시스템이
타입 시스템이 강력한 언에에서는 굳이 parser generator와 같은 툴이 아니라
Haskell의 Parsec과 같은 Parser Combinator Library를 만들어서 쓸 수 있습니다.
C++에서 비슷한 것을 찾자면 Spirit 같은 것이 있죠. (아마 지금은 boost에 포함된 듯)
컴파일이나 링킹에서 에러가 나도 파서생성툴에서 만들어 내는 코드에서 에러가 나는 것이
아니라 프로그래머가 직접 짠 코드에다 대고 컴파일러에서 직접 에러메시지가 나오고 같이
컴파일되기 때문에 소스 관리하기도 편하고 여러가지 장접이 있습니다.
dynamic typed 언에어서도 이런 걸 만들어 쓸 수 있긴 한데, 파서를 잘못 조합했을 때
컴파일 전에 에러가 잡히는 게 아니라 한참 돌다가 쪽나는 부분에서 에러가 나기 때문에
디버깅하는 것이 어렵습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
PDF 파일 파서 제작을
PDF 파일 파서 제작을 논의하는 문맥이 아니였던가요?
언어 디자인의 관점에서 타입 체킹으로 얻을 수있는 이점은 일정부분 있는 것으로 압니다만,
다른 부분은 무슨 말씀이신지 조금 이해가 안갑니다.
개발과정이나 프로그래밍 언어적 측면이 아니라, PDF 파싱에서도 이득이 있다는 말씀이신지?
만약 그렇다면 좀 자세한 설명 부탁드립니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
PDF 파서 제작을
Parser Combinator Library로 PDF 파서 제작하는 걸 이야기하고 있는 중이었습니다.
Parser Combinator Library가 있으면 굳이 parser generator에 의존하지 않고
그냥 라이브러리 수준에서 혹은 다른 말로 embdded DSL로 PDF 파서 등의 파서를
하나의 프로그래밍 언어 내에서 만들 수 있죠. 중간에 다른 코드생성기가 필요 없이요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
제 질문은 만들수
제 질문은 만들수 있다 없다가 아니라, 이점에 관한 것이었습니다.
님의 방법을 사용하면 "(E)BNF -> Parser Generator -> Parser"의 과정보다 더 나은 무언가가 있는 것처럼 말씀하시는 듯해서요.
제생각에는 EBNF로 만들어두면 다른 언어에서도 동일한 시스템을 구축하는 것이 용이할 거라고 생각합니다만 (Parser Generator가 있다는 전제하에), 님의 생각은 저랑 조금 다른 것같군요.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
Parser Generator 를 거친
Parser Generator 를 거친 코드에서 에러가 났을 때 그것이 원래 EBNF 어디에서 에러가 났는지 원인이 무엇인지 역추적해 들어가는 과정이 훨씬 더 어렵습니다. Parser Combinator Library 에서는 컴파일 타임에 아예 컴파일도 되지 않을 에러가 런타임에 파서 제너레이터를 무사히 통과한 다음 정정 타입조차 없는 언어라면 아예 런타임에 에러가 나버리죠.
파서든 무슨 프로그램이든 짜다가 가장 많이 하게 되는 일이 무었을까요? 바로 잘못된 에러 코드를 보고 디버깅을 하는 것입니다. 그렇게 한참을 거치다가 마지막에 제대로 돌아가는 코드를 얻는 것이죠. CPU 인스트럭션 설계에서부터 소프트웨어 설계에 이르기까지 가장 빈번한 동작에서 효율을 높이는 것이 기본입니다. 그렇다고 한다면 코드 제너레이터를 거치는 것보다는 가능한 한 하나의 프로그래밍 언어 시스템에서 최대한 정적으로 에러를 빨리 어디서 났는지 신속하게 알 수 있게 하는 것이 중요하겠지요.
또한 EBNF가 있더라도 어차피 다른 언어로 출력을 내려면 파서 제네러이터가 별도로 다른 언어를 생성하는 백엔드가 있어야 합니다. Parser Combinator 라이브러리리를 한번 사용해 보시면 아시겠지만 이것도 EBNF 형식을 거의 그대로 쓸 수 있으며 다른 언어로 출력을 할 수 있도록 프로그램하는 것도 당연히 가능합니다. Parser Generator를 포함한 소스코드 생성기는 프로그래밍 언어가 충분히 일반적이지 못한 단점을 보완해 주기 위한 차선책이지 한 프로그래밍 언어 내에서 구현된다면 사용할 필요가 없습니다. 컴파일러를 한번만 거치면 될 일을 별도의 툴을 거쳐서 뭘 생성하고 하는 것 자체가 복잡성만 높이는 일입니다. Lisp이나 Smalltalk 같은 동적 타입 언어에서도 이런 Parser Combinator 라이브러리를 못 만드는 것은 아닌데 정적 타입 시스템이 없기 때문에 에러 잡는데 애를 많이 먹습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
caml 메일링 리스트를
caml 메일링 리스트를 뒤져 보니 ARM 크로스 컴파일링은 가능합니다.
이미 여러 사람들이 시도해 본 듯 하네요.
Haskell도 ARM에 올린 사례가 있습니다. 그런 관련된 일을 하는 기업도 있고요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
저보고 프로그램을
저보고 프로그램을 짜라고 하면 Haskell이 더 마음에 듭니다만 (미학적인 측면일지도요 ㅎㅎ),
성능을 따지지 않을 수 없네요. PDF 리더들의 속도 문제는 많이 경험하셨을 겁니다.
OCaml도 imperative하게 짜지 않으면, 성능이 잘 나올지 걱정이긴 합니다.
>OCaml을 사용한다는 것만으로도 함수 중심 언어를 다룰 줄 아는 개발자들의 이목을 집중시킬 겁니다.
노리는 바 이기도 합니다. ㅎㅎ 절대적인 이력서 개수는 적겠지만, 내공있는 프로그래머들에게는 호감을 사리라 기대하고 있습니다.
이직을 막아주는 부수적있 효과도 있겠군요. ㅋ
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
음...인력확보 부분을 양보하시면..
LISP 은 어떻까요? 확장성, 안정성 이야 최강이고. 요즘 컴파일러는 C++ 비슷,혹은 더나은 성능을 보입니다.
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
모든 것을 하나로
모든 것을 하나로 통일한다는 것은 효율적이지도 않고 무모하다고 생각합니다.
저 같으면 가장 독립적이고 작은 부분 부터 java나 ocaml로 진행하면서 경험을 쌓은 후 코어한 부분에 점진적으로 적용시킬 듯 합니다. java의 경우 좀 더 큰 규모로 옮겨가도 상관 없을 듯 하구요.
인력수급 측면을 제외하고라도 사용자 층이 두텁다는 것은 많은 장점이 있다고 생각합니다. 이미 구현된 reference들과 교육용 교재가 많다는 거죠. 특히 java는 웹 개발에서 거의 표준으로 자리 잡았기 때문에 프레임 워크도 많고 수 많은 시행 착오들의 결과물들이 인터넷에 많이 있습니다. 웹 프레임워크를 제외한 일반적인 라이브러리도 말이죠. OCaml, erlang, lisp 등이 java 보다 "언어적"으로 낫다고 하더라도, 평범한 개발자가 그 언어로 할 수 있는 일은 자바가 훨씬 많을 겁니다. 가져다 쓸 게 원체 많으니까요.
그건 그렇고...
함수형 언어 사용자를 구인한다면 대우가 좋지 않으면 안 될 것 같은데... ^_^
회사 여력이 어떤지요?
뛰어난 programmer들을 고용하신다면 좋겠지만 그렇다고 기존 직원들을 내치시는 것은 문제일테니까요...
고용하신다면 1~2명 정도 생각하시나요?
어쨌든 언어 재교육은 쉬운 것이 아니라고 생각합니다.
더 큰 것을 얻기 위해서 지금 쥐고 있는 것을 내려 놓아야 한다는 말은 제대로 보여주는 사례니까요.
언어만큰 다양한 것의 연관관계가 얽힌 것이 없다고 생각합니다.
그리고 그것들이 거의 직접적으로 움직이지 않으면 효율이 크게 떨어지죠.
새로운 paradigm을 도입한다는 것은 기존의 판을 완전히 다시 짠다는 것이니까.
함수형언어
함수형언어 프로그래머가 아니라 누구라도 대우가 좋아야 겠지요.
대우를 나쁘게 하면서 좋은 결과 기대 하지말라는 것은 누구나 아는 사실이잖아요. ㅎㅎ
오히려 기존의 프로그래머들에게 더 좋은 기회가 될 것이라고 믿는 측면이 강합니다.
모던 프로그래밍 언어를 배우고 현실에서 사용함으로써 프로그래머 자신의 몸값을 올리고 가치를 높일 수 있는 기회가 되지 않을까요?
일년 내내 구인을 하고 있습니다만, 기본적인 아이디어는 기존 프로그래머들에게 더 나은 도구를 제공해서 생산성을 높이자 입니다.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
이식성.. C 만큼
이식성..
C 만큼 좋은것도 흔지않아보입니다.
프로그래머의 수급
C/C++ 인력이 부족합니까?.
혹시 보수를 제대로 안쳐주신거 아닌가요?
제가알기론 동급인력 동급비용으로 자바보다 훨씬 구하기 쉬운걸로 압니다.
다만 글내용으로보아 중고급이상구하셔야겠죠..또한 적당한인력을구한다면말이죠..
"C/C++는 프로그래머의 역량에 따라 결과물의 편차가 매우 큽니다." <- 맞는말입니다.
그러니 잘구하시고.. 보수를 충분히 지불하세요.. 아시듯이 잘만구하면 C/C++의경우는 다른언어에비해 ..
결과물또한 기대이상으로 좋아질겁니다.
생산성, 안정성
C/C++의경우 프로그래머가 어느정도의 역량이 넘어서면 다른언어보다 훨씬 생산성과 안정성이 증가 하는언어입니다..
그냥 일반적으로 개발 하시길원한다면.. java 나 다른언어를 선택하시면될듯합니다.
유지보수
고급기술자가 개발하고 초급을 시켜유지보수시킬 작정이시라면 C/C++을 선택안하시는게 좋을듯합니다.
유지보수또한 어느정도 실력이 되는사람을 뽑는다면.. 유지보수측면에서도 기타언어에비해 인력면에서 이득을 보게될겁니다.
C/C++언어의 특징상 매우효율적으로 작성될수도 있는 언어입니다. 그만큼 적은인력으로 유지보수도 가능하다는뜻이지요.
반대로 매우 난잡해질수도 있습니다. 그러니 그 기준점을 넘어서는 인력으로 개발유지보수 하십시요..
그사람을 알아보는눈은 사장님의 몫입니다.
특히나 C/C++은 머릿수로 그런효율적인 개발이 되지 안는다는건 잘알고 계실거라 봅니다..
높은성능
C 를 추천합니다. ..
"이미 Numerical code의 성능도 인텔 하드웨어에서 Java가 C++에 비해 20% 정도밖에 느리지 않을 정도라니 .."
직접한번 성능비교를 해보시는것도 좋을겁니다.
제가 이런말해서 발끈하는 분들도 계시겠지만...
주로 java측의 성능비교(거의차이가 없다) 의 코드를 가져와 직접테스트해본적이 있습니다.
각각 양쪽최신컴파일러로 최적화 옵션으로 비교테스트해본결과 대부분의 코드가 약250% 이상 성능차를 보였습니다.
많은경우 테스트자체가 잘못되었더군요.. 최적화 옵션을 안주었거나.. 자바는최신컴파일러 C는 오래된컴파일러..
코드상의 차이.
java가 250% 이상의
java가 250% 이상의 성능차를 보일정도로 이젠 느리지 않습니다.
runtime 에 최적화가 되는 이야기도 있고 이 이야기는 새로운 논쟁을 일으킬 위험이 있으니 이전 topic 에 찾아 그 이야기를 하는게 나을 것 같습니다.
그리고 상황에 따라 매우 다르기때문에 단순비교도 불가능합니다.
어떤 언어가 더 빠르다 라는건 이제 별 의미없는 플레임에 가까울수도 있으니 이러한 이야기는 되도록 삼가하는게 좋을듯 합니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
직접해보시고
직접해보시고 이야기하시는건지요..
더차이났으면났지 덜나지 않을듯싶네요..
물론상황에따라다르지요.. 해보시면 대부분 상황에따라 더많이나는경우를 보게될겁니다.
그리고 언어가 빠르다라는게 별의미가 없다구요? 과연그럴까요?
무슨기준에 그런말을 하시는지 모르겠군요...
빠르면 빠른만큼 이득입니다.
두배 빠르다는것이 얼마나큰 이득을 가져올지 계산해보죠.. 단순하게. 하드웨어 성능이 반쪽짜리 구해도 되겠죠..
자 수억원나가는 장비라면.. 몇억원의 싼장비를 구해도 동일 성능을 내겠죠? 몇억원 절약되었습니다.
작은 기기에 들어가거나 환경적 제약사항이 있는곳은 돈을투자하여 기기의성능을증가하고 싶어도 하질못하죠?
요즘 PC들 성능참좋아졌죠.. 그러면 더이상 성능좋은 PC는 불필요한가요? 전아닙니다. 빠르면 빠를수록더좋고.. 아무리빨라져도
더빠른 PC를 얻기를 원할겁니다.
아마도 10~20% 더빠른 CPU를 사기위해 두배에가까운 돈을 지불하는 사람들을 흔하게 보셨을겁니다.
마찬가지죠..PC가 아무리빨라져도 소프트웨어가 더빠르게 동작하면 그또한 그만큼 이득입니다 아무리빨라져도 더빠르게 동작하면 그만큼더이득입니다. 또한 더빠르길원하죠.. 더많은 적업을 시킬수 있으니까요..
요즘속도는 별의미없고 플레임이다? 그러니 속도를따지지말자? 전이말을들으면 마치 자신의 단점을 개선하려하지는 않고 숨기려고만 드는 패배주의처럼들려 동의할수 없습니다.
이미 KLDP 에는
이미 KLDP 에는 6페이지상에 걸쳐 본 논의가 진행된적이 있습니다. 그 상황을 아시고도 이런소리를 계속하신다면야 할말없습니다만.
충분히 비교 되었고 충분히 해볼만큼 한 토픽으로 생각합니다.
제 글은 상황에 따라 너무 변수가 많기에 비교하는게 의미가 없다지 빠른게 의미없다는 의미가 아닙니다.
즉 어떤 언어가 빠르다 라고 비교하는 행위자체가 논리나 설득력을 갖추기가 힘들기에 의미가 없다는겁니다.
단순히 루프 몇번 돌려보고 이언어가 빠르다고 주장하기엔 수많은 변수가 존재하기 때문이죠.
제 글을 어떻게 해석했는가 모르겠지만, 말씀을 너무 심하게 하시는군요.
공부 열심히 하시는건 좋지만 다른사람의 글을 제대로 읽는 법부터 배우시는게 좋을것 같습니다.
패배주의라니요, 본인이 오히려 '성급한 일반화'를 하고 있는게 아닌가 생각해보셔야 할 것 같습니다.
다시한번 말씀드리지만 전 결코 속도는 별 의미없다고 한적이 없습니다. 따라서 위의 모욕적인 말을 들을 어떤 이유도 없습니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
제가말을 심하게
제가말을 심하게 했다면 죄송합니다만..
님또한 분명 "언어가 더 빠르다 라는건 이제 별 의미없는 플레임에..." 이라고 하셔서 그렇게 생각되었습니다.
궂이 토론하실생각이 없으시면 끌어들이지 않겠습니다.
저는 기존에 7페이지의 토론이 있었건 어쨋든, 토론이 덜됬다고 생각되거나 그토론조차 모르고 계신분이 있다고 생각되니,
이미 알고 계시거나 관심없으시면 궂이 더이상 이런토론꺼내지마라 면박주느니보단 지나가셔도 될일아닌가요..
현실적인 답안..ㅎ
가장 현실적인 답일지도..하지만..조금만 첨언하면
저는 멀티미디어 관련 real-time 시스템 개발 일을 하고 있습니다.
처음 3년 정도까지는 C/C++ 을 사용했고
1년 정도 C++ Builder
그후 5년간은 LISP 과 C++ 를 섞어서 쓰고있습니다.
C/C++ 좋은 언어입니다. 고속으로 돌아야되는 함수나 모듈을 만들기에 이것만한게 없더군요 (어설픈 어셈보다 빠릅니다)
하지만 프로젝트가 커지고 복잡해 지기 시작하면..악몽입니다. 특히 쪼금쪼금식 발생하는 메모리 leak 디버깅하는건 악몽이죠..
또 C++ 는 초기 클라스 설계가 한번 정해지면 나중에 가서 구조도 못바꿉니다..사실상 리팩토링 불가..
이런 저런 방법을 써보다..저한테 제일 편한 방식은 고속처리 함수나 모듈은 C로 짜서 DLL로 붙이고 전체 프레임웍이나 구조는 LISP 으로..
요즘 LISP 컴파일러 무지하게 빠름니다. float 처리할때는 C 보다 빠르기도 하고요.
제 생각은..C/C++ 로 대형 프로그램 짜는건 너무 많은 노력이 필요하기에 함수언어로 메인구조를 짜시고 고속모듈만 C로 하면 어떠실런지.
C 모듈에서 인라인으로 MMX 로 처리하면 이미지 프로세싱 같은건..정말 날라 다닙니다..
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
개발 히스토리가 이해가 안됩니다
위 말씀대로면 1 년 6 개월 동안 ANSI C 로 개발한 엔진을
겨우 1 년도 채 사용 못하고 C++ 로 전환했고
C++ 로 전환한 엔진을 2 년여 정도 사용하고
또다시 다른 개발 플랫폼으로의 전환을 고려한다는 말씀이
매우 이해가 안됩니다.
그간의 개발 히스토리를 보면
사내에 기술력을 가진 개발자분들이 계시거나 계셨던걸로 보이고
엔진 자체도 여러가지 예외처리가 많이 누적되어서
보기에 안 이쁠지언정 안정성은 많이 확보되었을리라 생각됩니다.
개발 플랫폼을 전환하려는 판단이
대표님 스스로의 판단인지
개발자분들의 요구에 의한것인지가 궁금합니다.
개인적으로 엔진의 개발 플랫폼을
그렇게 쉽게 자주 바꿀려는 판단에 매우 놀랐습니다.
C에서 C++로의 전환은
C에서 C++로의 전환은 상대적으로 쉽게 이루어 졌습니다.
원코드가 OO적으로 만들어 져 있었기 때문에 큰 무리가 없었습니다.
10일 정도 만에 완료 했던 것으로 기억하고, 바꾸는 와중에도 리그레션 테스트는 문제없이 통과할 수 있었습니다.
당장 쓰고 있던 엔진을 폐기하겠다는 것은 아닙니다. 말씀드렸듯이 지금부터 2년 후 정도에 쓸 엔진을 준비하려 하는 것이지요.
위에서 언급한 여러가지 문제들 때문에.
판단은 지금까지는 제 판단입니다. 제 생각이 정리되면 다시 논의를 시작할 예정이고요.
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
--
Jeong
http://www.pdfpro.co.kr/blog/jeong
원래 질문의 취지에서 많이 벗어난것 같아 보이지만....
OCaml의 안정성은 C++과 비교할 바가 못되고,
=> Ocaml의 안정성(stability)의 근간은 안전성(safety)의 덤이라고 생각합니다. static strong type checking, Hindley–Milner type inference algorithm 과 제한적인 imperative feature(포인터등) 들 때문에 생기는 것이라 생각합니다.
두 언어 모두 유지보수, 안정성, 확장성에는 최소한 C++ 보다 좋다고 생각합니다.
=> 한 4년간 Ocaml을 사용해본 결과 Ocaml역시도 OOP를 잘 따르는 것이 중요하다고 생각합니다.
Ocaml은 매우 적은 양의 코딩만으로도 원하는 결과를 구할 수 있기 때문에 OOP를 대부분 하지 않습니다.
대신에 모듈단위로 쪼개어 놓지요. 오랫동안 Ocaml을 사용했지만 한번도 유지보수가 쉽다는 생각은 않했습니다.
아무래도 제가 부족한 탓이겠지요. 그렇지만 Ocaml로 프로그래밍을 하게되면 매우 높은 추상화단계의 생각을
코드로 옮기게됩니다. 따라서 정확히 "그 코드"를 작성한 프로그래머와 "동일한" 생각을 해내야만, 그 코드가 이해가
되는 것이죠...따라서 Ocaml 프로그램은 문서화 작업을 많이 필요로 하게 됩니다(생각했던 방식을 글로 써놔야 하므로).
이식성의 경우 Java야 문제가 안되겠지만 OCaml의 이식성이 어떤지 궁금합니다.
=> JAVA가 이식성이 좋다고 한다면 Ocaml 역시도 JAVA정도는 됩니다. (자바도 사실 3rd party들이 만들어놓은 VM이 더 많습니다)
원하시면 Ocaml 소스코드를 받아서 타킷에서 다시 컴파일하셔도 됩니다(저도 오늘알았습니다). 물론 Ocaml이 C로 짜여있지만, 정확히 ANSI C로
짜여진것은 아닙니다. 포팅을 위해서 Ocaml light를 사용하셔도 됩니다. 몇가지 없는 feature들이 있지만, 이식하기에 충분한 정보를 제공하고 있습니다.
결론을 말씀드리자면, 개인적으로 한국에서 Ocaml을 사용하기는 굉장한 도전이라 생각됩니다. 명령형 언어에 익숙한 개발자를 대상으로 Ocaml을 가르친다는 것은 패러다임을 전환시키는 것인데, 함수형 패러다임에 익숙해지기 위해서는 많은 노력이 필요합니다. 이것은 한번도 프로그래밍 해보지 못한 "수학자" 가 오히려 더 빨리 함수형 언어를 습득하는 이유이기도 합니다.
아.. 중요한것을 빼 먹었네요. OCaml의 전망도 꽤 중요하네요.
=> 이게 사실 중요하죠... 제 대답은 "매우 맑음" 입니다. 왜냐면 프랑스의 inria 연구소는 프랑스의 컴퓨터 과학에 아주 중요한 기관입니다. 사실 이 과학기관의 연구논문들을 찾아보면 거의 시대의 발명품들입니다. 이 기관에서는 ocaml을 주류 언어로 여러가지 실험을 진행하고 있습니다. 그 한예가 "증명도우미" - coq 입니다.
만약 inria가 문을 닫는다면, 당연히 ocaml은 open source화가 될 것입니다. 지금도 오픈소스이긴 하지만 매우 더이상 지원이 없는 경우, 저는 저와 같은 ocaml을 사용하는 사람들이 유지보수를 할 것이라고 믿습니다. (학술적 연구 또는 새로운 이론들을 적용하는 실험대로 사용함으로써...)
Minhyuk Kwon
-------------------
SureSoftTech
minhyuk@suresofttech.com
Minhyuk Kwon
-------------------
SureSoftTech
한가지 덧붙이자면
한가지 덧붙이자면 inria가 문을 닫는 건 프랑스가 망했다고 봐도 됩니다 -_-;; 문자 그대로의 "만약"이죠. 참고로 지금 OCaml 등 함수형 언어를 대학교에서 가르치는 곳이 제가 확실히 아는 곳만 해도 서울대 카이스트 포항공대 한양대 부산대 동덕여대 등이 있는 걸로 압니다. 제가 모르는 곳까지 포함하면 훨씬 많겠죠.
그런데 love77님께서 계속 이 사이트를 보고 계신지는 모르겠지만 pdfpro 웹사이트 파이어폭스에서도 잘 보이게 해 주실 순 없나요? 리눅스에서 파이어폭스로 보니 가운데 아무것도 안보이고 정렬도 이상하게 되어 보이거든요. supresoft 홈페이지는 리눅스 파폭으로도 잘 보이는군요 ^^
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin