다중 플랫폼을 고려한다면..., mysql workbench의 궁색한 변명?

kirrie의 이미지

아시는 분은 아시겠지만, mysql에서는 workbench라는 아무 멋진 디비 모델링 툴을 내놓고 있습니다. 아직 베타 딱지가 붙어 있기는 하지만,
erwin보다는... 훨씬 예쁩니다. -_-;; (저한텐 그게 제일 중요했어요. ㅜ.ㅜ)

사실 이 프로젝트가 시작된 것은 꽤 오래전이었는데, 2007년에 프로젝트가 다시 재정비 되었고 그럭저럭 쓸만한 베타를 내놓기 시작한 것은
작년 정도부터였습니다. 현재는 윈도우즈 버전에 이어 리눅스와 OS X용 버전이 릴리즈 된 상태입니다. (단, alpha...)

애초부터 윈도우즈만 지원하려고 마음 먹었다면야 상관이 없지만, 프로젝트 초기에 다중 플랫폼을 지원하겠다고 발표한 상태였고
애타게 리눅스용을 기다리던 제게는 '어째서 윈도우즈용 버전만 계속 릴리즈 되는 것인가!' 하고 분통을 터뜨리고 있었는데
제가 놓친 공식 블로그의 글 가운데 이런게 있어서 옮겨봅니다.

http://dev.mysql.com/workbench/?p=19

Quote:
If you are on Linux or OS X you might ask why we have decided to first release on the Windows platform. And why the releases for Linux and OS X will happen a few months later. Here is why.
만약에 당신이 리눅스나 OS X를 사용하고 있다면 어째서 우리가 윈도우즈 플랫폼으로 첫번재 릴리즈를 가기로 했는지 묻고 싶어 할 것입니다. 그리고 어째서 몇달 뒤에나 Linux나 OS X용의 릴리즈가 나오게 될 것인지도요. 그 질문에 답변하도록 하겠습니다.

We believe we can deliver better quality if we focus on one platform first. By having the whole team focusing on one platform we can get a release out sooner than it would be possible by supporting all three platforms from the beginning.
우리는 우리가 하나의 플랫폼에 집중하게 될 때 더 나은 품질을 보장할 수 있다고 믿고 있습니다. 팀 전체가 하나의 플랫폼에 집중하는 것은 다른 모든 3개의 플랫폼에서 처음부터 시작하는 것보다는 훨씬 더 빠르게 첫번째 릴리즈를 낼 수 있다는 것입니다.

And the sooner we release, the earlier we get bug reports. And this benefits the quality. When we are going to release on the other platforms the back-end code will already be well community-tested. And even the first releases on Linux and OS X will have a decent quality.
그리고 일찍 릴리즈 하는 만큼, 우리는 버그 리포트도 일찍 받을 수 있을겁니다. 이것이 바로 품질과 직결되는 것이죠. 그리고 나서 우리가 다른 플랫폼용의 릴리즈를 내려고 할 때는 (이미 이전에) 잘 테스트된 백-엔드 코드가 준비되어 있을겁니다.

But why did we choose Windows as the first platform? Actually, it was not us - it was you, our users. Looking at the bug reports we got for the old GUI tools it is clear that 90% of the reports are for Windows. And that made the choice easy.
하지만 어째서 윈도우즈가 첫번째여야만 했을까요? 사실, 그건 우리가 결정한 것이 아니라, 바로 우리의 고객들이 결정한 것입니다. 기존의 GUI 툴들에 대해 우리가 받았던 버그 리포트들을 보면, 그것의 90% 이상은 윈도우즈 사용자들에게서 나왔습니다.

The question remains why we do not use Java or a cross platform GUI toolkit. The answer for that is that a lot of developers do not want Java to be installed on their development machine. I personally love Java as a language but I can see their point, so that was not an option. For the cross platform GUI toolkits - we have tried a number of them. But non of them really delivered what we needed.
물론 이렇게도 묻고 싶을겁니다, 어째서 자바나 크로스-플랫폼의 GUI 툴킷을 사용하지 않았냐구요. 왜냐하면 많은 개발자들은 개발 머신에 자바를 인스톨하기를 원치 않습니다. 물론 저는 개인적으로 자바를 좋아합니다만, (개발 머신에 자바를 인스톨하기를 원치 않는) 개발자들의 의견도 이해할 수 있습니다. 그러니 그것은 고려대상이 될 수 없었지요. 크로스-플랫폼 GUI 툴킷에 대해서는... 우리는 여러가지 것들을 테스트 해봤습니다만, 우리가 원하는 것들을 충분히 반영할 수 있었던 것은 없었습니다.

So I hope our fellow Linux and OS X users (I’m on OS X now as well) will understand our motivation behind this decision and will be even more happy when they are going to try Workbench on their platform and find it working very well.
그러니 저는 우리의 Linux와 OS X 사용자들이(사실 전 OS X를 사용하고 있답니다.) 우리가 이런 결정을 내린 것에 대해서 이해해 주기를 바랍니다. 또한 어쩌구 저쩌구...

Michael G. Zinner

이들이 주장하는 바를 요약하자면,

1. 여러개의 플랫폼을 고려하는 것 보다는 하나의 플랫폼에 집중하는 것이 더 빠른 결과를 낼 것이다.
2. 더 빠른 결과는 더 빠른 버그 리포트를 얻을 수 있다는 의미이고, 이것은 곧 결과물의 품질과 관계가 있다.
3. 그들의 기존 GUI 툴에 대한 버그 리포트의 90%는 윈도우즈 사용자들로부터 온 것이었다. (엥?)
4. 자바나 크로스-플랫폼 GUI 툴킷에 대해서는
4.1 자바의 경우 개발자들은 자신의 개발머신에 자바를 인스톨하는 것을 싫어한다. (엥?)
4.2 크로스-플랫폼 GUI 툴킷은 그 어느것도 우리의 기대를 충족시키지 못했다.

정도입니다.

제가 이해할 수 없는 부분은 4.1과 관련한 4번입니다. 자바 개발자라면 당연히 자바가 설치되어 있을 것이고, 자바 개발자가 아니어도 자바 런타임 정도는 다들 (필요하다면) 인스톨 하지 않을까요? 무슨 근거로 단지 '개발자들이 자신들의 머신에 자바를 인스톨하는 것을 싫어한다.'라고 생각하고는 자바를 고려대상에서 제외했던걸까요?

또 3번도 좀 의문스럽습니다. 본문에 달린 댓글 가운데 Porta란 사람이 하는 말이 인상깊은데요, '버그 리포트의 90퍼센트가 윈도우즈 사용자로부터 왔다는 것은 반드시 90퍼센트의 사용자가 윈도우즈를 사용한다는 것을 의미하지는 않는다.' 이에 대해서 zinner는 이상한 답변을 합니다. '.. (뭐 다 맞는 말이긴 한데) 리눅스 사용자는 대부분 안정성에 대해서 불평만 하지, 그들로부터 정말 valuable한 버그 리포팅을 받기는 매우 힘들다.' 음.. -_-;;

뭐 세월은 흘러흘러 이제 3개의 플랫폼에서 그럭저럭 돌아가는 릴리즈가 나오긴 했습니다만...

만약에 여러분이 다중 플랫폼을 지원하는 프로젝트를 맡았다고 한다면, workbench가 선택한 방법론, 즉 '하나의 플랫폼에 집중해서 그 (검증받은) 결과물로 나머지 플랫폼들에 적용하겠다.'는 것을 고려하시겠습니까? 아니면 그냥 자바나 크로스-플랫폼 GUI 툴킷을 사용하시겠습니까? 어떤게 나을까요?

chunsj의 이미지

일단 자바를 설치하기 싫어한다라는 말은 이해가 됩니다. 그런거 싫어하는 사람 많습니다. 더더구나 설치한 후의 결과물이 보기
좋지 않은 경우 더 그렇습니다 - 윈도/리눅스의 경우 SWT를 쓴다면 이부분은 해결이 될 수도 있었겠네요, 맥에서는 그래도 삐꾸지만.

그리고 아마 전체플랫폼에서 돌아만 가면 되느냐 아니면 그 플랫폼의 사용자 경험을 철저히 이용할 것이냐에 따라서 크로스플랫폼이냐
아니면 백엔드만 같이하고 프론트엔드는 다 개별적으로 만드느냐가 결정이 될 것 같습니다. 전자는 개발은 쉽지만 모든 플랫폼의
사용자가 다 100%만족 못할 가능성이 높습니다.

lateau의 이미지

저도 자바를 설치하기 싫어한다에 동의합니다.
전 자바 개발자이긴 하지만 자바 깔기 싫습니다. :(
최근 릴리즈 들어 jdk 포함해 jre의 용량은 기적에 가까울 정도로 줄어들었지만,
'개발 이외의 목적'을 위해서 혹은 '프로그램 하나'를 위해서 자바를 설치해야한다면 '싫다'라고 느낄 것 같습니다.

좋은 글 잘 읽었습니다. :)

- Why don't you come in OpenSolaris? I hope you come together.

--
I think to myself...what a emerging world.

kslee80의 이미지

다중 플랫폼 프로젝트를 시작한다고 가정했을때...
처음부터 다중 플랫폼 상에서 개발할 수 있는 상황이 아니라면
하나의 플랫폼을 타겟으로 개발한 후 다른 플랫폼에 집중하는 방식도 나쁘지는 않다고 생각합니다.

그리고 크로스-플랫폼 GUI 툴킷에 대해서는...
(어디까지나 과거의 경험을 가지고 이야기 하는 것입니다. 현재는 다를 수 있겠죠)
제가 접해본 다중 플랫폼 GUI 툴킷의 대부분은 플랫폼별로 결과물이 달랐습니다.
단지 '여러 플랫폼에 포팅된 GUI 툴킷' 일뿐
같은 코드로 다른 플랫폼에서 같은 결과물을 내 주는 경우는 별로 없었습니다.
자바의 경우도 플랫폼이 달라지면 레이아웃이 틀어지거나 하는 문제점이 있었죠.

해당 개발팀에서 이러한 크로스-플랫폼 GUI 툴킷의 문제점을 접하고,
그 문제점들을 개발팀에 소속된 개발자들이 감수하고 개발하기 싫었다면
(아니면 단순히, 크로스-플랫폼 GUI 툴킷을 사용한 결과물이 개발자들 맘에 들지 않았을지도 모르겠네요)
개별 플랫폼에 집중하는 선택을 하지 않았을까 싶습니다.

alfalf의 이미지

이곳에서 글을 읽고 다운로드하여 설치하려고 하니 .NET framework 2.0 이상이 필요하군요.
전 자바보다 저거 설치하는게 몇 배는 더 싫은데... 자바는 안되고 .NET은 되고?
저 사람들 말이 앞 뒤가 안 맞네요. 혹시, Linux 용은 mono 설치하라고 하는거 아닙니까?

creativeidler의 이미지

.NET은 윈도우 XP 이상에는 거의 99% 이상 깔려 있다고 봐도 될 겁니다.

kilikan의 이미지

99%보다 훨 적을겁니다. -_-;

.NET 깔려 있는 컴터 보기가 더 힘들텐데요.. ;

warpdory의 이미지

귀찮다고 윈도업데이트도 안하는 사람들이 태반인데.. .net 이 깔려 있을 확률은 매우 낮습니다.

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

Risty의 이미지

요즘 나오는 XP에는 .NET 1.1 프레임워크가 기본으로 설치되어 있는 것 같기는 한데, 2.0용 프로그램을 돌리려면 2.0을 따로 설치해야 합니다.

뭐 인스톨러를 제대로 만들었다면 잘 알아서 깔리겠지요.

mycluster의 이미지

적어도 윈도 닷넷은 자바에 비해서 사이트 치고 들어가서 여기 저기 기웃대다가
버전 맞춰서 이건가 저건가 다운받게 하는 수고는 훨씬 덜 하게 해주죠.
보통 오케이 몇번 누르면 다운되죠.

왜 자바는 꼭 선에 가서 받아야만하는지... 찾기도 힘들고...

--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러

--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러

youlsa의 이미지

진정 거부감 없이 깔수 있는 크로스 플랫폼 환경은 Flash 밖에 없는게 아닌가 하는 생각이 드네요. Write once, run everywhere의 세상은 아직 먼건가요?

MySQL workbench 개발을 Qt나 WxWindows툴킷으로 시작했으면 어땠을까 하는 생각이 드네요.

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

cppig1995의 이미지

버그 리포트를 많이 받기 위해 Windows부터 했다는 게 본문에서 버그 리포트 90% 운운하는 부분이로군요.
"버그 리포트의 90%가 Windows 사용자로부터 왔다고 해서 Windows 사용자의 비율이 90%는 아니다"라는 건 논점과 전혀 상관 없는 부분입니다. 버그 리포트를 초기에 많이 받기 위한 목적이라면 버그 리포트가 많이 들어오는 플랫폼부터 시작하면 되니까요.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

송효진의 이미지

핑계같고 변명같지만 개발자라는 이유로 다 이해해줍니다.
아쉬..귀찮아...

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

creativeidler의 이미지

어떤 다른 대안이 있을까요?

자바는 설치해야 한다는 문제와 GUI가 느리다는 문제가 있습니다. 전, 사실 듀얼 코어 시대에 서버에서는 C++과 성능을 견준다는 자바가 GUI는 왜 이렇게 느린지 잘 이해가 안 가긴 합니다만. 심지어 파이썬이나 루비로 GUI 바인딩해서 쓰는 것보다도 한참 느리더군요. SWF도 느린 건 마찬가지. 사실 자바 GUI가 빠르기만 하다면 다른 건 다 참을 수 있을 텐데 말입니다.

GTK도 윈도우에서는 아주 느린 느낌입니다. 이볼루션을 윈도우에서 써볼려다가 답답해 죽는 줄 알았다는.

wxWindows는 네이티브 바인딩을 해서 빠르다는 설이 있는데 UI가 너무 못생겼더군요.

요즘은 .NET과 모노에 기대를 걸고 있습니다. 현실적으로 이게 제일 좋은 대안이 아닐까 싶기도 합니다. 맥도 모노를 지원하던가요? 잘 모르겠네요.

Qt는 잘 모릅니다. 윈도에서는 역시 느렸던 기억이 있는데 요즘은 어떨런지...

다른 분들의 경험도 궁금하네요.

kirrie의 이미지

그런데 자바 GUI가 정말 그렇게 느리던가요? 오픈 오피스와 이클립스 정도를 쓰고 있는데, 초기 로딩 속도 (이건 자바 구조상 어쩔수 없는건가요? -_-;;) 를 참고 버티면 그 외에는 그다지 느리다는 느낌은 못받았거든요. (윈도우즈에서 쓰고 있습니다.)

gtk는 pidgin 윈도우즈용을 쓰는데 (이게 아마 gtk가 맞을겁니다.) 이건 좀 동의합니다. 창 전환이라던가, 클릭시 반응이 느껴질 정도로 좀 느리더라구요. ㅎㅎ;;
--->
데비안 & 우분투로 대동단결!

--->
데비안 & 우분투로 대동단결!

creativeidler의 이미지

그냥 이클립스만 쓰면 그럭저럭 쓸만하다는 느낌이 들다가도 다른 네이티브 애플리케이션이랑 비교를 해보면 확 차이납니다. 키보드나 마우스 눌렀을 때 반응 속도며 창 뜨는 속도, 메뉴 뜨는 속도, 가끔 버벅이는 현상까지 차이가 꽤 큽니다. 열어놓은 파일이 많아질수록 느려지기도 하구요. 에디트플러스 같은 에디터랑 비교해보면 확 차이가 느껴지죠. 물론, 이클립스는 이클립스 자체가 느린 것도 있긴 하지만요.

fender의 이미지

전 자바 개발자이지만 자바 스윙 어플리케이션은 어지간하면 쓰지 않습니다. 다만 속도에 불만이 있는 것이 아니라 특히 리눅스 환경에서 네이티브 피델리티가 너무도 마음에 들지 않다는 이유입니다.

제 경우 SWT는 속도나 룩엔필 모두 만족스럽습니다. 이클립스와 에디트 플러스를 비교해서 UI반응속도를 따지는 건 올바른 비교는 아닌 듯 합니다. 거의 계산기와 일반 PC 만큼 서로 구조적, 기능적 차이가 있는만큼, 왜 계산기는 전원 누르면 바로 켜지는데 PC는 20초씩 걸리냐고 불평을 할 수는 없으니까요...

대표적 SWT 어플리케이션이 거의 이클립스나 Azureus 등 기능집약적 제품이 많아서 체감상 차이는 있을지 몰라도 SWT 자체가 느리다고 생각하진 않습니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

네이티브 애플리케이션의 예로 에디트 플러스를 든 것 뿐입니다. 비주얼 스튜디오도 이클립스보다 훨씬 빨리 뜨고 반응 속도도 빠릅니다.

그리고, UI 반응 속도는 애플리케이션의 무게보다는 GUI 시스템의 속도가 더 큰 영향을 끼칩니다. 자바 SWT로 아주 간단한 애플리케이션을 만들어서 띄워도 메뉴 반응 속도가 비주얼 스튜디오보다 느립니다.

fender의 이미지

정말 SWT로 만들면 메뉴가 네이티브 어플리케이션보다 눈에 띄게 느리던가요? 저 역시 하드한 데이터를 가지고 있지 않아서 말만으로 반박하고 싶진 않습니다만 직접 SWT로 개발을 해본 입장에서 공감은 가지 않는군요...

순수하게 툴킷의 차이로 '메뉴의 반응성'에서 현격한 격차가 난다면, SWT가 wxWidgets와 마찬가지로 네이티브 위젯을 사용하고 있고 구조상 예를들어 스윙처럼 복잡한 상위 레이어가 없다고 보면 사실상 그건 JNI호출 자체가 심각한 오버헤드를 유발한다는 주장이 될 수밖에 없습니다. 물론 다른 경우에 JNI의 오버헤드가 문제가 되는 경우도 있습니다만, 최소한 1-2회의 호출이 사용자가 '느리다'고 느낄만큼 0.5초 쯤의 지연을 초래할만큼 심각하다는 건 경험상으로도 쉽게 납득이 가는 이야기는 아닙니다.

그런 류의 반응성은 JNI 호출 보다는 메뉴를 뿌릴 때 어떤 어플리케이션로직이 동기적으로 실행되는지에 따라 결정된다고 보는 게 훨씬 일반적이고, 단일 어플리케이션이 아닌 '플랫폼'인 이클립스의 경우 특히나 이 부분이 심지어 비주얼 스튜디오 같은 상대적으로 복잡한 어플에 비해서도 단순비교가 어려울만큼 복잡할 수밖에 없습니다.

비주얼 스튜디오는 IDE 제품이지만 이클립스는 범용 플랫폼입니다. SWT가 아닌 RCP나 이클립스 플러그인을 개발해보면 메뉴하나 뿌리는데도 얼마나 많은 계층을 통해 호출이 일어나는지 실감하실 수 있을 것입니다.

모든 걸 떠나서 어플리케이션 로직을 고려하지 않고 구조와 용도가 상이한 어플리케이션을 한 두개 서로 비교해보는 것으로 어떤 UI 툴킷이 느리다고 이야기하는 건 지나치게 성급한 주장입니다.

PHP로 만든 어떤 사이트가 0.5초만에 뜨는데 ASP로 만든 사이트는 3초 이상 걸린다고 'ASP가 PHP보다 6배 넘게 느리다'라고 결론 내릴 수는 없는 일이니까요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

저 역시 SWT는 물론이고 스윙, AWT에 JavaFX까지 개발을 해봤고 .NET, MFC 개발에 파이썬의 윈도우 바인딩까지 해봤습니다. 단언하건데, 자바가 느립니다. 모두가 알고 있는데 자바 프로그래머들만 부인할 뿐입니다.

저는 원인이 툴킷에 있다고 한 적이 없는 것 같은데요. 전 자바에서 원인을 찾습니다. JNI가 원인은 아닐 겁니다. 문제느 JVM 자체죠. JVM이 throughput은 아주 높게 설계되어 있지만 response time이 높게 설계되어 있진 않습니다. 저는 그냥 느리다..라는 주장을 하는 게 아니고 response time이 떨어진다는 주장을 하고 있는 것이지요. 대조를 해본다면, .NET은 throughput에서 JVM에 아직 못 미친다는 평가를 받고 있지만 response time은 더 좋습니다. 사실 JVM이 throughput에서는 C++로 짠 것보다도 빠릅니다. 메모리를 더 많이 먹을 뿐.

그리고, 자바에서 스윙과 SWT의 성능에 대한 여러 가지 이론이 있는데, 요즘은 스윙이 더 빠르다고 합니다. 그런데, 그 이유가 스윙이 계층이 더 많기 때문이라고 합니다. SWT는 계층이 7단계에 불과한데 스윙은 30단계가 넘습니다. 그래서 역설적으로 JVM이 최적화하기는 더 좋다고 합니다. 즉, 자바에서는 계층이 많은 게 꼭 나쁜 건 아니라는 것입니다. 핫스팟이 왜 좋은 거겠습니까.

비주얼 스튜디오도 이클립스랑 비슷한 구조입니다. 비주얼 스튜디오 redistributable 같은 패키지를 활용하면 RCP랑 유사하게 활용할 수 있습니다. 비주얼 스튜디오와 이클립스가 구조와 용도가 상이하다고 하시면 대체 어떤 게 비슷할까요?

간단한 실험이 하나 있습니다. 메뉴를 띄워놓고 왼쪽 화살표키를 계속 누르면서 메뉴를 돌려보는 겁니다. 그러면 애플리케이션의 종류, 기능, 크기에 상관 없이 GUI 툴킷과 VM의 종류에 따라 속도가 결정된다는 사실을 눈으로 확인할 수 있습니다. 자바는 .NET보다 느리고 .NET은 네이티브보다 느립니다. 이외에도 몇 가지 GUI 성능 테스트 방법들이 있는데 컨텍스트 메뉴 뜨는 속도, 텍스트 에어리어에서 클릭한 곳으로 커서가 위치하는데 걸리는 시간 등등 재보면 다 자바가 느립니다. 이 실험으로 해보면 자바로 아주 단순한 애플리케이션을 만들어서 비주얼 스튜디오 .NET이랑 비교해봐도 자바가 더 느리게 나옵니다.

fender의 이미지

제가 단지 '자바 프로그래머'라서 당연한 사실을 왜곡하고 있다는 뜻인가요? ㅎㅎ; 기술적 토론이 아닌 플레임은 사절하겠습니다.

JNI가 원인이 아니라면 말씀하신 '오버헤드'는 JNI 앞단에서 발생한다는 이야기인데, 윗글에서 직접 언급하신 것처럼 SWT의 자바쪽의 계층은 기껏해야 몇 번의 자바 메소드 호출 정도입니다.

GUI에서 사용자가 체감할 수 있는 정도라면 적어도 0.5초 근처의 차이가 나야하는데, 로직에 관계없이 단지 자바라는 이유 만으로 고작 몇번의 메소드 호출이 타 언어에 비해 그 정도의 엄청난 오버헤드를 가져온다면 아마 실무에서 자바는 진작에 퇴출되었을 지 모릅니다.

'response time'이나 'throughput'은 상당히 일반적인 개념이라 정확히 어떤 컨텍스트로 말씀하신 건지는 모르겠습니다만 메뉴 돌려보는 정도의 GUI 어플리케이션에서 'throughput'을 이야기하는 것과 예컨대 동접 사용자가 얼마 일 때 서버 어플의 'throughput'이 얼마라고 이야기할 때의 개념과는 상당히 차이가 있습니다.

아마 최대한 연관성이 있는 주제를 찾는다면 gc를 response time에 최적화 시켰느냐 throughput에 최적화 시켰는가에 따라 GUI어플의 반응성 차이 정도가 아닐까 싶습니다.

그리고 계층이 많을 때 런타임 최적화에 유리하다는 건 계층이 없을 때보다도 더 빨라진다는 뜻이 아니라 그만큼 최적화의 '마진'이 많다는 뜻입니다.

비주얼 스튜디오의 구조에 대해선 제가 .NET 이후의 제품에 대해 잘 모르는 부분이 있을 수 있어 다시 질문드립니다. 말씀하신 redistributable이란 것을 이용하면 VS '플랫폼'을 이용해서 에볼루션 같은 이메일 클라이언트를 만들거나 아니면 써드 파티 벤더가 VS IDE에 전혀 새로운 언어 지원을 추가할 수 있는 등의 확장성이 제공된다는 뜻인가요?

마지막으로 말씀하신 '실험'이 가능하도록 swt snippet을 살짝 변경한 프로그램을 만들어봤습니다. 자바가 설치된 상태에서 압축 풀고 더블클릭하거나 커맨드로 java -jar test-??.jar 하시면 됩니다.

다른 분들께서도 관심이 있으시다면 피드백을 주셔도 환영합니다. 과연 creativeidler님 말씀대로 메뉴 활성화하고 화살표를 눌렀을 때 사용성에 문제가 될만큼 지연이 생기나요?

저는 리눅스에서만 돌려봤습니다만 다른 GTK 어플리케이션과 비교했을 때 눈에 띄는 차이가 있는지 전혀 모르겠는데요...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

댓글 첨부 파일: 
첨부파일 크기
Package icon test.zip2.49 MB

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

>제가 단지 '자바 프로그래머'라서 당연한 사실을 왜곡하고 있다는 뜻인가요?
사실, 불쾌하게 느끼실 수도 있다는 점은 압니다. 그 점 죄송스럽게 생각합니다. 다만 그저, 이런 솔직히 이런 생각이 드는 건 어쩔 수가 없습니다. "아니 누구나 다 알고 있는 사실인데 왜 아니라고 하실까?" 하고 말입니다.

>GUI에서 사용자가 체감할 수 있는 정도라면 적어도 0.5초 근처의 차이가 나야하는데, 로직에 관계없이 단지 자바라는 이유 만으로 고작 몇번의 메소드 호출이 타 언어에 비해 그 정도의 엄청난 오버헤드를 가져온다면 아마 실무에서 자바는 진작에 퇴출되었을 지 모릅니다.

이 말씀 속에 답이 있는 것 같습니다. 자바 GUI는 진작에 시장에서 퇴출되었죠. 자바 GUI 애플리케이션 중에 쓸만한 거라곤 자바 개발툴 밖에 없지 않습니까? 일반 사용자용으로 자바 GUI를 선택하는 경우가 몇 퍼센트나 될까요? 최근에 나온 플래시 에어만도 못할지도 모릅니다.

GUI 반응성은 JNI문제도 아니고 메소드 호출 속도도 아닙니다. 왜 그렇게 자꾸 뭔가 하나로 원인을 한정하려고 하시는지요? 전 JVM이 문제라는 것까지는 알지만 그 안에 정확히 어떤 부분이 문제인지는 모릅니다. 다만 확실한 건 JNI도 아니고 메소드 호출도 아닙니다. 자바의 virtual 메소드 호출은 C++보다 몇십 배는 빠릅니다. 그런데 네이티브 GUI는 C++도 virtual 메소드를 쓰죠. 이것도 원인이 아닐 겁니다. 클래스를 어떻게 로딩하는지, OS 이벤트를 받을 때 어떻게 처리하는지, 핫스팟이 언제 네이티브로 재컴파일하는지 등등의 요소를 다 고려해야 합니다. 성능이란 게 그렇게 딱 잘라서 원인을 찾을 수 있는 문제였다면 자바 GUI 성능 문제는 진작에 해결되었을 꺼고 SWT는 나오지도 않았겠죠.

>그리고 계층이 많을 때 런타임 최적화에 유리하다는 건 계층이 없을 때보다도 더 빨라진다는 뜻이 아니라 그만큼 최적화의 '마진'이 많다는 뜻입니다.

이것은 그 사람의 주장이고 아직 검증된 것은 아니지만, 그 사람의 주장에 따르면, stack이 깊으면 더 많은 코드를 핫스팟이 재컴파일을 하기 때문에 실제 네이티브로 컴파일되서 실행되는 비율이 스윙이 더 많다고 합니다. javalobby에서 본 글이었던 것 같은데 검색이 안되네요. 다음에 찾으면 링크를 달겠습니다. 꼭 stack의 문제만은 아니겠지만 어쨋거나 여기서 중요한 것은 stack이 깊어도 어차피 핫스팟이 다 해결해주기 때문에 큰 차이가 안 난다는 것입니다. 이 사실 자체는 간단한 실험으로 확인할 수 있습니다. 일부러 무거운 작업에 대해 스택을 깊게 구현해서 성능 테스트를 해보면 처음에는 스택 깊은 쪽이 느리지만 런타임이 1,2분만 지나도 비슷해집니다.

>화살표를 눌렀을 때 사용성에 문제가 될만큼 지연이 생기나요?

두 가지를 구분하고 싶습니다. 먼저, 전 이클립스는 사용성에 문제가 될 정도로 느린 상황을 아주아주 많이 경험합니다. 밑에 소타씨가 썼듯 타이핑을 화면이 못 따라가는 일조차 흔합니다. 오른쪽 버튼 눌렀는데 한참 있다 뜨는 일은 부지 기수죠. 메뉴 찾는데 왜 버벅거리는지는 아직도 이해를 못하고 있습니다. fender님은 그렇지 않으신가요?

그리고, 아주 간단한 애플리케이션을 짜면, 화살표를 눌렀을 때 사용성에 문제가 될 만큼 지연이 생기진 않습니다. 하지만, 여전히 네이티브보다 느리고, .NET보다도 느리고 파이어폭스의 크롬 UI보다도 느립니다. 올려주신 소스코드 역시 마찬가지입니다. 똑같은 기능을 MFC로만 짜서 실행해보시면 로딩 속도만이 아니라 반응 속도 자체가 차이가 있다는 것을 실감하실 수 있을 겁니다.

>비주얼 스튜디오의 구조에 대해선 제가 .NET 이후의 제품에 대해 잘 모르는 부분이 있을 수 있어 다시 질문드립니다. 말씀하신 redistributable이란 것을 이용하면 VS '플랫폼'을 이용해서 에볼루션 같은 이메일 클라이언트를 만들거나 아니면 써드 파티 벤더가 VS IDE에 전혀 새로운 언어 지원을 추가할 수 있는 등의 확장성이 제공된다는 뜻인가요?

네. 그걸로 새로운 IDE를 만들기도 합니다. IronPythonStudio를 참고하세요.

그리고, 리눅스에서만 돌려보셨다면 Gtk랑 큰 차이가 안 느껴지실 수도 있다고 생각하긴 합니다. 전 사실 Gtk도 느린 편이라고 보거든요. 하지만, 차이를 알 수 있는 방법이 하나 있습니다. compiz를 띄우면 이클립스는 참기 힘들 정도로 느려집니다. 하지만 그래도 Gtk는 쓸만하더군요.

fender의 이미지

그간 자바가 데스크탑 시장에서 힘을 못쓴 이유는 전적으로 속도 문제라기보단 배포방식의 불편함과 이 글타래에서 저도 지적했던 네이티브 통합성의 한계등이 복합적으로 작용한 결과입니다. 단적으로 말해 처음부터 AWT대신 SWT가 있었고 java를 쉽게 exe로 컴파일해 배포할 수 있는 방법이 일반화되었다면 데스크탑 자바는 지금 같지 않았을 지 모릅니다.

더구나 그간 데스크탑 자바어플리케이션에 대한 일반 사용자들의 인상이, UI 반응성이나 네이티브 피델리티 측면에서 SWT에 비해 상대적으로 불리한 스윙 기반 제품들로 인해 형성된 바 크기 때문에 '데스크탑에서 자바를 많이 안쓴다'는 사실로부터 툴킷에 무관하게 자바 데스크탑 어플리케이션은 무조건 느리다는 식의 결론을 도출하는 건 상당히 무리가 있는 논리전개라고 생각합니다.

또한 말씀하신 현저한 오버헤드의 원인이 JNI도 아니고 메소드 호출도 아닌 '알 수 없는 어딘가'에서 발생한다라고 하신다면 이는 결국 검증할 수도 없고 제가 반박할 수도 없는 그냥 '주관적 생각'일 뿐입니다. 이 부분에 대해선 제 경험에 기반한 '주관적 판단'으로는 말씀하신 현저한 문제점을 확인하지 못했다는 정도로 정리할 수밖에 없을 것 같습니다.

저는 이클립스의 반응성이 빠르다는 주장을 한적이 없습니다. 오히려 이클립스가 구조적으로 복잡하기 때문에 메뉴를 띄우는 등의 간단한 작업에도 오버헤드가 있을 수 있다고 이야기했습니다. 특히 메모리가 부족한 경우 이클립스에서 무거운 프로젝트를 개발하다보면 중간 중간 UI가 굳는 경험도 꽤 했습니다. 아무튼 전 이클립스가 빠르다고 말한적도, 또 그것을 근거로 SWT나 자바가 빠르다고 주장한 적이 없습니다.

반면 creativeidler님은 자바 플랫폼 자체의 문제로 GUI 어플리케이션이 느릴 수밖에 없다라고 하셨고 그 근거로 이클립스를 예로 드셨습니다. 자바로 짠 특정 어플리케이션이 윈도우즈 기반 비슷한 어플리케이션보다 느리다고 해서 그 자체로 자바 플랫폼 자체에 근본적인 문제점이 있다고 주장하는 것은 논리적으로 맞지 않습니다. 이는 이미 이전 글에서 지적한 바 있지만, 여전히 creativeidler님께서는 컴피즈에서 이클립스가 느리다거나 - 참고로 저는 거의 매일 같이 컴피즈를 켜놓고 하루 종일 이클립스로 작업을 하고 있지만 심각하게 UI가 느리다는 생각은 해보지 못했습니다 - 이클립스가 VS보다 느리다는 것을 근거로 '모든 자바 데스크탑 어플리케이션은 느리다'라는 일반화를 하고 계십니다.

예를들어 말씀하신 메뉴가 늦게 뜬다거나 타이핑을 화면이 따라가지 못하는 현상에 대해 creativeidler님께서는 별다른 근거 없이 '자바 자체의 문제일 것이다'라고 주장하고 계시지만 논리적 타당성을 제쳐놓고 기술적으로 판단해도 이는 플랫폼의 문제가 아닌 어플리케이션 로직의 차이일 가능성이 훨씬 높습니다.

좀 더 구체적으로 말씀드리자면, 메뉴를 보여줄 때 지연현상이 있다면 일반적으로 개별 액션의 상태를 계산하는 부분이나 아이콘을 뿌리는 부분등 관련 이벤트와 동기적으로 코딩된 부분의 오버헤드일 가능성이 매우 높습니다. 즉, 어느 메뉴 아이템이 활성화 상태인지 아닌지 판단하기 위해 반복작업을 한다거나 해서 발생하는 코드상의 오버헤드가 툴킷이나 플랫폼 자체적으로 발생하는 오버헤드보다는 비교할 수 없이 큰 값이라고 보는 것이 정상적이라는 뜻입니다. 더구나 이클립스처럼 메뉴 아이템을 하드코드된 GUI 코드가 아니라 각 플러그인의 action contribution을 조합해서 보여준다던지 하는 추가적 계층을 통해서 보여준다면 그럴 가능성은 더 높을 것입니다.

VS의 쉘익스텐션 같은 것이 이클립스 플랫폼과 같은 레벨이라고 생각하지 않지만, 이 부분에 대해선 제가 VS의 내부 구조를 잘알지 못하기 때문에 'VS보다는 이클립스가 훨씬 복잡하다'는 주장은 철회하도록 하겠습니다. 그래도 전체적인 논리 전개에 문제는 없을 듯 하군요.

마지막으로 creativeidler님께서는 제가 위에 올린 샘플에서도 네이티브 어플에 비해 체감할 수 있는 성능차이가 있다고 하셨는데 과연 다른 분들도 그렇게 느끼실는지 궁금합니다. 또한 creativeidler님조차 이와 같은 단순한 어플리케이션에서는 사용성에 문제가 될만큼 차이가 없다라고 인정하신 듯 합니다만, 그렇다면 과연 '자바 데스크탑 어플리케이션은 사용성에 지장이 있을 만큼 느리며 이는 자바 자체의 문제이다'라는 주장에 대한 근거는 무엇인지 모르겠습니다.

기술적 근거는 '알 수 없는 어딘가에서 느려진다'로 검증할 수 없는 방향으로 결론 났고, 이클립스가 느리니까 자바 GUI어플리케이션이 느리다라는 건 논리적으로 맞지 않으며, 만일 제가 올린 샘플에서 사용성에 문제가 없는데 이클립스에선 문제가 생긴다면 그건 자바 자체의 문제가 아니라 어플리케이션 로직이나 복잡도 자체의 문제라고 보는 게 훨씬 타당한 결론이 아닌가요?

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

시장 퇴출 이야기는 fender님께서 그 정도로 느리다면 벌써 퇴출되지 않았겠느냐... 라고 하신 말 속에 "아직 퇴출되지 않았으니까 자바는 그 정도로 느리지 않다"라는 뉘앙스가 느껴져서 그 말을 반박하는 것이 목적이었습니다. 꼭 GUI 때문에 퇴출되었다고 100% 주장할 생각은 없습니다. 정황적으로 범인이 누군지 심증은 가지만 말입니다.

거듭 말씀드리지만, 저는 이클립스만 가지고 이야기하는 것이 아니고, 자바로 작성한 최소 기능의 테스트 프로그램으로 검증해도 같은 결과가 나온다는 이야기를 하는 것입니다. fender님이 올려주신 프로그램, 메모장보다 기능이 많다고는 할 수 없겠죠? 하지만 메뉴 순환 속도는 메모장보다 약간 느립니다. 심지어 비주얼 스튜디오 2008이랑 비교해도 메뉴 하나를 랜더링하는 속도가 더 느립니다. 물론, 사용성에 영향을 줄 정도는 아니지만 느린 건 느린 겁니다. 그렇기 때문에 애플리케이션 로직이나 복잡도의 문제가 아니라 자바 자체의 문제라고 결론을 내릴 수 있는 것입니다.

믿기 힘드시다면 한 번 재보세요. 왼쪽 화살표키를 가만히 누르면서 1분 동안 몇 번이나 왕복하는지 세보세요. 대조 프로그램도 똑같이 테스트해보고 나서 메뉴 개수로 나누면 메뉴 하나 랜더링 속도가 나오겠죠. 물론 메뉴마다 항목의 숫자가 다르지만 어차피 네이티브 쪽이 더 빠른 걸로 나올 테니 상관 없습니다.

이것도 메뉴 테스트만 했기 때문에 이 정도 차이가 나는 거지 메세지 상자, 텍스트에어리어, 버튼, 이미지 로딩 등 광범위하게 테스트해보면 격차는 더 큽니다. 좀 복잡한 화면을 구성해서 for 문으로 랜더링만 반복적으로 시키는 프로그램을 짜 봐도 속도 차이가 납니다.

여기서 자바의 어디가 원인이냐...라고 묻는다면 제 대답은 "모르지만 JNI나 메소드 콜은 아니다"입니다. 그리고, 자바 GUI가 느리냐 아니냐의 문제에서 자바의 어디가 원인이냐는 필요하지 않은 이야기입니다.

그럼, 단순 테스트는 사용성에 문제가 없을 정도로 빠르니까 속도 때문에 자바 GUI 못 쓴다고는 할 수 없지 않느냐. 네, 이 부분도 100% 증명 가능한 논리전개가 가능한 상황이 아니라는 점 인정합니다. 정황적으로 그렇게 볼만한 증거가 꽤 있다는 것입니다.

1. 단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션들은 다 속도에 문제가 있습니다. 비슷한 기능의 다른 프로그램들은 자바 버전보다 압도적으로 빠릅니다.
2. 최소 기능 셋으로 비교를 하면 자바가 네이티브, .NET 등보다 느립니다. 1번과 맞물려서 생각해보면 기능이 많아질수록 처음에는 작은 차이이던 것이 점점 증폭된다고 상상하기 쉽겠죠.
3. 유용한 PC 애플리케이션 중에 자바로 된 것은 극히 드뭅니다.

정리하면 이렇습니다. 자바 GUI가 다른 GUI보다 느리다는 것은 이미 주관적인 의견이 아니라 그냥 fact라고 봅니다. 하지만 단순 테스트로는 자바 GUI가 사용성에 지장을 줄 만큼 느리다는 증명은 할 수 없다는 것 역시 사실입니다. 그 이상의 이야기는 정황적인 추측입니다. 제가 아무리 느린 자바 애플리케이션을 예로 들어봤자 "어, 그거 잘못 짜서 느려"라고 하면 할 말 없죠.

그러나, fender님은 이 논쟁에서 아주 유리한 입장에 서 있으십니다. 제 주장을 단 하나의 반례로 뒤엎을 수 있습니다. 제법 실한(?) 기능을 갖추고 있으면서 아무도 이의를 제기하지 않을 정도로 빠른 속도를 보이는 자바 애플리케이션을 단 하나만 소개해주시면 되겠습니다. 그럼 저도 자바 GUI가 충분히 빠르다는데 바로 동의할 겁니다.

fender의 이미지

제가 이야기한 건 그렇게 일반적인 주장이 아니라 단순한 메소드 호출 몇 번이 0.5초대의 오버헤드를 초래할 정도로 느리다면 자바는 데스크탑은 물론 훨씬 고성능이 요구되는 서버 시장에서도 애초에 퇴출됐어야 한다는 뜻이었습니다. 이 부분에 대해선 creativeidler님이 주장하시는 오버헤드가 JNI도 아니지만 메소드 호출과정에서 생기는 것도 아닌 알 수 없는 어딘가에서 발생한다라고 하셨기 때문에 더 이상 논의가 진행될 수 없이 결론났을 뿐입니다.

제시하신 '실험'에 대해선... 솔직히 잘 모르겠습니다. 눈으로 봐서는 메모장의 메뉴보다 제가 만든 샘플이 느린지 안느린지 잘 분간이 가지 않습니다만 그게 그렇게 논지에 중요하다면 넉넉잡아 한 20%쯤 느리다고 인정해드릴 수는 있습니다. 하지만 그게 정말로 creativeidler님의 논지에 도움이 되나요?

creativeidler님께서는 데스크탑 자바 어플리케이션의 활용을 막는 문제로 느린 반응성을 드셨고, 그 근거로 이클립스와 같은 특정 프로그램은 실제로 비슷한 다른 네이티브 어플리케이션과 비교해서 (주관적이지만) 사용성에 영향을 줄만큼 느리다고 하셨습니다. 여기까지만 봐도 일반화의 오류입니다만, 님께서는 한 단계 더 나아가 이는 자바 플랫폼 자체의 문제라고 하셨고 이는 메뉴 하나만 띄워봐도 확실히 알 수 있다고 하셨습니다.

그래서 샘플을 만들어봤더니 제가 만든 샘플의 메뉴가 메모장보다 대충 20%쯤 늦게 뜬다고 가정하겠습니다. 그런데 그 20%의 차이란 것이 메뉴를 활성화시키고 화살표로 메뉴 전환을 수십번씩 해가면서 시간을 재고 반복횟수를 재야 알 수 있을 정도의 차이라면, 메뉴의 일반적인 의도된 동작 - 즉, 일상적으로 메뉴를 클릭하고 사용하는 과정이라면 거의 눈치채기도 힘든 정도의 차이라고 할 수밖에 없을 것입니다.

그럼 이 '실험'이 creativeidler님의 주장을 뒷받침하는 근거로 사용되려면, 그 미세한 차이가 보통의 어플리케이션에서는 실제 사용에 지장을 줄만큼 엄청나게 증폭되어야하고 이는 코드의 문제가 아닌 자바 플랫폼 자체의 문제라는 사실을 증명해야합니다.

아직까지 말씀하신 내용 중에는 이와 같은 사실을 납득할만한 어떠한 객관적 논증도 찾아볼 수 없습니다.

마지막으로 제가 creativeidler님의 주장을 반박하기 위해서 속도 빠른 자바 데스크탑 어플리케이션을 찾아야할 이유는 없습니다. 왜냐하면 creativeidler님과는 달리 저는 특정 어플리케이션과 다른 언어로 작성된 비슷한 특정 어플리케이션의 체감 반응성 비교 정도로 언어의 근본적인 성능 문제를 논할 수 있다는 생각은 갖고 있지 않기 때문입니다.

제 입장을 정리하자면 최소한 속도와 네이티브 피델리티 측면에서만 볼 때는 SWT의 경우 대부분의 데스크탑 응용프로그램을 작성하는 데 충분히 적합하다는 것입니다.

아직까지 SWT 응용프로그램의 수가 많지 않다면 JRE배포의 문제, 패키징의 문제, 이 글타래에서도 극명하게 드러난 언어에 대한 인식 문제 등이 결정적이라고 생각합니다만, 이를 순전히 제 개인적 추측이라고 치더라도 역으로 그 모든 건 성능의 문제이고 이는 자바의 근본적 한계이다라는 결론을 낼 수 없습니다.

최소한 그런 주장을 이클립스와 VS의 체감 성능 비교나 메모장이 1초에 메뉴 전환이 몇번 가능한가 같은 식의 실험으로 '증명'하는 것은 논리에 맞지 않는다고 봅니다.

아무튼 추가적인 논거를 제시하시지 않는다면 이 정도로 그냥 주관적 느낌/생각의 차이로 정리하고 끝낼 수밖에 없을 듯 합니다. 저 또한 creativeidler님의 주장을 '이건 의견이 아니라 fact다'라는 일방적 선언하나로 수긍하고 넘어갈 수는 없으니까요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

fender님은 계속 자바 GUI가 느리다는 "증명"을 원하시는 것 같습니다. 그거라면 전 못합니다. 자바 GUI가 느리다는 저의 주장은 수많은 비확정 증거에 기반하고 있지만 확정 증거를 제시할 수는 없습니다.

그러나, 이게 주관적이냐 객관적이냐랑은 또 다른 문제입니다. 과학이라고 해서 확정 증거만으로 이론을 정립하는 것은 아닙니다. 진화론조차 수학적인 정리 수준으로 "증명"을 할 수는 없습니다. 수많은 증거들을 가장 잘 설명하는 이론이 진화론이라는 것 뿐이죠. 그렇지만 이런 비확정 근거들을 통해서도 가설을 세울 수 있고 그 가설을 발전시키고 또 활용할 수 있습니다. 전 이런 실용적인 측면에서 논의가 진행되기를 바라는 것입니다.

성능 문제라는 게 언제나 확실하게 증명하기는 어렵습니다. X가 느리다는 것도 클라이언트-서버 구조가 문제일 것이라고 많은 사람들이 주장해왔지만 아무도 증명해내진 못했습니다. OS 커널부터 디바이스 드라이버, 인터럽트 구조, VM 구조, 클래스 로딩까지 수많은 부분을 고려해야 하는 부분이고 이론만으로 증명하기엔 복잡도가 너무 큽니다.

제가 이야기하는 근거 중에서 확정 근거는 "자바 GUI가 네이티브나 .NET보다 느리다"를 뒷받침하는 "최소 기능 셋 테스트에서 자바 GUI가 느리다"라는 것 뿐입니다. 이건 충분히 입증가능한 확정 근거라고 볼 수 있겠지요.

하지만, 여기서 "자바 GUI가 사용성에 지장을 줄 정도로 느리다"로 가는 이야기에는 확정 근거가 없습니다. 대신 비확정 근거들로 뒷받침하고 있는 것이죠. 최소 기능 셋이 약간 느리니까 기능이 많아지만 그 차이가 증폭될 것이다, 현실적으로 serious한 자바 애플리케이션 중에 빠른 애플리케이션이 없다 등이 그것입니다. 이클립스 역시 비확정 증거입니다.

어차피 이 논쟁은 fender님 역시 "serious한 자바 GUI 애플리케이션의 속도가 충분히 빠르다"라는 것을 증명하실 수는 없으실 것입니다. 제 주장이 논리적으로 100% 증명할 수 없는 것이라고 반박할 수는 있겠지만요. 서로 현학적인 증명 논쟁을 하고 싶은 게 아니라면 좀더 실용적인 수준에서 이야기를 하는 것이 바람직하지 않겠습니까.

그리고, 제가 다시 코딩하기 귀찮아서 이야기를 안 꺼내고 있었지만, 더 확률을 높여줄 수 있는 테스트도 있습니다. 다른 기능은 전혀 없이 GUI 컴포넌트만 잔뜩 집어넣고 테스트해서 비교하는 것입니다. 제가 재작년에 해본 테스트인데 그 때만 해도 엄청난 차이가 났습니다. 트리, 테이블, 리치 텍스트, 이미지 아이콘 등까지 포괄하면 차이는 점점 더 벌어집니다. 하지만 이것 역시 확률을 높여주는 비확정 증거일 뿐이고 fender님이 원하시는 "증명"은 안될 것입니다.

진화론자들이 반대파에게 흔히 하는 말이 있습니다. 고생대 화석으로 포유류가 나오면 진화론 다 집어치우겠다고 말입니다. 진화론이 비확정증거에 기반한 과학이다보니 반대 쪽의 확정 증거 하나만 나오면 아주 쉽게 뒤집을 수 있습니다. 제 주장 역시 마찬가지입니다. 진화론만큼의 신뢰도는 아니겠으나-_-a 충분히 실용적인 비확정 증거를 확보하고 있다고 생각합니다. 하지만 fender님이 반대되는 확정 증거 하나만 제시하면 아주 손쉽게 뒤집을 수 있다는 것입니다. 이건 fender님에게 드리는 "요청"이 아니고 그냥 그러면 fender님이 손쉽게 논쟁을 종식시킬 수 있다고 알려드리는 것 뿐입니다.

만약 그렇게 논리적 결함이 전무한 주장을 원하신다면 저는 이렇게 주장하겠습니다.

----
자바 GUI를 최소 기능 셋으로 테스트해보면 네이티브보다 약간 느릴 뿐 사용성에 지장은 주지 않는다. 그러니 여러분은 자바 GUI로 기능이 많으면서 빠른 애플리케이션을 작성할 수 있을지 모른다. 하지만 신기하게도 아직 그걸 해낸 사람은 본 적이 없고 현존하는 유용한 자바 GUI 애플리케이션은 전부 느리다. 하지만 네이티브나 .NET으로는 기능이 풍부하면서 빠른 애플리케이션이 엄청나게 많다.
----

fender의 이미지

주장하시는 것이 결국 '객관적 근거는 없지만 아무튼 자바는 느려서 못쓰겠다'는 것이라면 그냥 '그건 내 주관적 느낌이다'라고 하시면 될 문제입니다. 제가 썬의 마케팅 담당도 아닌데 다른 사람의 주관적 느낌에 대해 왈가왈부할 이유가 없습니다. 왜 주관적 느낌을 진화론까지 연결해가면서 '자바 개발자만 외면하는 진실' 쯤으로 강변하려 하시나요?

객관적, 기술적, 논리적, 사실적 근거가 있다면 이를 제시해서 논의를 더 이어가시는 건 환영합니다만, 주관적 느낌을 아무리 반복적으로 길게 단정적으로 말한다고 해서 신뢰도가 높아진다고 생각하진 않습니다.

그리고 왜 자바 데스크탑 어플리케이션이 안쓰이는 가에 대한 부분 역시 충분히 논리적 오류와 기술적 이유에 대한 설명을 드렸음에도 불구하고 동일한 주장을 반복하신다면 저 또한 이전 논점을 요약하는 것으로 논의를 접겠습니다. 이런식으로 논점은 하나도 없는 동어 반복은 보는 분들에게도 짜증을 유발할지 모르니까요...

만일 주장하시는 대로 '자바 언어 자체가 데스크탑 어플리케이션에 못쓸만큼 느리다'가 참이라면 SWT도 자바인이상 SWT 기반 데탑 어플리케이션이 별로 없는 이유를 설명할 수 있습니다.

하지만 역으로 SWT기반 데스크탑어플리케이션이 별로 없다는 사실로 부터 자바 언어 자체가 데스크탑에서 못쓸만큼 느리다는 일반 명제를 도출하는 건 말씀대로 '논리적 결함이 전무한 주장'이 아니라 교과서에도 나오는 기본적인 논리의 오류입니다.

기술적 배경도 이미 설명드렸지만 데스크탑 분야에서 자바에 대한 인지도가 매우 낮고 배포방법 등에도 해결되지 않은 문제가 많은 마당에 SWT 어플리케이션 수가 많지 않은 건 반드시 성능상의 문제를 의미하는 건 아니니까 말입니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

----
자바 GUI를 최소 기능 셋으로 테스트해보면 네이티브보다 약간 느릴 뿐 사용성에 지장은 주지 않는다. 그러니 여러분은 자바 GUI로 기능이 많으면서 빠른 애플리케이션을 작성할 수 있을지 모른다. 하지만 신기하게도 아직 그걸 해낸 사람은 본 적이 없고 현존하는 유용한 자바 GUI 애플리케이션은 전부 느리다. 하지만 네이티브나 .NET으로는 기능이 풍부하면서 빠른 애플리케이션이 엄청나게 많다.
----

아니, 이 주장에서 그런 논리적 오류를 찾아내셨단 말씀입니까! 놀라운 능력이십니다. 혹시, 확대 해석의 오류를 범하고 있지는 않은지 생각해보시면 어떨까요.

거듭 말씀드리지만, 확정 증거 / 비확정 증거는 주관적 증거 / 객관적 증거와는 다릅니다. 진화론 비유가 마음에 안들어도 이해는 하고 반박을 하셨어야죠. 님 논리대로라면 진화론도 그냥 주관적 의견이 되버리는 건가요? 객관적(?) 증거가 하나도 없으니?

그리고 참고로 말씀드리면 2001년에 자바 스윙이 세간의 주목을 받고 있을 때도 비주얼 에이지 등에서 자동 배포를 지원했습니다. SWT가 나왔을 때도 자바 GUI가 전례 없이 재조명을 받았는데 그 때도 이미 인스톨쉴드랑 비슷한 자바 패키저, 인스톨러가 있었습니다.

현재는 그때보다 상황이 훨씬 좋아졌죠. CPU나 그래픽카드는 훨씬 빨라졌고 자바 배포 방법으로 여러 가지 좋은 대안이 있는 상태죠. 그럼 이 토론을 지켜본 합리적인 사고 능력이 있는 개발자들은 자바가 느리다는 객관적 증거가 없으니까 자바를 선택할까요? 아니면 여러 가지 정황을 보고 다른 방법을 선택할까요?" 어떤 선택이 더 합리적일까요? 지금은 사람들이 자바 GUI가 느리다는 과거의 속설에 갇혀서 크로스 플랫폼 애플리케이션을 만들 때 자바는 고려조차 해보지 않았기 때문에 MySQL Workbench 같은 방법을 선택하는 것일까요?

fender의 이미지

전 빠지겠습니다. 더 이상 '토론'이 아니군요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

원래, 토론이 아니라고 생각될 때는 그냥 아무 말 없이 빠져야 하는 겁니다. 더 이상 토론이 아니라는 토를 다는 것은 싸우다가 상대에게 돌멩이 던져놓고 "난 이제 안 싸울래"하고 도망가는 얍삽한 행동입니다.

저도 이 토론이 진흙탕이 되었다고는 생각하지만 같이 진흙 묻혀놓고 이제 와서 그런 말씀 하시니 좀 그러네요. 뭐, 먼저 선을 넘은 것은 저니까 제 책임이 더 크지만 결과적으로 똑같은 행동을 해놓고 그러시는 건 유감입니다.

뭐, 판정은 GUI 애플리케이션 개발자들이 하겠지요. 그저, 이번 일을 통해서 fender님도 배우는 것이 있기를 바랄 뿐입니다. byebye~

bookgekgom의 이미지

님 말투는 상당히 재수 없습니다.

'ㅅ' 누군가 말해줘야 할것 같아서요.

저도 말투가 꽤나 정상이 아닙니다만은

님 말투를 듣고 있자면 "내가 최고니까 너넨 듣고 배워"

이런 싸가지가 들리는거 같아여.

"그저, 이번 일을 통해서 fender님도 배우는 것이 있기를 바랄 뿐입니다. byebye~"

는 님의 병맛스러움을 한층 업그래이드 시켜주는 말투중 하나라고 볼수 있겠군요.

저는 지식이 별로 없어서 누가 옳고 그른지 알지는 못하겠으나

두분의 대화를 읽으면

fender 님께서 지금 creativeidler 실력이 아주 낮다고 치더라도

몇달후면 creativeidler 님보다는 더욱 실력이 높아질것이라고 생각합니다.

왜냐구요?

님처럼 병맛스럽게 대화하는 새끼들보고 지식을 빠르게 습득하는 새끼들은 본적이 없어요.

지는 남들에게 배우라고 하면서 지는 귀를 틀어막고 배우질 않는 아주 병X 들 말이죠.

댓글읽으면서 느끼는거 없나여?

딴 사람들이 "creativeidler 님이 하시는 말에 배울게 있으니 배워야겠다~"

이러니까 지는 배울게 없다고 느끼나여?

님이 저에게 알려주신것들중 몇부분은 감사드리지만

이번과 같은 토론의 자세는 배우지않곘어요.

이글은 로금을 각오하고 쓰는거임

할말은 하고 살아야 겠음

결론은 님 재수없음 'ㅅ' ㅗ

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

creativeidler의 이미지

짧은 지식으로 고수들 훈계했다가 다 뽀록나서 쪽팔리셨음? 그래서 열받았음? 잘 모르면서 설치는 건 당신도 나만큼이나 재수 없소이다. 내가 재수 없다는 건 나도 이미 알고 있고 여기 다른 사람들도 이미 다른 쓰레드들을 통해서 다 알고 있을 꺼요. 나름 각오하고 썼을 텐데, 별반 새로울 것도 없는 이야기인 줄은 몰랐으려나?

글고, 글이나 좀 제대로 읽으삼. 내 말에서 배우라는 이야기가 아니고 이 사건에서 배우라는 이야기임. "fender님도"라고 쓴 거 안 보이오? "도"가 뭘 뜻하는 건지 상상 한 번 해보시오. 나 역시 이 사건에서 교훈을 얻었기에 한 말이오. fender님도 자바 고수인데 내가 뭐 가르칠 게 있다고... 물론 당신은 나한테 직접 배울 꺼도 엄청 많을 꺼요-_-

ddoman의 이미지

두분은 주제를 바라보는 시각이 살짝 달라서...
(느리다는 표현의 정의가 다른거 같습니다) "기술적" 토론을 했지,
아무도 상대방을 비하하거나 근거없이 비판하지 않았습니다.

bookgekgom님은 위에서 creativeidler님의 댓글에 마음의 상처를 입으신건지
가만히 있다가

뜬금없이, 아무런 근거 없이

그냥

"님 재수없음 'ㅅ' ㅗ"

과 함께 fuck you를 의미하는 욕을 날리시네요.
당신같은 사람들이 더 문제입니다.

도대체 저런 글에 +1 을 준 사람이 누군지는 모르겠는데
설마 bookgekgom님 자신이 자신의 글에 +1은 주지 않았기를 바래봅니다.

serikas의 이미지

이 분 밑에서 어설프게 글 썼다가 반박을 무더기로 받더니 삐지셨군요.

누가 누구에게 해야 할 말인지 원...

lateau의 이미지

당사자이신 두 분은 '진흙탕' 정도로 표현하셨습니다만, 나름 재미있고 유익한 토론이었다고 생각합니다.
사람이 감정이 있고 그에 따라 토론도 여러 양상을 보입니다.

'말투' 이것도 어느 정도 선을 넘지 않으면 별 문제가 아니겠지요. :)
만약 '배운게 있으리라 봅니다 bye~ bye~'가 문제가 되려면 양키들이 운을 띄울 때 많이 쓰는 'as You know...'는
상대를 완전 무시하고 있다고 봐야겠군요.

전 두 분 다 배운게 있으리라 봅니다. 당장은 아니더라도 앞으로 차차 시간이 지나면 말이죠. :)
두 분 덕분에 몰랐던 내용, 즐거운 내용을 잘 읽고 갑니다.

아무리 누가 뭐래도 독자는 독자나름대로 결론을 낸다... 겠죠? :)
너무 직설적인 표현은 자제해주세요. '사진 찍지마.. 시..ㅂ' 가 생각나는군요. 불특정 다수를 불쾌하는 건 스스로를 공격대상으로 만들 뿐이 아닐까요? :)

- Why don't you come in OpenSolaris? I hope you come together.

--
I think to myself...what a emerging world.

hongminhee의 이미지

토론 내용과 상관 없이 ‘원래, 토론이 아니라고 생각될 때는 그냥 아무 말 없이 빠져야 하는 겁니다’라는 말에는 정말 동의합니다.

lateau의 이미지

UI반응 속도도 속도이지만 사용하는 메모리양을 보면 가히 예술적입니다.
순수 swing이 아닌 NetBeans Framework로 작성한 어플일 경우에는 메모리 누수현상이라고 의심될 만큼 많은 메모리를 소비하더군요.

하지만 그저 비교하기만 할 수 없는 것이 운영체제 차이도 큰 것 같더군요.
OpenSolaris 2008.11에서 swing으로 작성한 어플은 다른 운영체제에 비해 메모리도 더 소비하고
jds관련 runtime exception이 빈번히 발생하더군요. 같은 어플을 윈도우에서 돌렸을 때는 절반 이하의 메모리 소비에 runtime exception도 발생하지 않았습니다만...

절대적인 수치로 계산해보지 않았지만 일단 자바 쪽이 기본적으로 너무 많은 리소스를 사용하는 것 같습니다.
개발자로선 엄청난 불만이군요. :(

- Why don't you come in OpenSolaris? I hope you come together.

--
I think to myself...what a emerging world.

unipro의 이미지

구글의 크롬이 이와 같이 개발하는 것으로 알고 있습니다. 우선 사용자가 많은 윈도우즈 플랫폼을 목적으로 빠른 시간에 테스트 버젼을 출시합니다. 테스트 버젼을 빨리 출시하면 그만큼 사용자로부터 제품의 개선사항을 받을 수 있어서 완성도 있는 제품을 좀 더 짦은 기간에 출시할 수 있습니다.

개발자 관점에서는 다중 플랫폼을 고려한 개발이 제일 먼저 눈에 띄겠지만, 정작 중요한 것은 고객 관점에서 그들의 요구사항을 제품에 잘 적용하는 것 입니다. 다중 플랫폼을 위해서 기껏 이것저것 구현하느라 시간을 더 쓰면서 개발을 했더니, 막상 고객이 원하지 않는 기술이었다면 쓸데없는데 시간을 낭비한 셈 입니다. 따라서 고객의 요구를 좀 더 빨리, 좀 더 정확히 알 수 있는 방법이 있다면 그것을 첫번째의 목적으로 해야 한다고 생각합니다.

----
내 블로그: http://unipro.tistory.com

내 블로그: http://unipro.tistory.com

hongminhee의 이미지

충분히 일리가 있는 이야기들 같은데요. 그리고 저도 JRE 설치하기 무척 싫더군요. 크로스플랫폼 GUI 툴킷 사용하지 않는 이유도 바로 이해가 됩니다. Mac OS X에서 비 Cocoa 애플리케이션이 얼마나 우스꽝스럽게 나오는지 아는 사람은 이해가 될 겁니다. X라도 뜨게 되면 얼마나 보기 싫은지. (아는 사람의 표현을 빌리자면 “무도회장에 노숙자 갖다놓은 것 같은” 모양.) MySQL GUI Tools의 Mac OS X 버전은 모두 Cocoa로 작성된 것 같던데, 그래서인지 무척 깔끔하고 만족스러웠습니다.

noblepylon의 이미지

wxWidgets(전 wxWindows)는 어떤가요?
크로스 플랫폼이지만 플랫폼마다 네이티브로 작성된걸로 알고있습니다.
(윈도에서는 WinAPI, 맥에서는 Carbon, 리눅스에서는 GTK+)
여기 보면 Cocoa버전도 개발중이라는군요.
---
“내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라.”(빌립보서 4:13)

---
“내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라.”(빌립보서 4:13)

bookgekgom의 이미지

윗분들 자바에 관해 그렇게 얘기하시다니요.

지금 저의 애인 자바가 울고 있습니다.

하나 하나 반박을 하겠습니다.

--------------------------------------------------------------------------------------------
1. creativeidler "자바 GUI 는 느리다"

자바 개발 툴에서 자신이 만든 프로그램을 실행하면서 느리다고 하시는건 좀 아니잖아요.

일단 jar 파일로 컴파일하신후 에디터를 통해서가 아닌 실재로 돌려보셔야죠.

debug 프로그램하고 release 프로그램하고 같나요?

그리고 씨쁠쁠에서 컴파일 할때는 컴파일 옵션을 주시면서 자바는 아무것도 안주시지 않나요?

예) 자바에서 게임이라면 OS 에서 지원하는 그래픽 카드 파이프 라인

OpenGL 혹은 DirectX 파이프라인을 사용하는 컴파일 옵션을 주셔야

만족하는 jar 파일 결과가 나옵니다.

----------------------------------------------------------------------------------------------

2. fender "자바 스윙 look & feel 이 맘에 안든다(?)"

자바 스윙은 3 가지의 테마를 지원합니다.

- 지금 사용중인 OS 의 기본 테마.

- 자바에서 지원하는 몇 종류의 테마.

- 자신이 직접 만든 테마 (JTattoo 혹은 JNapkin 등)

이중에서 자신이 직접 고르면 됩니다.

혹은 오버라이딩을 통해 직접 색을 칠해주는 방법도 있죠.

제가 2 번에 ? 표를 친 이유는 자바 개발 자시라면 당연히 알고 계실거라 믿기에

제가 질의를 잘못 파악한것 같아서 친겁니다.

제가 잘못이해했다면 사과드립니다.

------------------------------------------------------------------------------------------------

3. lateau "메모리를 너무 많이 먹는다. 메모리 리킹이 있다!"

이 부분은 반박 할수가 없군요.

일단 자바자체가 jvm 위에서 돌아가는 것이기에 일정량의 메모리를 먹습니다.

더욱 큰 문제는 메모리 리킹인데...

이것은 최신 버전을 받으면 대부분은 사라집니다.

하지만 아직도 메모리 문제가 남아 있긴하죠.

그래도 대부분의 경우는 유저가 프로그램을 잘못 짠겁니다.

무식하게 룹에서 new 를 통해 필요이상의 객체들을 생성하고 처리는 하지 않죠.

어느 한 지점에서 한번씩 System.gc() 를 통해 쓰레기 처리를 해주는것이 중요합니다.

-------------------------------------------------------------------------------------------------

자바 개발 자들이어...

자바는 신생언어 입니다.

문재가 많을 수도 있고 마음에 안들수도 있지만.

새로나오는 기술들도 보지않고 옛날 기술들만을 고집하면 어찌 됩니까?

새로 새로 릴리스 되는 자바 문서를 읽으며 공부를 하는 습관을 들입시다.

-미국에서 자바하던 학생이 돌아다니다가 끄적여봄-

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

creativeidler의 이미지

글들을 다시 한 번 읽어보시기 바랍니다. 자바 애플리케이션 개발자의 관점이 아니라 사용자의 관점입니다.

그리고, 이클립스에서 실행한다고 디버그 모드로 실행되는 거 아닙니다. SWT 같은 GUI 툴킷에서는 컴파일 옵션 아무 거도 안 줘도 잘 동작합니다. JVM 옵션을 준다면 모를까. 게임은 논외입니다.

또, GUI 테마는 OS 전체의 테마와 어울려서 돌아가야 합니다. 자바는 그게 잘 안됩니다. 네이티브 룩으로 골라도 매끄럽게 안됩니다. 맥 유저들이 이클립스가 코코아 테마 안 쓴다고 얼마나 싫어했는지 아십니까? KDE에서 떡하니 뜨는 Gtk의 이클립스 역시 밉상이긴 마찬가지입니다.

자바의 메모리 사용량이 많은 것과 메모리 누수는 완전히 다른 문제입니다. 자바의 메모리 사용량이 많은 것은 메모리 누수 때문이 아니라 JVM 설계 자체가 메모리를 희생해서 속도를 높이겠다는 튜닝 전략이 들어가 있기 때문입니다. 자바 버전하고도 상관 없는 문제입니다.

그리고, 자바 신생 언어 아닙니다. 10년 가까이 프로그래밍 언어 세계 시장 점유율 1위를 지키고 있는 언어가 무슨 신생 언어입니까. 구닥다리 자바를 아직까지 쓰냐는 소리를 듣기도 하는 마당에 말입니다. SWT 나온지는 언젠지 아십니까? 신기술이 무조건 좋은 것도 아니거니와, 신기술 기준으로 따지면 .NET이 자바보다 신기술입니다. 그럼 이제 .NET 쓰시렵니까?

여기 님보다 자바 잘 알고, 잘 하는 사람 많습니다. 어설픈 지식으로 공부하라느니 훈계 늘어놨다가 뒷감당은 어떻게 하시렵니까?

bookgekgom의 이미지

훈계를 한적은 없는데...

맨 마지막 세줄은 님이 옳습니다.

GUI 테마가 OS 와 어울리지 않는다는 것은 납득이 가지 않네요.

스크린 샷이 한번 보고 싶습니다.

그리고 자바의 퍼포먼스는 버전이 바뀔때마다 발전하기 때문에 새버전을 쓰라고 한것이구요.

위에 답글을 보면 자바의 반응이 느리다고 하시는데

예제 소스를 볼수있을까요?

그리고 어떻게 이해하면 제말이 훈계로 바뀌는지 궁금하군요.

전 훈계를 한적이 없습니다.

억울해요 ㅠㅠ 으허헝ㅎ;ㅣ어히ㅏㅓㅇㅎㅎ

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

xylosper의 이미지

그놈쪽이면 또 모를까, Gtk가 리눅스의표준도 아니고, KDE에서는 눈꼽만큼도 어울리지 않습니다.

hongminhee의 이미지

SWT로 그려진 GUI는 Mac OS X에서 확실히 못생겼습니다.

fender의 이미지

이클립스 3.5부터는 코코아 버전의 SWT가 정식으로 들어간다고 하네요...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

소타의 이미지

이클립스를 주 개발도구로 쓰고 있는데 구동시간이야 그렇다 치고 글자 찍히는게 타이핑을 못 따라옵니다. 맥이랑 윈도우에서 쓰고 있고요.
자바가 10년이 훨씬 넘었으면서 아직도 성능 우선적인 프로젝트에서는 왠만하면 배제할 만큼 느리다는 생각을 가지고 있는 사람 중에 하나입니다.. =_=

우리가 익히 쓰고 있는 어플 중에 자바로 된 것이 어떤것이 있는지 궁금합니다.
그 중에서 그동안 느린걸 모르고 써온게 있다면 "어? 자바로 된 것 중에도 이렇게 느리다는 생각 못하고 편한게 있었다니?" 라고 느끼게 되지 않을까요?
반대 케이스만 언급해 봤자 아무도 설득 안 될 것 같습니다.

아니면 비교가 될만한 어플과 같은 기능을 가지면서 충분히 빠른 어플의 코드를 주셔도 됩니다. (사실은 필요 없음... 특정 케이스에 대한 코드 요구는 토론에 전혀 도움 안됨; )

lateau의 이미지

1. 컴파일 옵션
필요할 때 골라서 주고 있습니다. 덤으로 테스트 시(실사용)는 항상 컴파일/패키징 완료 후 진행합니다.
대부분 넣지 않을 거라는 말씀은 동의합니다. 저도 자바 컴파일 옵션이 황홀할 정도로 많다는 걸 뒤늦게 깨달았거든요. :)

2. 스윙 UI
여러 프로젝트가 진행중인 것으로 알고 또 만족할 만한 UI가 많이 만들어져 개발시 '테마' 형태로 넣으면 된다는 발상은 매우 매력적이며 개발자가 UI가 아닌 기능에 충실할 수 있도록 도와주는 것 같습니다. :)

그건 그렇지만 스윙 자체에서 지원하는 고유OS UI도 그렇게 좋은 성능은 보여주지 못하는 것 같습니다. 일단 사용하다보면 '이건 절대 네이티브가 아니야'라고 알아채는 사람도 많습니다.(정말 미묘하지만 알아채더군요. 이질감이랄까요?)
특히나 개발자 입장에서 보면 드래그 시 컴포넌트를 다시 화면에 뿌려주는 것이 미묘하게 느립니다. 그 무겁다던 이클립스보다 체감상 느리다는 느낌을 받을 때가 많더군요.

그리고 특히... 제가 이 부분을 수긍하기 어려운 것은 제가 오픈 솔라리스 유저이기 때문입니다. JDS. 이 말한마디로 '아하~'라고 하시는 분들이 꽤 많을 듯 싶습니다. 오픈 솔라리스의 JDS와 Java desktop system Project는 분명 차이가 있습니다만, 공통적인 이야기는 '느리다' 입니다... 그리고 넷빈즈 유저이기도 합니다...

3.
System.gc()
의외로 많은 분들이 무시하거나 잘 쓰지 않고 있다고 생각합니다만 어느 정도 효과는 있는 것 같습니다.

그 외에

인스턴스 = null

로 gc에 메모리 해제를 알리는 방법도 쓸만하더군요.

좋은 이야기 감사합니다. ~:)

- Why don't you come in OpenSolaris? I hope you come together.

--
I think to myself...what a emerging world.

creativeidler의 이미지

explicit nulling, explicit gc call 모두 throughput을 떨어뜨리는 방법이기 때문에 하지 말라는 것이 JVM vender들의 기본 입장입니다.

fender의 이미지

이전 글에서 말씀드린 '네이티브 피델리티'의 문제는 단순히 '테마가 마음에 들지 않는다'의 문제는 아닙니다.

말씀하신 네이티브 룩엔필의 경우도 최대한 네이티브 위젯을 비슷하게 그렸다고는 하지만 일반 사용자 입장에서 어렵지 않게 스윙 어플리케이션을 구분해낼 수 있을 정도로 완벽하지 않습니다.

그나마 윈도우즈의 경우는 상황이 나은 편입니다만 리눅스의 경우 특히나 글꼴, 파일 선택창의 모양과 동작, 드래그엔 드랍, 단축키의 동작 등에서 스윙의 GTK L&F은 실제 GTK 어플리케이션과 상당한 차이가 있습니다.

그 정도의 차이를 용납할 수 있느냐는 전적으로 개인 취향의 문제이겠습니다만 제 경우에는 상당히 눈에 거슬려서 어지간하면 다른 대안을 찾아보게 만들게 하더군요...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

soungno의 이미지

데이터 베이스 모델링 툴 이라면 아마 경쟁 제품에서 ERWin이 가장 유력한 제품일 것인데요
ERWin은 M$ 기반에서 동작 합니다.
ERWin 자체가 잛은 시간 사용된 애플리케이션도 아니고 , 지속적으로 개발되고 시장에서 선택 받은 제품으로 만약 ERWin 경쟁 제품을 만든다면 M$ 기반의 데이터 베이스 모델링 툴 사용의 사용자가 압도적으로 많다는 걸 인지 하였겠지요.
저도 개발 프로젝트에서 데이터 베이스 모델링 툴은 vbox에서 실행 되는 M$ NT에서 ERWin 사용하는 입장에서 충분이 납득이 갑니다.

잘 가야지.

kirrie의 이미지

네 사실 저도 궁금했던게 바로 이런 것이었습니다.

어째서 윈도우즈가 먼저였을까. 세가지 플랫폼 가운데 어느 하나를 먼저 출시해서 나머지 두개의 고품질 백엔드 코드를 만들겠다는
시도는, 뭐 그럴 수도 있다고 해도 어째서 윈도우즈가 먼저여야만 했을까가 궁금했던거죠. 리눅스나 맥이 먼저일 수도 있었던거잖아요.
그것의 대답이라고 내놓은 '버그 리포트 율이 윈도우즈가 가장 높았다'는 어딘지 모르게 빈약해 보였고...

soungno님 말씀처럼 라이벌 제품의 마켓쉐어를 염두한 선택일 가능성이 높아 보이는군요.
--->
데비안 & 우분투로 대동단결!

--->
데비안 & 우분투로 대동단결!

소타의 이미지

글이 GUI에서의 자바 성능 문제로 흘러가고 있군요 ㅎㄷㄷ;;

idotrip의 이미지

회사입장에선 쓸데없는 낭비는 줄여야 합니다.

2% 밖에 안되는 리눅스 유저를 위해 같은 50%의 비율로 개발비를 투입하는건 미친짓입니다.

마치 운동권에서 자기들이 절대 다수인량 의견을 관철하는 것과 비슷하지요.

kirrie의 이미지

mysql workbench가 일반 유저들이 사용하는 단순한 어플리케이션이고, 국내에서만 출시하려고 한다면 idotrip님의 말씀에도 일리가 있을 수 있습니다만,
이것은 개발자용 툴이고 국내와는 달리 외국에는 윈도우즈 외에 다양한 플랫폼에서 개발하는 분들이 엄청 많습니다.
하나의 예로, '몇분만에 블로그 만들기' 운운하는 각종 언어들의 프레임웤 동영상을 보면 하나같이 모두 맥에서 작업하는 것을 확인할 수 있습니다.
(cakephp나 codeigniter, ruby on rails... 적어도 제가 확인한 바로는 그렇습니다.)

다양한 플랫폼을 지원하려고 계획한다는 것은 '쓸데없는 낭비'가 아니라, 이제는 필수가 아닌가 하고 생각해봅니다. 새로운 needs를 창출할 수도 있고
그렇게 창출된 시장에서 선도하는 입장에 설 수 있으니까 말이죠.
--->
데비안 & 우분투로 대동단결!

--->
데비안 & 우분투로 대동단결!

mycluster의 이미지

경험적으로...

모 가상화 솔루션의 콘솔프로그램이 Java로 되어 있고, 다른 가상화 솔루션의 콘솔프로그램은 냉정하게 .Net 기반의 윈도우용만 제공하는데, 두가지를 다 본 고객의 왈...

'얘는 자바로 해서 정말 미치는 줄 알았는데, 역시 윈도에서는 전용클라이언트가 좋군요. 확실히 빠르네요'

이것 말고도 Java로 만들어진 콘솔을 제공하는 프로그램에 대한 반응은 항상 별로였다는 것...

'윈도용부터 제대로 좀 만들고, 반응이 좋아서 리눅스용도 사람들이 원한다면, 그때 돈많이 주면 만들어줘. 윈도우에서 잘나가는 프로그램을 사용하고 싶은 리눅스 유저들은 기다리라면 기다리니까... 기다리기 싫으면 딴거 쓰라고 하고...'라고 모 개발회사에 요청한 상태죠.

--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러

--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러

yielding의 이미지

CDC급 jvm을 clean room 구현 하기에는 팀의 역량이나 시간에 한계가 있어서 제가 일하던 곳에서는 ORP 라는 intel기반 vm위에 kaffe의 AWT를 붙여서 iPAQ에 올렸습니다. 저는 AWT 쪽이었습니다. 뭐 그당시 Kaffe의 AWT가 지금의 AWT에 비교가 되겠습니까만, 여하튼 iPAQ에서 AWT프로그램을 돌리는데 성공을 했습니다.(삼성의 넥시오에 올리기 위해서 영업을 하다 외국제품에 밀려서 뭐 프로젝트를 접긴했습니다만...)

간단한 AWT 프로그램 하나를 띄우기 위해서 5개의 Thread가 돌고 상당히 복잡하게 context swiching을 합니다. 상상초월입니다. 디버거로(evc 3.0) JVM을 들여다 보면 프로그램이 동작하는게 신기할 정도입니다. 위젯 하나 show하는 걸 따라가본게 정리된게 있는데..

        MT = main thread
        CT = collector thread
 
 (0)    MT : show                                        (main java)
 (1)    MT :   addNotify                                 (Window)
 (2)    MT :       createNative                          (Toolkit)
 (3)    MT :           [in Block No.1]                   (Toolkit)
 (4)    MT :           evtSendWMEvent(e);
 (5)    MT :              in native                      (evt.cpp)
 (6)    MT :              PostMessage   -->              (context switch)
 (7)    CT :                 in WndProc WMEvent.dispatch
 
 (8)                   [in Block No.2 of (2)]
 (9)    MT :           wait      -->                     (blocking)
 (10)   CT :                 [in WMEvent.dispatch]                               
 (11)   CT :                 c.addNotify              (Window)
 (12)   CT :                      supper.addNotify()      (Window)
 (13)   CT :                      supper.addNotify()      (NativeContainer)
 (14)   CT :                      supper.addNotify()      (Container)
 (15)   CT :                      supper.addNotify()      (Component)
 (16)   CT :                      return to Container     (Compoment);
 (17)   CT :                      for (0 to nchildren)
                                      children[i].addNotify();
                                  }   
                                  return to NativeContainer
                                                              (Container)
 (18)   CT :                      return to Window        (NativeContainer)
 (19)   CT :                      finishAddNotify         (Window)
 (20)   CT :                      return to WMEvent.dispatch (8) 
 
 (21)   CT :                 notifyAll                      (unblock MT) 
 (22)   CT :                 return to WndProc       (evt.cpp)
 (23)   CT :                 end of WndProc and context switch
 (24)   MT :       return to (2): createNative
 (25)   MT :       return to (0): show

위의 구조보다야 지금이 더 좋겠지만 앞으로도 JVM 그리고 UI integration layer의 혁혁한 발전이 몇 번 더 거듭되지않고는 native 만큼 쓸만한 반응성을 보일만한 java GUI 프로그램은 어려울것 같습니다.

Life rushes on, we are distracted

Life rushes on, we are distracted

소타의 이미지

자바로 개발되었고 여러 플랫폼에서 편하게 쓸 수 있는 어플들이 궁금합니다.
자바로 되고 멀티플랫폼 지원하는 좋은 어플들을 나열하면 자바가 GUI어플과 친하지 않다는 것의 충분한 반증이 될 것 같습니다.
제 컴퓨터에는 젠드 스튜디오(이클립스)와 신한은행의 ezplus 가 있고요. 네이티브 어플처럼 이질감이 별로 없습니다. 다른 어플중에도 있을 수도 있을 것 같은데 겉으로 봐서는 이 정도 밖에 구별이 안가네요.
torrent 클라이언트는 Azureus 쓰다가 저번에 다른걸로 바꿨고요. Azureus는 소스포지에서도 award에서 1위를 할 정도로 잘 나가더군요.

자바 느리다 안느리다 백번 얘기해 봐야 소용 없는 것 같습니다. 내가 느낄땐 안그렇다고 하면 끝인데;
사람들이 이미 편히 잘 쓰고 있는 어플이 자바로 된 것을 알게 되면 다시 보게 되지 않을까요..

fender의 이미지

음... 점점 글타래의 본래 주제에서 이탈하는 것 같지만, SWT 조차도 데스크탑에서 널리 쓰이지 않는 이유는 이런 것 같습니다.

(1) 사용자 인식의 문제

이 글타래에서도 극명하게 드러났지만, 데스크탑 자바 어플리케이션에 대한 개발자들과 사용자들의 인상은 상당히 나쁩니다.

일반 사용자 입장에서 접해본 자바 프로그램은 우선 설치하기 불편하고 느리며 이질적입니다.

JRE를 따로 다운받아야 하는 경우도 있고 그나마 시스템에 몇개씩 다른 버전의 자바가 깔리거나 JRE를 다운 받는데 엉뚱하게 오픈오피스나 구글툴바를 기본으로 설치하기도 합니다.

또한 최소한 제 지식과 경험으로는 SWT는 물론이고 심지어 스윙조차도 요즘에는 충분히 빠르고도 남습니다만 일반 사용자의 인식은 그렇지 않습니다. 그 이유는,

- 스윙/AWT는 과거에 정말로 느렸던 적이 있습니다. 또한 JVM 자체의 성능도 최근에 급격하게 향상이 되었기 때문에 과거의 경험을 토대로 판단을 한다면 자바 어플리케이션은 여전히 느리다고 생각합니다.

- 스윙은 체감상 느리게 느껴지는 문제가 있었습니다. 1.5근처에도 스윙은 상당한 성능상의 개선이 있었지만 특히나 레이아웃을 조절하거나 화면 전환시 리페인트 과정이 눈에 보여 껌뻑임이 있다거나 (awt의 더블버퍼링 테크닉 같은 것과는 다른 문제입니다) 해서 더욱 굼뜨게 느껴지는 경우가 있습니다.

- 자바 어플리케이션은 보통 많은 메모리를 소비합니다. 더구나 데스크탑에서 쓰이는 자바 어플리케이션은 jedit, eclipse, azureus 등의 예를 보아도 드러나듯, 컴팩트함 보다는 자바의 언어적 특성을 활용해 다양한 기능을 내세우는 것들이 많습니다. 이 경우 메모리 설정 등을 세심하게 튜닝하지 않는다면 gc나 페이징 등으로 GUI 반응성이 때때로 급격히 떨어지는 경우가 있습니다.

- 스윙 어플리케이션은 이질적입니다. 글꼴, 드래그엔 드랍 특성, 파일 선택 창 등 여러모로 '난 자바 어플리케이션이다'라고 광고하는 느낌이 있습니다. 물론 안좋은 쪽으로 말입니다.

- 상대적으로 마이너한 원인입니다만 사용자는 항상 최신 버전의 JRE를 사용하지 않습니다. 예컨대 우분투 게시판에서 이클립스나 azureus 관련 속도/안정성 관련해서 올라오는 글타래를 보면 절반 넘게 썬이나 OpenJDK 대신 GCJ를 사용해서 생기는 문제입니다.

(2) 개발자 인식의 문제

다른 모든 문제를 떠나서 회사에서는 (1)의 사용자 인식상 위험을 감수하며 굳이 자바로 데스크탑 어플리케이션을 개발할 이유가 전혀 없습니다. 또한 데스크탑 실무 경험이 있는 자바 개발자도 전체 자바 개발자 중 극소수에 불과합니다.

이는 충분히 다른 대안이 있는 경우도 있지만 대다수의 웹관련 비즈니스 어플리케이션이 자바로 작성되는 이유와 흡사합니다. 이미 시장에 널려 있는 자바 개발자와 레퍼런스를 제쳐두고 찾기도 힘든 소수 언어 개발자를 모아 대규모 개발 유지보수를 하겠다는 건 개발사 경영진이나 클라이언트사 담당자 모두 납득할 수 없는 논리입니다.

데스크탑 시장만 봐도 그냥 남들 하듯이 VS로 뚝딱뚝딱 GUI 만들어 낼 줄 아는 개발자가 널렸고, 경쟁업체를 봐도 그게 일반적인데 굳이 다른 방법을 찾을 이유도 없고 실제로 찾기도 어렵습니다.

물론 자바도 마음만 먹으면 위지위그로 개발할 수 있고, exe만들고 인스톨러 만들 수 있습니다. 하지만 예컨대 실무에서 VE로 개발해서 JSmooth등으로 exe 만들고 NSIS 같은 걸로 JRE 디텍트/자동설치 스크립트 짜본 개발자가 도대체 몇 퍼센트나 되겠습니까?

또한 특히 스윙 같으면 최근 까지 네이티브 통합에 여러 어려움이 있었습니다. 하다 못해 브라우저 컴포넌트 하나 어플리케이션에 끼워 넣는 것이 간단한 문제가 아니었습니다. VS로 하면 그냥 웹브라우저 컨트롤 가져다가 떨구면 끝나는 걸 스윙에서는 돈주고 써드파티 컴포넌트 사다가 써야 하는 것입니다, 더구나 크로스플랫폼을 포기해가면서 말입니다.

회사 입장에선 자바로 데스크탑 개발할 이유가 전혀없고, 실무 자바 개발자는 이미 서버등 다른 분야에서 더 나은 대우 받으며 잘살고 있으며, 새로 개발자로 진입하는 사람들에겐 데스크탑 자바의 인식은 최악입니다. 그런 상황에서 데스크탑 자바 어플리케이션이 많지 않은 건 당연합니다.

또한 인식상이 아닌 실제적인 문제 역시 분명히 존재합니다. VS와 달리 개발 환경상 패키징 배포의 번잡함은 이미 이야기한바 있습니다. 회사에서 데스크탑 자바를 개발하지 않는다면 오픈소스에서 나와야 하는데, 특히 리눅스 진영의 자바에 대한 널리 퍼진 선입견은 제쳐놓고라도 실제 리눅스를 타겟으로 하는 자바 클라이언트 어플리케이션을 만드는 것은 쉽지 않습니다.

우선 스윙/AWT는 윈도우즈 환경에 비해 글꼴 처리나 속도의 문제도 해결되지 못했고, 무엇보다 패키징이 무척 애매합니다. 자바 런타임은 메인 저장소에 들어있지도 않을 뿐더러 정책상, 윈도우즈에서 하듯 사용하는 모든 의존 라이브러리를 번들할 수도 없습니다.

더구나 많은 수의 자바 데스크탑 어플리케이션이 플러그인이나 동적으로 라이브러리를 참조하는데, 이를 위해 따로 리눅스용 스크립트를 만들고 버전 충돌이나 클래스 로딩의 잠재적 문제를 다 해결하는 건 간단한 일이 아닙니다. 자바 개발자가 다 리눅스 사용자는 아니니까요...

(3) 결론

앞서 나열한 이유로 아직까지 데스크탑 시장에서 자바의 입지는 무척 협소합니다. 그러다 보니 그러한 상황에서 성공적인 데스크탑 어플리케이션은 주로 자바의 특성을 활용해서 동종 제품 중에 최고 수준의 기능을 집약시키거나 아니면 상대적으로 배포 등의 문제가 덜 민감한 대신 유지보수나 백엔드 통합성, 혹은 크로스 플랫폼 특성 등이 중시되는 특화된 시장에서 사용되는 경우가 많습니다.

첫번째의 예를 SWT와 스윙에서 하나씩 꼽아 보자면 대표적으로 Vuez(Azureus)와 JEdit를 들 수 있습니다. 각각 BitTorrent 클라이언트와 편집기 부분에서 극단적으로 기능과 확장성을 강조해서 성공한 경우입니다. 당연히 동종의 다른 제품들보다 기능은 매우 많고 따라서 무겁습니다.

반면 두번째의 예는 일반사용자들이 거의 접할 수 없는 분야에서 주로 사용됩니다. 특히 RCP 관련 어플리케이션들이 그렇습니다만 특정 솔루션의 프론트엔드나 특화된 분야의 클라이언트 제작에 주로 쓰입니다. 그나마 극소수인 실무 자바 데스크탑 개발자는 거의 이런 쪽으로 먹고 삽니다.

이와 같이 데스크탑 시장에서 엔드유저가 쓸만한 자바 어플리케이션이 많지 않은데에는 상당히 복합적인 이유가 있습니다.

그런 부분에 대한 고려없이 '내가 xx와 yy라는 자바 어플리케이션을 써봤는데 느리더라. 그러니 모든 자바 어플리케이션은 느릴 수밖에 없다'라던가 '자바 데스크탑 어플리케이션이 별로 없는 건 느려서 그럴거야, 안그러면 자바로 안만들 이유가 없잖아?'라고 결론 짓는 건 상당히 나이브한 생각입니다.

적어도 이 분야의 문외한인 일반 사용자들보다 오픈소스 개발자가 많은 커뮤니티라면 이와 같은 토론은 기술적, 논리적 근거를 두고 선입관에 대해 오픈된 태도로 이루어져야 한다고 봅니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

powersys의 이미지

쭉 읽어봤지만. creativeidler 님 말에 동의합니다.

fender님은 사람들이 다 느끼는데 자신만 아니라고 끝까지 우기는 모습은 그리 보기 좋지 않군요..
서로 인정할건 인정해야 대화가 되지 않겠어요..
인정하지 않으려면 확실한 근거가 있어야 하는데. (님이 쓰신 글 중)그런 근거는 보이지 않는데도 우긴다면
그 사람이 대화의 자세가 잘못되어있다고 밖에 할 수 없습니다.

그리고 bookgekgom 님은 좀 돌출적인 오버를 하셨네요..
아무리 자신이 하는 것 이지만. 이성을 가지고 냉정히 글의 내용부터 읽어 보셔야 할 것입니다.
언어가 도구 일뿐이지 자신의 인격은 아니지요. 도구에 문제가 없다면 증명을 하면 될 일이지 흥분할 일은 아닐 것으로 보입니다.
더구나 대화자체를 저급으로 만드는 발언을 하신 건 좀 과하군요.

fender의 이미지

도대체 제가 우기는 게 뭐라고 생각하시는데요? 그리고 사람들이 뭘 다 느끼는데요?

서로 동의를 하건 못하건 저와 creativeidler님은 나름대로 시간과 노력을 들여 장문의 '근거'를 주고 받았는데 어디서 툭 끼어든 분이 밑도 끝도 없이 '넌 근거도 없고 아무튼 다 틀렸다 도장 꽝!' 해버리니 되게 뜬금없네요 ㅎㅎ;

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

moons의 이미지

저역시 powersys님 말은 좀 뜬금없네요

사람들이 다느끼는데? 라는 표현은 뭘보고 하신 말씀이신지..

또한 이스레드에서 gui속도에 객관적이고 확실한 근거를 올리신분은 없으신거같은데요

"해보니 느리더라", "해보니 체감상 느린지 모르겠다."

이정도로 언급이 되있고 제 생각에도 데스크탑 어플리케이션 gui 속도는 밀리세컨드 단위 이상으로 비교하는건 큰 의미가 없어보입니다.

뭐 위에서 fender님이 다 언급하시긴 하셨지만

gui이동속도 0.0x초 차이가 사용자관점에서 불편함을 유발할까요?

배포문제역시 인스톨러를 네이티브로 구현하면 불편함이 없지않나요?

제가볼때는 차라리 실행 메모리가지고 swing이나 swt에 단점을 이야기하는게 더 설득력 있어보입니다만..

제가 간단히 테스트 해보니

이클립스나 넷빈즈의 경우 적당한 프로젝트 하나 띄우고 이것저것 작업해보니
사용 메모리가 100메가가 넘어가더군요
반면 MSDev는 50메가 안쪽이구요
이경우는 사실 기능상의 문제 때문에 메모리 사용량은 차이가 날수 밖에없다고 봅니다. 자바 IDE툴은 모든 객체/패키지 관계를 모두 메모리에 담고있기 때문이죠

오피스의 경우 약간 무거운 파일을 열었을경우
한글 2007의경우 50메가가 안넘어가는데 비해
씽크프리 write의 경우 80메가를 웃도네요

하지만.. gui 속도는?

기능적으로 동작하는데 들어가는 부하량을 제외하고 단순히 gui만 아무리 움직이고 클릭해봤지만 속도차이를 체감하지는 못하겠네요

제 데스크탑 사양은 밑에 댓글에 적혀있습니다.

추신 : 팬티엄3나 그이하에서 느리다는건 아니시겠죠? 팬3이하에서는 네이트브 어플이라도 느린거 많습니다. -0-

idotrip의 이미지

좀 보다 건설적인 토론이 되었으면 합니다.

뭐가 더 낫다느니만 따져서 뭐하겠다는 건지 참..

여기서 논쟁의 핵심은 우월성이 아니라

"왜! 플랫폼을 우선순위를 둬서 개발할수 밖에 없는 회사의 마음.."

이란 겁니다.

무슨 자바가 어떻네 하는 동문서답식 뜬구름잡기 논쟁은 논쟁의 질만 하락시키는군요

Fe.head의 이미지

전 뭐든지 추가로 깔라고 하면 일단 "이 제품이 진짜 필요한가?" 질문을 던지고 시작합니다.

깐다고 해도 쌍욕을 하면서 깔것 같습니다.

자바나 .NET 추가로 깔라고 안했으면 좋겠습니다.

메모리 장난 아니게 잡아 먹는데 뭐가 좋은지..

전에 .NET 처음 나왔을때 "Hello world!" 프로그램짜서 컴파일후 실행했는데

갑자기 하드에서 굉장한 소리를 몇초동안 낸후 모니터에 "Hello world!" 찍어내는데

그후로 C#은 거들떠도 안봤습니다.

자바는 그정도 까지는 아니였지만.. 느린건 마찬가지였구요.

PS) 386 PC에서 터보 C로 "Hello World!" 출력하던거랑 어셈블리로 "Hello World!" 출력했을때
생각이 나네요.

두가지 버전이 화면에 출력하던거 보고 C언어 배우지 않고
어셈블리 배우기로 결정 했었습니다.

그때 당시 어셈블리는 바로 출력되었고 C언어는 0.5~1초후에 출력 되더군요.

-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.

고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"

moons의 이미지

검색 링크타고 왔다가 글 재미있게 읽었습니다.
좀 지난 쓰레드이긴 하지만..
creativeidler 님 테스트 방법처럼

자바(swing)로 만들어진 오피스(thinkfree writer)와
네이티브C++(wtl)로 만들어진 오피스(한글 2007)의 메뉴를 화살표로 돌려보왔습니다.

메뉴의 갯수와 드롭다운된 리스트 갯수가 서로 틀리므로 밀리초단위의 시간을 비교한다는거는 의미가 없어보일거같구요.

눈이나 느낌으로 체감하기엔 자바로 만들어진 오피스가 느리다는 느낌을 전혀 받을수 없네요.

기능에 대한 속도 테스트는 하지않았습니다. 그건 위에서도 말씀하셨듯이 로직 구현에 따라 다를수 있기 때문이죠.

횟수당 30초 이상씩 10회이상 돌려봤는데 사람이 느끼는 속도 차이는 거의 없다고 봐도 될거같은데요.

주가로 자바로 만들어진 Jedit와
네이티브로 만들어진 Notepad++ 역시 같은 방식으로 비교 해봤는데..

역시나 제눈이나 감각으로는 차이를 못느끼겠네요..

제 컴퓨터 사양은
듀얼코어 2.4
메모리 2기가
지포스 7600 gs

입니다.

메뉴 이동속도말고 다른걸 비교 해보고 싶은데 비교자료같은거라도 있으면 좋겠습니다

imyejin의 이미지

그게 그럴 수밖에 없는 게 리눅스 쓰는 쪽에서는 예전부터 짜 놓은 스크립트로 텍스트 환경에서 쓰는 사람들이 많을테니 GUI 툴이 나왔다고 좋아라 하기보다는 한번 대강 써 보고 무지 좋지 않으면 그냥 신경 끄는 경우가 많지 않을까요?

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

송효진의 이미지

구조를 다이어그램으로 만들고 보여주면 적용되는 것은 대강 써보면 무지 좋다고 느낄 확률이 높습니다.
(이거 그런 프로그램 맞죠?-_-;)

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

liame의 이미지

저도 자바로 밥벌이를 하고 있습니다.

서버쪽도 하고, 쓰레드에서 언급된 SWT도 합니다.

그런데, 사용자들이 JVM설치에 거부감이 있었다는 것하고 JAVA GUI에 이렇게 불만이 있었다는 것을 처음 알았습니다.

개인적으로는 처음 2004년에 Eclipse를 접하고 Java 쪽에 혁신( 여러가지 면에서 )이 될 거라고 느꼈습니다만, 일반 사용자들은 다르게 생각하는가 보군요.

자바가 더 사랑받을 수 있도록 더 노력해야 겠네요. ^^;

lazycoder의 이미지

이제는 visio를 쓰긴 하지만 제가 자주 사용했던 Together workflow editor(http://www.enhydra.org/workflow/jawe/index.html)가 있는데 몇년째 사용했었지만 여기서 제기된 문제들은 전혀 느끼지 못했는데.. ;;

workbench는 다운받으려니 가입해야 하네요. 그래서 패스.. ;;
ERWin의 Complete Compare를 능가하는 기능이 있다면 가입해서 다운받아 보겠는데..

tinywolf의 이미지

creativeidler씨의 이야기를 들으면 왠지 혼나고 있는 것 같아 살짝 기분이 나빠지기는 하지만..
좋은 내용을 잘 보았습니다.
저도 자바 GUI 사용하다가 보면 미묘하게 뭔가 멈짓하는 것을 느끼곤 합니다.

하지만 그 차이로 인해 전체적으로 느려진다면 모르겠지만..
이 글에 언급된 workbench라는 어플리케이션에게는 영향이 없을듯한데..
아마도 90%가 반응하는 윈도우즈용 소프트웨어에서
.Net을 사용해 설치파일로 만들면 한번에 같이 설치할 수 있지만
자바는 jre를 추가로 설치한다는 것이 꽤나 큰 영향을 주었을 것같습니다.

그리고 가장 간과했던 것이..
이미 C/C++로 한 플랫폼에 적응하고 개발하고 있는 개발자들이..
자바의 GUI가 이쁘게 테마를 만들고 원할하게 돌아가도록 프로그래밍 기술을 익히고 컴파일 옵션을 익히고 다시 배워서 적응하는 것이 싫었기 때문이 아닐까요?

ㅡ_ㅡ;

카二리의 이미지

최근 임베디드 자바를 하면서 느끼는걸 좀 써보려고 합니다.

결론부터 말하자면 자바의 문제점은 위에서 creativeidler님이 말한 문제가 맞다고 생각 합니다.

사실 제가 SE 내부는 보질 않아서 잘 모르겠지만, CDC VM과 CDC-PBP를 구현 하면서 느낀 점들을 쓰자면, graphic layer에서 아무리 빠르게 한다고 해도,

어플리케이션 짜는 사람들이 묘하게 코드를 짜게 되면 느리게 됩니다. 이건 어느 언어에서나 어느 플랫폼에서나 일어날 수 있는 문제죠.

근대 자바 같은 VM이 있는 언어들은 이 묘한 코드에 GC의 garbage collection time이 끼어들면서 문제가 생깁니다.

특히 빠르게 움직이는 menu 같은 부분에서 문제가 일어날 수 있습니다.
어찌 되었건 반복되는 로직 안에서 garbage collection time이 필요한데, 거지같은 코드로 짜 놨다면,(아니면 어쩔수 없이 로직이 복잡했다거나..)
이 사이에 많은 양의 garbage collection이 일어나게 되고, 이 때 프로그램은 정지하고, 쓰래기 수거를 하게 됩니다.

근대 이 시간이 개발자들은 매우 짧다고 생각할 수 있는데, 이 시간이 최소 0.0000001초라고 하더라도 코드에 따라 0.1초 혹은 상황에 따라 0.1초가 넘는 시간이 들어갈 수도 있다는 겁니다.

문제는 위에서 fender님이 말한것처럼 0.5초 정도 이하의 시간은 사용자가 못 느끼느냐... 인데,

제가 BD(Blue-ray Disk)-player에 있는 BD-J framework를 손보면서 느낀점은 사람의 눈은 생각보다 위대 해서,
0.1초 정도만 (연속도 아니고) 잠깐 버벅여도 사용자들이 바로 눈치 챈다는 점입니다. 하물며, 이게 반복되면... 우욱..-_-;;

물론 대다수의 시간을 눈치 못채고 살 수도 있지만, 계속 반복해서 보다보면 언젠가는 느끼게 되는 거죠. 특히 menu 처럼 반복해서 수시로 보는 UI인 경우 더 합니다.

이 menu에 화려한 effect가 들어가 있다면 더 심하게 되죠(BD title은 menu가 매우 화려한 경우가 많습니다.)
바로 이때 자바의 느린 GC response time이 보는 사람을 더럽게 짜증나게 하는 거죠 -_-...

사실 이렇게 써놨지만, 전 CDC만 보고 있는지라 요새 SE 내부가 어떻게 되어 돌아가는지 잘 모릅니다... 하지만 저 부분이 UI를 보는 사람을 충분히 짜증나게 할 수 있다는 데 공감이 가서 이렇게 글을 씁니다.

즉 0.1초 정도면 사람을 충분히 짜증나게 할 수 있다.. 라는 거죠 -_-;

새 생각 :)

새 생각 :)

fender의 이미지

저는 반대로 임베디드는 전혀 경험이 없습니다. 그래서 어쩌면 말씀하신 가비지 컬렉션의 문제가 임베디드 자바의 일반적인 문제점일지도 모른다는 가능성은 열어 놓고 이야기를 하겠습니다.

Quote:
특히 빠르게 움직이는 menu 같은 부분에서 문제가 일어날 수 있습니다. 어찌 되었건 반복되는 로직 안에서 garbage collection time이 필요한데, 거지같은 코드로 짜 놨다면,(아니면 어쩔수 없이 로직이 복잡했다거나..) 이 사이에 많은 양의 garbage collection이 일어나게 되고, 이 때 프로그램은 정지하고, 쓰래기 수거를 하게 됩니다.

우선 위와 같이 말씀하신 부분은 최소한 거의 대부분의 데스크탑 어플리케이션에서 발생하지 않을 것입니다. 설사 위에서 creativeidler님이 제시하신 메뉴 무한 전환이 전체적 어플리케이션 반응성을 결정하는데 유용한 테스트라고 치고, 그리고 그 중에 0.1초의 지연 조차 데스크탑 어플리케이션을 사용하는 데 있어서는 안될 심각한 장애라고 가정 하더라도 말씀하신 상황 자체는 데스크탑에서는 아마 재현하기도 어려울 것입니다.

물론 가비지 컬렉터에도 데스크탑 어플리케이션에 적합하도록 응답성 위주로 튜닝할 수 있는 옵션이 있습니다만, 설사 그런 옵션을 다 무시하고 일부러 서버처럼 오랜 컬렉션 타임을 갖도록 설정한다쳐도 우선 단순 메뉴 전환 중에 가비지 컬렉션이 빈번하게 일어날만한 코드를 짜는 것도 흔한 일이 아니고 더구나 그 가비지 컬렉션이 일반적 사양의 데스크탑 환경에서 0.1초 이상 걸리도록 하는 것도 쉬운 일이 아닙니다.

로드가 걸린 서버 어플리케이션에서 메가바이트 단위로 메모리를 쌓고 이를 한번에 가비지 컬렉션하면 0.x초 정도 지연이 있을 것입니다. 데스크탑 어플리케이션에서 메뉴 전환 한 두번에 그 정도 메모리를 할당하고 해제한다면 이미 정상적인 예제가 아니라고 생각합니다.

물론 위와 같이 단순 메뉴 반복 같은 극단적인 예가 아니라면 데스크탑 응용프로그램 사용 중에 가끔씩 가비지 컬렉션으로 0.1초 정도의 지연이 발생하는 경우는 충분히 가정할 수 있습니다. 하지만 일반적인 데스크탑 어플리케이션에서 모든 동작이 0.1초 안에 일어나야만 사용성에 지장이 없다는 식의 기준은 조금 극단적이라고 생각합니다.

무엇보다 카二리님의 지적에서 잘못된 부분은 가비지 컬렉션이 일어나는 경우 그 기간 동안 무조건 응용프로그램이 응답없는 상태가 될 것이라는 가정입니다. 그런 가정이 사실이라면 예를들어 자바로 끊김없이 동영상을 재생하거나 애니메이션을 보여주는 코드를 짜는 것은 원천적으로 불가능합니다.

다시 한번 강조를 하지만 저는 임베디드의 상황은 모르겠습니다. 그리고 스윙의 경우 가비지 컬렉션은 몰라도 그래픽 부분은 저 역시 아직까지도 안좋은 인상을 가지고 있기 때문에 개발자 입장은 물론 사용자 입장에서도 다른 대안이 있다면 가능하면 쓰지 않습니다.

하지만 스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다.

지나간 토론을 다시 끄집어내 시작할 생각은 없는만큼 카二리님의 글에 대한 반론을 떠나서 다시 이전 논점으로 돌아가지는 않겠습니다. 그 부분에 대한 앞선 토론은 솔직히 생산적이었다고는 생각하지 않으니까요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

Quote:
하지만 스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다.

그런 주장을 한 사람은 이 쓰레드 전체에 걸쳐서 한 명도 없는 걸로 알고 있는데요. 앞선 토론이 생산적이지 않았던 이유는 이런 확대해석 때문은 아니었는지 생각해보셨으면 좋겠군요.

fender의 이미지

Quote:
자바가 GUI는 왜 이렇게 느린지 잘 이해가 안 가긴 합니다만. 심지어 파이썬이나 루비로 GUI 바인딩해서 쓰는 것보다도 한참 느리더군요. SWT도 느린 건 마찬가지...(중략)... 전 자바에서 원인을 찾습니다. JNI가 원인은 아닐 겁니다. 문제는 JVM 자체죠

기억력도 나쁘시군요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

헐, 또 이러시는군요. 이래놓고 또 나중에 토론이 아니니 전 빠지겠습니다..하시려구요?

제가 친절하게 어느 부분이 확대해석인지 다시 인용해드리죠. 강조된 부분을 자세히 보시면 될 듯.

Quote:
하지만 스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다.

이쯤되면 문제는 제 기억력이 아니라 fender님의 이해력인 것 같은데요? 역시나 fender님이 참여하는 논쟁에서 흔히 보이는 현상 같습니다. 늘 fender님 글만 따로 떼서 놓고 보면 완벽하게 말이 됩니다. 끄덕끄덕. 근데 쓰레드 맥락 속에서 보면 상대방은 그런 말을 한 적이 없다는... 허수아비 때려잡는 솜씨는 그야말로 일품이십니다.

fender의 이미지

Quote:
자바 SWT로 아주 간단한 애플리케이션을 만들어서 띄워도 메뉴 반응 속도가 비주얼 스튜디오보다 느립니다

허수아비 인증인가요?

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

예상대로군요. 지난 번에도 이 부분을 오독했을 꺼라고 예상했는데 역시나...

이번에는 똑같은 인용에 다른 부분을 강조하도록 하죠.

Quote:
하지만 스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다.

언제부터 비주얼 스튜디오의 속도가 데스크탑 환경 적합성의 기준이 되었을까요?

그냥 잘못 읽었다, 오해했다, 한 마디만 하면 될 것을...

fender의 이미지

Quote:
언제부터 비주얼 스튜디오의 속도가 데스크탑 환경 적합성의 기준이 되었을까요?

비주얼 스튜디오 메뉴 렌더링 속도가 SWT보다 빠르다고 자바에 근본적인 문제가 있다고 주장하던 분이 그러시면 어쩌란 말인가요? 진짜 빠르기는 한가요? ㅎㅎ

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

Quote:
하지만 스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다.

몇 번을 인용해줘도 읽지를 않으시나 봅니다. 그래도 혹시나 하는 마음에 다시 인용해봅니다. 자신이 무슨 말을 했는지 다시 한 번 읽어보십시오.

뭐, 그래도 인용은 인용이고, fender님의 이해력을 감안하면 직접 설명하는 게 좋겠지요.

1. 저는 SWT로 아주 작은 프로그램을 만들어서 메뉴 반응성을 테스트해보면 비주얼스튜디오보다 느리다는 말을 했습니다.
2. 그래서 자바 GUI 툴킷에 성능 문제가 있다고 짐작할 수 있다고 했죠.
3. 그리고, 자바, 특히 JVM에 근본적인 문제가 있다고도 했습니다.

하지만, SWT로 아무리 간단한 응용프로그램을 만들어도 데스크탑 환경에 적합한 만큼의 성능이 안 나올 것이라고는 한 적이 없습니다. 1,2,3을 아무리 조합해도 fender님이 이해한 것 같은 이야기는 안 나옵니다. 논리적으로 조합한다면 말입니다.

이제 아시겠습니까? fender님이 두 이야기를 자기 마음대로 합쳐버려서 허수아비를 만들어냈다는 것을?

진짜 빠르기는 하냐구요? 직접 한 번 재보란 말 밖에. 비주얼 스튜디오랑 똑같은 숫자로 메뉴 구성해서 돌려보세요.

실수는 누구나 할 수 있습니다. 그냥 실수를 인정하면 문제는 간단해집니다. 하지만 실수를 인정하지 않으려고 하다보면 잘못은 눈덩이처럼 불어나게 마련이죠. 어디까지 불어나게 하시렵니까?

fender의 이미지

아... 그럼 위에서 그렇게 장문으로 하고 싶으셨던 말씀이 '자바에는 근본적으로 문제가 있어서 느리지만 데스크탑 어플 작성할만큼 속도는 나온다' 내지는 '자바에는 근본적인 문제가 있어서 느리지만 SWT로 만든 GUI 어플은 쓸만하다'였던가요? ㅎㅎ

자바 GUI는 느려서 못쓰겠고 뭘해도 느리고 바로 그 이유로 데스크탑 시장에서도 퇴출됐다고 강변하시던 건 다른 사람입니까?

그리고 '자바 GUI 툴킷에 성능 문제가 있다'라고 하셨다구요?

Quote:
저는 원인이 툴킷에 있다고 한 적이 없는 것 같은데요. 전 자바에서 원인을 찾습니다. JNI가 원인은 아닐 겁니다. 문제느 JVM 자체죠

무슨 신종 '오해다' 시리즈입니까? ㅎㅎ; 남의 말꼬리 잡을 생각만하지 마시고 본인이 위에서 무슨 이야기를 했고 어떤 논리를 전개했는지를 먼저 따져 보시고 토론을 하시죠.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

툴킷은 저의 실수가 맞군요. 네, 인정합니다. 열심히 찾느라 수고하셨습니다.

Quote:
아... 그럼 위에서 그렇게 장문으로 하고 싶으셨던 말씀이 '자바에는 근본적으로 문제가 있어서 느리지만 데스크탑 어플 작성할만큼 속도는 나온다' 내지는 '자바에는 근본적인 문제가 있어서 느리지만 SWT로 만든 GUI 어플은 쓸만하다'였던가요? ㅎㅎ

저는 자바에는 근본적인 문제가 있어서 느리다는 말도 했고 자바를 쓰는 게 좋지 않다는 말도 했습니다. 제가 하지 않은 말은 아무리 간단한 응용프로그램을 만들더라도 못 써먹을 정도로 느리다.입니다. 이걸 다시 설명해야 할 줄은 몰랐네요.

Quote:

자바 GUI는 느려서 못쓰겠고 뭘해도 느리고 바로 그 이유로 데스크탑 시장에서도 퇴출됐다고 강변하시던 건 다른 사람입니까?

이것도 강조 부분이 확대해석이죠? 거의 습관성입니다. 제가 하는 거의 모든 말을 약간씩 확대해석하니까 fender님이 비판하기는 좋겠지만 여전히 허수아비입니다. 자바 GUI는 느려서 못 쓴다고 한 거 맞고, 그래서 데스크탑 시장에서 퇴출되었다고 하는 것도 맞는데, 뭘해도 느리다는 말은 한 적이 없습니다.

그냥 이기려고 논쟁을 하시는 건가요? 정말 가슴에 손을 얹고 차분히 생각해도 fender님이 오해한 게 없다고 생각하시나요? 실수 하나 찾자마자 득달같이 달려드는 모습도 안쓰럽네요. 자기가 한 수많은 실수는 눈에 잘 안 들어오나보죠? 이 정도면 오해가 아니고 거의 오독 수준입니다.

제가 전에 제 주장을 어떻게 정리했는지 아시나요?

Quote:

자바 GUI를 최소 기능 셋으로 테스트해보면 네이티브보다 약간 느릴 뿐 사용성에 지장은 주지 않는다. 그러니 여러분은 자바 GUI로 기능이 많으면서 빠른 애플리케이션을 작성할 수 있을지 모른다. 하지만 신기하게도 아직 그걸 해낸 사람은 본 적이 없고 현존하는 유용한 자바 GUI 애플리케이션은 전부 느리다. 하지만 네이티브나 .NET으로는 기능이 풍부하면서 빠른 애플리케이션이 엄청나게 많다.

이거 본 기억이나 있습니까? 제대로 읽지도 않았겠죠.

이래도 허수아비 아니라고 하시겠습니까? 언제까지 우기는지 두고 보겠습니다.

fender의 이미지

말장난에도 일가견이 있으시군요.

진짜 '확대해석'이 무언지 보여 드릴까요?

Quote:
스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다

제가 한 이 발언을 가지고 트집을 잡아서 여기까지 끌고 오셨습니다만, 도대체 저 '아무리 간단한 응용프로그램'이 위 토론에서 언급한 로직 하나 없이 메뉴만 달랑 띄우는 수준의 코드 샘플 같은 거라는 건 어디서 튀어나온 해석입니까?

자꾸 '오독'어쩌구 하시는데, 위 토론에 비추어봐도 저 문장의 의미가 다음 중 어느 쪽이겠습니까? :

(1) 이클립스 같이 무거운 SWT 어플리케이션뿐 아니라 훨씬 단순한 어플리케이션을 만들어도 로직과 관계없이 자바 근본 문제로 느릴 것이다.
(2) 자바로는 메뉴하나 달랑 띄우는 코드 샘플을 만들어도 메뉴 뜨는데 용납이 안될만큼 무지막지 느릴 것이다.

메뉴만 띄우는 코드 샘플이 '응용프로그램'입니까? 그리고 앞선 토론 주제가 '자바로는 무지막지 안느린 코드 샘플조차 만드는게 불가능하다'라고 생각하시는지...

그걸 혼자서 애써 (2)라고 해석하고 본인이 무슨 주장을 했는지조차 망각한 체 말꼬리 잡기에 열을 올리는게 바로 '확대해석'이고 '오독'이며 자주 찾으시는 '허수아비 논증'입니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

Quote:
이클립스 같이 무거운 SWT 어플리케이션뿐 아니라 훨씬 단순한 어플리케이션을 만들어도 로직과 관계없이 자바 근본 문제로 느릴 것이다.

이렇게 주장하고 싶으셨던 거라면 그 뜻은 이제 알겠습니다. 그러나,

Quote:
아무리 간단한 응용프로그램을 만들어도

이런 표현을 해놓고 그런 말씀을 하시면 곤란하죠. 이건 이해력이 아니라 국어 실력의 문제가 아닌가요? 아무리 ~~해도는 뭔가 극단을 표현할 때 쓰는 말 아니던가요?

어쨋든, 본인 뜻이 그렇다니 이제 그 부분은 더 이상 문제삼지 않겠습니다. 하지만, 여전히 fender님의 오류는 해명이 되지 않고 있습니다. 인정하기 때문에 언급하지 않으시는 건가요? 예전 껀 들추지 않고 이번 것만 다시 정리해보겠습니다.

1. 먼저, 제가 그런 말 한 적이 없다고 하니까 다음 문장을 인용하면서 기억력이 나쁘다고 하셨죠?

Quote:

자바가 GUI는 왜 이렇게 느린지 잘 이해가 안 가긴 합니다만. 심지어 파이썬이나 루비로 GUI 바인딩해서 쓰는 것보다도 한참 느리더군요. SWT도 느린 건 마찬가지...(중략)... 전 자바에서 원인을 찾습니다. JNI가 원인은 아닐 겁니다. 문제는 JVM 자체죠

그 문장이 1번이건, 2번이건 이 인용은 아무 것도 증명해주지 못합니다. 이것이 첫번째 오류.

2. 허수아비 인증 건도 마찬가지죠? 다음 문장을 인용하셨지만 역시 1번이건 2번이건 전혀 뒷받침해주지 못하고 있습니다.

Quote:
자바 SWT로 아주 간단한 애플리케이션을 만들어서 띄워도 메뉴 반응 속도가 비주얼 스튜디오보다 느립니다

이걸 데스크탑에서 못 쓸 정도로 느리다라고 확대해석하셨죠.

3. 다음 질문에 대해..

Quote:
언제부터 비주얼 스튜디오의 속도가 데스크탑 환경 적합성의 기준이 되었을까요?

다음처럼 대답하셨죠.
Quote:
비주얼 스튜디오 메뉴 렌더링 속도가 SWT보다 빠르다고 자바에 근본적인 문제가 있다고 주장하던 분이 그러시면 어쩌란 말인가요?

이것 역시 위와 같이 비주얼 스튜디오보다 느리다..를 데스크탑에서 적합하지 않을 정도로 느리다..로 확대해석한 증거입니다.

4.

Quote:
아... 그럼 위에서 그렇게 장문으로 하고 싶으셨던 말씀이 '자바에는 근본적으로 문제가 있어서 느리지만 데스크탑 어플 작성할만큼 속도는 나온다' 내지는 '자바에는 근본적인 문제가 있어서 느리지만 SWT로 만든 GUI 어플은 쓸만하다'였던가요?

이건 단순한 오독. 저는 자바에는 근본적인 문제가 있고 데스크탑에서 쓸만하지 않다라는 주장을 펼치고 있는 거랍니다. 물론, 이건 비꼬느라 한 말일 테니 카운트하지 않으셔도 좋습니다.

5.

Quote:
자바 GUI는 느려서 못쓰겠고 뭘해도 느리고 바로 그 이유로 데스크탑 시장에서도 퇴출됐다고 강변하시던 건 다른 사람입니까?

자바 GUI가 느려서 데스크탑 시장에서 퇴출되었다는 말을 뭘해도 느리다까지 확대해석했죠.

건수로는 다섯 건이지만 핵심은 두 가지죠. 하나는 자바에 근본적인 성능 문제가 있다라는 말을 아무리 간단한 프로그램에서도 못 쓸 정도로 느리다라고 확대해석한 것, 또 하나는 비주얼 스튜디오보다 느리다데스크탑 환경에 적합치 않을 정도로 느리다라고 확대해석한 것. 이번 쓰레드 뿐 아니라 예전 쓰레드에서의 오류들도 대부분 이 확대해석에 기인하고 있죠.

묻고 싶은 게 있습니다. 다른 건 다 대답 안하셔도 되는데, 이것 하나만 대답해주시면 좋겠습니다.

정말 진심으로 본인이 확대해석한 것이나 오독한 것이 없다고 생각하십니까? 감정을 가라앉히고 차분하게 생각해도 그렇습니까?

fender의 이미지

저도 똑같이 인용해서 일일이 논리를 지적해드릴 수도 있습니다만 이제까지 수차례 그렇게 해도 비꼬기에 동문서답으로만 일관하시니 그만 두겠습니다. 제가 무슨 개인 논술 교사는 아니니까요.

말꼬리 잡으려고 제 발언을 일일이 분석하는 시간의 10분의 1이라도 도대체 자기 자신이 같은 글타래에서 무슨 주장을 어떤 근거를 가지고 했었는지 살펴보는데 투자하시라고 충고드리고 싶습니다.

creativeidler님이 위에서 장문으로 주장하신 내용이 정말 '자바로도 충분히 데스크탑 환경에 적합한 응용프로그램을 만들 수 있다'입니까? 아니면 저와 님이 위에서 토론한 주제가 '자바로는 성능 좋은 샘플코드조차 만들 수 없는가?'라고 생각하십니까?

바로 위 글에서도 본인 스스로 '자바에는 근본적인 문제가 있고 데스크탑에서 쓸만하지 않다라는 주장을 펼치고 있는 거'라고 하지 않으셨습니까? 또 위에 본인 스스로 주장한 내용을 인용해 드릴까요?

위에서 '단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션들은 다 속도에 문제가 있고 네이티브보다 압도적으로 느리다'고 하셨죠?

님이 보기엔 이 주장은 아무 문제가 없는데,

'자바로 아무리 간단한 응용프로그램을 만들어도 자바의 근본적인 문제로 적합한 만큼의 성능이 안나올 것이다'

라는 제 인용은 '습관적 오독'이고 '확대해석'입니까? 두 개가 뭐가 그렇게 다른데요? ㅎㅎ 다른 분들 보시기에도 그런가요?

본인 스스로 '단순 테스트'와 '애플리케이션'은 구분하면서 제가 '응용프로그램'이라고 한 건 굳이 '코드 샘플'까지 포함해서 해석해서 '코드 샘플도 느리단 이야기는 안했다'라고 딴지 거는 건 무슨 심보입니까?

그리고 다 떠나서 그런식의 말꼬리 잡기가 자바의 데스크탑 성능 문제라는 토론의 맥락에서 어떤 의미가 있는데요? 자기가 한 이야기는 다 까먹고 남 문장만 문구 하나하나 분석하고 있으면 어쩌란 겁니까?

저는 일부러 위에 카二리님의 글에 덧글 달면서 creativeidler님과 지난 토론 다시 끄집어 내지 않기 위해 명확히 선까지 그었습니다만 굳이 말꼬리 잡아서 먼저 시비를 거시니 상대해 드리고 있을 뿐입니다. 위에서도 장문의 '토론'을 했지만, 쓰신 글에 드러나는 기술적 지식의 깊이는 존중해드릴만 합지만 토론태도나 논리 전개는 전혀 그렇지 못하군요.

이미 서로 조금이라도 건설적인 이야기는 할만큼 다 한 것 같고, 자바 성능 이야기도 나올만큼 나왔다고 생각합니다. 개인적으로 어떤 사실근거나 논리를 가지고 자바를 비판하는 분들 이외에도 단순히 이런 저런 선입견을 바탕으로 자바에 대한 반감을 가진 분들도 많다고 느낍니다. 하지만 솔직하게 그런 분들 설득하고 싶은 생각도 없고 그럴 이유도 없습니다.

저는 자바 개발자 입장에서, 혹 다른 분들은 자바를 비판하는 입장에서 각기 사실관계에 부합하지 않는 주장이 있다면 그 부분을 논리적으로 반박하거나 하면 읽는 사람이 알아서 판단할 문제라고 봅니다.

쓸데없이 지나간 토론을 주제와도 무관하게 말꼬리 잡아 다시 불붙이는 건 시간 낭비입니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

Quote:
저도 똑같이 인용해서 일일이 논리를 지적해드릴 수도 있습니다만 이제까지 수차례 그렇게 해도 비꼬기에 동문서답으로만 일관하시니 그만 두겠습니다. 제가 무슨 개인 논술 교사는 아니니까요.

동문서답은 fender님이 하고 있으신 것 아닙니까? 제가 계속 오독 문제를 지적하자 그 문제에 대한 답변은 피하시고 계속 반격만 노리고 있으시잖아요. 저는 fender님이 질문하거나, 주장한 내용 중에 제가 대답해야 할 것 같은 건 전부 대답했습니다. 하지만 fender님은 단 하나도 제대로 대답하지 않으셨습니다. 심지어, 제가 이것만은 대답해달라고 한 것조차도요.

Quote:
말꼬리 잡으려고 제 발언을 일일이 분석하는 시간의 10분의 1이라도 도대체 자기 자신이 같은 글타래에서 무슨 주장을 어떤 근거를 가지고 했었는지 살펴보는데 투자하시라고 충고드리고 싶습니다.

저는 충분히 하고 있습니다. 저는 처음부터 끝까지 일관된 주장을 하고 있고 제 주장이 옳을지 아닐지는 몰라도 적어도 모순된 논지가 있다거나, fender님처럼 상대방의 글을 잘못 이해하고 주장을 펼친 건 없습니다. 그런 게 있다고 생각하시면 찾아서 제시해주시기 바랍니다. fender님이 저한테 그런 말씀을 하시는 이유는 fender님이 제 주장을 잘못 알고 있기 때문에 제가 하는 이야기들이 fender님이 잘못 해석한 그 주장과 맞지 않아서 그러는 것이겠지요. fender님이 마음을 열고 제 주장을 이해하려고 노력하신다면 아마 다 일관성이 있다는 것을 아실 것입니다.

Quote:
creativeidler님이 위에서 장문으로 주장하신 내용이 정말 '자바로도 충분히 데스크탑 환경에 적합한 응용프로그램을 만들 수 있다'입니까? 아니면 저와 님이 위에서 토론한 주제가 '자바로는 성능 좋은 샘플코드조차 만들 수 없는가?'라고 생각하십니까?

죄송하지만 둘다 아닙니다. 그러니까 이해를 못하고 있다고 하지 않습니까? 제 주장은 이겁니다. 자바로 성능 좋은 샘플 코드 정도는 만들 수 있지만 일정 수준 이상의 기능을 가진 프로그램은 사용성에 지장을 줄 정도로 느리다는 겁니다. 근데 어떻게 절묘하게 딱 이 주장만 제외한 두 가지 극단을 물으시는지 모르겠군요. 이 논쟁은 처음 mysql workbench에서 출발한 것이고, 이 정도 크기의 app를 자바로 만들면 답답한 느낌이 좀 들 거라는 것입니다.

Quote:
위에서 '단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션들은 다 속도에 문제가 있고 네이티브보다 압도적으로 느리다'고 하셨죠?

결국 찾아내셨군요. 언제 찾아내나 했습니다. 네, 맞습니다. 솔직히 그 문장은 오해의 소지가 있다는 거 인정합니다. 거기서 "뭔가 기능을 하는 자바 애플리케이션"이 "모든 자바 애플리케이션"으로 이해할 수 있죠. 제가 원래 의도했던 것은 "일정 수준 이상의 기능이 있는" 애플리케이션입니다. 말은 거창하지만 그렇다고 엄청 큰 애플리케이션을 의미하고자 했던 것은 아니고, 에디터, 메신저, 압축 해제 프로그램, 단순 파일 탐색기 등을 의미한 것입니다.

저도 예전 토론 때 이미, 이 표현을 fender님이 "모든"으로 해석하고 있다는 것을 알았습니다. 그래서 그 표현을 정제하기 위한 표현들을 이어지는 답글들에서 추가했었습니다. "현실적으로 serious한 애플리케이션", "기능이 많으면서" 등의 표현이 그 노력의 증거죠. 그래서, 문장만 보면 "모든"으로 해석할 여지도 있지만 그 오해를 불식시킬 만큼 충분한 맥락을 제공했다고 생각합니다.

굳이 따지자면, 네, 확대해석의 책임은 "뭔가 기능을 하는"이라는 모호한 표현을 쓴 저에게도 일부 있습니다. 그렇지만, 그 이후에 그 모호함을 명확하게 하려는 노력을 했는데도 불구하고 여전히 확대해석된 상태를 고수하고 있는 부분에서 뒷 부분의 제 글들을 안 읽은 티가 난다는 것이죠. 상대방의 주장을 충분히 알 수 있음에도 불구하고 글의 일부분을 가지고 트집을 잡는 것, 이런 걸 말꼬리잡기라고 하는 것 아니던가요?

네, 그래도 인정은 해드리죠. 사실 이 부분은 저도 알고 있었던 부분이고, 저에게 책임이 전혀 없다고 할 수 없으니 핵심 확대해석 두 가지 중 하나는 해명하신 걸로 보겠습니다. 그럼 이제 남은 확대해석, 비주얼 스튜디오보다 느리다는 걸 데스크탑에서 못 쓸 정도로 느리다고 한 건 어떻게 해명하시겠습니까?

그렇긴 하지만 사실상 fender님이나 저나 생각하는 "간단한" 애플리케이션의 정도는 비슷할 겁니다. 이를테면, 메신저, 메모장 정도의 에디터, 단순 파일 탐색기, 압축 해제 프로그램 정도면 아마 fender님이 말한 "아무리 간단한"에 속하겠죠? 이 정도에서도 저는 자바가 느린 게 티가 난다고 봅니다.

Quote:
위에서도 장문의 '토론'을 했지만, 쓰신 글에 드러나는 기술적 지식의 깊이는 존중해드릴만 합지만 토론태도나 논리 전개는 전혀 그렇지 못하군요.

아쉽지만, 저는 fender님의 기술적 깊이도, 토론태도도, 논래 전개도 인정하지 않습니다. 자기 글을 논리적으로 쓰는 사람이라고 해서 다른 사람의 글을 논리적으로 이해하는 것은 아니라는 사실만 깨달았을 뿐. 사실, 저는 자바 성능에 대해 더 많은 이야기를 하고 싶었습니다. 자바 GUI 성능을 개선하기 위한 최근 흐름에 대해서도 나름 이야기할 것들이 있었고, 원인 분석에 대해서도 나름 파고 들어본 이야기들이 있었습니다. 하지만 fender님이 제 이야기를 이해하려는 노력을 안하시기에 꺼낼 기회가 없었던 것 뿐이죠. 조금만 더 남의 말을 들으려는 태도를 보이셨다면 훨씬 생산적인 이야기들이 많이 오고갔을 겁니다.

Quote:
쓸데없이 지나간 토론을 주제와도 무관하게 말꼬리 잡아 다시 불붙이는 건 시간 낭비입니다.

마치 자신이 끄집어낸 게 아니라는 듯 말씀하시는군요. fender님이 다시 불 붙인 거라는 증거를 보여드릴까요?

Quote:
하지만 스윙이 아닌 SWT로 아무리 간단한 응용프로그램을 만들어도 SWT자체, 혹은 자바의 근본적인 문제로 데스크탑 환경에 적합한 만큼의 성능이 안나올 것이다라는 주장에는 전혀 동의할 수 없습니다.

일단 문제의 이 문장. 앞서 카이리님의 글을 포함, 이전 서너 개의 글에서 이런 내용이 없는데도 굳이 이런 표현을 끄집어낸 것은 fender님과 저 사이에 있었던 논쟁의 내용을 끌어온 것이라고 짐작하는 게 자연스럽겠죠? 카이리님이 제 아이디를 언급하긴 했으나 저와 다른 주장을 하고 있다는 것 역시 제대로 읽는다면 아실 수 있을 것입니다. 물론, 쓰레드의 원문에도 전혀 그런 내용이 없구요. 주제와 상관 없는 이걸 다시 끄집어낸 건 바로 fender님입니다.

거기에다가...

Quote:
그 부분에 대한 앞선 토론은 솔직히 생산적이었다고는 생각하지 않으니까요.

이런 표현을 통해서 그 문장이 이전에 저와의 토론에서 끄집어낸 것이라는 점을 다시 확인하고 있는데다가, 양자간의 토론을 생산적이지 않았다고 말함으로써 자신은 생산적이지 않았던 데 대한 책임이 없는 듯한 뉘앙스마저 풍기고 있죠. 이것만 아니었어도 저도 다 끝난 토론에 다시 돌아올 생각은 추호도 없었습니다.

확대해색 뿐 아니라, 이렇게 은근슬쩍 상대방에게는 돌 던져 놓고 자신은 손에 흙 묻히지 않으려는 것도 거의 습관성인 것 같네요. 돌 던져 놓고 도망가기에 이은 또다른 신공입니까? 돌을 주워서 던지면 이미 던지는 순간 자기 손에 흙이 묻는다는 사실 정도는 아셔야 할 듯.

fender의 이미지

Quote:
제가 원래 의도했던 것은 "일정 수준 이상의 기능이 있는" 애플리케이션입니다. 말은 거창하지만 그렇다고 엄청 큰 애플리케이션을 의미하고자 했던 것은 아니고, 에디터, 메신저, 압축 해제 프로그램, 단순 파일 탐색기 등을 의미한 것입니다.

트롤 상대하려니 슬슬 지겹군요.

'단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션들은 다 속도에 문제가 있고 네이티브보다 압도적으로 느리다'라고 써놓고, 그보다 훨씬 과격한 주장도 근거도 없이 신나게 쏟아내시더니...

제가 그걸,

'자바로 아무리 단순한 어플리케이션을 만들어도 느리다는 주장'이라고 요약하니까 뜬금없이 오독이네 허수아비 논쟁이네 별의별 공격을 퍼부어대며 발끈하셨습니다. 그래놓고 '오독'의 이유라는게... 자기는 '단순한'을 테스트 코드보단 복잡한데 '에디터, 메신저, 압축 해제 프로그램, 단순 파일 탐색기'보다는 단순한 그 무엇만은 쏙 빼고 말한거다, 그런데 제가 그걸 구분하지 않았으니 확대해석했다구요? 어이가 가출하십니다...ㅎㅎ...

그 기준은 누가 정한 건가요? 아니 그 구분이나 기준이 도대체 님이 말꼬리 잡는 용도 이외에 논쟁에서 무슨 의미가 있나요?

그리고 제가 카二리님 글에 답글 달면서 위의 토론을 저렇게 한 줄로 언급한게 님 기준에선 '시비'인가요? 예전부터 뻑하면 남의 습관이 어떻네 인신공격 일삼는 본인은 토론이구요? ㅎㅎ '확대해석'의 정의를 모르시면서 즐겨 쓰시는 것 같은데... 제가 '이전 토론은 생산적이지 못했다'라고 하는 걸 굳이 '이게 다 상대방 탓이다'로 해석해서 시비거는 게 정말로 '확대해석'인겁니다.

Quote:
이 논쟁은 처음 mysql workbench에서 출발한 것이고, 이 정도 크기의 app를 자바로 만들면 답답한 느낌이 좀 들 거라는 것입니다
이 글타래의 creativeidler님 주장들을 저렇게 정리할 수 있다면, 저는 이 글타래의 제 주장은 '자바는 프로그래밍 언어다'라고 정리하겠습니다. 반론의 여지가 없죠? ㅎㅎ 전자의 논리가 이해되는 사람이라면 후자도 어렵지 않게 이해할 것 같군요.

뭐 계속 상대해드리는 건 어렵지 않습니다만 갈수록 스스로 트롤 인증하시는 건 안타깝군요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

뭐, 누구 말처럼 원래 이게 토론이 아니었다 치더라도 이제 아주 개싸움으로 가자는 것인가요?

여전히 제 질문들에 대해서는 묵묵부답이고 반격에 여념이 없으시군요.

Quote:
그 기준은 누가 정한 건가요? 아니 그 구분이나 기준이 도대체 님이 말꼬리 잡는 용도 이외에 논쟁에서 무슨 의미가 있나요?

누가 정한 거냐구요? 제가 정했습니다. 당연한 거 아닌가요? 제 주장에 제가 선을 긋는 게 뭐 잘못되었습니까? 말꼬리는 누가 잡고 있는데요? fender님이 "아무리 단순한"이라는 표현에 메뉴만 있는 프로그램 정도는 포함 안한다고 하셨을 때 그럼 "아무리 단순한"이 그런 의미라는 건 누가 정한 건데요? 분명히 fender님은 본인의 의도와 다르게 표현하셨고, 나중에 그 의도를 해명했죠. 전 그 해명을 받아들였고, 그 부분은 더 이상 트집 잡지 않겠다고 말씀드렸습니다. 말꼬리를 잡기 싫었으니까요.

하지만 fender님은 겨우 약점 하나 찾아냈다고 생각하신 건지 "뭔가 기능을 하는" 표현 하나를 끝까지 붙들고 있으십니다. 하지만 안타깝게도 나중에 "현실적으로 serious한 애플리케이션", "기능이 많으면서" 등의 표현으로 보완되었답니다. 그런데, 이미 제 의도를 이해할 생각은 물건너 가셨겠지요. 그러니 그 말 하나 가지고 끝까지 트집을 잡는 것이구요. 이런 걸 말꼬리 잡는 거라고 하지 않던가요?

Quote:
그리고 제가 카二리님 글에 답글 달면서 위의 토론을 저렇게 한 줄로 언급한게 님 기준에선 '시비'인가요?

시비라는 말을 또 문자 그대로 해석하시는군요. fender님에게는 context라는 게 없는 모양입니다. 좋습니다, 표현을 바꾸죠. 그럼 fender님이 저에게 시비를 거신 건 아니고, 그냥 철지난 토론을 다시 끄집어내신 것 뿐입니다.

Quote:
이 글타래의 creativeidler님 주장들을 저렇게 정리할 수 있다면, 저는 이 글타래의 제 주장은 '자바는 프로그래밍 언어다'라고 정리하겠습니다. 반론의 여지가 없죠? ㅎㅎ 전자의 논리가 이해되는 사람이라면 후자도 어렵지 않게 이해할 것 같군요.

허수아비 논증의 제왕 인증하시는 거죠 지금? 대단하십니다.

Quote:
뭐 계속 상대해드리는 건 어렵지 않습니다만 갈수록 스스로 트롤 인증하시는 건 안타깝군요.

돌 던지고 도망간다고 뭐라 그러니까 이제 방식을 바꾸셨군요. 그래도 그 말은 듣기 싫었나보죠? ㅋㅋ 상대해드린다? 핫핫. 지겨운데 저를 배려해서 애써 상대해주고 있으신 거군요? 제가 토론할 때 지저분하고, 인신공격도 마구 쏟아놓고 하는 거, 맞습니다. 저는 인격적으로 그렇게 훌륭한 사람은 아니거든요. 다만, fender님처럼 뒤통수나 치고 온갖 지저분한 짓 다 해놓고 혼자 깨끗한 척 하지는 않습니다.

그 끈기, 언제까지 가는지 두고 보겠습니다. 물론, 언제든지 그냥 돌 던져놓고 도망가셔도 이번에는 뭐라 그러지 않겠습니다. 이미 fender님이 그런 사람이라는 건 알았으니 놀랄 것도 없지요.

그나저나, 제 질문들에 대한 대답은 언제까지 회피하실 건지 모르겠네요.

fender의 이미지

Quote:
분명히 fender님은 본인의 의도와 다르게 표현하셨고, 나중에 그 의도를 해명했죠. 전 그 해명을 받아들였고, 그 부분은 더 이상 트집 잡지 않겠다고 말씀드렸습니다. 말꼬리를 잡기 싫었으니까요

제가 의도와 다르게 표현해서 해명까지 했다구요? ㅎㅎ;... 뭐 그렇게 믿으시는 게 기분이 좋으시다면 그렇게 믿으세요. 안말립니다.

근데 말이죠... 제 의도를 곡해해서 트집을 잡으셨다는 걸 아셨으면 잘못을 인정하는 건 안바래도 더 이상 시비는 걸지 말아야죠. 아닌가요?

제가 의도와 다르게 표현했으니 제 잘못이라구요? 그 해석 기준도 님이 맘대로 만들었다면서요... 그걸 제가 무슨 수로 알아서 님 입맛에 맞게 표현해드립니까?

상식적으로 '단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션들은 다 속도에 문제가 있고 네이티브보다 압도적으로 느리다'라는 걸 ''자바로 아무리 단순한 어플리케이션을 만들어도 느리다는 주장'이라고 해석하는 사람이 잘못된 겁니까, 아니면 그렇게 말해놓고 논쟁이 되니까 자신의 원래 의도는 '자바는 에디터, 메신저, 압축 해제 프로그램, 단순 파일 탐색기 이상의 복잡한 프로그램을 만들기엔 너무 느리다'였는데 제가 그걸 '아무리 단순한 어플리케이션'이라고 요약했으니 오독이라고 트집잡고 인신공격해대는 사람이 정상입니까?

제가 그 표현에 집착한다고 하시는데, 그럴 수밖에 없는게 제3자의 글에 답글단 내용의 바로 그 표현 하나를 가지고 이제까지 집요하게 트집잡으신게 님이니까요.

다른 사람에게 단 덧글을 자기 멋대로 기준잡아 해석해서 공격 실컨 해놓고 이제와서 저보고 집착하지 말라구요? ㅎㅎ;

제안 하나 하죠. 저도 이쯤해서 빠질테니 creativeidler님도 이쯤에서 접고 빠지세요. 만약에 님이 진심으로 님의 논리는 이상없는데 제가 괜히 이기고 싶어서 억지쓰는 거라고 믿는다면 이쯤 이야기 했으면 다른 사람들도 알아서 판단할 거 아닙니까?

안쓰럽군요...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

Quote:
인용:

분명히 fender님은 본인의 의도와 다르게 표현하셨고, 나중에 그 의도를 해명했죠. 전 그 해명을 받아들였고, 그 부분은 더 이상 트집 잡지 않겠다고 말씀드렸습니다. 말꼬리를 잡기 싫었으니까요

제가 의도와 다르게 표현해서 해명까지 했다구요? ㅎㅎ;... 뭐 그렇게 믿으시는 게 기분이 좋으시다면 그렇게 믿으세요. 안말립니다.

이 이야기는 그럼 "아무리 간단한 응용프로그램이라도"라는 말 자체에 본인 의도가 제대로 표현된 거라는 뜻인가요? 그러면 저도 문자 그대로 해석하면 되는 거죠? 그럼 그나마 봐줄려고 했던 오해 하나마저 원상태로 돌아가는 거군요. 그럼, 여전히 fender님은 확대해석을 한 상태이십니다.

Quote:

제가 의도와 다르게 표현했으니 제 잘못이라구요? 그 해석 기준도 님이 맘대로 만들었다면서요... 그걸 제가 무슨 수로 알아서 님 입맛에 맞게 표현해드립니까?

그 기준이 그 기준이 아니거든요? 제가 제 맘대로 잡았다는 것은 "뭔가 기능을 하는"이라는 표현을 제 맘대로 "serious한 프로그램"으로 잡았다는 것입니다. 이게 제 맘대로 잡은 표현이라 fender님처럼 맥락 없이 멋대로 해석하는 사람이 있을까봐 부연 설명을 두 번이나 달았던 거구요. fender님이 잘못 표현했다는 것은 "아무리 간단한"입니다. 이 표현은 말만 놓고 보면 명백히 테스트 프로그램을 포함하는데도 포함 안한다고 우기고 있으시죠? 그래놓고 이제는 잘못 표현한 게 아니라굽쇼? 이것도 기준이라는 말에 말꼬리잡기를 하는 것에 불과합니다. 다시 말씀드리지만, 논쟁에는 맥락이라는 게 있답니다.

Quote:
상식적으로 '단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션들은 다 속도에 문제가 있고 네이티브보다 압도적으로 느리다'라는 걸 ''자바로 아무리 단순한 어플리케이션을 만들어도 느리다는 주장'이라고 해석하는 사람이 잘못된 겁니까, 아니면 그렇게 말해놓고 논쟁이 되니까 자신의 원래 의도는 '자바는 에디터, 메신저, 압축 해제 프로그램, 단순 파일 탐색기 이상의 복잡한 프로그램을 만들기엔 너무 느리다'였는데 제가 그걸 '아무리 단순한 어플리케이션'이라고 요약했으니 오독이라고 트집잡고 인신공격해대는 사람이 정상입니까?

허허, 이제 동어반복까지 해가면서 말꼬리잡기를 하시는군요. 그 논점은 이미 제가 이전 논쟁에서 부연 설명이 있었던 일이라고 반박하지 않았습니까? 그런데 그 반박은 조용히 무시하고 동어반보을 하는 것은 말꼬리 잡기 밖에 안됩니다. 아니면 차라리 그 반박을 인정 못하겠다고 하시든지요.

자, 그리고 "비주얼 스튜디오보다 느리다"를 "데스크탑에서 적합하지 않을 정도로 느리다"로 확대해석한 건 어떻게 하시렵니까? 안타깝게도 여기에 관해서는 앞서처럼 말꼬리잡을 거리조차 못 찾아내셨나보군요.

Quote:
제안 하나 하죠. 저도 이쯤해서 빠질테니 creativeidler님도 이쯤에서 접고 빠지세요. 만약에 님이 진심으로 님의 논리는 이상없는데 제가 괜히 이기고 싶어서 억지쓰는 거라고 믿는다면 이쯤 이야기 했으면 다른 사람들도 알아서 판단할 거 아닙니까?

헐헐. 다른 사람이 판단한다뇨. 누가 이걸 끝까지 보고 있겠습니까-_-a 다른 사람이 fender님은 아주 논리적으로 대응하고 있는데 저만 트롤처럼 구는 걸로 볼까요? 아니면 그 반대로 저는 논리 전개를 잘하고 있는데 fender님이 우기는 걸로 볼까요? 당연히 둘다 진흙탕 싸움하는 걸로 밖에 안 봅니다.

그렇게 지겹고 안쓰럽고 그만두고 싶은데 왜 그냥 그만두지 않으시나요? 제가 또 뭔가 답글 달면 괴로우신가요? 그게 진흙탕 싸움입니다. 저는 유쾌할 것 같은가요? 싫으면 그냥 떠나면 됩니다. fender님이 더 이상 답글 안 달고 그냥 휙 사라지시면 제가 끝까지 쫓아가서 괴롭힐 것 같으신가요? 걱정하지 마십시오. 그냥 조용히 떠나면 저도 더 뭐라 그럴 생각 없습니다.

사람이 논쟁을 하다보면 감정이 격해지기도 하고, 서로 늘어놓은 말이 너무 많아서 기억이 잘 안 나기도 하고, 이래저래 실수를 하게 마련입니다. 때때로 그런 실수가 결정적인 오해를 낳기도 하지요. 저 역시 실수를 하고, 또, 실수한 게 확인되면 바로 인정하지 않습니까? 그런데 fender님은 이미 이번 논쟁에서만도 많은 실수를 했음에도 불구하고 자신은 실수한 게 하나도 없는 것처럼 말씀하십니다. 제가 이 논쟁을 이어오고 있는 이유는 이제 이것 뿐입니다.

전에도 말한 바 있듯, "아무리 간단한" 문제는 fender님의 표현이 틀렸다고 보기는 하지만 무슨 뜻인지 알았기 때문에 더 이상 트집 잡을 생각 없습니다. 앞서, 원상태로 돌아갔다는 말을 하긴 했지만, 그건 어차피 fender님이 자신의 표현이 틀렸다는 것을 인정하기 싫어서 한 이야기에 불과하기 때문에 별로 무게를 두지는 않습니다. 어차피 중요한 건 자신의 실수를 단 하나도 인정하기 싫어한다는 것, 그거기 때문에 소재는 계속 바뀌어도 같은 이야기지요.

그래서, 저는 fender님이 자신의 잘못을 시인하거나, 혹은 말없이 조용히 떠나기 전까지는 계속 답글을 달 겁니다. 물론, 그게 fender님의 잘못이 아닌 걸로 명백히 밝혀지는 경우에도 저의 무고를 사과하고 접을 것입니다.

목표가 fender님 잘못의 시인이니만큼, 마지막으로 제가 fender님의 잘못이라고 생각되는 것을 정리합니다.
1. "뭔가 기능을 하는 애플리케이션"이라는 표현을 뒤에 이어서 "serious한", "기능이 많은" 등의 표현으로 부연 설명을 했음에도 불구하고 끝까지 "모든 애플리케이션"이라고 확대해석하고 있는 것.
2. "비주얼 스튜디오보다 느리다"를 "데스크탑 환경에서 적합하지 않을 정도로 느리다"라고 확대해석한 것.
3. "아무리 간단한 응용프로그램이라도"라고 말했으면서 테스트 프로그램은 제외한다고 주장하는 것.

물론 1번은 fender님만의 실수는 아닙니다. 저 역시 모호한 표현을 쓴 죄가 있으니 50:50 정도겠죠. 단지 fender님의 책임 부분만큼이라도 인정하시면 더 이상 문제삼지 않겠지요.
2번은 해명 혹은 인정을 하시면 좋을 듯 합니다.
3번은 그냥 말실수라고 보고 있긴 하나, 끝까지 틀린 표현이 아니라고 하신다면 이것도 결국 확대해석에 들어갑니다. 그냥 표현이 좀 그랬다..정도로만 하셔도 대의를 이해하는데는 아무 지장이 없는 상태입니다.

물론, 그냥 그만두고 싶어서 떠나셔도 더 이상 괴롭히지 않을 겁니다. 이렇게 자신의 잘못을 인정해보라고 말을 하기는 했지만 그런 일이 실제로 일어나지는 않을 테고, 그렇다면 앞으로 어디서든 fender님과 말을 섞는 일은 없을 테니까요.

fender의 이미지

Quote:
목표가 fender님 잘못의 시인이니만큼, 마지막으로 제가 fender님의 잘못이라고 생각되는 것을 정리합니다.
1. "뭔가 기능을 하는 애플리케이션"이라는 표현을 뒤에 이어서 "serious한", "기능이 많은" 등의 표현으로 부연 설명을 했음에도 불구하고 끝까지 "모든 애플리케이션"이라고 확대해석하고 있는 것.
2. "비주얼 스튜디오보다 느리다"를 "데스크탑 환경에서 적합하지 않을 정도로 느리다"라고 확대해석한 것.
3. "아무리 간단한 응용프로그램이라도"라고 말했으면서 테스트 프로그램은 제외한다고 주장하는 것.

누가 보면 제가 자바가 느리다고 주장했는데 creativeidler님이 안느리다고 반박한 줄 알겠습니다 ㅎㅎ; 제발 기억이 안나시면 본인이 무슨 주장을했는지 좀 읽어라도 보고 덧글 다시죠?

님이 '일부 기능이 많은 자바 어플리케이션은 느릴 수도 있다'라고 했는데 제가 '아니다 모든 자바 어플리케이션이 느리다'라고 했습니까?

제가 SWT 메뉴 테스트 코드가 비주얼 스튜디오보다도 느리니까 기능 많은 어플리케이션 만들면 더 느릴거라고 주장했습니까?

'간단한 응용프로그램'이 테스트 프로그램을 포함하는 거라면 본인이 '단순 테스트 외에 뭔가 기능을 하는 자바 애플리케이션'이라고 말한 건 뭐가 되는 데요? ㅎㅎ;

아니... 꼭 그렇게까지 간절하게 말싸움에서 승리하고 싶으시다면 옵션을 하나 드리죠.

그럼 님이 앞선 장문의 토론에서 주장하고 싶으셨던게 단지 '일부 기능많은 자바 어플리케이션은 느릴 수 있고, 어떤 자바 프로그램은 비주얼 스튜디오보다 느리더라도 데스크탑 환경에 적합할 수 있다'였습니까?

그랬다면 그 다음부터 제 주장들 다 철회하고 님이 승리하셨다고 치죠. 토론 주제에 대해 입장이 똑같은데 싸워서 뭐합니까? ㅎㅎ

Quote:
저 역시 실수를 하고, 또, 실수한 게 확인되면 바로 인정하지 않습니까?

근데 왜 끝까지 이기고 싶어서 억지를 부리시나요? ㅎㅎ

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

creativeidler의 이미지

Quote:
누가 보면 제가 자바가 느리다고 주장했는데 creativeidler님이 안느리다고 반박한 줄 알겠습니다 ㅎㅎ; 제발 기억이 안나시면 본인이 무슨 주장을했는지 좀 읽어라도 보고 덧글 다시죠?

비슷하지만 정도가 약간 다르죠. 저는 자바가 90만큼 느리다고 했는데 fender님은 100만큼 느리다고 한 것처럼 확대해석하고 있으니 제 입장에서는 그래도 100보다는 10만큼 괜찮다는 이야기를 할 밖에요.

Quote:
님이 '일부 기능이 많은 자바 어플리케이션은 느릴 수도 있다'라고 했는데 제가 '아니다 모든 자바 어플리케이션이 느리다'라고 했습니까?

아뇨. 그게 아니라니까요. 이것보세요. 또 오독하셨지 않습니까. 어떻게 매번 이런 실수가 나옵니까? 일부가 아니고, 기능이 많은 자바 애플리케이션은 다 느리다!라고 말했습니다. 자꾸 확대했다 축소했다 하지 마시고 있는 그대로 좀 봐주세요.

Quote:
그럼 님이 앞선 장문의 토론에서 주장하고 싶으셨던게 단지 '일부 기능많은 자바 어플리케이션은 느릴 수 있고, 어떤 자바 프로그램은 비주얼 스튜디오보다 느리더라도 데스크탑 환경에 적합할 수 있다'였습니까?

아, 정말, 왜 이러십니까? 그게 아니라니까요! 자꾸 두 가지를 합치지 마세요. 저는 "아무리 간단한 자바 애플리케이션이라도 GUI 반응성이 비주얼 스튜디오보다 느리다"라고 했고, "기능이 많은 자바 애플리케이션은 데스크탑에 적합하지 않을 정도로 느리다"라고 했습니다. 자꾸 이렇게 제 주장을 조각조각 내서 마음대로 합쳐버리시니 논의가 진도가 안 나가지 않습니까?

다시 반복하지만, 제 주장은 어느 정도 기능이 많은 자바 애플리케이션은 모두 데스크탑에서 답답한 느낌이 들 정도로 GUI 반응성이 느리다는 겁니다. 결코 입장이 같지 않습니다. 저는 분명히 자바는 데스크탑에서 쓸만한 게 아니라고 보고 있습니다. 제가 예외로 두고 싶은 부분은 아주 기능이 작은 애플리케이션의 경우 뿐입니다. 그 점 때문에 확대해석이라고 하는 겁니다.

이 이야기는 제가 잘못 표현한 건 아닌 게 확실합니다. 왜냐하면, 이전 논쟁 때 제 이야기를 올바르게 이해한 사람이 있거든요. 뭐, 그 사람과 제가 같이 착각한 거라고 하실려나요?

Quote:
인용:

저 역시 실수를 하고, 또, 실수한 게 확인되면 바로 인정하지 않습니까?

근데 왜 끝까지 이기고 싶어서 억지를 부리시나요? ㅎㅎ


제가 써먹은 말 재활용해서 반격해보시는 건가요? 유치하기까지 한 사람은 아닌 걸로 알았는데... 논쟁이란 게 참 사람을 밑바닥까지 내려가게 만들기도 하는군요. 뭐, 제가 인정한 것 외에 또 실수가 있으면 언제든지 증명만 해주십시오. 증명만 되면 바로 인정하지요.

그나저나, 비주얼 스튜디오 건은 언제 인정하시려나...

페이지