MS "자바 사용못해"
글쓴이: geekforum / 작성시간: 금, 2001/07/20 - 12:53오후
한겨레신문 기사입니다. 자세한 내용은 관련 링크를 참조하십시오.
미국 마이크로소프트는 오는 10월25일 내놓을 예정인 새 운영체제 윈도엑스피(XP)에 자바 응용프로그램을 지원하는 기능을 없애기로 했다고 미 <월스트리트저널>이 19일 보도했다.
자바는 미 선마이크로시스템스가 1995년 개발한 대화형 프로그래밍 언어로, 기술료가 거의 없는 사실상의 공개프로그램이라는 점 때문에 인터넷의 쌍방향 게임이나 과학실험 사이트 등에 널리 이용되고 있다. 이에 따라 윈도엑스피 이용자들은 자바로 만든 프로그램이나 사이트를 이용하려면 별도의 공개 소프트웨어를 내려받아 설치해야 한다.
이에 대해 많은 전문가들은 마이크로소프트가 자바와 비슷한 기능의 자사 프로그래밍언어 "C#"를 보급하기 위해 운영체제의 독점력을....
Forums:
님 어차피 데스크탑 OS로 리눅스는 걸음마 수준입니다.님이 말한 콤포
님 어차피 데스크탑 OS로 리눅스는 걸음마 수준입니다.
님이 말한 콤포넌트 기술 필요하다는것 인정합니다. 리눅스가 그쪽으로는 걸음마 수준인것은 맞습니다. 문제는 님이 콤포넌트 하나로 리눅스를 평가절하하고 있는듯해서 한소리적었습니다.
그리고 서버 사이드쪽 코딩이라면 리눅스에서도 자바를 거의 사용하게되므로 큰 문제는
없을겁니다. 님이 말한 데스크탑에서 콤포넌트를 이용한 개발이라면 약한것이 사실이죠.
하여간 서버쪽에선 대개 자바로 하므로 저의 경우 아쉬운게 없었습니다.
솔직히 리눅스를 데스크탑OS로 사용하는 경우는 희귀하고 요청도 없으므로 님이 말한
클라이언트 쪽에서 콤포넌트를 이용한 개발은 사실 별 효용성이 없습니다.
님은 이러저러하다고 콤포넌트를 사용한 NT가 우수하다는 것을 은근히 비추면서
자신이 결론을 적지 않았으므로 순전히 저의 추측에 의한것이라는 말을 하고 있습니다.
님의 글의 의미를 새겨보면 그렇게 밖에 받아 드릴 수 없습니다.
만약 오해라면 오해를 받지 않도록 글을 작성해야하는 것 아닙니까? 내 기준으로 썼으니
알아서 읽는 사람이 해석하라는 것도 아니라면 무책임하다는 생각안듭니까?
님의 글을 읽으면 콤포넌트써서 쉽게 코딩할 수 있으니까 NT가 우수하다 리눅스는 구닥다리다 이렇게 밖에 요약안되는 제 머리가 한심한겁니까?
그리고 콤포넌트 아니라도 할 수 있다는 말을 그렇다면 어셈블리로도 가능하다는 말이냐?
라고 말씀하신것은 어처구니가 없군요.
어셈블리니 C니 하는 것은 언어입니다. 언어와 코드 재사용을 극대화하기 위한 개발 방법론들을 혼동하시는군요. 절차식이니 객체지향이니 콤포넌트니 하는 것은 또 다른 이야기입니다. 실재로 유닉스 프로그래머들중에는 객체지향 조차 싫어하는 사람들이 많습니다. 이들은 잘짜여진 C라이브러리를 더 선호합니다.
객체지향을 선택하던 콤포넌트를 선택하던 개발자가 판단해서 선택할 일입니다.
OOP로 짜더라도 생각없이 짜면 오히려 구닥다리 절차식으로 짜는 것보다 못한 결과가 나옵니다. C++쓰는 경우에 보면 제대로 OOP로 구현하는 사람이 얼마나 있습니까?
하다 못해 우리나라에서 UML 제대로 가르치고 요구하는 곳이 얼마나 있습니까?
OOP가 뭔지도 모르면서 OOP니깐 좋은거야라던가 콤포넌트니깐 좋다고 말하는 것은 문제가 있습니다.
님의 글에는 왜 콤포넌트 기반의 윈도우가 우수하다고 말하면서 정작 어떤 분야에
어떠한 강점을 가졌는지 구체적 언급이 없습니다. 그냥 콤포넌트라서 좋다. 이것말고
얻을 수 있는 정보가 없군요.
주변에 보면 전혀 필요없는 곳에 필요없는 기술을 적용해서 좋다고 히히덕거리는 개발자들 가끔봅니다. 어디서 XML이 좋다고 하니깐 전혀 없어도 될곳에 적용하고 좋다고
떠벌립니다. 좋은 기술이지만 나왔다가 사장된 기술도 부지기수죠.
콤포넌트가 대세인것은 맞을 수 있겠지만, 과거 절차식 코딩이 아직도 살아있듯이
미래에도 님이 구닥다리라고 말씀하신 절차식 기반 코딩은 건재할겁니다.
또한 콤포넌트의 단점을 개선한 그 무엇이 나올거라는 것도 분명하구요.
결론은 콤포넌트 장점 많은것 인정하고 리눅스 콤포넌트 기반의 프로그래밍 환경이
취약한것 맞습니다. 제대로 보신겁니다. 하지만 콤포넌트 기반이 아니라고 구닥다리
운운하신 것은 문제가 있군요. 리눅스가 처음나왔을 때 구닥다리 모놀리틱 커널이라느니
70년대 기술이라느니 그런 소리있었습니다. 그런데 중요한건 그런게 아니었죠?
KDE, GNOME이나 이런것들도 처음에는 얼마나 취약했는지 아십니까? 오죽하면 우스개소리로 core 생성기라고 불렀을까요?
이론적으로야 언어와 개발방법론이 구분되는 것이겠습니다만실제로야 어디
이론적으로야 언어와 개발방법론이 구분되는 것이겠습니다만
실제로야 어디 그런가요? 어셈 -> C -> C++ -> Java로 언어가
변화해온 것은 그냥 그렇게 된 게 아니라 엄연히 개발방법론이
변화함에 따라 발맞춰 발전한 건데 말이죠.
물론 어셈으로도 OOP적인 개발을 할 수 있고 어셈으로도 컴포넌트
만들 수 있습니다. 이론적으로는 말이지요.
실제론 아무도 안그럽니다.
"컴포넌트 안쓰고도 얼마든지 좋은 소프트웨어 개발할 수 있다"는 주장은
"Java로 구현가능한 건 어셈으로도 얼마든지 구현가능하다"와 비슷한 부류의 주장이지요.
언어와 개발방법론을 혼동하는게 아니라 원래 그 둘은 비슷하게 같이 가는 겁니다. 쩝
Anonymous님... -_-;;글을 쭉 읽다보니 짜증이나
Anonymous님... -_-;;
글을 쭉 읽다보니 짜증이나서 한마디 하렵니다.
님의 주장에 대해 잘못을 지적한 글이면
다시 반론을 펼치던지, 아니면
자신이 잘못 생각했다라고 인정을 해야 되는거 아닙니까?
반론을 못쓰는것에 대해서는 그냥 넘어가면서
반론을 할 수 있는것에 대해서만 이렇게 답글을 다는것은
"너가 뭐라 하든 내 주장이 무조건 맞다." 라고 하는거 아닙니까?
그리고 어떻게
"컴포넌트 안쓰고도 얼마든지 좋은 소프트웨어 개발할 수 있다"와
"Java로 구현가능한 건 어셈으로도 얼마든지 구현가능하다"가 비슷한지 모르겠군요.
뭐 둘다 사실이라는 점은 비슷하군요.
Java로 구현가능한 건 어셈으로도 구현가능하지만 무척 힘들어서 그렇게
하는 사람 아무도 없죠...
그럼 컴포넌트 안쓰면 좋은 소프트웨어를 만드는게 무척 힘들까요?
님이 생각하는 좋은 소프트웨어의 기준이 무엇인지는 모르겠지만...
저는 좋은 소프트웨어는 그 소프트웨어의 목적을 수행하는데 있어 기능적으로
잘 수행되고, 사용자 입장에서 편리한 인터페이스, 개발자 입장에서 유지보수가
용이하도록 제작된것이라고 생각하는데요. 그런것들이 컴포넌트의 유무하고
무슨 관계가 있는지 궁굼하군요.
반론은 쓰고 쓰고 또 썼기때문에한 말은 더이상 안쓰려는겁니다.흐미
반론은 쓰고 쓰고 또 썼기때문에
한 말은 더이상 안쓰려는겁니다.
흐미 이 더운날 나도 머하는 짓이람
아 이 논쟁도 지긋지긋하네요..쓴내용 또쓰고 또쓰고님 잘 보세
아 이 논쟁도 지긋지긋하네요..
쓴내용 또쓰고 또쓰고
님 잘 보세요
애초에 전 리눅스에서 컴포넌트 개발환경이 부족하다고 썼습니다.
근데 주현님이라는 분이 말씀하시길 컴포넌트 안쓰고도 얼마든지
좋은 소프트웨어 만들 수 있다고 하셨네요.
저는 그건 경우에 따라 다르다고 주장하는겁니다.
C랑 절차적 방법론만 가지고서도 우수한 품질의 소프트웨어를 만들어낼수 있는
프로젝트가 있는 반면에
그것만가지고는 부족해서 자바나 C++, OOP와 컴포넌트 기술이 동원되는 편이
유리한 프로젝트가 있는 겁니다.
그렇기 때문에 리눅스에 컴포넌트 환경이 부족하다는 지적에 대해
"컴포넌트 안쓰고도 좋은 소프트웨어 만들 수 있다"고 주장하는 건
오류라는 겁니다.
예로 드신 아파치 같은 건 그럴 수 있을지 몰라도, 소프트웨어 시스템의
덩치가 커지면 커질수록 컴포넌트 시스템의 장점이 부각되는 것이
명백함에도 불구하고
"컴포넌트 안써도 다 돼!"라는 건 "어셈으로도 다 할 수 있어!"라는
생떼랑 비슷하다는 거지요.
아시겠나요?
겨우 vi 만드는데 컴포넌트 안쓰면 나쁜 소프트웨어라는 게 아니란 말입니다.
아 짜증나~ 짜증나 한말 또하고 또하고
님 그건 저도 말한거네요. 개발자의 선택의 문제라고문제는 님이 리
님 그건 저도 말한거네요. 개발자의 선택의 문제라고
문제는 님이 리눅스는 컴포넌트 기반이 열악하다고 구닥다리 운운한게 화근입니다.
아직도 문제의 핵심을 파악하지 못하고 계시군요. ^^; 그리고 님이 리눅스는 구닥다리다
에 대한 근거로 제시한것이 컴포넌트가 취약하다 딱 이거하나였고 아무런 부연 설명도
없었습니다.
그리고 리눅스도 SUN에서 JVM 포팅해주고 있습니다. 실재로 님이 말한 컴포넌트 필요한
것들 현업 업체에서 리눅스에서 자바로 거의 수행합니다. 솔라리스도 마찬가지구요.
따라서 리눅스는 컴포넌트 기반이 아니라서 구닥다리다라는
님의 주장은 틀렸다는 것을 말하고 싶은겁니다. JAVA처럼 컴포넌트 기반의 쓸만한
언어 몇가지만 나와도 금방뒤집어지는 이야기란말입니다. 뭐 .NET도 리눅스로
포팅되고 있다는 이야기도 들리는데...
그리고 그렇게 되어도 여전히 리눅스는 절차식 개발 방법, 객체지향, 컴포넌트 기반이
혼재되어 있을것이구요. 개발자는 골라서 쓰겠죠. 님처럼 컴포넌트이기 때문에 우수하다고 말할 필요는 없는거죠. (물론 님이 직접적으로 그런말씀하신 것은 아니지만 워낙 컴포넌트 기반의 우수성이라는 잣대로 흑백을 가리길 좋아하시니...)
제가 말하고 싶었던 것은 리눅스가 컴포넌트 기반이 없는 것도 아니고 배제하는 것도 아니다. 개발자들은 절차식이던 객체지향이든 그 프로젝트에 최선의 것을 선택할 뿐이다.
아파치는 절차식이 효과적이므로 그렇게 짠것이고 님이 말씀하신 그런류의 프로젝트는
컴포넌트로 짜면 되는것이다. 그걸 가지고 컴포넌트라서 진보적이고 좋다라고 흑백론으로 말하는 것은 잘못된것이다. 리눅서 (엄밀히 광신도 ^^;)로써 기분 무지 나쁘다라는게 솔직한 이야기입니다.
휴...... 만나게 되면 술이나 한잔..... ^^;
즐거운 하루되시길...
흐미 그렇담 일단 "구닥다리"라는 용어에 대해서는 사과하도록 하지요.
흐미 그렇담 일단 "구닥다리"라는 용어에 대해서는 사과하도록 하지요.
절차적 프로그래밍 방식이 쓸모없다라는 것이 아니라, 구식임은 분명하므로
그런 말을 썼지만, 또한 저 역시 각종 구닥다리(vi, 콘솔 프로그래밍, C 등등)을
사랑하는 사람 중에 하나기 때문에 그 용어가 다른 사람들에겐 기분 나쁘게
들리리라고는 미처 생각하질 못했네요.
그러나 리눅스에 "컴포넌트 기반이 없는 것도 아니고 배제하는 것도 아니다"라는
말씀에는 동의하기 어렵군요. 배제하는 거야 물론 아니겠지만, Java 외엔 없다고
해도 과언이 아니죠. 그런데 Java가 리눅스에선 본격적으로 쓸만큼 잘 도는 것도
아직은 아니고(스케일러빌리티에 문제가 있지요), 게다가 Java와 Bean은
웹애플리케이션 분야를 제외하면 아직까지는 별로 썩 좋은 선택이라 할 수 없지요
(무무물론 돈되는 수많은 프로젝트가 웹 프로젝트이므로 그것만 해도 어딥니까마는;;)
개발자의 선택의 폭이 별로 넓다고는 볼 수 없습니다. C와 C++로 바닥부터 시작해서
모든 걸 다 만들던가, 제한된 분야에서 Java를 쓰던가. native 컴포넌트 시스템이
부족해서 그렇지요.
머 어쨌든 개인적인 취향으론 Bonobo든 Kparts든 간에 어서 무럭무럭 자라서
윈도우의 COM 역할을 리눅스에서 해줬으면 하는 바램입니다. (COM도 시작은
데스크탑 OLE에서였다지요?)
아니 겨우 vi 라니요.미워잉!!! ^^;
아니 겨우 vi 라니요.
미워잉!!! ^^;
--- gvim의 열렬한 팬
개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?
흐미 사실은 저도 골수 VIM 팬인데..비쥬얼 스튜디오 쓸때 빼곤 유
흐미 사실은 저도 골수 VIM 팬인데..
비쥬얼 스튜디오 쓸때 빼곤 유닉스 콘솔에서건 윈도에서건
모든 텍스트 작성은 VIM으로 하죠
vi를 비하하는 뜻은 아닌데 말이죠
한마디만 더 하죠.님 말씀대로 구닥다리 절차식 기반 코딩은 건재할 겁
한마디만 더 하죠.
님 말씀대로 구닥다리 절차식 기반 코딩은 건재할 겁니다. 절차식 기반
코딩이든 컴포넌트 기반 디자인이든, 프로젝트마다 개발의 효율성/경제성에
가장 적합한 방식이 채택될 겁니다.
문제는 리눅스는 전통적인 절차식 기반 코딩에서는 성공적이었고 강점을
가지겠지만, 컴포넌트가 필요한 대형 프로젝트에서는 OS로서 해주는 게
별로 없다는 것. 그것은 분명히 경쟁자인 NT에 비해 약점이 될 수 밖에 없습니다.
약점을 제대로 인식하는 것이야말로 발전의 초석이건만, 여기선 리눅스의
약점 같은 거 한마디만 써도 님처럼 열내시는 분들 때문에 참으로 피곤하군요.
한마디 할때마다 일일히 "그렇다고 꼭 NT가 훌륭하다는 건 아니지만" "꼭 어느게
낫다고는 할 수 없지만" 이딴 식의 하나마나한 당연한 소리 꼭 써주건만 그것도
소용없고 말이죠.
결론을 다시 재정리하죠. --;리눅스가 콤포넌트 기반이 취약한것은
결론을 다시 재정리하죠. --;
리눅스가 콤포넌트 기반이 취약한것은 맞는데, 그것만으로 평가절하당하기엔
너무하지 않느냐는거죠.
흐미 애초에 제가 쓴 글을 살펴보죠.."시스템이 복잡해질수록 리눅
흐미 애초에 제가 쓴 글을 살펴보죠..
"시스템이 복잡해질수록 리눅스가 OS차원에서 해주는 일이 없다..
마치 C처럼, 못만들건 없지만 해주는 건 별로 없다.."
이 평가가 제 주관적인 가치평가( = 평가절하 )라고 생각하십니까 아니면
객관적인 사실( = FACT )라고 생각하십니까.
"실력이 일천하여 어느것이 낫다고 평가는 못하겠지만 API사용자 입장에서
NT쪽이 편한 것은 사실이다"
이건 순전히 제가 실제로 양쪽에서 개발해보면서 개인적으로 느낀 것에 대해
서술한 것입니다. 리눅스 쪼금만 안좋다는 해도 님처럼 발끈하는 분들이 많아서,
어느게 좋다는 평가는 유보한다고 조심스럽게 썼건만, 소용도 없군요. 리눅스는
모든 게 좋습니까? 더이상 발전할 필요 없어요? 왜 그리 감정부터 앞세워요??
님이 제 글을 "리눅스를 평가절하한다"라고 읽으신 것은 님이 색안경을
끼고 "어디에 리눅스 까내리는놈 없나" 하고 있기 때문이지, 제가 오해할만하게
썼기 때문이 아닙니다. 자신부터 돌아보시길.
흐미 그럼 "OS로서 해주는 게 별로 없다"는 제 말에 대해 좀 구체적으로 설명해보죠.
H.323 시스템 (자꾸 이 것만 예를 들어서 죄송하지만, 제가 직접 접해본
나름대로 꽤나 "복잡한" 시스템은 이것 뿐이라 어쩔 수가 없군요.)을
구현한다고 가정을 하죠. 이 h323이란 게 단지 h323뿐만 아니라, 주변에
여러 관련된 것들 ( 컨퍼런스, 각종 Supplementary Service들, 인터넷 팩스를
위한 T.38, 화이트보드등 공유애플리케이션을 위한 T.120 등등등 )과 연결될
필요가 있습니다. 그런데 사실 H.323이나 T.120이나 이런 스펙들은 그 자체
구현들만으로도 높은 복잡도가 요구되는데, 이것들을 유연하고 확장성있게
구현하려면 각 부분들을 컴포넌트로 구현하는 것이 최적입니다. 사용될
음성코덱도 여러가지, 화상코덱도 여러가지, 네트웍 프로토콜도 최소 2가지,
call hold/transfer등 Supplementary Service도 필요한 경우가 있고 아닌 경우가
있고, t.120에서의 각종 애플리케이션 프로토콜 핸들링은 말할 것도 없고..
개개의 프로젝트마다 수십가지의 변수가 작용하는데(즉 프로젝트의 프로필이
다 달라지는데), 거기에 단일한 소스로 대응하려면 컴포넌트화(혹은 모듈화)가
절대적으로 필요합니다. 그렇지 않으면 하드코딩 난무의, 프로젝트마다 소스코드들이
다 달라지는, 관리불능의 수십가지 버젼의 소스가 난립하게 되더군요.
자, 리눅스에서 이런 시스템을 개발하려면, 컴포넌트 시스템(내지는 모듈 시스템)
디자인 단계가 반드시 필요합니다. 쉬운 일이 아니지요. 어쨌든 이것이 끝나야
서비스들을 디자인하고, 각각 필요한 부분들에 어디서 C라이브러리를 가져와서
캡슐로 만들어서 끼워넣고 할 수가 있는거죠.
NT에서는 이 단계가 생략이 됩니다. 이미 있는 컴포넌트 시스템에, 바로 사용가능한
컴포넌트도 많습니다. 서비스 디자인부터 바로 시작하면 되고, 특히 미디어
프로세싱 부분은 direct show 필터로 구성하면 일이 훨씬 간단해집니다.
게다가, 클라이언트에 사용되는 컴포넌트와 중앙의 MCU에 사용되는 컴포넌트들도
공통되는 것들이 많아서, 따로따로 개발할 필요가 없습니다.
자, 개인적인 취향으론 직접 컴포넌트 내지는 모듈시스템을 만드는 것이 더
재밌으리라고 생각합니다. (내 손으로 처음부터 모든 걸 다 만든다.. 개발자의
로망이랄까;) 하지만 개발의 경제적인 측면에서 본다면 어느쪽이 나은지 자명하죠.
시스템이 복잡해질수록 리눅스가 해주는 게 별로 없다는 것에 대한 설명이 되었는지요??
이것은 평가절하입니까 (발전의 초석이 되는) 객관적인 현실 파악입니까?
글쎄요. 물론 생산성과 편리성 이게 윈도우의 장점이니까요.뭐 거기에
글쎄요. 물론 생산성과 편리성 이게 윈도우의 장점이니까요.
뭐 거기에 대해서 크게 흠잡을 생각은 없습니다. 편하면 좋으니까요. 그리고 리눅스도
그러한 윈도우의 장점에다 유닉스의 장점을 합쳐서 발전해나가는 잡종이니까요.
그런데 꼭 리눅스랑 비교해서 "구닥다리", "겨우" 이런 이야기를 써서 기분 나쁘게할 필요는 없겠죠. 그걸 구닥다리나 겨우가 아니라고 생각하는 사람도 있는데...
vi나 emacs는 최고의 편집기죠. 편집기가 편집하는데 유용하면 되지 컴포넌트 같이
위대한 성배를 겨우 하찮은 텍스트 기반의 저 도스 시절의 edlin 같은 편집기에
어떻게 쓰느냐는 식으로 말씀하시면 안되죠.
KLDP에는 리눅서 광신도들이 많은데 어떻게 감당하실려고... -_-;
비판은 받아들여도 비난은 못참는게 리눅서들인데... ^^;;
물론 님의 글은 80%는 건설적 비판이었지만 10%의 비난(?) 때문에 문제가 생긴것이구요.
하여간 여기서 구닥다리, 겨우 형편없는 애들 장난감 이런 이야기하면 굴비가
주렁 주렁 매달린답니다. 비판은 해도 좋지만 저런 글들은 감정을 상하게 하기 쉽죠.
특히 저 같이 단순무식과격한 사람들에겐 (구닥다리, 장난감 소리만 나도 핏대팍) ^^;
흐미 vi에 "겨우"소리가 붙은 건 그 덩치가 작아서 한 말씀일 뿐입니다
흐미 vi에 "겨우"소리가 붙은 건 그 덩치가 작아서 한 말씀일 뿐입니다.
기분 나쁘셨다니 죄송하군요. "구닥다리" 건도 그렇고 용어 선택에
부주의했다는 점은 인정하지요.
그런데 사실 비판은 받아들여도 비난은 못참는게 리눅서들인데..라는
말씀에는 글쎄올시다라는 개인적인 의문을 품고 있다는;
happyhacking의 도구로서 리눅스에 만족하는 사람들이라면 몰라도,
"윈도대체,세계정복"이라는 현실적인 야심을 가진 사람들이라면
그만큼 현명하고 철저하게 현실적이어야 할텐데, 툭하면 파란화면이
어떻고 도스기반 95/98 씹는 얘기나 하고 말이죠.
M$ 욕하는 것은 좋습니다. 그런데 그것은 어디까지나 정치적인 이유에서
M$를 욕하는 것이어야지, 기술력이 허접하다는 식으로 욕해서는 큰 착각이
될 거라고 봅니다. M$가 원래부터 기술력 없던 회사도 아니지만, 없던 기술력도
돈이면 다 사는 겁니다. 정치적으론 철저하게 보이콧하되, 베낄 수 있는 건
다 베껴와야죠. 조롱하면서 무시하는 게 아니라.
그럼 윈도는 컴퍼넌트 중심이구, 리눅스는 무슨 중심이라고 해야하나?(용어
그럼 윈도는 컴퍼넌트 중심이구, 리눅스는 무슨 중심이라고 해야하나?(용어가 생각안남)
컴퍼넌트의 장점은 바이너리의 재사용이 용이하다라고 할수 있다. 사실 컴퍼넌트의 장점에서 본다면 소스레벨에서는 개체지향으로 작성해도되고 절차적, 구조적으로 작성해도 된다고 한다. 컴퍼넌트 내부 소스는 어떻게 짜던지 상관없고 인터페이스 정의만 잘해주면 된다. 두분다 옳으신 말씀이다. 각각 일장일단이 있으니 프로그래머나 사용자는 필요에 따라서 쓰면 된다. 윈도, 리눅스 서로 장단점을 파악하고 장점은 발전시키고 단점은 개선해나가면 되는 것이다. 개발자는 회사의 상술에 너무 신경쓸필요는 없다고 본다.
흐미 일단 bytecode gc 등이 Java가 최초로 발명해낸 것도
흐미 일단 bytecode gc 등이 Java가 최초로 발명해낸 것도
아니고 Java만의 전유물이 아니라는 것도 사실입니다. 그럼에도
불구하고, 그러한 '실험적인' 개념들을 최초로 범용언어로서
실용화(?) 일반화(?) 해낸 공로는 있지요. 그런 의미에서 일종의
원조라고 불릴 자격이 있다고 봅니다. 뭐 그래봤자 C#이 그걸 따라해선
안된다는 건 말도 안되지만요. (베낌은 발전의 원동력! -_-+)
C#.. 물론 Java에는 없는, 프로그래머의 편의를 도모해주는 개념들을
새로 도입했겠지요. 가령 님께서 예로드신 delegate-event 모델이니
get-set 메서드 모델 같은 거요, 물론 좋습니다. 그런 개념을 문법
차원에서 지원해주지 않더라도 구현 불가능할 껀 아니지만, 있으면
프로그래머가 편하고 좋죠. 그러나 그 정도는 C#이 Java의 성공을
보고 Java의 _성공요인_을 그대로 가져온 것에 비하면 감히 '잡다한'
거라고 말하겠습니다.
다시 말하죠. Java의 성공요인이라고 했습니다. C#이 베낀 것은 그냥
단순히 "VM/bytecode 모델"이 아닙니다. Java 이전엔 VM이란 개념은
단순히 실험적이고 제한적인 용도였을 뿐이지만, Java로 인해 분산/이종
환경에서의 새로운 컴퓨팅 패러다임으로 떠오르게 된 것입니다. C#이
베낀 것은 그 "새로운 패러다임"으로서의 VM이죠. 그 차이를 이해하시겠죠?
무무물론 전 그 '베낀다'는 것 자체는 기술발전이란 측면에서 아주
바람직한 행동이라고 생각하는 부류입니다; C#이 Java를 벤치마킹해서
장점을 '베껴'내고 단점을 보완하고 새로운 개념을 집어넣는거,
"기술발전"이란 측면에서 아주 긍정적으로 봅니다. 사실, M$의 기술들
대부분 기술적인 측면에선 아주 감탄하고 있는 바죠.
(뭐; 독점으로 번 돈 잔뜩 쳐발르면 누군들;; 이라고 생각이야 합니다만)
그럼에도 불구하고 M$의 모든 행동을 비판적으로 바라볼 수 밖에 없는
이유는 설명하지 않아도 님께서도 잘 아실 겝니다. M$의 모든 행동은
궁극적으로 모든 경쟁자를 죽여없애고 모든 걸 독차지하는 걸로 귀결되어
왔습니다. C#이 등장한 이유도 별다를 바 없죠. 정치적인 이유에서 C#을
좋아할 수가 없군요.
ps. 흐미 저는 리눅서라 칭할만큼 리눅스를 잘하지도 못하지만 GNU가
말하는 바에 공감을 하고 있으며 언제나! 항상! 기회가 닿는대로! M$를
욕하고 댕깁니다. 아마 저도 님께서 말씀하시는 'M$욕하는 걸로 리눅서임을
자위하는 사람들'에 포함될 듯 한데요. 근데 그게 뭐 잘못되었나요? 독점기업에
사사건건 트집 좀 잡기로서니 님 같은 분한테서 "오픈소스운동과 리눅스
정신이 우리나라에서 시작되지 않았음에 큰 다행을 느낍니다" 이딴 비아냥을
들을 이유가 없다고 생각합니다요.
좀 첨언하자면..솔직히 리눅스의 기술력과 M$의 기술력을 비교하자면
좀 첨언하자면..
솔직히 리눅스의 기술력과 M$의 기술력을 비교하자면 리눅스는
그야말로 어린애 수준에 불과하다고 생각합니다. 리눅스의 성공은
아직은 어디까지나 값싼 웹서버로서에 머물고 있을 뿐, 하이엔드
서버나 데스크탑으로 가는 길은 아직 멀고도 멀죠.
윈도우 파란화면이 어쩌고 하면서 M$ 기술을 우습게 보시는 분들,
95/98은 이미 구닥다리 기술입니다. 더이상 허접기술로 파란화면 띄우는
주제에 독점으로 먹고사는 M$가 아니라고요. 이미 윈2000은 거의 예술이고,
M$의 기술은 단순히 OS기술 뿐만 아니라 컴포넌트 기술을 바탕으로 모든 걸
통합하는 방향으로 나아가고 있습니다. 통합되고 강력해진 기술들은
독점체제를 더욱 더 공고하게 만들껍니다. 이런 게 우습다고요? 전 무서운데요;
반면 리눅스는 아직 구닥다리 posix/single unix 스펙 정도와 X, gcc 정도가
핵심기술일 뿐이죠. 아 뭐 이 구닥다리들이 아직까지도 꽤나 효율적이고
쓸만한 게 사실이고, 앞으로도 당분간은 그러리라고 보지만요, 별로 썩
미래지향적인 기술은 못된다고 봅니다.
값싼 웹서버로 만족할 게 아니라 궁극적으로 M$를 대체하려는 이상을
가졌다면, 자유소프트웨어 진영은 더욱 분발해야 하리라 봅니다.
(개인적으론 미구엘 같은 사람이 올바른 방향으로 나아가고 있지 않나 생각해요)
할말이 없군요. 좀 더 구체적이고 기술적인 이유를 제시바랍니다.리
할말이 없군요. 좀 더 구체적이고 기술적인 이유를 제시바랍니다.
리눅스 설치해서 아파치만 돌리셨나?
리눅스가 어떻게 활용되고 있는지 아직 소식도 못 들으셨나보네요.
님이 지금 하신 이야기는 한 4-5년전 이야기 되겠습니다.
윈도우 2000이 왜 예술적이죠? 아직도 솔라리스에 비하면 떨어지는 안정성을 가지고 있고 엔터프라이즈로 간다고 M$는 떠들지만 실재 엔터프라이즈 시장은 모조리 IBM, SUN, HP쓰던데... x86에 갇힌 윈도우가 고작 8개 정도의 멀티프로세스 지원으로 감지덕지해야하지만 진정한 엔터프라이즈 분야에선 64개 정도의 SMP는 보통입니다.
그리고 콤포넌트는 M$에서 전세냈어요? 타 OS는 그런거 없답니까?
값싼 웹서버 메일 서버 용도를 대체하기 위해서 이미 커널 2.4 내놓고 오라클같은 상용 DBMS 지원 사격도 받고 있습니다. 저널링 파일시스템만 해도 벌써 JFS, XFS, Reiserfs, ext3 정도 나와있고 무얼골라 써야할지 난감한 상황입니다.
님이 입으로 떠들 동안에 리눅스 개발자들은 리눅스의 약점을 솔직히 인정하고 개선하고 있습니다. 왜 리눅스를 오픈소스라고 하는지 모르시나보군요. 우리가 최고야라는 생각을
가지고 있었다면 현재의 리눅스는 존재하지도 않았습니다.
데스크탑 분야든 엔터프라이즈 분야든 상당히 진보되어왔습니다. 4-5년전 리눅스 한번 설치해본거랑 지금이랑 비교하시는겁니까?
물론 MS도 윈도우 2000 이후 많은 발전이 있다는거 다 인정하는 분위기입니다. 돈으로 쳐바르든 어쨌든 기술력을 갖추고 있는 것도 사실이구요.
리눅스 만능주의자 만큼 당신도 위험한 생각을 가지고 있군요.
흐미 실력도 없고 무식한 저지만 리눅스가 2.4커널 이후로 엔터프라이즈를
흐미 실력도 없고 무식한 저지만 리눅스가 2.4커널 이후로 엔터프라이즈를
지향한다는 거나 저널링 화일시스템 개발 경쟁이 치열하다거나 또 대한항공에서
예약시스템을 IBM 리눅스로 구축했다거나 그런 정도는 들어 알고 있습니다.
그래서 리눅스가 엔터프라이즈 시장의 몇 %나 차지하고 있나요? -.-;
4~5년전 얘기라니요 지금 기업들 중에 리눅스를 하이엔드 서버로 쓰고 있는데가
얼마나 되는지 -_-; 여전히 리눅스는 값싼 웹서버 정도일 뿐입니다. 물론
발전하고 있고 저 역시 흥분하고 있습니다만 아직은 IBM 정도되는데서 보증하고-.-;
설치해주지 않는 이상 아무도 리눅스를 하이엔드의 솔라리스나 NT/2000을 대체하려
하진 않을 겁니다.
여기까진 정황적 근거이고.. 개인적인 경험에서 예를 들어보면
개인적으로 I/O에 조금 관심이 있는데, 리눅스는 아직 그 '구닥다리' posix의
aio_* (async I/O)조차 제대로 구현되어 있지 않더군요.. glibc 차원에서 별도의
쓰레드를 돌려서 구현해주고 있던데.. 뭐 SGI kaio 패치가 있기는 합니다만 어쨌든
아직은 공식적으로는 지원되지 않는게 맞죠. /dev/poll 같은 것도 그렇구.. 물론
솔라리스에는 구현되어있죠. aio_*대신 구 aio* 가 더 안정적이란 소리는 들어봤지만
머 한번정도 써본 입장에서 그정도까진 모르겠구요.. NT에는 물론 aio;;나 /dev/poll
같은게 없지만 (제가알기론)모든 I/O에 대해 I/O completion port로 어싱크
오퍼레이션이 가능하더군요.
제가 잘 몰라서 그렇지 찾아보면 이 외에도 리눅스가 (여타 상용OS에 비해) 부족한
부분이 많이 있으리라고 봅니다만 그걸 지적하고 분발을 요한다고 썼다고 님처럼
성부터 내시면 황당해지죠;; 위험하긴 모~가 위험한 생각입니까?
그리고 컴포넌트 기술.. M$에서 전세낸 건 아니지만 M$가 가장 잘 써먹고 있죠?
타OS에서 컴포넌트 기술을 얼마나 잘쓰고 있는지 모르겠지만, 제가 알고 있는 한도에서
보면 OS/2 SOM이나 스텝 정도 같은데요.. 얘들은 아쉬비하게도 맛간지 오래구요..
(맥은 어떤지 전혀 모름) 리눅스야 뭐 아직 데스크탑 일부에서 약간; 장난감 정도로
쓰이는 정도구요. 반면 M$는 모든 걸 다 컴포넌트로 대체하기라도 할 양 COM을
전면에 내세우고 있구요. 그런 걸 지적한 건데 왜 대책없이 흥분하시는건지? @.@
(더위먹으셨나;)
개인적으로 윈도보다는 솔라리스나 리눅스의 콘솔에서 프로그래밍하는데 더 즐거움을
느끼고, 실력은 없고 이해는 못해도 가끔씩 리눅스 커널 들여다보기도 하고 그럽니다.
하지만 유닉스와 NT 양쪽에서 개발해보면서, 리눅스엔 아직도 부족한게 많구나 하는걸
느껴서 위와 같은 글 좀 올렸기로서니 "4~5년전에 리눅스 한번 설치해본" 사람이라는
둥 "위험한" 생각을 한다는 둥 황당한 소리를 하시니 당황스럽네요 ㅎㅎ
흐미 끝으로 한가지 지적하자면, 제가 살아오면서 "위험한 생각" 운운하는 것들 치고
제대로 된 인간들 못봤습니다. 파시스트들이 남 입막을 때 주로 쓰는 용어죠.
위험하긴 개뿔이 위험;;;
뚫린 입이라고 막 지껄이네요...나도 살아오면서 남들 쓰는걸 어린
뚫린 입이라고 막 지껄이네요...
나도 살아오면서 남들 쓰는걸 어린애들 수준이라느니 파시스트니 개뿔이니하면서
약올리는 사람치고 제대로 되쳐먹은 인간을 못봤네요.
이런말 들으니 기분좋아요?
흐미 받은 건 곱배기로 돌려주자는 주의라서 말이죠?엄한 소리로 입막으
흐미 받은 건 곱배기로 돌려주자는 주의라서 말이죠?
엄한 소리로 입막으려는 거에 비아냥 좀 했기로서니 어쩌라구?? ^^;;
상관말고 님이나 잘하시지.
역시 되먹지 않았어..
역시 되먹지 않았어..
그렇군요. 커널분석까지 하셨구... 할말 없습니다. 윈도에도 장점과 단점
그렇군요. 커널분석까지 하셨구... 할말 없습니다. 윈도에도 장점과 단점이 있고,
리넉에도 장점과 단점이 있죠. 문제는 장점만 내세우고 단점을 인정안한다는 거죠.
제가 윈도의 단점은 많이 들어봤지만 리넉의 단점은 거의 들어본적이 없어서요.
리넉이 윈도와 비교해서 단점이 될만한것을 알려주시면 안되겠습니까?
그렇게 해야 개선을 하죠. 윈도를 능가할려면 말이죠.
커널은 가끔 그때그때 필요한 부분부분만 구경이나 하는거지 분석같은 건
커널은 가끔 그때그때 필요한 부분부분만 구경이나 하는거지 분석같은 건
할 실력도 없구요;
리눅스가 부족한 점을 대충 써보자면.. 어디까지나 실력이 일천한 자의
어리석은 소견일 뿐입니다만..
일단 리눅스의 스케일러빌리티가 떨어지는 점은 잘 알려져 있구요..제가
조금이나마 줏어들은 바 있는 쓰레드랑 I/O 모델에서 예를 들자면..현재는
전통적인 fork나 커널쓰레드 모델 정도가 지원되고 있는 반면에, 솔라리스나
NT에서는 유저쓰레드 모델, 이벤트드리븐 I/O 혹은 어싱크 I/O 모델등이
지원되죠. 저널링 파일시스템 이런 것도 관련이 있나본데 전 잘 모르구요..
뭐 그렇지만 이런 건 뭐 많은 사람들이,특히 IBM 같은 대기업에서도 개선에
참여하고 있으니(IBM NG-pthread나 SGI kaio같은거) 좋아지리라 보고요
그 외엔 소위 소프트웨어 산업의 미래라고 일컬어지는; 컴포넌트 기반이
넘 부족하지 않은가 하고 생각하고 있지요. 아직도 리눅스는 c가 가장 잘
어울리는 환경이니까요. 자바가 있다고는 해도 아직 자바 런타임이 썩 잘도는
건 아니구.. kde나 gnome은 아직 기본적인 데스크탑 컴포넌트 마련하는
단계인 것 같구..
모 제가 나름대로 중요하다고 생각하는 건 이정도인 듯.. 고수님들의 생각은
또 다르겠지만서도;
약간 정정.. 리눅스에서도 이벤트드리븐 I/O가 가능;scalibil
약간 정정.. 리눅스에서도 이벤트드리븐 I/O가 가능;
scalibility에 문제가 있긴 해도 select()와 poll()을 쓸 수 있음
/dev/poll은 지금 지원되는지 모르겠네요.. 최신 커널에서는 포함되었으려나?
궁금해서 그런데요...윈2000의 기술 중 '엄청난 기술'에 대한 자
궁금해서 그런데요...
윈2000의 기술 중 '엄청난 기술'에 대한 자세한 서술 부탁합니다..
님의 말에 딴지를 걸겠다는 게 아니라, 그냥 궁금해서요...
(저도 친 Linux 파이긴 하지만... MS가 기술력 갖고 있다는 점은 인정합니다..)
그리고, 또 궁금한 것은...
'과연 정말로 리눅스는 값싼 웹서버 이상의 가치는 없나' 라는 것입니다.
(최소한 저는 리눅스를 웹서버로 안 씁니다..)
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
흐미 윈2000의 기술 중 '엄청난 기술'에 대해선 쓴적이 없는데요;
흐미 윈2000의 기술 중 '엄청난 기술'에 대해선 쓴적이 없는데요;
제 개인적인 생각으로 윈도의 미덕은 특정한 하나의 '엄청난 기술'
같은거라기보단, 컴포넌트를 기반으로 한 잘 정리된 시스템이라고 보거든요
세세한 각론은 저도 제대로 아는 게 별로 없네요.. dshow정도나 조금 써봤을
뿐이라서 (흐미 허접한 실력)
흐미 그리고 리눅스가 값싼 웹서버 이상의 가치는 없나라는
질문은 제가 대답할 수 있는 것이 아닌 듯 하네요; 그거야
쓰는 사람 나름이죠. 다만 지금 리눅스의 성공은 다분히 값싼
웹서버로서의 성공일 뿐이라고 보기 때문에, 데스크탑이나
하이엔드로 성공하고자 한다면 M$ 윈도우가 후졌다느니 파란화면이
어쩌니 하는 시대착오적인 태도보다는, 적의 장점을 공부해서
내 것으로 흡수하려는 노력이 더 건설적이지 않나 하는 개인적인
생각을 쓴 것 뿐; 무무물론 제가 이런 말을 하든 안하든 어딘가에선
열심히 오늘도 공부와 해킹에 정진하는 분들이 계시겠지만서도;
멋진 분이군요^^얼핏 감정 싸움으로 치달을 수 있는 분위기를 잘
멋진 분이군요^^
얼핏 감정 싸움으로 치달을 수 있는 분위기를
잘 추스려 주셨네요.
님의 글에서 많은 것을 배웠습니다.
참고도서는 Inside Windows 2000 이며간단하게 말씀드
참고도서는 Inside Windows 2000 이며
간단하게 말씀드리자면 COM+ 입니다.
COM+가 2000에서만 돌아가니 그렇게 말해도 될려나? 분산객체가
COM+가 2000에서만 돌아가니 그렇게 말해도 될려나?
분산객체가 호환성이 없다고 운영체제에 포함되나??
또 자바도 코바도 다 가지고 있는 것 아닌가???
물론 각론에서 다른점은 있겠지만....
COM+ 가 좋다는 예기는 있지만 문제가 많다는 점도 인정을 해야 서로 얘기가 될터인데....
미구엘에 대해서 알고 싶군요.
미구엘에 대해서 알고 싶군요.
GNOME과 mono(GNU의 .Net 대체 프로젝트)를 주도하는 사람이
GNOME과 mono(GNU의 .Net 대체 프로젝트)를 주도하는 사람이지요
컴포넌트 기술을 리눅스에 도입하는 데 관심이 많은 사람인 듯 합니다.
KLDP에는 리눅서들이 자주오다보니 반 MS감정이 강하죠.물론 무조건
KLDP에는 리눅서들이 자주오다보니 반 MS감정이 강하죠.
물론 무조건 Free Software vs. MS 라는 구도로 몰아간 언론의 책임도 있지만...
정확히 말해서 .NET 이 싫은게 아니라 M$가 .net을 내세우는게 싫은게 아닐까요?
그 동안 M$가 이쁜짓을 한게 있어야 이쁘게 봐주겠죠.
대부분 리눅서들은 MS에서 무슨 새로운 기술 발표를 하면 이번엔 어느 회사 잡아먹으려고 저러나하고 색안경끼고 볼껄요. 이번에 .NET은 분명히 SUN잡아먹으려고 하는것 같군요. 리눅서들이 그러는 것은 MS의 너무 공격적인 마케팅에도 원인이 있습니다. 그리고 MS의 이런 태도가 리눅서들에게 손해를 끼치고 있습니다.
사실 MS 플랫폼만 쓰면 MS에서 뭔짓을 하든말든 별로 손해볼 일 없습니다. 돈내고 MS 플랫폼 사용하면되는거니까요.
하지만 리눅스는 MS에서 내세운 독자적 표준, 물흐리기, 경쟁사 죽이기 때문에 많은 손해를 보고 있습니다. 이미 MS 독점적 미디어 포맷, 독점 프로토콜로 많이 손해를 보고 있죠. IE가 대세가 되면서 웹서핑조차 마음대로 못하고 있습니다. 웹서핑할 때마다 엑티브엑스니, ASF니 독점적 포맷과 태그, 기술로 도배된 사이트땜에 골치가 아픈 경우가 많습니다. 처음에는 이렇지 않았거든요.
MS에서 자사 플랫폼이 아니면 벼랑으로 몰아버리는 정책이 있는한 뭔짓을 해도 이쁘게 보이지 않을껍니다. MS 자신이 모두를 적으로 만들고 있습니다.
경쟁사 모두 죽이고 뭐할껀지는 여태해온 짓거리보면 뻔히 보입니다.
솔직히 제 개인 의견 말하라면 M$가 내세우는 모든것이 싫습니다.
오늘은 무슨 기술을 어떤 업체를 망하게 할껀지... 오죽하면 MS와 경쟁하지 말라는 이야기가 나옵니까? 지금 당장 좋다고 넙죽넙죽쓰다보면 결국엔 모두 사라져버릴겁니다.
그렇습니다. 여기는 토론장이지 스트레스 푸는곳이 아니란 말입니다.C#
그렇습니다. 여기는 토론장이지 스트레스 푸는곳이 아니란 말입니다.
C#도 모르면서 JAVA와 같다고 주장하니...
진정한 리눅서라면
MS를 욕하지 않고 리눅스가 좋다하고 리눅스에 대한 비판도 받아들일줄 압니다.
정말 확실하지 않게 알면서 큰소리치는 것은 안 좋다고 봅니다.
질문 하나~~"그리고 도대체 무슨 근거로 C#이 Java의 클론이
질문 하나~~
"그리고 도대체 무슨 근거로 C#이 Java의 클론이란거죠?
참 나원... delegate+event 모델, get-set 메서드를 알기나
하는건지. "
이런 말을 했는데요???
이것의 의미는 이점이 C#이 우수 하다는건지???
아니면 java의 이런것도모르는사람들이
C#에 대해 말하는것이 싫은 건지???좀 궁궁해져서요???
아님 자바에도 이런거 있는데 설마
c#에만 있는줄 알고 쓰신건지???
이 말의 의도가 이해가 않되는군요
자바에 없어요...
자바에 없어요...
저는 c# 세미나에 갔었는데요..거기서 java 를 낮추며.. c#에
저는 c# 세미나에 갔었는데요..
거기서 java 를 낮추며.. c#에는 java 에 없는 기능이 많다고 하더군요
그런데.. java 제작자 들이 그걸 몰라서 못만들은건지 의심되더군요..
그게 꼭 필요한지??
몰라서 못만든것도 있고, 알면서도 못만든것이 있습니다.자바와 C#은
몰라서 못만든것도 있고, 알면서도 못만든것이 있습니다.
자바와 C#은 5년의 차이가 있습니다. 적어도 자바에서 언어적 단점은 보완을 했을것입니다.
문제는 .NET의 최적화이겠죠.
자바는 만들어질때부터 간단함을 모토로 했거든요. 요즘들어서 복잡해지지만...
자바도 만들어질때 C++ 깎아 내리지 않았잖습니까?
분명 자바와 C++은 개념이 다른데도 불구하고 C++과 비교하는 JAVA는 무슨 의미인지?
실제로 자바초기에 책을 보면 C++과 비교를 하였습니다.
그 당시에 MS는 주력언어가 C++이었으며 JAVA와 비교되니까 전전긍긍했었죠.
결국 C#과 .NET 이 두가지로 JAVA와 대결을 벌일려고 하는것입니다.
상당수의 리눅서들이 'MS 욕하는걸로 리눅서임을 자위하는 사람들' 이기도
상당수의 리눅서들이 'MS 욕하는걸로 리눅서임을 자위하는 사람들' 이기도 하지만
또한 많은 사람들이 '자기는 무조건 남들보다 잘났다고 생각하는 사람들' 이기도 합니다.
이 사람들이라면 대부분 몇몇 영단어를 나열하면서 자기의 지식이 높다고 시위하고 , 토론이란 자기가 옳음을 주지시키는 일이라 생각하고 , 남들은 모두 아무것도 모른채 잘난체만 하는 삼류들 이라고 생각 한다는 거지요..
은근히 비꼬는 말투와 도발적인 어휘선택 .. 뭐 님과 같은 사람들도 꽤 됩니다.
읽어보니... '역시 KLDP다'라는 말은 무슨뜻인가요? 이곳을 이용하는
읽어보니... '역시 KLDP다'라는 말은 무슨뜻인가요? 이곳을 이용하는 모든 리눅서들에게 하는 말인듯하군요. "...라는 도발적 제목"이라는 둥, "애매모호한 한계레 신문기사"라는둥... 그런 평가는 어디서 하는겁니까? 이곳도 엄연히 사람들이 모이는 곳이고, 잇슈가 되고 있는 주제에 대해 여러의견이 나올 수 있다고 생각합니다. 그냥, 다른 커뮤니티의 그것과 성격이 비슷하다고 보면 될터인데... 얼마나 객관적인 판단을 가지고 하는 말인지는 모르겠으나...
세상을 넓게 보세요. 님 주변에 계신 리눅서들만 보지 마시고. 님이야 말로, M$ 욕하는 리눅서를 보면서 "적어도 난 그렇지 않아."라고 스스로 자위하는 건 아닌지...
MS와, SUN, 둘중 하나 택하라면 전 차라리 MS를 택하겠습니다.
MS와, SUN, 둘중 하나 택하라면 전 차라리 MS를 택하겠습니다.
SUN을 좋게 볼 이유가, 도대체 뭐가 있단 말입니까 ?
--------
제가 MS 사장이면 당연, java 안쓰죠.
- 2000만달러 줘서 기분나쁘고,
- 최신 버젼 jvm을 쓸 수도 없고,
- 사용자 90%가 Windows 쓰는 마당에,
몇년 노력하면(?) 자바 죽일수 있을 것 같은데, 뭣하러
java 씁니까.
-----------
치사한 짓이다, 독점이다,... 뭐 그렇게 말할 수도 있겠죠.
기분나쁜건, SUN도 똑같은 놈들인데 왜 모든 욕이 MS쪽에 쏟아지냐는 겁니다.
전 M$와 $un 둘중 하나 택하라면 $un을 택하겠습니다.$un은
전 M$와 $un 둘중 하나 택하라면 $un을 택하겠습니다.
$un은 M$보단 독점력이 약하죠. 기껏해야 솔라리스랑 스팍 팔아먹는 신세
반면 M$는 손에 닿는 것 모두를 말라 비틀어지게 하고 있습니다.
넷스케이프(작전종료), 볼랜드(작전종료), 리얼(거의 완료), 팜(진행중), 자바(진행중),
기타 윈집 pc애니웨어등 자잘한 것들
사실, 우리나라에서만 봐도 이미 M$의 독점의 폐해가 서서히 현실로 드러나고
있지 않은가요? 예전에 용산업체들과의 마찰, 얼마전 불법단속기간동안의
가격상승 및 협박포스터 발송등의 비도덕적인 작태, 대학들과의 약속위반사건,
XP 인증관련 마찰음 기타등등.
SUN은 적어도 M$처럼 경쟁업체를 고사시키는 일을 한 적이 없습니다.
SUN은 적어도 M$처럼 경쟁업체를 고사시키는 일을 한 적이 없습니다. 어쩜 그 정도 수준의 힘이 없는지도요... 썬을 대변하고 싶기보다.. M$ 욕하면.. 광팬들은 이렇게 대드네요. "쓰파야.. 왜 우리만 가지고 그래?!"
잘 보시지요...
노벨 OS 호환성 결여시키기. IBM과 OS/2 공동개발하다 Windows95 만들어 왕따시키기. MAC UI빼끼구.. 저작권문제로 뒷거래해서 Office 이식시켜나 주기. Win95 OSR2에 리얼 플레이어 탑재하여 기술 싹 빼먹고 에러나게 만들기 (리얼에서 법정까지 갔지요) SGI와 협정맺고 파렌하이트 개발한답시고.. OpenGL기술 빼끼다가.. 리눅스지원 못한다고 깬 거.. (지금 DX 8.0 기술력이 다 그거죠) Netscape 작살내기 위하여 기본모듈 부팅부터 호출하기, 자바스크립트 변형해서 ECMA에 제출해 놓고, 그네들은 안 지키기. ASP만들어 절대 기술오픈 안하기... (서버사이드에서 자바가 득세하여 JSP사이트가 많아진게 다행입니다) 각 OS별로 호환성 없도록 만들어서 강제로 업글시키도록 하기. 자바VM 변형시켜 자바호환성을 저해하기. 쓸데없는 기능이나 넣고.. 매번 이젠 Office 업글 안하면 읽히지도 않도록 만들기. 한글코드를 마음대로 만들고, 배열하기. MPEG4 표준도 정해지기 전에 자기네들 마음대로 MPG4라고 떠들고 다녀서 MPEG 회의에서 퀵타임이 Mpeg4로 정해지도록 일조하기(^^). 음질도 안 좋은 WMA지원토록 MP3 돈 주고 쓰도록 만들기. 주변회사 협박하기. 한국벤처 도둑놈으로 몰기...
숨차네요. ^^ 더 뭘 말할까요.. 욕하면 입 아프지..
누가 나에게 2000만불 투자하면 넉넉잡고 5년안에 C@을 만들어서 언어
누가 나에게 2000만불 투자하면 넉넉잡고 5년안에 C@을 만들어서 언어 천하를 통일시키겠습니다.
관심있는 분 이메일로 연락바람.
그동안 너무 힘들었죠?
C, C++, JAVA, 그리고 파이썬, C# 까지 멍청한 사람들은 특성에 따라 사용해야 한다고 하지만 저같은 유일무이한 천재에겐 이런 것들이 다 필요없어요 .
그냥 만능언어를 만들어 쓸까합니다.
왜 5년이냐구요.
제가 이제 3학년 올라가는 늙은 학생이걸랑요.
병신같은 인간들이 만든 언어에 골머리 썩히지 말고 저한테 투자하세요.
혹시 당신.. '초천재'?-.-;;뭐 언어든 뭐든간에 기술이
혹시 당신.. '초천재'?
-.-;;
뭐 언어든 뭐든간에 기술이 좋다고 천하통일할 수 있는 건 아니죠..
시장지배력과 시운이 따라주지 않으면 아무리 좋은 기술도 말짱 황..
NeXT, objective C, newton, OS/2, etc,.
만능언어라... PL/I 가 생각나네요...은행다니는 제 동기는
만능언어라... PL/I 가 생각나네요...
은행다니는 제 동기는 저걸로 프로그램 만들고 있다는... -.-
쓸데없는 예긴 올리지 맙시다.. -_-;;
쓸데없는 예긴 올리지 맙시다.. -_-;;
대학원 3년차라는 말씀이신가요?만약 대학 3학년이면 늙은 학생이라
대학원 3년차라는 말씀이신가요?
만약 대학 3학년이면 늙은 학생이라구요?
시작이 아닌가요...
약간은 분위기를 쇄신하자고 하는 의미에서 올리신 글 같지만,
약간 반발심이 들어서요.
ps. 저기.. os 만들어 보셨나요?
우리도 하나 만들자이름은 C@ [시엣]
우리도 하나 만들자
이름은 C@ [시엣]
옳소! 우리도 함 만들어 봅시다. 일본에는 Ruby가 있는데 우리도 하나
옳소! 우리도 함 만들어 봅시다. 일본에는 Ruby가 있는데 우리도 하나 쯤 만들수 있는 거 아니겠습니까?
C@ <-- 근데 이건 좀 이름이 그렇다. 발음도 별로 폼 안나구... 차라리 D 를 만듭시다. 우헤헤ㅎ
저 언어 하나 만들겁니다8.1 부터 프로젝트 시작하는디.. 넘 구린거
저 언어 하나 만들겁니다
8.1 부터 프로젝트 시작하는디.. 넘 구린거라 :>
왜 난리지??지금 클라이언트에서 자바 어플리케이션 쓰는 거 있는사
왜 난리지??
지금 클라이언트에서 자바 어플리케이션 쓰는 거 있는사람??
웹에서 자바 애플릿 쓰는 페이지는 얼마나 있죠??
별거 아닌거가꾸 그러시네..
어차피 자바는 지금 서버와 임베디드용 플랫폼입니다.
오히려 비표준 JVM이 제거되서 나온다니 환영할 일 아닌가요?
비표준 JVM이 디폴트로 있으면 오히려 어플리케이션 개발자들에게 족쇠를 다는 겁니다. 기능도 다 지원 안되는 녀석이 전 세계 90%의 데스크탑에 깔려있는데 이걸 무시하고 개발하실겁니까?
무시한다면 있으나 없으나 상관 없을테고...
그렇지 않다면 언제까지나 절름발이 1.1.x대의 자바 API만 가지고 프로그램을 짜시겠습니까?
완벽히 지원 못해줄 바에야 아애 사라져서 적어도 방해는 되지 않겠다니 전 오히려 다행이라 생각되네요.
이버전 저버전에서 테스트해보는 것이 얼마나 사람 미치게 하는 일인지 경험해본 사람들은 잘 알겠죠. 표준을 지향한다고 외치는 다른 VM 들끼리도 막상 붙여보면 서로 딴판으로 노는데 대놓고 난 안해 하는 넘까지 있음 돌아버립니다.
전혀 다르지만 같은 맥락이라고 저에게는 인식되는 것이 있습니다. 다름
전혀 다르지만 같은 맥락이라고 저에게는 인식되는 것이 있습니다.
다름아닌 인텔의 이타니엄의 출시 입니다.
지금까지 INTEL(mpu)+IBM(pc)+MS(os)의 조직이
저가격 고사양을 무기로 기존의 업체들을 밀어 붙여왔습니다.
이 과정에 아범이 제일 먼저 호환업체 때문에 힘겨워 졌고,
그 뒤로 남은 두회사의 관계는 계속되 왔지요.
그러나 팬티엄 계열에서 부터 두드러지기 시작한 인텔의 흡수 능력이,
이타니엄에 이르러 서는 엄청날 것으로 예측됩니다.
즉 이미 HP는 자신의 PA-Risc를 인텔과 이타니엄이라는 이름으로 공동 개발하였습니다.
아이비엠도 자신의 칩들이 있지만, 이타니엄도 사용할 것이 분명합니다.
컴팩은 인텔에 DEC으로 부터 인수한 알파칩을 넘겼으니 이제 이타니엄을 쓰겠지요.
나머지 칩 메이커들도 있지만 이 외에는 시장에서 별로 이니,
이제 선의 스팍만이 남습니다. 하지만 선은 솔라리스 인텔을 만들고 있습니다.
그럼 운영체제는 이 상황에서 어떻게 될까요.
리눅스야 이미 이식이 된 상태고, 솔라리스 인텔도 있고,
윈도우즈계열도 있고, 아범의 AIX도, HP-UX도, True64
전부 이식되지 않을까요??
그러면 괜찮은 메이커의 괜찮은 기계들의 가격이 많이 떨어지겠지요. 서로간의 호환성도 있겠지요.
결국 .NET JAVA 모두 자기 영역을 구축하면서 당분간 살아
갈 것이고,
문제는 MS의 PC에서의 능력이 이 상황에서도 소비자들에게
계속 선택을 받을 수 있는 가 일 텐데...
사실 자바는 선이 독점하고 있다는 문제가 걸림돌이니
역으로 선이 없어도 생존할 수 있습니다.
그러나 .NET은 지금으로서는 MS가 없다면 공중분해 되겠지요.
MS는 윈도우즈와 오피스에 그 생존이 걸려있으니 .NET은
서버를 지향하지만 클라이언트에 그 생존권이 있는 것입니다.
IT에서의 예측은 불가능 하지만 자바의 승리에 손들고 있습니다.
선이 없어도 자바가 생존할수 있겠죠. 하지만 .NET이 MS가 없다고 해
선이 없어도 자바가 생존할수 있겠죠. 하지만 .NET이 MS가 없다고 해서 공중분해 되지는 않을것입니다. MS도 그것을 알고 풀지 않았을까요? 클라이언트에 윈도, 오피스 안쓴다고 닷넷이 필요없지는 않습니다. 서버와 클라이언트는 별개이기 때문이죠. 그리고 자바의 승리는 그렇게 가능성이 있지 않습니다. 주변환경이 SUN에게 유리할지 몰라도 JAVA 자체의 성능은 향상이 더딥니다. JDK 1.4도 그렇게 기대에 미치지는 못하구요. 주어진 환경보다는 그 제품 자체가 더중요한것입니다. 그 뒤로는 사용자와 개발자가 얼마나 이용하느냐에 달려있구요.
SUN은 솔라리스와 자바로 살아남고 있습니다.MS는 윈도우즈와 오피스
SUN은 솔라리스와 자바로 살아남고 있습니다.
MS는 윈도우즈와 오피스로 생존하고 있구요.
SUN이 사라져도 자바는 남을 것 같습니다.
MS가 사라지면 .NET은 없어질 것 같구요.
"클라이언트에 윈도, 오피스 안쓴다고 닷넷이 필요없지는 않습니다"
그런 의미가 아니구요. 더불어 그렇다면 .NET이 나오자 마자 기존의 개발
환경을 속도,안정성,호환성,편리성 등등에서 완벽히 능가할 수 있을까요?
어차피 사람이 하는 일이라면 그럴 수는 없지요.
참고로 저는 윗 글을 쓴 사람이고, SUN 이나 MS 라는 것에는 그리 민감하지 않습니다.
단지 SUN의 솔라리스(x86)과 자바를 좋아하고, MS의 브라우저와 오피스를 좋아합니다.
C#이 뜨면 어떻습니까?저는 자바를 상당히 좋아합니다만, 자바가
C#이 뜨면 어떻습니까?
저는 자바를 상당히 좋아합니다만, 자바가
클라이언트쪽에서 약한 것은 사실입니다.
그렇다면 자바. 서버쪽에서 멋지게 활용하면 그만입니다.
클라이언트쪽 엑티브X 를 이용하던지 C#을 이용하던지
상관없습니다.
그리고 .NET ? 자바가 없어져도 상관없습니다.
자신이 어떤 프로그래머냐가 문제겠지요.
전 프로그래머는 프로그래밍 언어 독립적이어야
된다고 생각합니다.
어떤 플레폼이든지 간에. 그냥 사용해주면 될듯합니다.
예전에 윈도 nt 4.0 나왔을때 유닉스 다 사라진다고
했습니다.
그런데 지금은 어떻습니까?
Netscape 는 응용프로그램일 뿐입니다. ms 가 윈도에
탑제를 하지 않음으로써 망하게 했다.
그럴수도 있겠지요. 자바는 언어입니다. 그리고
자바는 윈도에서 클라이언트로만 돌아가는 언어가 아닙니다.
자바는 윈도 xp 가 자바를 제거함으로해서 가장 알맞게
동작할 수 있는 부분(지금은 서버쪽일듯 합니다. )에서
본격적인 경쟁체계로 들어갈 것입니다.
여하튼 중요한 것은 이러든 저러든 어떤 프로그래머냐에
따라서 상관있을수도 있고 없을 수도 있습니다.
무조건 MS를 싫어하지만 않는다면.새롭게 공부할 수 있는
녀석을 제공해서 기쁘군요 ^^ 하하
질문 한가지가 있는데요.자바의 버전이 올라갈수록 자바의 성능이 좋와
질문 한가지가 있는데요.
자바의 버전이 올라갈수록 자바의 성능이 좋와 지는건 이해가 가는데요.
그럼 버전이 올라감에따라 문법적인 측면에서 추가할만한 사항을 할수는 없는건가요?
C#이 처음 공개 되었을때 template의 지원, struct 사용가능 등이 부럽고
지금도 Java에서 이걸 삭제하지 않고 사용하지 않기를 권장하는 정도였으면..
하는 생각이거든요.
즉 질문이, 버전이 올라감에따라 문법적인 측면에서 추가할만한 사항을 할수는 없는건가요?
입니다. JDK 1.4이야기가 나와서, 궁금해서.
제가 알기로도 선이 JVM에 대해 문제 제기할때 엔진을 없애기로
제가 알기로도 선이 JVM에 대해 문제 제기할때
엔진을 없애기로 한걸로 아는데.
MS는 SM 처럼 그냥 뭔짓을 하던 욕먹을 뿐이져.
어짜피 이제 자바는 망한거같은데.
^0^
P.S : sun은 자바 엔진을 공개했어야 했습니다.
"sun은 자바 엔진을 공개했어야 했습니다." 무슨 말씀이신지..
"sun은 자바 엔진을 공개했어야 했습니다."
무슨 말씀이신지..
라이센스를 잘못 말씀하신거 아니에요?
라이센스가 아니고, JAVA의 설계를 선이 독점한다는 뜻입니다.MS가
라이센스가 아니고, JAVA의 설계를 선이 독점한다는 뜻입니다.
MS가 윈도에 맞게 VM을 수정하여서 소송당하였다는 것도 그런 이유에서죠.
설계를 독점한다는게 무슨 뜻이죠?제가 알기론 jvm 스펙과 소스를 이
설계를 독점한다는게 무슨 뜻이죠?
제가 알기론 jvm 스펙과 소스를 이용해서 완전히 재구현 하거나 포팅하는게 가능한걸로 아는데. 라이선스가 문제면 문제지 설계독점이라니?
그리고 MS는 윈도에 맞게 VM을 수정한게 아니고 vm 스펙을 어기고 자기들만의 interface를 추가해서 windows에서 바이너리 형태로 access를 가능하게 만든게 문제아니었나요?
님이 라이선스 문제가 아닌 그런 문제로 썬을 비난한다면 리눅스의 설계를 독점하고 인터페이스에 조금만 변경을 가하려고 해도 커널에서 빼버리는 토르발즈도 비난당해야 겠군요.
헉.. 내용은 달라도 제가 가진 생각이랑은 같네요. --;제가 용어
헉.. 내용은 달라도 제가 가진 생각이랑은 같네요. --;
제가 용어 이해의 부족으로, 죄송합니다.
// 어디서 퍼온지는 모르지만...일단 이번의 Java중단 조
// 어디서 퍼온지는 모르지만...
일단 이번의 Java중단 조치는 Sun의 요구에 의해서 입니다.
즉 Pure Java가 아닌 MS 나름대로의 Java는 폐기해야한다는
소송에 의해서 그동안 MS는 후속 Java 지원을 안하므로써
이 판결을 지켰고 (MS JVM이 아마도 윈도 98 버전 이후로
업그레이드 한번도 안 됐을겁니다.)
이번엔 아예 XP에서 빼버린 겁니다.
즉... Sun이 제 무덤을 판다고 밖에.. 물론 표준 기술을
지키지 않은 MS를 탓할수도 있겠지만. 당시에 내 놓은 Java
기술이 제 개인적으론 Sun보다 MS의 것이 좀더 구현성이
높고, 좀더 체계적이었다고 생각됩니다. 문제는 윈도즈에서만
돈다는 것이 문제였지요.
어쨌든 현재로선 MS는 자바가 필요가 없어졌습니다. 물론
JScript는 사용하겠지만.(이걸 자바로 봐야 하는건지..)
C#이 돌아가는 .NET이 나온 이상... 필요성을 못 느낄지도.
C#이 자바를 모방했다고 비난을 한다고 해도, 결국 Java도
C++을 모방한게 아니던가?
어쨌든 Sun은 좀더 제대로 된 Java 구현을 해내지 않으면..
쯔쯔~
썬의 JVM도 쏠라리스버전이 제일 안정성이나 성능면에서 좋다고 하죠.
썬의 JVM도 쏠라리스버전이 제일 안정성이나 성능면에서 좋다고 하죠.
자신의 OS에 더 잘 동작하도록 한것은 아마도 상업적인 측면이 있을 겁니다.
java의 c++모방은 다분히 문법스타일의 문제아닐까요.실제 프로그램 돌아가는건 개념상
완전히 다른내용이죠.
하지만 C#은 어떤가요? 프로그램 시작에서 끝까지 자바와 다른 것이 무엇인지...
VM에서동작해도 C#코드가 훨씬 빠르다는 유치한 거 말구요.
C#의 JAVA모방은 다분히 문법스타일의 문제아닐까요.실제 프로그램 돌아
C#의 JAVA모방은 다분히 문법스타일의 문제아닐까요.실제 프로그램 돌아가는건 개념상
완전히 다른내용이죠.
님은 JAVA와 C#의 언어부분만 보고 그렇게 판단하셨을것인데...
java는 플랫폼과 언어를 동시에 포함하고 있죠.
SUN에서도 그 두가지를 인정해야 한다고 하죠.
MS는 java의 언어부분만 인정했고, 그래서 VM을 고친거구...
SUN에서 그것을 보고 소송건구요.
여기서 VM부분은 현재 .NET Framework이고
언어부분은 C#이죠.
VM에서 돌아가는것은 현재 JAVA뿐이죠. 다른언어도 있다고 하지만 아직...
실행시 VM을 뛰워야하고 중간코드(바이트코드, MSIL)를 런타임에 해석
실행시 VM을 뛰워야하고 중간코드(바이트코드, MSIL)를 런타임에 해석하고
레퍼런스가 끊어진부분은 가비지컬렉터가 실행되고 언어자체에 쓰레드를 지원하고
이런게 단순히 문법스타일의 문제인가요. 돌아가는게 전혀 다른건가요?
java언어부분을 인정해서 VM을 고쳤다 이건 무슨말인지요.
VM을 고친건 윈도우즈가 아닌OS에서도 그대로 동작해 기반을 희석시키는 것에대한
방어적 차원에서 한것이 아니었나요?
특정 실행환경에 동작하는 언어가 오직한가지라는게 특별히 문제될게 있을까요?
오직 그 환경에 최적인 언어가 어떤것이냐가 관심 아닌가요?
.netFramework에 최적인 C#말고 VC나 VB가 어느정도 영향을 미칠지는 모르는 일이죠.
VM, 가비지 컬렉터, 그런 것들이 java 가 나오면서 생긴 것이냐면,
VM, 가비지 컬렉터, 그런 것들이 java 가 나오면서 생긴 것이냐면, 그렇지 않습니다.
가비지 컬렉터는 60년대(70년대?) lisp 때부터 있었습니다.
thread 지원은 c 든 vb든 뭐든 지원하게 되어있습니다. 그건 언어와는 상관 없는 것입니다. 이또한 몇십년 전부터 있었던 것이고요.
어떤 언어든, 전에 나온 기술에 기반해서 발전하게 됩니다. java도, c#도 예외가 아닙니다.
c#이 java에서 나온 것 외에 특별한 것이 없다면, java clone이라 해도 되겠지만,
c#은 java 나온지 5년 후에 나온 언어입니다. 5년이 컴퓨터 쪽에선 매우 긴시간임을 아실 겁니다. 많은 내용이 추가되었다는 얘깁니다.
음, ... 그렇다고 제가 C#을 잘 아는 건 아닙니다. ^^; 다만 겉모양 만으로 c#을 java clone 쯤으로 여기는 것은 좋지 않다는 생각입니다.
흐미 한가지만 지적하자면쓰레드 지원은 c든 뭐든 지원하게 되어있다는
흐미 한가지만 지적하자면
쓰레드 지원은 c든 뭐든 지원하게 되어있다는 말씀이 좀;;
c나 c++에선 언어차원에서 쓰레드를 지원하지 않아서 별도 라이브러리를
통해 사용했어야 하는 반면에 자바에선 언어차원에서 지원하고 있다는게
요점입니다.
아 물론.. 자바 이전에도 gc를 지원하던 lisp도 있고, 자바 이전에도
쓰레드를 지원하던 Ada가 있고.. 자바 이전에도 제대로된 OOP를 구사하는
스몰톡이 있었고... 뭐 어쩌고 저쩌고 그렇습니다만 그 중 어느것도 자바만큼
그런 훌륭한 개념들을 범용언어로서 일반화하는데는 성공하질 못했죠.
C#은 그런 자바의 성공을 그대로 가져다 썼을 뿐입니다. 자바보다 5년씩이나
지나서 나왔는데도 불구하고, 프로그래머의 편의를 위한 세세한 개선점들
외엔 그다지 혁신적이라거나 실험적인 개념을 구체화해냈다던가 하진 못했죠.
그런 의미에서 클론이라 불릴만 합니다.
뭐, 클론 그 자체가 나쁜건 아닙니다만..
언어가 오직한가지라는것은 좀 문제가 될수 있다고 봅니다.MS는 언어와
언어가 오직한가지라는것은 좀 문제가 될수 있다고 봅니다.
MS는 언어와 플랫폼의 분리를 강조하고 있습니다.
C#은 JAVA언어의 단점을 개선했다고 본다면
.NET은 VM의 단점을 개선했다고 볼수 있죠.
더 중요한것은 어느 언어나 똑같은 MSIL이 생성된다는 거죠.
즉 프로그래머들은 자신에게 익숙하고 편리한 언어로 작성할수 있다는것입니다.
이것은 생산성과 관련있는 문제이며 특정한 언어를 배우기 위한 비용을 줄일수 있다는 것도 됩니다.
기존의 다른언어로 작성된 어플리케이션들이 .NET으로 포팅이 될수 있다는 것이고, 처음 작성하는 사람들은 C#이 더 좋은 언어가 될수 있다는 뜻입니다.
즉 MS는 JAVA의 언어와 플랫폼 이 두가지를 C#과 .NET으로 공격한다고 봅니다.
만약 .NET에서 JAVA마저 지원할지는 모르겠지만 말입니다...
헌데 말입니다. 자바 역시 마찬가지입니다..class 화일만 만들어지
헌데 말입니다. 자바 역시 마찬가지입니다.
.class 화일만 만들어지면 어떠한 언어로 해도 상관이 없습니다.
저번에 얼핏 보니 이것과 관련된 프로젝트도 있는것 같고.. JVM의 어셈블리와 비슷한
언어도 하나 있는걸로알고 있는데여...
단지 다른 언어를 쓸 필요를 전혀 못 느끼기 때문이지요.. 뭐..
현재 재 생각은 그 멀티 언어에 대한것에 회의적입니다..NET환경
현재 재 생각은 그 멀티 언어에 대한것에 회의적입니다.
.NET환경에서의 멀티 언어라는게 CLS(Common Language Specification)
을 만족하는 거라는 전제이고, 그중 가장 잘 만족하는것이 C#입니다.
만족 시킬려면 다른 언어들에 칼질을 해야 합니다. 그래서 VB.NET이
VB의 탈을 쓴 C#이라고 불리죠.
데브피아에서도 이것 때문에 논쟁을 했었는데, 실제품이 나오고
저는 1년후~2년후 시점에서는 C#과 VB.NET외에는 전부 안쓰일꺼라고
확신 합니다. 안그런 분도 계셨지만..
현재 .NET에는 20종가량의 언어를 쓸수 있다고 합니다.
하지만 전시적인 면이라고 생각되고, (MS를 스폰서로 시험적인 작품
혹은 C#보다 더 좋은 면이 보이는 언어가 나올까 하는..)
또 한가지는.
그렇죠. 전시적인 면이 좀 있죠. ASP에서도 펄스크립트를 쓸수 있다고
그렇죠. 전시적인 면이 좀 있죠. ASP에서도 펄스크립트를 쓸수 있다고 들었는데 MS가 아닌 다른 회사에서 만들것을 쓴다는 군요. 즉 얼마나 다른회사들이 받쳐주느냐에 달려있는데 여담입니다만 볼랜드에서 C#컴파일러가 왜 안나오는지... 델파이때문인가? 이런 의문이 드는군요. 하지만 C#과 VB.NET이외의 언어들이 안쓰이지는 않습니다. 절대로. .NET은 분산컴퓨팅환경이지, 스탠드얼론환경이 아니기 때문입니다. VC++이 유일하게 네이티브 환경을 지원하고 서버환경에서는 ATL로 프로그래밍 할수 있습니다. 그리고 C#보다 좋은 언어가 나온다면 좋죠. 그리고 VB는 MS가 만든언어이기 때문에 MS맘대로 칼질하는것이죠. 그럼 질문인데 파스칼(델파이)은 볼랜드가 만들었을까요? 결론은 MS는 환경만 구축해놓고 있다는 것입니다. 필요하면 다른 언어써도 되는거죠. 현재 FreeBSD용 C#컴파일러가 개발된다는데 이렇게 된것이 좋은 현상이죠.
Java가 C++을 모방했다...다시한번 보시죠.다른걸요
Java가 C++을 모방했다...
다시한번 보시죠.
다른걸요 --;;
뭘보고 모방했다고 하시는건지 쩝...
문법? 그거야 비슷한언어 천지죠 --;;
그리고, SwingSet을 사용한 Applet을 위해선 어차피 JVM을 다시 깔아야하죠.
이건 해당사이트에서 재배포하고있구요 --;
MS는 필요없지만, 이번결정으로 바뀐것은 없다고 봅니다.
그리고 자바 훌륭하지 않나요? 그정도면.
느린속도야 1.4에서 HW Accel 지원한다구 했으니 GUI는 어느정도 해결될거궁...
쓰읍...
Let's be engineers!
음...제가 알기론 JAVA는 C++을 기본 모델로 만들어 진걸로
음...
제가 알기론 JAVA는 C++을 기본 모델로 만들어 진걸로 알고 있습니다.
그리고 이 걸 개발한 개발자들도 C++프로그래머들이고(C++만 하는 건 아니겠지만)...
그리고 C++을 모델로 만들고 고칠건 고치다 보니깐 JAVA가 나온겁니다.
그리고 자바는 일반 Application이나 Web Application용이 아니라 Embeded Language를 목적으로 만든것입니다.
그리고 현재 자바가 사용되고 있는 이들에서 제대로 작동을 하고 최고의 포퍼먼스르르 낸다는건 "소가 뒷걸으미 치다가 개구리를 잡은격"이 되겠지요...
그리고 이만큼의 포퍼먼스도 나오진 않지만...
저는 요즈음의 JAVA의 행보에 환영의 뜻을 표했었는데...
다시 JDK1.4를 냈다는건 C#과 경쟁에 들어 가겠다는 야무진 꿈에 사로 잡힌것 같네요...
(언젠간 또 울면서 꼬리를 내리겠지만...)
이럴 여유가 있음...
앞으로의 핵심 기술이 될 Embedding시장을 더 공략하고 인재를 양성하고 기술을 더 발전 시키는게 긴 안목으로 나을거 같은데(물론 지건 저의 개인적인 생각이고 SUN에선 저보다 더 나은 생각을 가지고 있겠지만...)...
앞으로는 집안의 모든 가전 기기에 OS가 들어가게 될것입니다(지금도 이런 경향이 없잖아 보이고 있습니다).
이 미래 지향적인 시장을 노리는게 옳지 않은지?
여하튼 요즘의 자바의 행보에 심히 실망감을 감출 수가 없네요...-,-
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!
과학사를 뒤져보면 인류사를 뒤흔들은 소 뒷걸음질은 얼마든지 있습니다. 플
과학사를 뒤져보면 인류사를 뒤흔들은 소 뒷걸음질은 얼마든지 있습니다. 플랫폼 독립적이고 자원관리가 쉬운 vm모델이 embedded용으로 만들어 졌지만 써보니 서버용으 좋으면 서버용으로 확장해서 쓰면 그만 아닌가요. 초기목적에 모든 발견과 발명의 용도가 한정되야한다는 건 도대체 무슨 근거인가요.
그리고 제가 님의 글에서 받은 인상으론 서버플랫폼에서 엔터프라이즈 솔루션으로서 자바를 사용해보시거나 고려해 보신 경험이 없으신 것 같은데 너무 쉽게 서버자바의 퍼포먼스를 논하시네요. 퍼포먼스 얘기는 나왔다하면 개싸움이 되버리는 민감한 주제니까 정확한 근거를 제시할 수 없다면 시작하지 않는 편이 낳겠네요.
그리고 자바가 C++을 모델로 만들어 졌다는게 정확히 어떤 의미인지 감이 오지는 않지만 매우 큰 오해의 소지가 있는 생각입니다. 자바는 C++과는 문법적 유사성외에는 설계철학부터 OOP의 구현방법까지 별로 공통되는게 없습니다. "C++을 모델로 만들고 고칠건 고치다 보니깐"은 좀 황당한 주장이군요. 자바는 언어자체가 객체간의 관계로 설정되어 있는 반면, c++은 자바에 비하면 객체(전통 c의 객체가 아닌 oop의)를 사용하는 c에 가깝죠. 반면 언어가 제공하는 기능으로 보면 c++이 더 표준적인 oop이고, 자바는 다중 상속조차 콤포지션 따위로 해결해야 하는 한계가 있죠. 어찌보면 이 모두가 컴파일타임과 런타임이 기계적으로 분리된 컴파일 언어와 그렇지 못한 인터프리터어 사이의 설계차이 때문일 수도 있겠죠. 아무래도 다중상속이 걸린 객체의 레퍼런스는 인터프리트할려면 런타임에 부담도 되고.. 레퍼런스카운팅도 복잡해져 가베지 컬렉션도 어려워 지지 않을까요...^^;
하여간 자바는 처음 시작이야 어쨌든 c++과는 매우 다른 언어이자 플랫폼입니다.
끝으로 자바관련 새로운 스펙이 발표될때마다 전 썬에 있는 인터페이스 디자이너들에게 놀랍니다. 제 무지인지는 모르지만 이전에 이런식으로 철저하게 사전계획된 인터페이스에 의해서 개발이 진행된 플랫폼(서버든, 임베디드든)은 본 적이 없거든요. 물론 저도 자바라이선스에 대해서는 불만이 많지만 플랫폼으로서 자바가 취하고 있는 자세는 매우 고무적이며 시도해볼만한 것이라고 생각합니다.
자바의 퍼포먼스는 누구나 느끼는 겁니다.좋은 사양이면 뭐 상관없겠
자바의 퍼포먼스는 누구나 느끼는 겁니다.
좋은 사양이면 뭐 상관없겠죠. 낮은 사양에서 돌려보면 자바의 진가가 발휘됩니다. ^^;
"자바는 C++과는 문법적 유사성외에는 설계철학부터 OOP의 구현방법까지 별로 공통되는게 없습니다."
이건 입장 차이입니다. c++과 유사한 언어가, 그 수많은 언어중에서,... java, c# ,.... 그리고 또 뭐가 있습니까 ?
설계철학, OOP의 구현방법이 공통되지 않다고 하지만, 여전히 C++잘하는 사람은 java도 잘하게 마련입니다.
퍼포먼스를 매우 좁은 의미에서만 해석하면 그렇죠. 퍼포먼스 = 짧은 실행
퍼포먼스를 매우 좁은 의미에서만 해석하면 그렇죠. 퍼포먼스 = 짧은 실행시간(응답시간?) 인가요. 전 그렇게 생각하지는 않는데. 적절한 한도내의 평균응답시간만 보장된다면 퍼포먼스는 좀더 많은 것들을 포괄해야죠. 안정성도 빼놓을 수 없고, 구현도 용이해야하고 확장성도 빼먹을 수 없고 논문 쓸 생각이 아니라면 비용을 빼먹어서도 안되죠. 그렇게 볼때 서버플랫폼으로 자바보다 나은 솔루션은 현재는 없습니다.
앞으로도 저는 자바가 기계적인 실행시간을 줄이는 문제보다는 쓰레드간의 로드밸런싱같은 전반적인 성능향상을 통해 전체과제를 해결하는 포괄적 의미의 실행시간을 줄이는데 더 노력을 들여야 한다고 생각합니다.
그리고 자바는 제 경험으로는 프로그래밍 언어 자체에는 큰 지식을 필요로 하지 않습니다. 어처구니 없는 실수를 하지않는 한 메모리릭 같은 치명적인 문제도 생기지 않고. 언어 자체가 oop 설계툴 같은 역할을 하기도 해서 오히려 패턴같은 oop 기술에 능한 사람이 자바를 잘한다고 할 수 있죠. 반면 c++을 잘한다고 한다면 상당부분 c 코딩같은 전통적인 프로그래밍 기술에 능해야만 하죠. 그리고 흔히들 그것만 잘하는 사람들이 c++을 잘한다고 불리기도 하더군요.
따라서 oop를 잘하는 사람이면 자바를 잘한다는 건 맞습니다만 보통 c++을 잘한다고 불리는 사람이 자바를 잘한다는 건 언어도단이라고 생각합니다. 아, 잠깐 근데 oop를 잘하는 사람이라고 c++을 잘할 수 있을까요? 값비싼 개발력을 테크니컬한 문제가 아니라 엔지니어링의 영역으로 집중시켜주는 이런 능력을 퍼포먼스라고 생각해보신적은 없나?
- "짧은 응답시간" 이 퍼포먼스가 아니면 뭐가 퍼포먼스입니까. 모든건
- "짧은 응답시간" 이 퍼포먼스가 아니면 뭐가 퍼포먼스입니까. 모든건 "짧은 응답시간"에서 시작됩니다.
- 비용에 있어서, java는 할 말이 없어요. 그 "짧은 실행시간" 을 위해서 좋은 사양을 구입해야 하니까.... 대기업에 jsp 좀더 잘굴리기위해 들어가는 sun 장비들 가격 생각해 보시면 될겁니다.
- 확장성에 있어서도, 제경우 java가 MS 것보다 확장성이 좋다고 생각하지 않습니다. MS쪽은 COM을 이용해서, 쉽게 무한대로 확장되죠.
- 구현 용이, MS쪽도 그렇게 어렵지 않죠.
요지는, java 가 좋다느니 MS 가 좋다느니 하는 것은 입장 차이란 겁니다.
- oop 잘한다는 것은 설계를 잘한다는 뜻이겠죠. 클래스를 잘 정의해서,... 어디서건 효율적으로 잘 돌아가도록. 허긴, 뭐하나 잘하는 사람이, 다른 것 못할리 없겠습니다만.
( 물론 제가 그렇다는 뜻은 아닙니다 )
근데 테크니컬은 뭐고 엔지니어링은 또 뭡니까. 그 둘을 구분한다는 것이 그리 맘에 들지 않네요. blue 컬러 white 컬러 구분하는 것 같군요.
정말로 테크니컬한, 기반이 철저한 사람이 전체 설계도 잘하는 겁니다. c++ 잘하는 사람이 java도 잘한다고 말하게 된 것은, 앞선 글에서
"자바는 C++과는 문법적 유사성외에는 설계철학부터 OOP의 구현방법까지 별로 공통되는게 없습니다"
이것이 제생각에 맞지 않기 때문입니다. 제생각에 한 80% 공통되고, 20%가 다르네요. ( 한 50% 잡아줄까요.... ^^;;; ) 기분나쁘게 들렸다면 죄송합니다만, '별로 공통되는 것이 없는' 아니라, '많이' 공통됩니다.
그렇다고 java가 c++ 클론이란 얘긴 아닙니다. 모든 기술은 예전 기술을 기반으로 하게 마련입니다. c++ 의 많은 부분이 c에서 나왔듯.
흐미 c++과 java가 많이 공통된다는 말씀은예약어 갯수가 그렇다는
흐미 c++과 java가 많이 공통된다는 말씀은
예약어 갯수가 그렇다는 말씀이시겠죠? ^^;
if랑 for 사용법이 같다고 해서 설계 방식까지 같아지지는 않는답니다
실제로 개발을 해보면 c++ 개발자가 헤더 꼬이는 거 까지 신경써주고
있는 동안에 자바 개발자는 패턴 사전 뒤지고 있지요..
으이구 무식이 티가 나는구만요자기 글이 반론이 나오면 무조건 억지
으이구 무식이 티가 나는구만요
자기 글이 반론이 나오면 무조건 억지 떠나 보죠?
그대는 아마도 클럭수로 컴퓨터 속도를 결정짓는 어리숙한 사람중 한명인가 보군요.
짧은 응답시간 만이 퍼포먼스라고 생각하신다면 거기 대해서는 더이상 드릴
짧은 응답시간 만이 퍼포먼스라고 생각하신다면 거기 대해서는 더이상 드릴 말씀이 없습니다. 앞에서도 말씀드렸듯이 퍼포먼스 논쟁은 지루한 벤치마크수치와 비용산정이 난무하는 개싸움이라 끼어들고 싶지 않습니다. 다만 퍼포먼스를 보는 다른 시각도 있다는 걸 염두에 두셨으면 합니다. 개발자로서 인식의 폭을 넓히는 셈치고...^^;
비용의 경우는 동일한 작업을 처리하는데, MS가 훨씬 비쌉니다. 아니라고 생각하시면 어쩔도리가 없지만 적어도 제가 보고 듣고 아는 영역에서 자바를 선택하는 업체가 처음에 혹하는 부분이 가격이므로 시장현실이 그렇다는 겁니다.
테크니컬과 엔지니어링은 제가 구분하는게 아니라 원래 다른 겁니다. 엄연한 직무영역의 차이를 맘에 들고 안들고 할께 뭐가 있는지 이해가 안되는군요. 엔지니어에게 테크니션으로의 숙련도까지 익히도록 하는건 개인에겐 이익일지 몰라도(?) 전체 프로젝트 입장에서는 손해입니다.
그리고 c++과 자바과 많이 공통된다고 별다른 근거없이 반복하셨는데. 앞에 말씀하신 입장차이라는 것이 java로도 c++처럼 혹은 심지어 c처럼 코딩할 수 있다는 뜻이라면 뭐 세상 어떤 언어에 차이가 있겠습니까. 공통점으로 한 100% 잡아드리죠. 오브젝트코볼도 있는 판국에 코볼인들 c++하고 다르겠습니까. 저는 'java다운'이 지향하는 프로그램의 설계,구현과 'c++다운'이 지향하는 프로그램의 설계,구현이 다르다는 말을 하고 싶은 거였습니다. 그리고 그 '..다운' 설계, 구현이라는 것이 외형적 큰 차이점으로 다가오는 것인지 아닌지는 모르겠지만 미묘한 차이가 흑연과 다이아몬드를 갈라놓듯 작아도 결정적인 차이라면 큰 차이입니다...^^;
나머지에 대해서는 님의 말처럼 입장차이가 있다는 정도로 마무리하죠. 공허한 논쟁같아서...^^;
(이 글에 대한 답장이 아니라 이 윗글에 대한 답장입니다.)OOP
(이 글에 대한 답장이 아니라 이 윗글에 대한 답장입니다.)
OOP 적인 관점에서 본다면, Java와 C++은 확연히 달라 보입니다.
그리고 테크니컬과 엔지니어의 관점은 확실히 다릅니다.
엔지니어의 관점에서 보면, Java와 C++은 확연히 달라 보일 것이고,
테크니컬의 관점에서 보면, Java와 C++은 50% 같아 보일 겁니다.
엔지니어와 테크니컬의 차이점을 잘모르겠습니다.예를 들어서 좀 말씀해주
엔지니어와 테크니컬의 차이점을 잘모르겠습니다.
예를 들어서 좀 말씀해주시길 바랍니다.
궁금...
단어의 뜻을 그대로 생각해 보시면 될 듯 한데요. 공학과 기술(스킬)..
단어의 뜻을 그대로 생각해 보시면 될 듯 한데요. 공학과 기술(스킬)...
개발역사가 긴 하드웨어에서는 이 차이가 명확하던데 확립 돼있는 것 같던데 소프트웨어는 하드웨어에 비하면 좀 혼재 되있는 것 같습니다.
예를들어, 엔지니어는 이 일을 수행하려면 어떤 기능을 하는 함수, 모듈 따위가 필요하다는데 집중을 하고 테크니션은 어떤 기능을 하는 함수나 모듈따위를 빠르고 효율적이게 만드는 방법에 집중하겠죠.
자바와 c++의 경우라면, 엔지니어의 일은 어떤 관계를 가진 클래스들을 만들것인가에 집중되어서 자바와 c++의 차이가 드러나는 부분에 관심이 많을 것이고. 테크니션의 입장에서 보면 클래스의 코드를 어떻게 만들가이므로 자바와 c++ 심지어 c도 크게 차이가 없는 부분에 관심이 집중되지 않을까요.
우리나라에서는 엔지니어와 테크니션의 차이를 거의 두지 않고 있죠.
이건 테크니션을 존중해서가 아니라 엔지니어이면 테크니션의 일은 당연히 할 줄 알아야 한다는 식으로 테크니션을 무시하고 쉬운 일로 치부해서 테크니션들을 전문가가 아닌 저임금 노동력으로 묶어두기 위해서가 아닐까라고 생각하는데...
말씀 잘들었습니다.그러면 소프트웨어공학이 공학, 즉 엔지니어군요.
말씀 잘들었습니다.
그러면 소프트웨어공학이 공학, 즉 엔지니어군요.
현재 프로그래머는 테크니션위주 잖아요.
확실히 분업되고 서로를 존중해준다면 개발도 그렇게 어렵지는 않을것인디...
좀더 깊게 공부를 해야 겠습니다. 감사...
"소가 뒷걸으미 치다가 개구리를 잡은격"인 부분은 자바 애플릿 아닌가요?
"소가 뒷걸으미 치다가 개구리를 잡은격"인 부분은 자바 애플릿 아닌가요???
그외부분(서버부분)은 다 선에서 계속적인 지원에 의해서 발전한 부분입니다
참고로 선에선 J2SE보다는 J2me ,J2ee 에대한 지원이 더욱 확발하고
가속도를 붙이고 있습니다.물론 J2ME에는 embedded 기기에대한 지원입니다..
그런데 과연 뭐가 얼마나 모자르다고 생각하는건지????
그리고 GUI 를 제외하고는 모든부분에서 만족스러운 속도가
나온다고 생각합니다
흐미 자바가 C++을 모델로 했다는 말은, 단지 문법이언어의 전부인
흐미 자바가 C++을 모델로 했다는 말은, 단지 문법이
언어의 전부인 줄 아는 사람이나 할 수 있는 말인 것
같군요. 자바의 핵심개념(VM & bytecode)과 전통적인
C의 모델을 답습하는 C++의 어디가 비슷한가요?
Java는 C++에서 단지 프로그래머들에게 익숙한 문법만을
간략화시켜 빌려왔을 뿐, 그 외엔 어느것 하나 비슷하지
않습니다. 오히려 스몰톡에 더 가까웠으면 가까웠죠..
반면에 C#과 자바의 관계를 보면 C#이 자바의 핵심 개념을
거의 그대로 가져와서 C++의 문법 약간(=자바가 빼버리고
안가져온 것들)을 더 추가한 것 뿐이죠.
모 사실 언어를 베껴냈다는 그 사실만 가지고선 M$를 욕할
생각이 없습니다. 어차피 서로 서로 베끼고 베끼는 와중에
발전이 있다는 것이 개인적인 의견이니까요. 다만 경쟁자를
죽여 없애고 모든 것을 혼자 다 처먹고 말겠다는 M$의 의도가
괘씸할 뿐..
저도 개인적으로는 좀 빨라졌으면 좋긴 하겠지만...그게 얼마나 지켜질
저도 개인적으로는 좀 빨라졌으면 좋긴 하겠지만...
그게 얼마나 지켜질 지 좀 의구심이 들긴 하는군요... ㅋㅋ
하기야... 그동안 자바가 점점 빨라진 게 사실이긴 하지만...
(작업에 따라서 몇 배씩 빠른 경우도 있더군요...)
암튼 1.4가 좀 기대되긴 합니다....
글구, 플래쉬 플러그인이 컴퓨터마다 깔리듯이 자바 플러그인도 컴퓨터마다 다 깔리는 시대가 오면 좋겠군요.
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
현재의 상황에서 객관적으로.. 냉정하게 생각하면 C#을 하는것이
현재의 상황에서 객관적으로.. 냉정하게 생각하면
C#을 하는것이 좋은 수인것 같은데..
자바를 더 깊이 공부하지말고 이 선에서
C#으로 전향할까 싶군요.
앞으로 몇년후의 변화가 궁금해집니다.
무슨 의도로 그런 글을 올리는지 알수가 없네여..MS사 직원인가여?
무슨 의도로 그런 글을 올리는지 알수가 없네여..
MS사 직원인가여?
페이지