|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
저는 One Source Multi Platform이 맘에 안듭니다. 지나친 욕심인 것 같습니다. 그냥 각 플랫폼에 최적화된 플래임웍을 따로 따로 만드는 게 가장 좋다고 생각합니다. Windows, OSX, iOS, Android는 생김새도 많이 다르고 용도도 완전히 똑같지 않아서 한 소스로 컴파일만 다시해서 모든 플랫폼용으로 만들어 내는 것은 의미가 없을 것 같습니다. 어차피 각 플랫폼마다 따로 따로 손을 봐야합니다. 그저 개발 방법만 통일시키는 것은 초보개발자들이나 좋아할 일이라고 생각합니다. 더군다나 파이어몽키가 Common Control을 사용하지 않고 모든 콘트롤을 자체적으로 구현한 것은 정말이지 바보같은 생각인 것 같습니다. 저는 델파이의 가장 큰 불만이, 개발자들이 User Interface인 폼 안에다가 비지니스로직을 포함한 모든 코드를 작성해 넣기 편리하도록 델파이가 디자인되었다는 점이 가장 큰 불만입니다. RAD툴의 특성일 수도 있겠지만, 조금만 그 부분에 신경을 쓴다면 얼마든지 장치를 마련할 수도 있는데말이죠. 한 소스로 여러 플랫폼을 지원하기 위해서 플레임웍을 하나로 통일하는 것은 그 문제를 더 악화시킬 수 있다고 봅니다. 차라리 플랫폼마다 소스가 다르다면 화면 콘트롤이나 파일입출력등은 따로 독립을 안시킬 수가 없을테니 자연스럽게 비지니스로직하고 분리가 될텐데 말이죠. 이제라도 파이어몽키도 아닌, One Source Multi Platform도 아닌, 각 플랫폼에 최적화된 플래임웍을 사용하는 버전의 델파이가 있었으면 좋겠습니다. 그걸 먼저 발표하고 나서 현재 버전을 조금 천천히 발표하는 게 어떨까 싶습니다. 에휴..... 답답해...... 사실 XE 버전까지 올라가면서도 여러번 삽질이 있기는 했지만, 득보다 실이 많았을지언정 나름 의미가 있는 변경들이긴 했습니다.
그런데 XE2부터 변경된 부분들은, 도무지 윈도우 개발자들에겐 거의 도움도 안되면서 이것저것 바꾸고 뜯어고치기만 합니다. 장단점이 모두 수두룩한 델파이, C++빌더의 가장 큰 미덕은, 새로운 기능을 지원하더라도 기존의 기능들과 사용법, UI, 프로그래밍 인터페이스는 최대한 개발자가 수정하지 않아도 되도록 최대한의 배려를 한다는 거였는데요. 이런 고객 개발자들에 대한 배려가 2009 버전에서 유니코드를 지원하면서 크게 한번 흔들리기는 했어도 전체적으로 오랫동안 지켜져 왔죠. 그런데 XE2부터는 이런 배려가 찾아보기 힘듭니다. 당장 파이어몽키만 해도, XE2에서 개발한 소스가 바로 다음 버전인 XE3에서 줄줄이 에러가 납니다. 위에서 썼다시피 수십년동안 자리를 잡아 정착한 오래된 라이브러리들을 일정한 일관성도 없이 여기저기 뜯어붙이고 옮기고 하기도 했고요. 델파이 언어의 모바일 지원 문서를 보면, 마르코 칸투는 '몇몇 변한 것 외엔 모두다 그대로다!'라는 것을 강조하는데, 물론 변한 것들이 몇가지 안되기는 하지만 그것들이 델파이 언어의 정체성이 상당부분 흔들릴 정도로 너무도 오랜 기간동안 정착된 것들이기 때문에 크게 와닿지도 않습니다. 모바일 지원을 위해 델파이 언어에 그렇게 이질적인 요소들을 도입하고 아예 컴파일러를 별도로 만들 정도인데, 뭐하러 RTL 라이브러리를 단일 소스로 유지하려고 그 어마어마한 삽질을 하고 있는지 모르겠습니다. 더 핵심인 컴파일러는 분리되면서 라이브러리는 억지로 붙여놓은, 주객이 전도된 이상한 모양새. 게다가 윈도우 개발자들의 입장에서는 아무런 이득도 없이 쓸데 없는 삽질만 반복하게 만들고 말입니다. 쓰다보니 논조가 너무 비판적으로 가게 됐는데, 몇번 다시 생각해봐도 다른 답이 안보이네요. 모바일이 아닌 윈도우 개발을 위해서는 XE면 충분하고 그 이후 버전에서 딱히 더 추가된 기능도 없습니다. XE2에서 도입된 유닛 이름의 네임스페이스 기능도, 따지고 보면 모바일 지원을 위해 라이브러리 유닛들을 카테고리화한 것에 불과하고요. XE2 이후로 또 하나 심각한 디버거 버그가 생겼는데, 어이없게도 XE4에 이르도록 전혀 수정되지 않은 상태입니다. 유닛이 많은 프로젝트를, 거기서 사용하는 패키지와 같은 프로젝트 그룹으로 디버깅하다보면 어느 순간 돌발적으로 디버거가 오동작합니다. 잡아놓은 소스 브레이크포인트로 잘 디버깅이 되다가 다시 디버그해보면 뜬금없이 어셈블리창으로 브레이크포인트가 잡히기도 하고, 다시 디버그해보면 다시 소스로 돌아가기도 하고요. 어떨 때는 컨트롤 F2로 리셋하고 나면 디버그 엔진이 맛이 가서 델파이를 다시 시작해야 하기도 하고요. 이런 현상은, 디버그하는 프로젝트에서 참조되는 패키지를 프로젝트 그룹에서 제거해버리면 싹 사라집니다. 문제는, 저같이 컴포넌트나 라이브러리를 복잡하게 다단계로 개발해서 프로젝트를 구성하는 개발자들에게는, 이렇게 패키지를 그룹에서 제외시키고 나면 뭘 어떻게 할 방법이 사라진다는 겁니다. 이 에러가 발생할 때 오류 메시지를 보면, XE2에서부터 OSX와 iOS를 지원하느라 디버거를 대폭 뜯어고치면서 이전에는 없던 버그가 새로 생긴 거라는 걸 알 수 있습니다. 제 개인적인 의견으로 하나의 기준을 제시하자면, 모바일 개발을 당장 델파이나 C++빌더로 할 것이 아니면 XE 이하 버전을 사용해서 개발하는 게 정답일 것 같습니다. 기존에 사용하던 구 버전들에 비해 쓸데 없는 변경 사항도 적고, 컴파일러와 IDE 모두 많이 안정화되었고요. 그 이후 버전에서는 윈도우 개발자로서는 너무나 불필요한 변경 사항들이 많고, 짜증나는 버그들도 많습니다. 전에 XE3 버전 출시때쯤이었던가, 파이어몽키에 대해 언급하면서 XE5 정도 버전쯤이면 안정화되지 않을까 했었는데요. 일단 안드로이드 지원이 단시간에 추가된 때문에 XE5에서 안정화는 물건너갔다고 보고요. 파이어몽키 문제는 문제도 아닐 정도로, 컴파일러와 기존 라이브러리를 계속 뜯어고치고 있는 탓에 안정화는 앞으로도 서너 버전은 더 거쳐야 가능하다고 봅니다. 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
그런데 이 작업은 1, 2년쯤 지나 deprecated 기간이 끝나서 SysUtils에서 없어지고 나면 전혀 필요가 없어진다. deprecated된 버전은 없애버릴 거니까. 결국 deprecated 처리로 인해 오히려 일이 몇배로 늘어난다. 개발툴 벤더로서 deprecated 처리를 제대로 하는 방법은, 한 소스 파일에서 deprecated된 버전과 새 버전이 같이 uses 되어 있더라도 Ambiguity 에러는 내지 말아야 하는 것 아닌가.