자바를 진정 해야할까요?
\'94 부터 슬랙웨어를 시작으로 지금껏 UNIX 시스템 관리와 인터넷 서비스 프로그래밍을 해왔던 엔지니어입니다.
많은 날들을 개발한답시고 C,C++,Perl,Python,apache + mod_perl, Jython, ASP, cocoon, Zope 등... FreeBSD 상에서 ports로 등록된 것들을 하나 하나 뜯어보구(?) 그 수많은 요구사항을 만족시켜 주느라 전공아닌 것들도 공부해야 했으며 (대표적으로 도서관에서 쓰는 KORMAC) 앞으로도 얼마나 많은 요구사항때문에 하기 싫은 것들을 공부해야 할지 모르는 상황입니다.
다행히 진행하던 프로젝트가 어느정도 종료가 되어 그동안 벼르고 벼르던 Design Pattern 과 UML을 제대로 공부하고 있지요. 객체지향 기술을 근본부터 제대로 알지 못하고서는 지금의 패러다임에 끌려갈 수 밖에 없다고 판단했었기 때문입니다.
언어 자체를 좋아하지만 유독 Java는 정이 가질 않아서 내버려 두다가, 최근의 Java 개발상황과 주변 돌아가는 정황으로 볼때 무시하지 못한다고 판단하고 어떻게든 해야겠다고 판단을 했습니다. 하지만, 할려고 할때마다 정말 짜증나는것을 어떻게 말을 할 수가 없더군요.
- 마우스 지나간뒤 엉망이 되는 어설픈 화면,
- Qt에 비교해서 (개인적인 생각으로) SLOT 과 SIGNAL 개념에 비교하여 철지난 C의 callback 함수사용과 번잡한 Event 모델을 쓰는 것,
- 순수 객체지향으로 인한 오버헤드 (당연한 것이지만...)
- 말처럼 되지 않는 플랫폼 중립,
- 늦은 속도
- 정작 LINUX나 FreeBSD에서는 Solaris에서처럼 지원되지 않는 것
....
게다가 (말로는) Java의 단점을 보완한 C#의 출현이 더욱 갈등스럽게 만들죠. (물론, 장점도 많은 것.. 알고 있습니다)
KLDP에서 많은 의논을 한 것중 하나의 주제와 같이, 진정 개발자로 살아남을려면(?) 지금껏 해왔던것같이 질질 끌려 다녀서는 안된다 보구요, 기초를 탄탄히 하여 정말 생명력 있는 개발자로 남고자 하는 것입니다.
2001년 중순, 과연 우리네 개발자들은 자바를 계속해야 합니까?
엄밀하게 전통적인 언어적 관점(VM을 Machine을 보지 않을 경우)에
엄밀하게 전통적인 언어적 관점(VM을 Machine을 보지 않을 경우)에서 봤을때는 interpreting language임니다.. script는 거의 명확한 interpreting language 임니다..
하지만... Interpret language = Script language 라는 말은
성립이 좀 어렵지요....
암튼... Java는 언어적 관점에서는 Interpret language 임니다. Java가 Compiler Language 라고 생각하시는 분들이 많으신것 같아서.. 그냥 한마디 적어 봄니다...
이그... 사실 이글 여기 나올께 아닌데....아래 어느 부분에서
이그... 사실 이글 여기 나올께 아닌데....
아래 어느 부분에서... 이런 얘기가 오가고 있길래... 지울수도 없네요... ^^;;;
요즘 왜 자바가 인기가 있을까요? 대부분의 서버용 상업어플리케이션
요즘 왜 자바가 인기가 있을까요?
대부분의 서버용 상업어플리케이션 업체는
순수 자바기반의 제품들을 내놓고 있습니다.
왜 속도도 native 보다 느리고, C를 많이 했던 사람이라면
답답하고 허잡(?)해 보기기까지 한데,
그들은 자바를 선택했을까요?
제가 생각하기에 그 이유는 Java가 제공하는
Framework이 현재 요구되는 패러다임에 가장
적합한 환경이기 때문입니다.
속도뿐이 아닌 여러가지 중요한 이슈(성능,
현재 이식성, 관리, 유지보수 )에 대해로 평가 했을 때
종합적인 점수가 가장 높은 것이 자바가 제공하는
Framework입니다.
Java랑 C랑 비교하는 것은 올바른 비교가 아닙니다.
객체지향 방법론의 목적을 해결하기위한 수단과
OS를 만들기 위해 개발된 언어의 비교는
비교대상 설정부터 잘못됬다고 생각됩니다.
마치 물을 끓이는데는 가스레인지가 필요하고,
못을 박을때는 망치가 필요한데.. 가스레인지랑 망치랑
어느게 더 좋은가라고 묻는 경우와 비슷합니다.
무엇을 선택하는냐는 어떤 분야로 갈지를 결정하면...
자동적으로 해결된다고 생각합니다.
주) 여기서 자바로 개발이라 함은 객체지향 방법론에 따라 정상적으로
주) 여기서 자바로 개발이라 함은 객체지향 방법론에 따라 정상적으로
개발되는 것을 말합니다.
잘못된 Design 이나 자바 개발환경에 대한 경험부족등으로 발생되는 문제는
자바의 단점이 아닙니다. (C/C++ 아니라 어떤 환경에서도 있을 수 있는 문제죠)
C..아주 조금 배우다가 C++제대로 구경도 못해보고 JAVA배운 사람입
C..아주 조금 배우다가 C++제대로 구경도 못해보고 JAVA배운 사람입니다. 뭐.전공도 전산이 아니구..프로그램 몇년 해보지도 않았으니 거의 초짜에 가깝지요...
남들이랑 꺼꾸로 JAVA배우고 C++배우고 있습니다. 그러면서 느낀건 참 자바가 편한 언어였구나라는 생각이 듭니다.
뭐 할려면 열씨미 Java Document만 찾아보면 대충 API가 있으니 가져다 쓰면 되구...예외처리 Exception은 대충 다 만들어놓았구...암튼...로직만 열씨미 생각하면 되더라구요..
음냐..그러다가 C++을 배울려구 하니까...쉽지 않네요.
잘 정리된 문서가 있는것도 아니구(어디 있을 수도 있지만 내가 못찾고 있는 것일수도 있구) 메모리 잡았다가 풀어주는것도 쉬운일이 아니구(일일이 기억하고 있어야 하니)... STL도 나름대로 체계가 있는 것 같은데 잘 이해는 안가구...
다른 사람들이 자바를 알면 C++을 안해도 될텐데 다들 자바는 모르고 C만 안다고 하니...좀 쳬계적으로 프로그램 짤 수 있는 유일한 대안은 C++밖에 없네요.
자바에서 C++로 배우기는 힘들어도 C++에서 자바 배우기는 쉽겠던데...
그리고 C++에서 쓰레드 프로그램은 어떻게 짭니까..? 자바 같으면 Thread 클래스 상속받으면 쉽게 쓰레드 프로그램 하겠더만 C++에서는 어떻게 하는지 잘 모르겠네요. C++자체에서 제공해주는게 아니고 시스템콜이나 뭐 비슷한 뭔가를 사용해야 될 것 같은데 잘 모르겠네요. 솔라리스에서 C++로 쓰레드 프로그램 짤 수 있는거 아시는분은 좀 가르쳐줘요....
저같은 경우는 C만 그럭저럭 할 줄 아는 사람입니다. 물론 C++도 억지
저같은 경우는 C만 그럭저럭 할 줄 아는 사람입니다. 물론 C++도 억지로(?)
한 이틀 정도 배우기도 했고, 자바도 97년도에 한 몇개월 하다 만적이 있읍니다.
저같은 경우는 C에 대해 약간은 맹신적인 사람입니다.
왜냐하면 제가 그런대로 유연하게 다룰 수 있는 언어가 C정도 이니까요.
꼭 자바나 아니면 다른 언어든지 어느게 좋고, 어느게 불편한게 있는게
아니라고 생각합니다.
어느 언어가 자기가 하고자 하는 목적에 맞고, 어느 언어가 자기가 쓰기 편한가에 달려 있다고 생각합니다.
프로그래밍할 때 중요한 것은 시간과 구성이라고 생각합니다.
시간이란 것은 어떤 일이 주어졌을 때 빨리 일을 완성하는 것을 얘기하고,
구성이란 것은 그 시간안에 얼마나 좋은 구조로 짜느냐를 말합니다.
뛰어난 프로그래머는 짧은 시간안에 나중에 프로그램 구조를 바꾸게 되었을
경우(윗사람의 요구에 의해서 울며겨자먹기로 바꿔야 되는 경우가 생기죠...
흑흑흑)에도
프로그램 수정에 많은 시간과 노력을 투자하지 않도록 짜임새
있는 프로그램을 짜는 사람이라고 말할 수 있다고 생각합니다.
저같은 경우 C를 주로 많이 사용하는 이유는 C++, 혹은 JAVA의 모든 기능들이
C로 거의 구현가능하기 때문입니다. 물론, 안되는 녀석들도 있지만 다른 식으로 피해갈 수 있읍니다.
C의 기능들을 상당히 친근하게 익히게 되면 C++이나 JAVA같은 녀석들도
친근감있게 접근할 수 있다고 생각합니다. 왜냐하면 거의 구현방식이나
동작이 비슷하게 이루어져 있기 때문이죠...
Thread같은 녀석도 POSIX thread의 동작을 익히게 되면 다른 언어나 툴들에서
제공하는 Thread library도 쉽게 파악이 가능합니다.
님께서 질문하신 solaris의 thread프로그래밍도 POSIX thread를 익히게
되면 금방 익숙해 질 수 있읍니다. 사용법이 함수이름만 약간 다를
뿐이지(pthread_create(POSIX thread), thr_create(Solaris thread, 이게 맞나 기억이...) 이런식으로) 서로 대동소이 합니다.
물론 windows쪽은 함수이름들이 완전 틀리지만 같은 개념의 함수들이
있으니 구현 가능합니다...
Solaris에서의 C++로 thread프로그래밍하는 것은 C++의 클래스에서
Solaris 쓰레드를 이용할 수 있는 C함수를 그냥 호출해서 사용하면 됩니다.
C++로 thread사용하는 방법을 배우고 싶으시면
www.freeamp.org에 가서 freeamp의 소스를 보시던지(되게 어렵지요),
아니면 거기서 링크되어 있는 freeamp를 만든 사람이 icecast용
source server로 작성한 Obseqiuem 0.3.0버젼을 참조하시기 바랍니다.
소스의 양은 상당히 많으나, 거기서 thread를 C++에서 사용하는 정답이
있읍니다. 상당히 배울점이 많을 겁니다. 제가 첨 그걸 봤을 때는
엄청 깔끔하다는 인상을 받았읍니다. 그리고 무지 잘 짜는 거 같더군요..
배울점이 아주 많은 프로그램입니다. 저도 C++을 그런대로 볼 줄 알지만
그 소스를 보면서 상당히 많이 배웠읍니다. 그 덕분에 요즘은 C++도
별 어려움없이 사용할 수 있을 거 같더군요...
그럼....
check V3!
check V3!
어떤 언어가 필요한지는 자기 자신이 가장 잘 알지 않을까 쉽네요...
어떤 언어가 필요한지는 자기 자신이 가장 잘 알지 않을까 쉽네요...
어떤 언어가 필요하다라는건...
나는 어떤걸 하고 시퍼하고 같은 의미가 아닐지요???
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!
님께서 걱정하시는 것은 프로그래머로써 고수의 길을 가고자 하는 고민 때문
님께서 걱정하시는 것은 프로그래머로써 고수의 길을 가고자 하는 고민 때문이신가요? 아니면 먹고 살기에 충분한 고수의 길을 가고자 하시는 건가요? 결코 먹고 살기에 충분한 고수를 욕하고자 하는 말이 아님을 분명히 밝힙니다. 저는 둘다에 해당되지 못하는 하수에 불과하기 때문입니다.
많은 분들이 명답을 해 주셨는데 굳이 사족을 하나 달자면.. 제의견입니다.
저는 살아남기 위해 열심히 프로젝트에 껴서 프로그램을 짜는 하수라 전체를 보지는 못합니다. 하지만 프로그래머로써 고수의 길을 가고자 하신다면 배워야 할지 말아야 할지를 미리 고민하는 것은 고수의 도가 아니라고 봅니다. 일단 들어가서 처절하게 배운 다음 결론을 내려야지 가 보지도 않고 다른 사람들이 가라 마라 한다고 가거나 안간다는 것은 (물론 그러시지 않겠죠? ^^ ) 고수로서의 올바른 몸가짐이 아니라고 봅니다.
그렇다면 먹고 사는 (흔히 전산쟁이들로 지칭을 받는 직업 전산인들이 필드라고 표현하는 ) 분야에서의 고수가 되시기 위해서 자바를 배워야 할지 말아야 할지를 고민하신다면 시간을 투자할 필요가 없다고 생각합니다. 우리 나라 현업에서 그렇게 유닉스 프로그래머가 자바를 퍼팩트 하게 한다고 돈을 더 주는 경우는 없습니다. 프로젝트에서 도움은 되겠죠. 다른 사람이 짠 프로그램을 보다가 이거 저거는 잘못짜셨네여~~ 하면서 훈수 두는 정도? 그렇지 않다면 자바로 같이 프로그램을 짜셔서 링크하실일은 없다고 봅니다. 그렇다면 우리나라 금융권이나 제조업에서 자바가 시장을 다 뺏어 갈까? 하는 질문이 남네요. 물론 금융권이 다가 아니고 제조업이 다가 아닙니다. 다가오는 시장은 인터넷을 중심으로 새로운 IT 산업시대라고들 하죠. 하지만 그거 해서 돈 버는거는 JSP 프로그래머는 아닌거 같습니다. EJB 패키지 회사들이 돈 다 벌고 분산 처립네 어쩌네 하면서 대형 서버들을 파는 회사들이 돈을 다 벌겠죠. (과연 용산에서 조립한 팬티엄 서버 여러대로 분산 처리를 완벽하게 해서 썬 E10000같은 서버와 맞먹을 수 있나요? 결국 하드웨어 업체에 돈을 대주게 됩니다. )
항상 좋은 제품이 시장을 제패하지는 못했습니다. 맥킨토시나 넥스트스텝이 그러했고 넷스케이프가 그러했습니다(비유가 적절치 않았나요? )
아무리 우리가 떠들어봐도 결국은 미국에 있는 기반 기술을 가진 회사들이 돈을 벌게 되죠. 차라리 리눅스나 유닉스쪽의 프로그래밍 기술을 더 연마해서 고수가 되는게 더 몸값을 높이는 길이 아닐까요?
많은 분들이 MFC와 자바를 비교하던데 좀 웃기지 않습니까? MFC로 서버 프로그램짜는 사람 있나요? 자바로 3차원 실시간 주가 분석 그래픽 툴을 짜려면 얼마나 걸릴까요?
그리고 .Net 과 자바에 대해서 비교를 하시던데 저는 사실 둘다 잘 모릅니다. M$를 욕하시는 분들에도 공감을 하고 JAVA를 욕하시는 분에게도 동의합니다. 하지만 곰곰히 생각해 보면 둘다 세계 프로그래머들의 평화를 위해서 프로그래밍 툴을 팔지는 않는 회사들입니다. $UN은 나름대로 H/W시장을 넓혀가야 하는 사명을 가진 회사고 M$는 말할것도 없이 세계 IT산업을 독식하려는 기업이고. 하지만 어느 회사든 완벽한 것을 판적은 없습니다. 나름대로 버그가 있고 과대 광고가 된 부분도 있습니다. 그걸로 서로 다른 언어 분야를 욕하고 평가하는 것은 잘못이 아닐까요? 그럼 C의 단점을 가지고 욕한다고 C를 버리실건가요?
결국은 유행과 시장의 선택에 좌우됩니다. 시장이 .NET을 선택하면 기술의 장단점과는 상관없고 기술자의 유무와도 상관없이 자바는 밀려 날것입니다. 그 역의 관계도 마찬가지죠. 너무 모호한 말만 한것 같네요.
결국 핵심은 시장이 선택하기에 달렸지 프로그래머가 그걸 선택하는것은 취미 아니면 도박 정도 밖에 안됩니다. 지금 python을 선택한다구요?
그럼 그게 언제정도에 시장을 점유한다고 생각하시죠? Power Builder를 선택한 사람들은 그럼 바보 멍청이들일까요?
저는 Unix 기반 networking programming을 개발자입니
저는 Unix 기반 networking programming을 개발자입니다. 현재는 c와 xml과의 application server를 구축하려 하고 있구요... 쩝... 거두절미하고...
c든 c++이든 java든 python이든 간에 남들이 무얼한다고 하던 간에 정작 중요한건 software개발이 아닌가 생각합니다.
하나의 software를 개발하기 위해서는 생각보다 많은 부분이 필요하지 않습니까...? 순수 programming의 가치는 사용자가 정말 유용하게 그 프로그램은 지속적으로 사용하는가에 있지 않나요..
어떤 언어를 사용하는가 보다는 software의 architecture를 더 많이 연구하고 더 많이 공부해야 하지 않나요? 그래야 우리도 외국기업 못지 않은 훌륭한 program들이 나오지 않나요...? 우리 제발 언어만 공부하지 말고 생산성있는 software을 개발하기 위한 순수 programming 의 방법론을 공부합시다...
자연히 언어는 뒤따라 오게돼있읍니다. c하다가 c++하고 그러다가 java하고 그러다가 c#하고 그리고 나서 또 뭔가가 나오면 또 따라하고 ... 이러면 남는게 뭐가 있을까요... 자신이 지금까지 했왔던 노가다밖에 없지 않을 까요...?
아래 어떤분이 자바로 시스템 프로그램이 가능하다 하셨는데한가지만
아래 어떤분이 자바로 시스템 프로그램이 가능하다 하셨는데
한가지만 물어봅시다.
하드웨어 접근하는 가장 흔한 방식인
특정 레지스터 접근하는게 자바로 가능합니까?
예를 들면 c 로
*((unsigned int*)0xaabbccdd = 0x01234567;
나 어셈블리로(물론 범용레지스터는 ax, bx 등이 될수도 있고...)
mov r1, #0x01234567
mov r2, #0xaabbccdd
str r1, [r2]
대충 이런게 가능한가요?
불가능한걸로 아는데...
훌륭한 나무꾼은 연장을 탓하지 않습니다.침엽수림에서는 그곳에 맞는
훌륭한 나무꾼은 연장을 탓하지 않습니다.
침엽수림에서는 그곳에 맞는
활엽수림에서는 역시 또 그곳에 맞는
연장을 쓰겠죠.
많은 분들이 말씀하듯이 결국 중요한것은 내공이 아닐까여?
(논점 일탈 죄송..)
요건 기술문제가 아니라고 보는데요...자바를 써야 할까요? 라는
요건 기술문제가 아니라고 보는데요...
자바를 써야 할까요? 라는 문제에 대한 대답은
기술과는 전혀 다른 곳에 있지 않을까 생각이 듭니다.
기업고객들이 어느 플랫폼을 선택하느냐에 대한
문제라고 보는데, 여기에서 분명 자바는 우위에 있습니다.
왜냐?
많이 쓰고, 지원도 제일 많으니깐!
글고 대규모 엔터프라이즈 환경에서
분명 자바는 검증됐습니다.
JSP사이트들이 죽는 문제들이 언급되고는 하는데,
이건 본격적으로 EJB같은 분산처리 기본이 적용되지
않았기때문에 MTS와 견줄수 없습니다.
EJB 컨테이너로 이미 웹스피어, 웹로직, JRun같은
상용제품이외에도 여러 공개제품도 있습니다.
그러나!
제가 하고 싶은말은
기술적으로 자바가 .Net보다 뛰어나다는 말이 아닙니다.
기술적으로 그런지 아닌지는
저도 모르겠습니다.
단지 기업환경에서
자바가 .Net에 비해
우위를 점유하고 있는건 사실이다.
정도는 말할 수 있을것 같습니다.
결론적으로
자바를 써야할까요?라는 질문에 대한 대답은
"당연히 써야 하는거 아닙니까?"라고 생각이 됩니다.
그전에 자바 갓 나왔을때
파워빌더 쓰는 사람이
"이런 허접한 랭귀지를 써야돼?"라고 하는 질문과
비슷한게 아닐까요?
결국 파빌은 역사의 뒤안길로 밀려나고
자바가 주류가 되지 않았나요?
파워빌더에 대해 구체적으로 설명해주시죠...VB처럼 4GL인지도요..
파워빌더에 대해 구체적으로 설명해주시죠...
VB처럼 4GL인지도요...
비유가 정확하지는 않았던 것 같습니다.파빌은 델파이와 더불어 엔터
비유가 정확하지는 않았던 것 같습니다.
파빌은 델파이와 더불어 엔터프라이즈 환경에서
RAD툴로 대단히 많이 쓰였던 툴입니다.
데이타베이스와 붙여서 하는 CS환경에서
최고의 성능을 발휘했습니다.
미들웨어는 턱시도나 CICS(IBM)같은 걸 쓰고요.
그런데 불과 몇년사이에 프로젝트에서 거의
자취를 감추었지요.
그간 해논게 있으니 여전히 수요가 있기는 하지만,
아무래도 예전같이 않은게 사실입니다.
여러 개발자님들의 말씀, 정말 감사하고 주제에 관련된 생각을 하는데 많은
여러 개발자님들의 말씀, 정말 감사하고 주제에 관련된 생각을 하는데 많은 도움이 되고 있습니다. 교통정리를 하자면,
1. 일단, 언어싸움이 아닌건 아시져?^^
시기는 정말 중요한 것이라 믿습니다. 저의 나이 32살 이거든여. 머리 돌아가는 거.. 아직 쌩쌩합니다. 술/담배를 안해서이고 무엇보다 예수님을 믿는 사람으로서 기도를 해왔거든여 (아... 개인적인 사항인거 이해해 주시리라 믿슴다). 말씀드렸듯이 언어는 좋아함다. 컴파일러도 공부해보고 허접한 검색엔진용 파서기도 만드는 정도이니깐여. 이 토론의 중점은 '시기에 따른 자바학습' 에 관해서 입니다. 패키지와 그에 따른 문제점및 논의는 이쯤에서 접어두고, 좀더 넓은 측면에서 님들의 안목을 예기해주셨으면 하는 거지여.
2. 몇가지 잘못 알려진 것은, "오버헤드" 라는 것을 쓴 것은, 개발자가 객체지향으로 프로그래밍을 하기위한 생각의 전환에 드는 비용(시간,물질포함)을 말하는 것이었고 속도와 같은 것을 말씀드린것은 아니었습니다.
3. 저는 (개인적으로) 웹 어플리케이션 쪽에선 손을 떼려합니다. 이건 남는게 없다고 봅니다. 이것에 대해서 답글은 없기를 바랍니다. 말씀 드렸다 시비 *개인적인* 판단이니깐여.
참으로 많은 분들의 개발관련 노하우를 들을 수 있어 좋습니다. 저또한 Zope (http://www.zope.org) 로 동시사용자 약 1000여명의 사이트를 만든 것이 바로 두달전이거든여. 끽~ 하면 죽습니다. 환장하겠더만여. T1 라인은 제쳐두고, 로드밸런스를 위해 알테온 스위치 쓰고, 4대의 클러스터링 서버와 1대의 Sun Solaris에 Oracle을 뛰웠습니다. 각 서버는 1GHz 광(Optic)케이블로 연결된 고속 이더넷으로 연결했구여. (4대의 클러스터 멤버서버의 OS는 Linux 였슴다.. -.- 망할..)
아시다시피 Zope 2.3.X 대는 Python 1.5.2 를 사용하지여.
한마디로, 엉터리 Thread 구현땜에 뒤집어 졌습니다. Python 이 Thread 구현을 Process 로써 처리한 것이지여. 이 죽는 사항은 Zope를 만든 Digital Creation 사의 핵심멤버의 말에 따르면 "사용자측의 오류"라구 딱 잡아 땝니다. 그러치만!, 근 한달간 눈딱구봐도 SQL만 있는 더 이상 간단해질 수 없는 로직에서 무슨오류가 있는지... 미치갔더만여. 그래서 별짓 다해봤슴다. ZODB를 BerkeleyDB로 바꾸고, OracleStorage로 바꿔보고.. 젠장할.. 본의아니게 Oracle 관련 Tuning 문서는 모조리 다 훝어보구... 현업에 종사하시는 분들 여러명 불러서 울 실장님 개인돈 들여가며 과외(?)도 받아보았지만... 결국... 안되었슴다. 죽어여. 최후로 제가 미친짓을 해서 일단 막았지만, 이미 사태는 벌어졌고 부산대학 어느 교수가 장관에게 보낸 탄언서 땜에 꺼꾸로 공문이 내려왔슴다 "관련자 엄중 문책하라" ...
제가 말씀드릴려는 것은, 하나의 언어, 하나의 패키지 혹은 그 이상땜에 이렇게 대외적으로나 개인적으로나 맘고생하고나면, "어떤 언어가 뭐가 중요하냐?", "이것 저것 아는 것이 좋은 것 아닐까여?" 등의 말씀은 더 이상 들어오지 않을 거라 이거져. 혹자는 또 리플을 달기를 "제대로 만들면 그런 일 생기나.." 하시겠져.. 흠... 혹 그런 분이 있다면 전 어떤 말도 할 수 없습니다. 다만, ... 열받겠져.
개발자는 앞날을 내다봐야 한다는 자질(?)이 필요하다 봅니다. 90년도 하반기때, Windows의 COM, OLE 기술이 한창 뜰려고할때에도 오직 UNIX! 를 외치면서 UNIX관련된 기술습득을 하던 그 때 덕분으로, 지금 UNIX 무쟈게 편합니다. 생각보다 UNIX 에 익숙해질려면 시간이 많이 들거든여. 그때 판단 덕분에 5년이 지난 지금 내적으로는 딱 뿌러지는 기술을 가지고 있다고 믿구여, 외적으로는 봉급 많이 받슴다.
그러므로, 시기를 타서 학습한다는 것은 토끼같은 마누라와 여우같은 자식을 위해서도 중요함다. 이 점을 유의해주시고 논지를 밝혀주셨으면 함다..
진짜루, 여기 토의에 참가하시는 분들,.. 의견 감사함다.
변하지 않는것...전산의 핵심...무슨 유행을 따르는것보다는 묵묵
변하지 않는것...전산의 핵심...
무슨 유행을 따르는것보다는 묵묵히 자기 자신의 갈길을 가는것...
장단점이 있으니 장점이 되는 부분에 쓰면 되는거죠얼마전 자바스터디
장단점이 있으니 장점이 되는 부분에 쓰면 되는거죠
얼마전 자바스터디를 결성했습니다
제가 자바를 공부하려는 이유는 네트워크 프로그래밍을 해보고 싶어서 입니다
어떤이는 모바일 프로그래밍을 해보고 싶다고 해서 시작했습니다
아무것도 모르고 시작하는 마당이라 시작이 잘된것인지는 모르지만 처음에 생각한거와 틀리다면 구지 설정한 방향을 고집하고 싶지는 않습니다
강점으로 부각되는 것을 만드는데 쓰면 그만이니까요
단! 제대로 쓰느냐가 중요한거 같습니다
너무 개론적이 얘기만 했나요?
아뭏든 이런 토론의 장이 있다는게 자바를 시작하려는 저에게는 큰 도움이 되었네요 ^^
에고... 글을 다 읽고마감글을 쓰는데...제 생각을 정리해
에고... 글을 다 읽고
마감글을 쓰는데...
제 생각을 정리해 볼께요...
제가 아직은 C, C++, JAVA등 에 능숙하지 못합니다. 솔직히 얘기해 드려서 이곳에 계신분들에게 감히 도전장을 내밀지 못합니다.
그런데 제가 하고 싶은 말은 그렇습니다. 자바라는 언어가 대체 어떤 언어이든간에 제가
주관적으로 필요하다고 보는 언어인 XML에 대해 중점을 두고 그와 짝을 맞추는 언어 중 자바도 있었습니다.
자바를 배워야 한다는게 시대의 흐름이라면 어쩔 수 없겠지만요.
글쎄요... 아직은 너무 이른 듯 합니다.
글도 짧은 횡설수설한 글 보아주셔서 감사드립니다...
주관적인 생각 입니다.현업에서 개발 관리(주로 자체 아이템)를 주로
주관적인 생각 입니다.
현업에서 개발 관리(주로 자체 아이템)를 주로 합니다.
저의 입장에서는 외주 받는 일이거나 다른 회사의 프로젝트를 진행할때는 거의 java를 주로 씁니다. 이유는 개발 기간이 빠르기 때문이고 프로그래머가 연봉이 싸죠(쉽게 구할 수 있고 ^^;)..
그리고 자체 개발프로젝트를 진행 할때는 주로 C++을 사용합니다.
이유는 자체 아이템은 주로 보안에 강해야 하거든요 알고리즘이나 스펙이 자바는 쉽게 노출 되드라고요(한번은 자바 프로그래머 외주 받은 프로그램을 다시 자바코드로 만드는데 깜짝 놀랬어요
알고리즘이 그대로 노출 되더라고요) 제가 주로 C++을 사용해서 이런결과가 생기지만 지금은 Java도 공부하고 있읍니다. 관리를 하자면 잘 알아야 하겠더라구요. 개인적으로 자바도 깔끔하고 쉽게 배울수 있고 장점이 많더군요.. 그래서 두 언어는 서로 장단점이 많이 있어서 같이 쓰게 되죠...
횡설 수설 이었습니다.....
참, 혹시 자바 알고리즘 노출안되게 하는 방법 아시는 분 있나요..
배운걸 그냥 놀리기 싫은데 그점이 문제더라구요.. (자바는 제가 잘 몰라서 ^^;)
그리고 중요한건 언어가 아니고 자기만의 가지는 노하우 입니다.
비젼 쪽이라던지 압축 알고리즘이라던지, 인공지능 이라던지 하는 현업에서 다른사람이 쉽게 할 수 없는것들 이죠...
이런 백그라운드가 없으면 프로그래머가 아니고 그냥 코더죠...
저의 짧은 생각이었습니다.
알고리즘 노출이라고 말씀하신 부분은 역컴파일 문제를 지적하신 것 같습니다
알고리즘 노출이라고 말씀하신 부분은 역컴파일 문제를 지적하신 것 같습니다.
jad 같은 프그램으로 쉽게 거의 완벽한 소스를 재현할 수 있는 반면 시중에 역컴파일 방지 소프트웨어가 많이 나와 있으니 이용해보시기 바랍니다.
상용프로그램들은 이런 기술을 적용해서 나오는 경우가 많더군요...
그럼...
정말 Java 프로그래머가 연봉이 싼가요?전자신문에서 전에 Jav
정말 Java 프로그래머가 연봉이 싼가요?
전자신문에서 전에 Java가 뜨면서 java 프로그래머 연봉이 천정부지로
치솟는데 반해 정작 실력자는 드물다고.. 그런 기사를 봤었는데...
그래서 그런 줄만 알았는데 역시 신문은 믿을게 못 되는구만요. 쩝
Java는 하지 말아야지.. ^.^
멀해야 연봉을 많이 받을라나?
Embeded linux 개발자는 돈 좀 벌려나?
개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?
글쎄요...확실한건언론에서 뭐 뜬다...이런거 다 믿지 말아야 할
글쎄요...확실한건
언론에서 뭐 뜬다...이런거 다 믿지 말아야 할듯...황색저널리즘 -_-;
인터넷 거품도 사실 언론이 만들어낸거 아닐까요?
자바도 뜬다 그러면...자바 프로그래머 똥값될듯...
고수들이야 제값받겠지만...막 학원 3개월 출신이 신입으로 들어가면
80정도 받겠죠
DEVPIA의 C# 담당자가 쓴글입니다..---------------
DEVPIA의 C# 담당자가 쓴글입니다..
-------------------------------------------------------
목 : EJB...엔터프라이즈(?)...푸하...뺏길려면 좀 제대로 하지..쯧쯧
EJB, J2EE는 사실 MTS 를 중심으로 한 마이크로소프트의
컴포넌트 미들웨어를 그대로..답습했습니다..
근데...
좀 EJB....뺏기려면 좀 제대로 했어야 하는데....
정말 단점이 많은 기술이더군요..
사실 자바 하는 사람들이 하도 좋다 그래서...
서버 쪽에 많이 사용한다느니...다 그걸 선택할꺼라느니...해서...
저도 최소한 MTS의 문제점은 고쳐 놓고...
최소한 COM+정도랑 비교할 만하겠지..라곤 생각했는데..
사실 저도 좀 기대는 했었는데..
보니까 .. 그게 아니더군요..
물론 좋은 것도 있어요..근데...
제가 보기엔 단점이 워낙 많아....서...그거 장점이라고 이야기하기
좀 민망하겠더군요.
포니엔진에, 중고타이어, 그랜저 껍데기 가진 차를..진짜 소나타 보다..
몇배나 돈을 더주고 사서...
껍데기 가 그랜저라고 자랑할 순 없는 노릇이잖아요...
특히 BEA의 WebLogic 서버 ...컴포넌트 하나 올릴때 마다..
왜 서버를 새로 시작해야되는지..
JSP 코드 하나 고칠때 마다...세션 정보를 새로 고쳐야 하고..
그 엔티티 빈인가 하는 거는 걍 아파트먼트도 아니고..
STA더만요..VB 5.0의...
더군다나 COM+에서 말하는 FTA나 NTA모델 같은 거는 없더군요..
성능은 우짤란고..하긴 그라이 $UN이나 IBM같이 하드웨어 팔거나...Oracle처럼 DB파
는 데가 목슴걸고 하지..안돌아가? 우리꺼 더 사..
사실 이거 말고도 웃기는 게 한두개가 아니던데..
실제 제품도...만족스럽지 못한데다..
사실 EJB 스팩 자체도..좀 비현실적이구..
뭔 스팩에 따르면 Pass by value만...허걱..그거 부하 우짤라고..
더군다나..객체 그래프 모두 지원할 수 있는 J2EE서버도 한정적이라던데..
보안상의 구멍하며..특히 서블릿에서...아주 왕구멍이더만요..
흐흐...플렛폼엔 독립적인데, 우째 각 벤더들에겐 종속적인지...
이걸 어떻게 해석해야 될지...
방금 말한 것들은 대부분 J2EE서버 중에서도..
젤 잘팔린다는 WebLogic이야김다..그려...풋...
더군다나 JAVA의 미래도 불투명하겠더군요...
JAVA의 가장 강력한 지지자인 IBM이 좀 삣긴거 같더군요..
하긴 나라도 삣기지...
같이 개발하자고 해놓고..개발하고 나니까..$UN이 중간에서 탁 가로채갔고..
이젠 라이센스비 내놔라..하고 버티고 있으니..
IBM이 보면 $UN이 얼마나 같잖게 노는 거 겠습니까..
그런 이유 땜에 오픈 소스 진영도..$UN에 좀 삣겨있구...
그래서..IBM이 만든 SOAP관련 Toolkit은 아예 $UN쪽으로 줄거 같지도 않고..
그것도 허덥하긴 했지만..
우씨....좀 짜증나더군요..저렇게 허덥하게 구현한 넘을 보고..좋다구..
괜히 책 사봤잖아요..잉..돈 아까비...
완전히 속은 느낌이 듭니다.
엔터프라이즈란 이름만 붙이면 걍 엔터프라이즈가 되는 줄 아는가보죠..
전 이렇게 생각이 들더군요...
"아마 EJB 하는 사람들은 다른 분산 객체 미들웨어 는 함도 안써봤는 갑다..그러니 저
렇게 좋아하지...순진하긴.."
여긴 WebLogic 써보신 분들 안계시겠지만...
걍 COM+나 열심히 하세요..EJB는 별로 고려할 가치가 없더군요..
제가 보장하죠...
어플리케이션 서버로는 더이상 ....비교는 무의미하겠더군요..
아마 .NET COM+나오면...머리가 있는 사람이면 뭐가 좋은 것인지..
알게 되겠죠...
추신.
JDBC 자료 계신 분은...저한테 보내주시면 후사하겠습니다.
//DEVPIA에서 펀글-------------------------
//DEVPIA에서 펀글
--------------------------------------------------------------------------
저는 asp한지 1년 반이 된즈음에 작년 8월쯤 Sun java 전문가 과정을 수료하고
jsp프로젝트에 참여했습니다.
그때만해도 jsp가 엄청 떴었고... asp의 단점을 jsp가 해결해준다 생각했엇쬬..
저도 asp가 넘 한계가 많다고 생각을 했었고(짧은생각에) 먼가 새로운걸 해보고 싶었
어요..
그런데 프로젝트가 진행되면 진행될수록 db연결이 넘 불안했습니다.
컨넥션 풀링...
ms는 odbc, oledb로 먼가 한가지로 통합되어 있잖아요..
그런데 이넘의 자바는 컨넥션 풀링해주는 소스만 해도 가지 각색입니다.
마치 파일 업로드 컴퍼넌트가 여러가지 있듯이..
첨에 많이 쓰는 컨넥션 풀링을 썼죠..
처음에 사용자가 많지 않을때는 문제가 없었는데 갑자기 서버당 동시 사용자 600명이
넘어가니 난리가 난더군요..
6개월의 프로젝트를마무리하고 2월 1일 오픈을 했는데 갑자기 사용자가 폭주하니 db서
버가 죽어버리더군요..(선 8500 이면 억대 서버이죠)
컨넥션풀링이 꽉 차버려서... sql문 사용하고 nothing해줘도 이게 제대로 해제를 못시
켜주공...
결국 다른 컨넥션풀로 다 대치하고... 난리도 아니었슴다.
서버 며칠 지나믄 꺼뻑 죽어버리고..알고 봤더니 제가 만든 사이트만 그런게 아니라
jsp로 만들어진 큰 사이트들도 심심하면 죽는다고 하더군요..
유명했어요... 웹로직 웹스피어 이넘들도 무지 비싸면서도 웹서버에서 가장 중요한게
끊기지 않는 서비스인데 심심하면 죽고 다시 시작해줘야 하니 원..
게다가 비용이 진짜 장난이 아닙니다.
웹로직을 사용할 정도의 사이트라면 로드발란싱이 필요하겠죠?
로드발란싱 지원하는 웹로직의 가격이 대단합니다.
cpu당 2800만원
4cpu에 2대만 사용하다고 해도2800 X 8 = 22400 만원..맞나요?
MTS쓰믄 공짜인데...
이거 배보다 배꼽이 더 큰거 아닙니까?
개발비보다도 더 비싼것 같슴다. 쩝...
java로 웹사이트 개발해보고 아주 jdbc, connection pooling에 치를 떨고 있슴다.
jsp, asp 많은 고민을 했었죠..
원래 계획은 자바를 좀 더 공부해보고 8월쯤에 .NET으로 다시 돌아설 생각이었는데
이제는 미련 없슴다.
6개월이 넘게 딴짓한게 넘 시간아깝네요..
그렇다고 후회하지는 않아요..
자바가 머가 문제인지 확실히 알았고 .NET에 확신을 가질 수 있게 된 계기였슴다.
java하는사람들 100이면 100이 MS를 무시하죠..
그런데 웃긴건 그사람들 100이면 100이 MS쪽 개발을 한번도 안해보고 그렇게 말을하는
데... 쫌 웃기죠?
이제는 그렇게 말을 하면 그냥 피식 웃고 맙니다.
여러분 ...확신을 가지셔도 좋습니다.
자바 이건 넘 불안해요..
다들 그렇게 말하고 있고 요즘 누구나 jsp로 만들먼 꺼뻑하면 서버 죽는다는 말을 하
고 있슴다.
그리고 속도가 빠르다고 했는데 절대 안빨라요...
차라리 그냥 asp스크립트로 하지...
작년에 본건데 자바진영에서 asp, jsp를 비교해놓은자료가 있슴다.
http://www.jspinsider.com/articles/jspasp/index.html
sun에서 말하는것두 있구요
http://java.sun.com/products/jsp/jsp-asp.html
그런데 얼마전에 읽은
.NET vs Java 2 Enterprise Edition (J2EE) 비교
이거 정말 공감합니다. 해보니 그말이 딱이에요....
암것도 모르고 막짜니까 그렇죠.ASP,VB,MTS,VC(뭐라고 하나라
암것도 모르고 막짜니까 그렇죠.
ASP,VB,MTS,VC(뭐라고 하나라고 말하기에도 어려운... 혼란)도
첨하는 사람이 책한권 사놓고 사이트 만들면 죽는 건 마찬가지 아닙니까?
iis에서 "트랩 오류. 알 수 없는에러" 이 메시지 보셨겠죠?
첨에는 정말 황당하지 않습니까? 근데 고수들은 대충 무엇무엇무엇을 점검하면 원인을 찾을 수 있다 라는 걸 알지 않습니까?
Java,Servlet,EJB쪽도 마찬가지 입니다. 첨에 책한권보고 ASP,PHP하듯이 막짜면 ASP,PHP보다 훨씬 어려워지고 서버는 막 죽고.
자기가 좋아하는 것 잘하는 것이 잘알지 못하는 것보다 훨씬 쉽고 편한건 당연하겠죠.
근데 .NET은 아직 실체도 없는 뜬 구름 아닙미까? 뭘 믿으시는 건지.
전 MS부터 먼저 시작했는데
저도 위에 글쓰신 분이 EJB에 대해 느낀 감정을 MS 플랫폼에 똑같이 느낌니다.
저보고 다시 MS 플랫폼에서 웹 개발하라고 하면 배째라고 하겠습니다. 진짜 싫습니다.
PS. 저도 사실은 .NET을 기다리고는 있습니다. Java랑 비슷하다고 하니깐 윈도용 클라이언트 어플짤 때는 유용하지 않을까 싶어서... .NET에 GUI에 관한 라이브러리같은 것도 SPEC에 정해졌있을랑가... 쩝.
질문인데요.IIS에서트랩 오류. 알 수 없는에러 는 왜 나는 거죠
질문인데요.
IIS에서
트랩 오류. 알 수 없는에러 는 왜 나는 거죠.
고수면 알 수 있는 쉬운 에러인가요... 흑~
저는 MS도 모르는 에러라구 생각해서 걍 그러려니 했는데
아시면 좀 가르쳐 주세요.
이미 .NET의 스펙은 나와 있습니다. 결코 뜬구름이 아닙니다. 오픈소스
이미 .NET의 스펙은 나와 있습니다. 결코 뜬구름이 아닙니다. 오픈소스 진영에서도 .NET중에서 CLR인지 CRL인지... 준비하고 있습니다.
님이 JAVA가 해볼만하다는 것은 플랫폼인지, 언어인지 모르겠지만(JAVA는 플랫폼과 언어를 동시에 포함하기 때문에...)
적어도 JAVA의 단점은 해결했다고 보여지며(플랫폼에서는 .NET, 언어에서는 C#)
.NET & C#을 준비하는 것도 나쁘지만은 않을 것입니다.
자신에게 맞는 것을 써야 최적의 효과를 낸다는 것이 결론인것 같군요.
전 공감할 수 없는 내용이군요.저는 오히려 M$의 개발툴에 질렸습
전 공감할 수 없는 내용이군요.
저는 오히려 M$의 개발툴에 질렸습니다.
M$게 아니면 안되고, 다른 대안도 별로 없고,
지금까지 불안한 제품을 팔아온건 M$가 아니던가요?
윈도우즈 시리즈를 비롯하여 ....
물런 기능은 좋은 제품들이지요.
그런데 이글에는 마치 M$의 제품이 최고의 안정성을
가진 것 처럼 간접묘사가 되있군요.
지금까지 써본 결과 결코 아닙니다.
오히려 그 반대지요.
다른 것은 대안이라도 있지만 M$는 자기가 뛰어난 실력으로
만들던가 아니면 기다려야지요. 물론 조금 기다리면 나오기는
하데요.
제가 M$에 감사하는 것은 IBM,Oracle,BEA, 등등
천정부지로 값을 메기는 회사들을 경쟁제품으로
그 가격을 사정없이 후려쳐서
아주아주 감사하고 있습니다.
정말 이 부분만큼은 M$의 존재에 감사를 드리고 싶습니다.
그리고 이글의 주제인 자바는 해볼만한 언어입니다.
(이쪽에 붙이는 것인데... 엉뚱한 곳에 붙네요...)C# 은 J
(이쪽에 붙이는 것인데... 엉뚱한 곳에 붙네요...)
C# 은 JAVA를 제대로 빼꼈나요?
아직 베타 버전이라 나무라기는 뭐하지만...
기존의 Visual J++ 버전에다가 패키지 명만
C/C++ 과 Object PASCAL(Delphi포함)에서 빌려와서 쓰고 있고
달라진 것은 별로 없는 것 같습니다.
JAVA를 잘 모른다는 사람이 코딩도 제대로 해보지 않고
그리고 각종 툴들도 셋팅하거나 사용도 해보지 않은 상태에서
그저 책에 나온 기본적인 사용법 정도나 읽어보고
판단한다는 것이 MCT 의 능력이라는 생각도 듭니다.
특정 언어에 맹목적일 필요는 없는 것 같습니다.
MS의 맹신도나 다름없는 사람들 입에서 나오는 말...
MS가 잘 되야지 자신들의 입지가 보장되는 사람들의 말...
이런 말들에 현혹될 필요는 없다고 봅니다.
BSD 나 Linux / Solaris 사이에 지원 정도의 차이는
JAVA지원의 차이라기 보다는
프로그래머의 운영체제에 대한 숙련도의 문제가 더 크다고 봅니다.
모든 운영체제의 세부적인 영역을 제대로 이해하는 사람이 얼마나 되겠습니까?
커널이 다른데 한쪽 마인드로 무장된 사람이 다른 영역에서는 버벅거릴 수밖에 없겠죠...
주의를 환기하고....
;
;
;
JAVA(EJB포함)는 나름대로 특성이 있고...
프로그래밍하는 것이 좋아서 시작하는 사람들에게는
낮은 단계부터 시작해서 올라간다는 점에서 매력이 있다고 봅니다.
C/C++ 은 그동안 오랜 기간 노하우가 쌓였고
제대로 구현하는 사람들은 상위 레벨의 소수 뿐입니다.
또한 UNIX 진영의 프로그래머냐 아니면 MS NT 영역의 프로그래머냐에
따라서 역량에도 차이가 많이 나지요...
(뒤 늦게 시작하는 사람들이 그 사람들도 동등 레벨이나
그 레벨을 뛰어 넘기 위해서는 무한 영역의 노력이 배가되야 합니다.
혹시 그리스 철학자 제논이 주장한 "제논의 역설"을 아시나요?
'아킬레스와 토끼의 경주'
역설이지만 물리적인 근육운동의 영역이 아닌
지적 세계로 들어오면 결코 '역설'이 아닙니다.)
C++로 MTS 를 제대로 구현하려면 많은 시간과 노력이 필요합니다.
하지만 EJB는 지금 막 시작단계고...
지금이라도 마음 먹으면 쉽게 접근하고
MFC 마스터 하는데 걸리는 이전 단계의 노력이라면
JAVA 는 이미 EJB 영역에 들어오고 남음이 있습니다.
후발 주자지만 선발 주자의 역량을 뛰어 넘을 수 있는 기회가
JAVA에게는 있습니다.
그리고 Linux를 선호하는 사람들도 결국은
기존 UNIX 라는 '철옹성'의 한계를 극복하고자 하는 것이 아닙니까?
(자신의 무의식 영역에 자리잡고 있는 자괴감을 들춰보세요.)
다시 주의 환기...
;
;
;
Java의 무용론을 주장하는 사람들은
이미 UNIX C/CPP 나 MS의 VC++이 이미 골수에 사무쳐서
전향하기 힘든 사람들의 입으로 부터 시작되는 것입니다.
그동안 JAVA로 전향하기를 주저해 오다가
새로운 것에 대한 도전으로 기존의 기득권 조차도 잃지 않을까
하는 막연한 두려움에서 망설이다가
이제 홀연히 뛰어들 수 없다는 판단에 섰기 때문에
'자기 합리화'의 반(半)무의식의 발로입니다.
이솝우화에 "배고픈 여우와 포도" 이야기 처럼요.
C++(특히 VC++)을 하는 사람들(특히 경력이 4~5년 정도) 사이에서나
나올 수 있는 얘기들입니다.
작년에도 KIST에서 프로젝트를 뛰던 연구원 출신의 프로그래머가
말하더군요...
매력적이지만 새로운 영역을 하기가 쉽지 않다구요.
부담도 크고 이미 머리가 굳어버려서 새로운 언어를 공부한다는 것이
두렵다는 것입니다.
그냥 참고로 하세요...
저도 VB, C/C++,Delphi 모두 경험해 봤지만...
JAVA만큼 학습욕을 충족시켜주지는 못하더군요...
지금은 EJB와 DBA 분야에 중점을 두고 있습니다.
왜 닷넷이, 자바를 베꼈다고 생각하시죠?나중에 나온 언어는 다른
왜 닷넷이, 자바를 베꼈다고 생각하시죠?
나중에 나온 언어는 다른 언어의 장점을 취사선택하기 마련입니다.
자바쪽에 들어간 개념중엔 ms에서 나온것도 많아요. beans 나오기 전에도 ms에선 ole, active-x 등이 돌아갔죠.
"Java의 무용론을 주장하는 사람들은
이미 UNIX C/CPP 나 MS의 VC++이 이미 골수에 사무쳐서
전향하기 힘든 사람들의 입으로 부터 시작되는 것입니다. "
이것도,.. 뭐 그런사람도 있겠지만 꼭 그런건 아니에요. java 한사람은 ms쪽으로(혹은 linux로) 전향하기가 쉽습니까? 서로 마찬가지죠. 그리고 아마도 몇은, java로 굳이 전향할 필요를 못느끼는 사람도 있을겁니다.
전 Java가 쓸모없다거나, 미래가 어둡다거나... 하고 생각하진 않습니다.
전에 Java공부를 (약간) 했었는데, 하는 일이 ms쪽이다 보니 요샌 거의 손을 못대고 있네요.
팔이 안으로 굽어선지, geekforum에선 거의 ms 골수처럼 글을 쓰고 다닙니다만,
이러는데엔, MS에 좀 공정하지 못한 것 같은 느낌도 있어서 그렇습니다.
특히나 SUN에 대해선 그리 좋은 감정을 못갖겠네요. 그들이 MS와 다른점이 뭡니까?
왜 SUN은 마치 MS보다 나은 회사인양, 취급받아야 하는지 모르겠습니다.
Devpia C# 담당자라면 자기 입으로 JAVA를 모른다고 하던 사람이
Devpia C# 담당자라면 자기 입으로 JAVA를 모른다고 하던 사람이
너무나 잘 알고 있는 것처럼 말하네요...
몇 일 전까지만 해도 그랬는데...
홍영준 씨가 맞는 지 모르겠네요...
C# 은 JAVA를 제대로 빼꼈나요?아직 베타 버전이라 나무라기는 뭐
C# 은 JAVA를 제대로 빼꼈나요?
아직 베타 버전이라 나무라기는 뭐하지만...
기존의 Visual J++ 버전에다가 패키지 명만
C/C++ 과 Object PASCAL(Delphi포함)에서 빌려와서 쓰고 있고
달라진 것은 별로 없는 것 같습니다.
JAVA를 잘 모른다는 사람이 코딩도 제대로 해보지 않고
그리고 각종 툴들도 셋팅하거나 사용도 해보지 않은 상태에서
그저 책에 나온 기본적인 사용법 정도나 읽어보고
판단한다는 것이 MCT 의 능력이라는 생각도 듭니다.
특정 언어에 맹목적일 필요는 없는 것 같습니다.
MS의 맹신도나 다름없는 사람들 입에서 나오는 말...
MS가 잘 되야지 자신들의 입지가 보장되는 사람들의 말...
이런 말들에 현혹될 필요는 없다고 봅니다.
BSD 나 Linux / Solaris 사이에 지원 정도의 차이는
JAVA지원의 차이라기 보다는
프로그래머의 운영체제에 대한 숙련도의 문제가 더 크다고 봅니다.
모든 운영체제의 세부적인 영역을 제대로 이해하는 사람이 얼마나 되겠습니까?
커널이 다른데 한쪽 마인드로 무장된 사람이 다른 영역에서는 버벅거릴 수밖에 없겠죠...
주의를 환기하고....
;
;
;
JAVA(EJB포함)는 나름대로 특성이 있고...
프로그래밍하는 것이 좋아서 시작하는 사람들에게는
낮은 단계부터 시작해서 올라간다는 점에서 매력이 있다고 봅니다.
C/C++ 은 그동안 오랜 기간 노하우가 쌓였고
제대로 구현하는 사람들은 상위 레벨의 소수 뿐입니다.
또한 UNIX 진영의 프로그래머냐 아니면 MS NT 영역의 프로그래머냐에
따라서 역량에도 차이가 많이 나지요...
(뒤 늦게 시작하는 사람들이 그 사람들도 동등 레벨이나
그 레벨을 뛰어 넘기 위해서는 무한 영역의 노력이 배가되야 합니다.
혹시 그리스 철학자 제논이 주장한 "제논의 역설"을 아시나요?
'아킬레스와 토끼의 경주'
역설이지만 물리적인 근육운동의 영역이 아닌
지적 세계로 들어오면 결코 '역설'이 아닙니다.)
C++로 MTS 를 제대로 구현하려면 많은 시간과 노력이 필요합니다.
하지만 EJB는 지금 막 시작단계고...
지금이라도 마음 먹으면 쉽게 접근하고
MFC 마스터 하는데 걸리는 이전 단계의 노력이라면
JAVA 는 이미 EJB 영역에 들어오고 남음이 있습니다.
후발 주자지만 선발 주자의 역량을 뛰어 넘을 수 있는 기회가
JAVA에게는 있습니다.
그리고 Linux를 선호하는 사람들도 결국은
기존 UNIX 라는 '철옹성'의 한계를 극복하고자 하는 것이 아닙니까?
(자신의 무의식 영역에 자리잡고 있는 자괴감을 들춰보세요.)
다시 주의 환기...
;
;
;
Java의 무용론을 주장하는 사람들은
이미 UNIX C/CPP 나 MS의 VC++이 이미 골수에 사무쳐서
전향하기 힘든 사람들의 입으로 부터 시작되는 것입니다.
그동안 JAVA로 전향하기를 주저해 오다가
새로운 것에 대한 도전으로 기존의 기득권 조차도 잃지 않을까
하는 막연한 두려움에서 망설이다가
이제 홀연히 뛰어들 수 없다는 판단에 섰기 때문에
'자기 합리화'의 반(半)무의식의 발로입니다.
이솝우화에 "배고픈 여우와 포도" 이야기 처럼요.
C++(특히 VC++)을 하는 사람들(특히 경력이 4~5년 정도) 사이에서나
나올 수 있는 얘기들입니다.
작년에도 KIST에서 프로젝트를 뛰던 연구원 출신의 프로그래머가
말하더군요...
매력적이지만 새로운 영역을 하기가 쉽지 않다구요.
부담도 크고 이미 머리가 굳어버려서 새로운 언어를 공부한다는 것이
두렵다는 것입니다.
그냥 참고로 하세요...
저도 VB, C/C++,Delphi 모두 경험해 봤지만...
JAVA만큼 학습욕을 충족시켜주지는 못하더군요...
지금은 EJB와 DBA 분야에 중점을 두고 있습니다.
님이 쉽게 배울 수 있다는 것은 남도 마찬가지입니다.
님이 쉽게 배울 수 있다는 것은 남도 마찬가지입니다.
누구나 쉽게 배울 수 있기 때문에 좋다는 것 아닙니까?문제는 구현
누구나 쉽게 배울 수 있기 때문에 좋다는 것 아닙니까?
문제는 구현하는 마인드죠...
언어나 문법을 쉽게 배워 접근하고 많은 사람들이 쓴다면
그것이 좋은 것이죠...
게다가 안정적이라면...
누구나 쉽게 할 수 있는 언어...
그리고 그 기본위에 자유로운 사고의 발현...
그 보다 더 좋을 순 없을 것입니다.
거기서 나오는 생산성...
한글이든 영어든
자신이 생각하고 있는 것을 자유롭게 구현할 수 있는 언어...
JAVA 로 시를 쓴다는 상상을 해보세요... ^^;;
(비유가 적절한가???)
여긴 C 잘하시는 분들이 많으신가 보군요..^^;전 주특기가 특별
여긴 C 잘하시는 분들이 많으신가 보군요..^^;
전 주특기가 특별히 없어서.. 잘하는게 없는데요.
사람들이 서버딴에서는 java가 살아남았다고 하는데요..
// 메모리만 많으면 java 경우 메모리에서 다 돌리니 왕 느리다고는 할수 없죠...
실제로 요즘은 php랑 jsp랑 비교하면... 음..
실제 사이트에서 클라이언트 부분에서도 swing 이용해서 java로 하는 곳도 시험적이나마 있다고 하더군요...
특히나... RDB와의 연동에서 java 언어자체의 통일된 지원은 java의 장점인거 같습니다.
같은 기능이라도..
// 특히 스트링 장난 할때..
unix c 의 길이보다 java로 하면 1/2~1/3정도로 코드가 줄어들던데요...^^;
결론은...
C가 맞을때가 있고 // C가 맞은 부분이 있죠.........
Java가 맞을때도 있고...
주특기 하나 가지시고 side로 다른 언어도 아시면...
좋지 않을까요???
// 여기 자바 웹 사이트 아니죠? ^^;
서버 프로그래밍에서 속도가 안빨라도 되는이유.조금 다른예기일지는
서버 프로그래밍에서 속도가 안빨라도 되는이유.
조금 다른예기일지는 모르지만, 펄이나 심지어는 파이썬같은
언어도 서버 프로그래밍에 써도 문제가 안되는 이유는 이겁니다.
TCP에 대한 책에서 나오는 예긴데,
네트워크상에서 동작은 크게 두가지로 나뉩니다.
RTT(Round Trip Time)와 SPT(Server Process Time)
네트워크 속도의 느림으로 인해 거의 언제나 RTT가 SPT보다
큰 관계로 SPT가 어느정도 늘어나는게 별로 큰 차이가
안나는 거죠.
예를 들어 일반적인 WAN에서 RTT는 200ms정도 됩니다.
(한국에서 워싱턴 갔다오는 정도?)
200ms면 요새 펜티엄 III 800MHz는 웬만한거 다끝내고
놀고 있을 시간입니다.
그러니 적어도 서버 프로그램에 있어서 심지어는 파이썬처럼
자바보다 2~3배 느린 언어도 높은 생산성때문에
충분히 가치가 있는겁니다.
이상 읽어주셔서 고마워요~~~
초당 100건 1000건 1000건을 처리해야 하는 경우는??증권전산
초당 100건 1000건 1000건을 처리해야 하는 경우는??
증권전산 등등...
어떻게 해결하죠?
한국통신 사내 교육용 인트라넷을 선 솔라리스에 펄로 올려서 구축한걸본
한국통신 사내 교육용 인트라넷을 선 솔라리스에 펄로 올려서 구축한걸
본적이 있습니다. 사용자가 수만명에 이르고, 동시사용자 역시 수천명이상입니다.
그러나 아주 잘 돌아갑니다...
이 경우는 펄 자체가 아직 스레드 지원을 안하기 때문에 사용자 증가할때마다
프로세스 포크하는 방식인데,
자바의 경우는 스레드 지원이 되니 훨씬 더 낫지요.
동시사용자 수십만명대인 구글은 리눅스 서버 4,000여대에 자바보다 5배 가량
느린 파이썬으로 구축되어 있습니다.
대개 RTT가 SPT에 비해 수십배이상이기 때문에 SPT 5~6배 증가한다고 해도
별 차이가 않납니다.
심한 부하에 대한 처리는 단지 코드 최적화 정도가 아닌
분산처리같은 부분을 고려해야 하는데, 이 부분 역시 C/C++이 자바나 펄, 파이썬
등에 비해 우위에 있다고 보기 어렵습니다.
but what if many people access the same
but what if many people access the same program at the same time?
자바에서 마우스 커서 움직이면 화면 깨지는 경우 있습니다..바로 마우
자바에서 마우스 커서 움직이면 화면 깨지는 경우 있습니다..
바로 마우스 커서 크기가 표준(?)이 아닌 경우입니다.
윈도우는 다양한 크기의 마우스 커서를 지원하는데 이걸
자바가 제대로 인식못하는 것 같더군요. 표준크기의 마우스
커서는 괜찮은데 제가 사용하던 그 무식하게 큰 마우스 화살표..
가 움직이면 화면이 왕창왕창 깨졌습니다. 저도 그거 보고서
욕 많이 했었죠.. 나중에야 우연히 알았습니다. 마우스 커서
크기때문에 그렇다는걸.. JBuilder 3.5에서 그랬습니다.
저같은 경우, 조금이라도 (자발적으로) 공부해 본 언어는Basic,
저같은 경우, 조금이라도 (자발적으로) 공부해 본 언어는
Basic, C, Perl, Python, Java 쯤 됩니다.
C++ 은 학기 과목에 있어서 듣긴 했지만, 들은 후로
쓰레기라는 관념에 머리에 박혀서 들어오질 않습니다.
지금은 자바에 빠져서 살고 있지요.
그래서...
우선은 아는 것만 반박해 보자고 한다면,
> - 마우스 지나간뒤 엉망이 되는 어설픈 화면,
학교 컴퓨터는 대부분 펜티엄2 200 정도에 램 32~64메가 정도입니다.
주로 스윙을 이용해서 GUI 를 구성하는데, 전혀 깜빡임이나
마우스가 지나가면 엉망이 되었다거나 하는 기억은 전혀 없었습니다.
(물론 paint 나 update 를 잘못 작성해서 그런적은 있지만...)
최근에 지뢰찾기 게임을 만든다고 버튼을 몇백개씩 배치하고,
여기다 MDI 식으로 해버리니 좀(많이) 느리긴 했지만요...
아마도 그것은 플랫폼 적인 문제가 아니었는지요?
> - Qt에 비교해서 (개인적인 생각으로) SLOT 과 SIGNAL 개념에 비교하여
> 철지난 C의 callback 함수사용과 번잡한 Event 모델을 쓰는 것,
QT... 제가 C++ 을 싫어하는 관계로 잘 모릅니다.
(GTK+ 는 그나마 조금...)
그러나, 자바 프로그래밍을 해보면서, VC++ MFC 에서 만큼의 황당함이나
어려움을 격지는 않았습니다. 과연 번잡하다는 것은 어떤 뜻인가요?
> - 순수 객체지향으로 인한 오버헤드 (당연한 것이지만...)
이건 어쩔 수 없으리라 생각되지요?
그러나, C++ 에 비해서 쉽다는 것은 누구나 아실것입니다.
저수준(low-level)인것을 빼버렸으니 왠지 안심도 되구요.
> - 말처럼 되지 않는 플랫폼 중립,
일단 제가 작성해 본 코드들은 모두 플랫폼 중립적으로 돌아가는군요.
앗, 맥에서는 테스트 못해봤군요.
일단 이부분에 대해서 반박할 수는 없겠습니다.
아참, GUI 애플리케이션의 경우 폰트 문제는 좀 있겠더군요.
흠... 보니깐 거짓말이 하나 있군요. 윈도우 플랫폼에서 println 은
캐리지 리턴이랑 폼피드, 유닉스 플랫폼은 걍 하나만... -_-;
이것은 플랫폼 고유의 성격이라서 그런가?
> - 늦은 속도
위에서 나온것 때문이죠? 순수한 객체지향과 프리플랫폼 지향.
> - 정작 LINUX나 FreeBSD에서는 Solaris에서처럼 지원되지 않는 것
솔라리스에서는 뭐가 특별히 지원되나요?
궁금해서 그럽니다.
속도 문제 빼고는 제가 알기론 특별한 차별은 없는듯 합니다.
일단 여기까지 개인적인 선입견 이었습니다만,
저도 자바가 완전히 좋지는 않습니다.
C 로 시작해서 C 로 죽자고 할 정도로 광적인 C 팬이었던 저로서는,
자바의 많은 부분이 좋지 않게 보이죠.
그러나, 그 편리성 만큼은, C 가 멀어 보입니다.
그래서 저는 파이썬을 제일 좋아합니다. ^^;
왠지 헛소리 같군요...;;; 죄송...;;;;
--
http://renn.sapzilla.org/
질문입니다.. sayclub은 뭐로 만들어졌습니까?jsp?
질문입니다.. sayclub은 뭐로 만들어졌습니까?
jsp?
자바로 만들어졌다고 하는데 세부기술이 뭐로 되어 있는지 궁금
함다.. 자바빈즈를 박아넣었나~... 대체 알 수 없군요
제가아는 범위에서 이야기 해드릴께요..여기 주세와 많이 어긋나는데
제가아는 범위에서 이야기 해드릴께요..
여기 주세와 많이 어긋나는데
하여튼
기본 스크립트는 PHP와 Java Script 입니다.
그리고 소켓 통신으로는 Java Applet를 가지고 합니다.
이 에플릿은 웹브라우저에서 숨겨 놓고 사용합니다.
(1) 클라이언트 측의 자바, 즉 스윙이나 AWT는 이미 사장된 기술이라
(1) 클라이언트 측의 자바, 즉 스윙이나 AWT는 이미 사장된 기술이라고 봅니다. 스윙의 경우 플랫폼 독립적인 특성상 때때로 상당히 유용한 어플리케이션을 제작할 수 있지만 아무래도 네이티브 어플리케이션보다 사용성과 속도가 떨어지는 건 어쩔 수 없습니다. 아마 J2SE1.4가 나오거나 자바기반 OS가 나오지 않는다면 클라이언트 어플리케이션에서 자바는 절대 대세를 이룰 수 없습니다.
(2) EJB를 포함한 J2EE 플랫폼의 발표 이후 논란의 여지는 있지만 서버측에서 자바의 위치는 거의 독보적입니다. 특히 제작하는 어플리케이션의 규모가 클수록 장점이 잘 부각되는 것 같습니다. .NET이 서버측에서 자바를 따라잡기는 아직 부족해보이는 군요... 게시판 정도 두들겨 만들기는 PHP, ASP, JSP나 거의 차이가 없지만 복잡한 설계를 필요로하는 대규모사이트에서는 거의 선택의 여지가 없다고 봅니다.
(3) 다른 모든 장점보다 상용언어 중 가장 객체지향 개념에 근접한 언어라는것이 마음에 듭니다. 클래스를 쓴다고 다 객체지향이라면 VB도 객체지향 언어라 할 수 있습니다. 하지만 Swing패키지만 한 번 뜯어봐도 그 자체가 디자인패턴과 OOP의 살아있는 교과서임을 알 수 있습니다. 서버측에서도 EJB패턴카탈로그 등 참신한 디자인 이론이 많습니다.
C#이 자바를 죽이려고 나왔다고는 하는데. 어찌됐건VM기반 환경은 대
C#이 자바를 죽이려고 나왔다고는 하는데. 어찌됐건
VM기반 환경은 대세가 되어 가는군요.
사실 VM기반이란게 시스템의 물리적인 부분으로부터 개발자를 떼내서
순수 응용프로그램개발에만 집중하도록 하자는게 그 근본이라
시스템환경에 대한 지식없는 일반인도 쉽게 다가갈수 있다는건 상당한 진보라고 생각됩니다.
아울러 많은 사용자들이 네트워크(인터넷)으로 집중되있는
상황에서 OS를 기반으로한 클라이언트 컴퓨팅이 계속해서 발전할것이냐
하는것두 의문이 들기도 합니다.
물론 현재는 메일검색이나 채팅등등 시시한 수준이지만 생각하기에 따라
좀더 높은 수준의 작업도 점차 이루어지는것으로 알고있습니다.
그 최전방에 자바가 있고 2선에 C#이 있으니 바야흐로 새시대가 목전앞에
와 있다는게 느껴지네요.
물론 전통의 C/C++/COBOL/POTRAN 이 계속 사용되기는 하겠지만
그 영역이 시스템의 물리적 처리를 위한 부분으로만 한정되지 않겠나
하는 생각입니다.
따라서
자바를 배우는것은 단지 또다른 언어를 알아야 한다는것 이상의
의미를 주는것 같습니다.
물론 C#을 배울수도 있겠지만 C#개발자들을 VisualJ++팀을 모조리 옮겨다가
만들었으니 뭐 자바나 다를바 없는 내용이겠죠.
2001.중반인 지금 자바는 꼭 필요합니다.
극단화 겠지요. VM을 필두로 이식성,운영체제안으로 들어가는 극단적인 효
극단화 겠지요. VM을 필두로 이식성,운영체제안으로 들어가는 극단적인 효율성.
하나는 엔터프라이즈 환경이고 하나는 임베디드 환경이 아닐까 생각합니다만은.
자바2ME의 약진을 보면 꼭 그렇지만은 아닌가 봅니다.
소프트웨어의 진화는 하드웨어라는 기계에서 탈피하려는 의도에서 시작된다고
생각되어 지니까요.자바가 미진한 부분을 C#이 보완해 가면서 역사는 흐르는거
같습니다.
자바 관련 문서에보면 대충 이런 말이 나옵니다..."자바를 사용한다고
자바 관련 문서에보면 대충 이런 말이 나옵니다...
"자바를 사용한다고 WORA가 되는것이아니라
자바는 WORA를 쉽게 해준다"
따라서 위와같이 자바를 사용한다고
어디서나 돌아가는것은 아닐 경우도 있습니다...
하지만 그것에 관련된 문서를 보면 충분히 해결방안이
나오는 걸로 전 알고 있습니다.
추가로 문제가 일어나는 부분은 거희 GUI아니면
Thread라고 들었는데 이를위해 자바는 자바만의
GUI를 만들고 자바만의 thread를 만든것으로 들었습니다
저는 뭐 그렇게 대단한 프로그램을 만든적도 없어서
윈도우에서 리눅스 정도는 간단히 되던데.
이런 저를 위해서 예제를 알려주실순 없습니까???
운영체제간에 호환 않되는 예제요..
그럼 그걸 되도록 만들어야죠..
한때 자바를 아주 싫어 하다가 지금은 열렬히 팬이된 사람으로서 몇자 적어
한때 자바를 아주 싫어 하다가 지금은 열렬히 팬이된 사람으로서 몇자 적어보면.
- 마우스 지나간뒤 엉망이 되는 어설픈 화면,
제가 Applet이나 자바 GUI쪽은 첨에 책보고 한 것 빼고는 한적이 없기 때문에 이부분은 뭐라고 말을 못하겠네요. AWT나 Swing이 느린것은 인정. 하지만 Client로서의 자바보다는 Server Side쪽이 훨씬 재미있습니다.
- Qt에 비교해서 (개인적인 생각으로) SLOT 과 SIGNAL 개념에 비교하여 철지난 C의 callback 함수사용과 번잡한 Event 모델을 쓰는 것,
물론 Gtk나 QT에 비하면 엄청나게 불편한 이벤트 핸들링과 위젯배치이지만 그래도 MFC보단 훨 편하던데요.
- 순수 객체지향으로 인한 오버헤드 (당연한 것이지만...)
오버헤드. 있기야 있죠. 근데 다른 python, perl과 같은 랭귀지보다는 훨씬 빠릅니다.(물론 최근의 JVM에서) 메모리를 많이 먹어서 그렇지. 순수 데이터 매니퓰레이션 쪽은 오히려 C/C++보다 빠르다고도 합니다.
- 말처럼 되지 않는 플랫폼 중립
말처럼 플랫폼 독립적이지는 않지만 상당히 플랫폼 독립적이라고 할 수 있습니다. 자바 자체가 플랫폼 독립성을 보장해주는 것이 아니라 자바는 단지 플랫폼 독립적인 어플리케이션을 쉽게 만들수 있도록 도와줄 뿐입니다.
- 늦은 속도
위에도 말했듯이 속도는 절대 처진다고 생각하지 않습니다. 서버 사이드에 국한된 얘기지만.
- 정작 LINUX나 FreeBSD에서는 Solaris에서처럼 지원되지 않는 것
이게 저도 젤 맘에 안드는 부분인데요. 뭐 어쩔 수 없지 않습니까.. 쩝.
글고 자바에서 정말 좋은 건 스타일이 잘 지켜진다는 것입니다. c/c++, python, perl 등은 이름 규칙부터 시작해서 각 라이브러리 마다 제각각이죠. 허나 자바에서 널리 사용되는 대부분의 라이브러리들은 Coding Style일이 동일합니다. 적어도 인터페이스 부분은. 전 이게 가장 맘에 듭니다.
무슨 언어를 하건 그건 자기맘입니다. 맘에 안들어서 죽어도 하기 싫다. 그거 안해도 먹고 사는데지장없다. 혹은 그걸해야만 밥먹고 살 수 있다면 차라리 굶게다. 하는 생각이 들면 안하면 그만입니다.
언어는 각각의 장점과 단점이 있습니다. 목적에 맞게 선택해서 사용하면 되는 것 아니겠습니까?
아무리 좋은 언어라도 철지나면 사그러들기 마련입니다.
결론은 언제나 "알아서 잘 판단하세요" 입니다. :-)
자바의 강점은... C, C++을 제외한 언어 중에서 유일하게 시스템 프
자바의 강점은... C, C++을 제외한 언어 중에서 유일하게 시스템 프로그래밍이 가능한 언어입니다. OS를 만들 수 있는 언어는 사실상 C, C++아니면 자바가 고작이지요.
어느 언어나 다 그렇듯이, 자바도 왠만한 일은 해결할 수 있습니다. GUI 어플리케이션을 만들 수로 있고 서블릿을 이용하면 웹 어플리케이션도 만들 수 있습니다. 데이터베이스 연동에도 좋지요.
그런데 최근의 경향은... 펄이나 python과 같은 언어에서 볼 수 있듯이 하이 레벨 어플리케이션은 굳이 힘들게 C나 C++, 심지어는 자바로 할 필요가 점점 줄어들고 있습니다. 속도가 빠르네 느리네 하지만 최근의 엄청난 시피유의 발전 속도를 생각하면 속도 빠른 프로그래밍 언어로 어플을 개발하는 것보다 빨리 개발하고 시피유 속도가 빨라지는 것을 기다리는 것도 나쁘지 않다고 봅니다. :) 이런 상황에서는 자바가 별다른 장점을 지니지 못하지요.
그렇다면... 자바가 가지는 장점은 두가지가 나옵니다. 시스템 프로그래밍이 가능하다는 것, 그리고 엔터프라이즈급 솔루션이 많다는 것. 이 둘 중의 하나가 필요하다면 당연히 자바를 해야 하지 않을까 싶습니다.
java 로 시스템 프로그래밍을 한다니,차라리 basic으로 시스
java 로 시스템 프로그래밍을 한다니,
차라리 basic으로 시스템 프로그래밍을 한다는게 더 말이 됩니다.
java는 보안과 이식성 때문에, 시스템 프로그래밍을 못하도록 일부러 기를 쓰고 막아놓은 언어인데(그게 장점인데), 시스템 프로그래밍을 연관시키시면 어떻합니까...
저는 생초보이긴 합니다만 , Sun의 자바OS 백서를 읽어본 적이 있는데
저는 생초보이긴 합니다만 , Sun의 자바OS 백서를 읽어본 적이 있는데요 .
두가지로 나누더군요 . 다른Os 기반위에 자바VM을 올려놓고 실행시키는 환경과 순수 자바OS인데 이 경우도 기반은 네이티브코드로 구성되어있다고 적혀있었던듯 .. ..
음, 아마도 JavaVM을 일일이 올릴필요없이 여러개의 Java프로그램을 돌려주는 운영체제 -> 자바OS 가 아닐까 하고 생각합니다만 ( 지적해주세요 , 제가 잘못 알고 있는걸지도 ) .
P.s : 어디선가 봤는데요 .. Ada로 OS짠다는 프로젝트도 있더라고 ..
어차피 밑바닥과 바로 닿는 부분은 어셈으로 짜게 되지 않나요 ?
( 다만 C나 C++이 좀 OS짜기엔 좋다 - 는거라고 생각합니다만 )
저도 들은 이야기지만 JavaOS 라는 용어를 접해본 기억이 있습니다.
저도 들은 이야기지만 JavaOS 라는 용어를 접해본 기억이 있습니다.
이것과는 다른것인지는 몰라도 Java 로 OS 를 만든다는 말도
얼핏 들은 기억이 있네요.
혹시 이쪽에 대해 자세히 아시는 분 계시면
포스팅좀 해주시지요 ^^
시스템 프로그래밍이라...제가 자바를 잘 몰라서 그런데요.시스템
시스템 프로그래밍이라...
제가 자바를 잘 몰라서 그런데요.
시스템 프로그래밍이라 하면, 언어 그 자체만으로 하드웨어를 직접 제어할 수 있어야 할텐데
자바에서 버추얼 머신 없이 접근한다는 말인가요?
VM 없이 접근하면 그건 자바가 아니지 않나요. 그래도 플랫폼독립적인 언어라는데...
그런 플랫폼 독립이라는 기치 때문인지 시스템 함수는 자바 API에서 잘 안 보이는 것 같던데
어떻게 시스템 프로그래밍을 하지요?
만약 시스템 프로그래밍이 단순히 시스템 API를 쓰는 수준이라면
시스템 프로그래밍 못할 언어는 또 뭘까요?
다리 역할을 할 수 있는 라이브러리를 해당 언어를 위해서 만들어 놓는다면요.
요새 언어들은 다른 언어, 특히 C랑은 잘 붙으니깐 C 라이브러리랑 붙여서 구현할 수도 있지 않나요.
JNI를 쓰는 거라면 똑같을 꺼구요.
이렇게 따지면 어셈블리어, 아니 기계어가 아니면 시스템 프로그래밍이 불가능하다라고
결과가 나올지 모르겠지만...
뭐 크로스 컴파일러를 만드는 노력만 한다면 대충, C나 C++도 범용적인 시스템 프로그래밍 언어라
할 수 있겠지만요.
생각에 VM을 포팅해야 하는 자바의 경우 시스템 프로그래밍과는 좀 거리가 먼 것 같은데요.
제가 시스템 프로그래밍을 잘못 이해하고 있어서 그런지. (넘 고상하고 힘든 걸로 ^^;)
아니면 자바를 잘 몰라서 그런지 좀 가르쳐 주십시오.
제 짧은 지식으로도 위의분 (현차리님말구요)이 말씀을 잘못하신듯합니다.
제 짧은 지식으로도 위의분 (현차리님말구요)이 말씀을 잘못하신듯합니다.
시스템프로그래밍이란 것은 커널이나 드라이버등의 프로그래밍을 말하는걸루 알기에..
자바라는 것이 JVM 없으면 암것두 아니죠 --;
혹 위의 분이 (다시 이번에도 현차리님 말구 ^^;) JavaOS가 나온것가지구 하시는 말씀이 아닌가 해서 하는 말입니다.. 자바오에스는 JVM이 아마 커널상에 있어서 자바프로그램을 바루 쓸수 있는 OS겟죠?-_- 아닌가.. 아님 말구욤... 글읽어본적이 엄써서 ㅡㅡ;;
그럼,,
시스템 프로그래밍의 정확한 의미가 뭔지는 모르겠지만(학교 다닐 때 시
시스템 프로그래밍의 정확한 의미가 뭔지는 모르겠지만
(학교 다닐 때 시스템 프로그래밍 시간에 어셈블러, 링커, 로더, CPU 에뮬레이터 같은 거 맹글 었는데. 이런 거라면 대부분의 언어는 다 시스템 프로그래밍을 할 수 있지 않남..)
하드웨어 건드리는 것도 웬만한 언어에서 다 할 수 있지 않나요?
약간의 C나 asm으로 된 라이브러리가 필요하겠지만. 그건 어차피 C도
asm 코드로 이루어진 라이브러리 통해서 하는 거니깐 뭐...
곰곰히 생각해보면... 자바가 나을 것 같습니다...왜 그렇게 생
곰곰히 생각해보면... 자바가 나을 것 같습니다...
왜 그렇게 생각하냐면... 소프트웨어(MFC)를 돌리자면 다운 받아
야 하는데, 매 시간마다.. 그 소프트 웨어가 필요하다고 해서
다운 받을려면 얼마나 짜증이 나겠습니까......
앞으로의 발전 방향으로 봐도... 그런소프트웨어는 무용지물이
될 것입니다.. (자바라는 비교대상의 더 나은 프로그램이 있
기 땜시로... 배척당하게 될 거라는 것이죠, 은젠가는)
웹에서 중립적이고, 독립적으로 소프트웨어를 감상하고 싶어하는
(소프트웨어 깔 필요를 못느끼는) 사람들 일명 초보자나, 시간이
없는 자,(전자상거래 법률 공부할때 꼭 뭐뭐 하는 자라고 해서리)
는 될 수 있으면 편한걸 쓰려고 하겠죠 시간도 절약되고.
그렇다면 java의 JRE가 MFC의 바턴를 이어받겠군요 단 웹에서....
사람들은 웹를 많이 사용하죠
음...mfc를 돌리기 위해서의 다운(?)과 자바의 그것과 다른게 무
음...mfc를 돌리기 위해서의 다운(?)과 자바의 그것과 다른게
무엇인가요? 제가 초보라서 잘 몰라서 그러는데요.........
어차피 네트위크를 통해서 데이터가 오가는건 마찬가지 아닌가?
큰 차이죠........ 골때리느냐 안때리느냐.. 응케케자바는 그
큰 차이죠........ 골때리느냐 안때리느냐.. 응케케
자바는 그냥 멍뚱멍뚱 페이지 열어놓고... 기둘리면 되니깐~
펄이 느린가요... 정말? -.-;perl인데..
펄이 느린가요... 정말? -.-;
perl인데..
자바 최고의 장점은자바 깊숙히 볘겨 있는 스타일과 무수한 패턴들...
자바 최고의 장점은
자바 깊숙히 볘겨 있는 스타일과 무수한 패턴들...
이건 짜보지 않은 사람이면 영원히 모를 것 같네요.
밑에 분이 쓴 글에 자바의 장점은 UI를 각각의 플랫홈에서
동일하게 돌릴 수 있는 것이고 했는데
그건 정말 아주아주 조그마한 부분일 뿐입니다.
자바는 자바라는 언어 자체에도 큰 장점이 있죠.
그다지 많은 언어를 사용해보진 않았지만..
스타일로 보자면 자바만한 언어 없죠..
좀 깊이 있게 둘러보세요.
아무도 당신에게 이것하라 저것하라 말하지는 않습니다.이 점은 마치
아무도 당신에게 이것하라 저것하라 말하지는 않습니다.
이 점은 마치 리눅스와 같지요... 수많은 사람이 리눅스를 두고 뭐라 합니다. 데스크탑은 안 된다는 둥 이걸 왜 쓰냐는둥..
자바에 관해서는 님께서 이런 차례입니다. 배워보고 , 익혀보고 좋다면 하는거고 싫다면 안 하는 겁니다.
만약 자바의 미래가 궁금하신 거라면 전 단언 할 수 있습니다.
자바는 미래 컴퓨팅 환경을 지배 할 것입니다.
자바는 일단 느려보입니다. 느려 보일뿐 입니다. 말 그대로 UI가 너무 느립니다. 하지만 성능은 그렇지 않습니다. win2000 의 경우 처리 속도는 VB보다는 빠르며 VC++에 근접 혹은 빠릅니다.
플랫폼 독립이 안 되는것 같습니다. 하지만. 독립적입니다. 자바 클래스는 정말로 플랫폼 독립적이어서 믿지 못할지 모르지만. windowns , linux , os/2 , solaris 전부 하나의 프로그램으로 돕니다. 안 돈다는 말을 들으셨습니까..? 해 보십시오..
그리고 자바는 모든단점을 덮을 수 있을만큼 아릅답습니다. 언어에 아름답다는 말.. 전 붙일 수 있습니다. 객체적으로 돌아가는 너무나도 아름다운 언어입니다.
기존의 모든 언어들은 시스템을 알아야 합니다. 머리속으로 아름답게 시스템을 설계 한다 할지라도 여러 환경에 의해 좌절 되야 합니다. 하지만 자바는 그렇지 않습니다. 생각만 한다면 자바로 짤 프로그램을 구상만 하고 그걸 소스로 옮겨서 컴파일을 한다면 그대로 돌아갑니다. 생각이 최소의 수정으로 결과가 됩니다.
이런 놀라운 언어가 어떻게 장악하지 않을수 있겠습니까...
워크스테이션에서 메인프레임까지.. 소스코드 한줄의 변화없이 돌아가는데요..
C# 말입니까... 무섭긴 하지요.. C# 이 C++을 계승했다고 하지만 사실 닷넷 이라는것 자체가 자바 플랫폼을 그대로 흉내낸 것에 불과합니다...
뭐 진보된 형태라는것은 분명하지만.. winnt + DB2 에서 작업한 걸
나중에 AS/400 기종에 옮길때 뭔짓을 해야 할지는 모르겠습니다. 뭐 윈도우 프로그래밍 하고는 원체 관계가 멀다보니 객관적인 평가는 힘들군요.
쩝..
여하튼 자바. 하고 안 하고는 개인의 선택일겁니다. 자바를 배우신다면 후회는 아마 없으실 겁니다. 나온지 얼마 안 되는.. 제일 진보된 언이입니다.
그럼..
쯧... 아름답다구? 그렇다면 자바를 하던 사람이 자바를 버려야 하는 이
쯧... 아름답다구? 그렇다면 자바를 하던 사람이 자바를 버려야 하는 이유는 무엇일까?
진보된 언어가 아니라 진보된 플랫폼이라는 것이 정확하지 않을까요?
참으로 가슴아픈 일이 아닐 수 없습니다. 결국 자바라는 것은 썬이라는 이
참으로 가슴아픈 일이 아닐 수 없습니다. 결국 자바라는 것은 썬이라는 이윤을 위해 존재하는 단체가 만들어낸 상품일 뿐입니다.
그렇습니다. 시스템에 대해서 세부적으로 알지 않아도 되고, 엄청나게 추상화된 코드 한줄로 엄청난 작업을 해낼수도 있습니다. 그럼 자바가 없으면요?
당신은 무얼 할수 있습니까? 당신이 자바로 하는 수많은 일들을 c컴파일러로 또는 어셈블러로 할 수 있습니까? 당신은 하산하셔도 좋습니다.
그렇지만 대부분 그렇지 않을 것입니다. 그러면 결론은 어셈부터 마스터하라 인것인가? 저도 아이큐가 3자리인지라 그런 엄청난 소리는 안 합니다.
다만 그냥 하나의 도구라는 것이죠. 필요에 의해서 사용되는 도구요.
걍 프로그래밍 하시는 분들이 도구에 맹신을 갖고, 종속화 되지 않으면
좋겠다는 생각을 해 봅니다.
바다있죠? 수많은 강줄기가 바다로 흘러갑니다. 그 셀수 없는 수많은 강줄기중 하나가 바로 자바입니다. 물론 바다에 닫지 못하는 강도 수없이 많습니다.
자바는 바다에 닿았다 할수 있겠죠..하지만 이 얼마나 미미한 존재입니까? 그냥 강일뿐입니다.
..모두 화이팅 입니다....헛소리 읽어 주셔서 감사하구염...
--- 인용 --- 당신이 자바로 하는 수많은 일들을 c컴파일러로 또
--- 인용 ---
당신이 자바로 하는 수많은 일들을 c컴파일러로 또는 어셈블러로 할 수 있습니까?
------------
당연히 자바로 하는것은 C 로 되지 않읍니까
당신이 c 컴파일러로 하는 수많은 일들을 자바로 할 수 있습니까?
이렇게 하는것이 순리 아닐까요..
자바를 보면서 C 로 포팅하는것은 안되는게 없는데 (충분한 lib 보유시)
C 를 자바로 포팅하는것은 워낙 간결하고 노가가 줄여주는 point 를
활용 못하니 좀 아픔이 있던 기억이 나는데 ...
글쎄요. 제일 진보된 언어라는 말을 서슴없이 불이는 것은 조금 그렇군
글쎄요.
제일 진보된 언어라는 말을 서슴없이 불이는 것은 조금 그렇군요.
그리고, 안돈다는 말,
많이 들어 보았거든요..
jvm bug를 떠나서라도 말이죠.
예전에 thinkfree office 개발에 관한 세미나가,
자바 공동체 세미나 때 있었는데, 한번 보시길 바랍니다.
http://realseminar.co.kr 에 가면 무료로 보실수 있을겁니다..
안 돈다는 말, 그거 실력이 없다는 소리입니다. 제일많이 이야기 하는
안 돈다는 말, 그거 실력이 없다는 소리입니다. 제일
많이 이야기 하는 것이 GUI의 리소스를 다룰 때 제대로
안된다는 것과 Thread 문제 인데, Spec을 보면 자기가
뭘 잘못 했는지 나옵니다. Thread를 예로 하자면 SPEC
에는 어디에도 Preemtive인지 Non-Preemtive인지
지정하지 않습니다. 그럼에도 불구하고 많은 JAVA개발자
들이 그냥 자기가 개발 하던 플랫폼의 특성이 표준인줄
알고 그냥 만들고 다른데서 안된다고 난리를 치지요...
GUI의 리소스 문제, 폰트, 국제화 등도 마찬가지 입니다.
ThinkFree의 경우 윈도에서만 한글이 제대로 되지요.
이건 VM을 그대로 이용했기 때문입니다. 만약 모든
플랫폼에 같은 언어, 폰트가 지원되지 않으면???
참. 까먹고 올려서.. -.-a제일 진보된 언어는 없고, 다만 각
참. 까먹고 올려서.. -.-a
제일 진보된 언어는 없고, 다만 각각의 특성이 강한 언어만이
존재한다는게 제 생각입니다만..
다른자바는 사실 사장될 기술이라 봅니다.대체 처음 나온 의도와 맞
다른자바는 사실 사장될 기술이라 봅니다.
대체 처음 나온 의도와 맞는 게 하나도 없습니다.
플랫폼 독립적?? 이거 말이 독립이지 잘되는 OS는 고작 솔라리스 하나밖엔 없죠.
플랫폼에선 솔라리스에서보단 너무 느립니다.
이거야 최적화를 했으니 그렇지만,,
그리고 완전한 객체지향을 표방하고 나왔지만,,
지금 뭐 객체지향적이지 않은 언어 있나요..
자바는 제가 볼땐 C++에서 포인터 빼고 다중 상속 클래스 뺀거 밖엔
차이점을 몰르겠습니다. 결국 C++의 단점을 모두 이어 받았습니다.
차라리 파이썬 같이 아주 기존의 호환성을 무시하고 처음부터 OOP적으로
설계된 언어가 여러면에서 낳은거 같네요. 문법 깔끔하고...
그리고 인터프린터 이지만 속도도 각 플랫폼마다 그리 차이가 나지 않습니다.
자바는 결국 CORBA같은 분산 컴퓨팅 기술을 정했다는 거밖엔 나온 이유를
몰르겠네요. JSP같은 웹플밍을 위해서 쓰이는 것도 같고,, 후후
속도? wora? 분산 컴퓨팅? C++ 차이점나 원참 자바 깊이 있게
속도? wora? 분산 컴퓨팅? C++ 차이점
나 원참 자바 깊이 있게 보지도 않은 사람들아...
이런 소리 하덜 말아라...
-_-
자바가 다른게 없다고 으이그 공부 좀 해라.니는 디자인 패턴도 모르제
자바가 다른게 없다고 으이그 공부 좀 해라.
니는 디자인 패턴도 모르제....
쯧쯧... stl 에 디자인 패턴이 있더냥..
으이그..
디자인 패턴은 객체지향 개념과 관련된걸로 알고 있는데요오랜시간동안
디자인 패턴은 객체지향 개념과 관련된걸로 알고 있는데요
오랜시간동안 객체지향 프로그래밍을 해온사람들이 거기에 일정한 패턴을
추려서 만든걸로 알고 있는데요...제가 잘못 알고 있는건가요?
객체지향 개념이라면 당연히 C++도 디자인 패턴이 적용 가능한거 아닐런지요
STL과 디자인 패턴과는 상관이 없습니다.자바에는 없는(?) 템플릿으
STL과 디자인 패턴과는 상관이 없습니다.
자바에는 없는(?) 템플릿으로 만들어낸 라이브러리이고,
STL은 generic programming을 구현하기 위한 것입니다.
디자인패턴은 C++로도 설계및 구현이 가능합니다.
Effective C++을 보시길...
C++과 자바는 서로 비교를 할수 없는 다른 개념입니다.
단지 C++의 문법을 빌어서 간단하게 한것 뿐입니다.
자바의 장점은 웹브라우져에서 윈도우의 Graphic User Interf
자바의 장점은 웹브라우져에서 윈도우의 Graphic User Interface를
구현시키는것이죠 일반 소프트웨어는 운영체제 내에서 실행되지만
자바 응용프로그램은 웹브라우져 내에서 응용프로그램이 실행되는
장점이 있죠...예를 들어 메뉴봐..스테이춰스 바... 뭐 이런것들
플랫폼 독립적으로....
이게 장점이면 장점이겠군요... 윈도우엔 MFC(Microsoft
Foundation Class)가 있고 자바엔 JRE가 있고... 뭐......
자바는 않해서리 철자는 잘 모르겄숨다. 그럼 안녕
파이썬은 자바보단야 빠릅니다. 아주 약간이지만,, -_-;;
파이썬은 자바보단야 빠릅니다. 아주 약간이지만,, -_-;;
파이썬이 좀 느리져...
파이썬이 좀 느리져...
빠른가요?제가알기론 2,3배 느린걸로 알고있는데...
빠른가요?
제가알기론 2,3배 느린걸로 알고있는데...
재미있는 사이트가 있더군요. =)http://www.bagley.
재미있는 사이트가 있더군요. =)
http://www.bagley.org/~doug/shootout/
뭐, 프로그래밍 언어의 비교. 만 큼이나 영원히 계속될(?) 논쟁도 없겠지만요. ^^
달랑 Hello, World이런걸 프로그램이라고 하면그렇겠지요. 아마
달랑 Hello, World이런걸 프로그램이라고 하면
그렇겠지요. 아마 벤치를 직접 돌려 보시면
다른 이야기가 나올 껍니다. Python은 TCL보다
는 빠르지만 Perl보다도 느리던데요? Java는
C같은 언어 보다야 최대 10배 느리지만(수치계산)
Perl,이런 언어보다는 10배 빠릅니다. 한번
해 보세요, 물론 JIT는 켜야 합니다.
아참, 빼먹은 것이 있는데, 당연히 Virtual Machine로딩
아참, 빼먹은 것이 있는데, 당연히 Virtual Machine
로딩 시간은 빼야 겠지요??
참고로 자바가 플랫폼 중립이 안된다는 그런 이야기를 몇번 들었는데..
참고로 자바가 플랫폼 중립이 안된다는
그런 이야기를 몇번 들었는데...
실제로 보면은...
Windows 상에서 컴파일을 시켜서
linux 로 ftp를 이용해서 보냅니다...
그런데...방식이 ascii방식으로 전송을 해서...
(원래 class 화일을 ftp로 전송시 bin모드로 전송해야 합니다)
안되는 걸 가지고 java 의 플래폼 중립이 안된다는
이야기를 들은 적도 있고
역시 위와 같은 조건에서 JDK 1.3으로 컴파일후
Linux 의 1.08 지원 VM에서 작동을 시킬려고 하니
안되는 경우도 봤읍니다.다른 운영체제에서 않된 다는것이
이것처럼 자바의 부족한 점이 아닌 다른
원인일 경우가 제가 봤을때는
많이 있었습니다.
그리고 JAVA가 느리다는 말을 많이 쓰는데...
만만치 않게 느린 Python 이나 perl 은 어떻게 쓰지요???
제가봤을때 Python 은 자바보다 느리다고 들었습니다
그럼 C나 C++로 짜서 OS마다 컴파일하는 것이 더 나을것 같네요..
그럼 C나 C++로 짜서 OS마다 컴파일하는 것이 더 나을것 같네요..
gcc는 버젼이 다르다고 코드가 컴파일안되는 경우는 없을테니까요 :)
전 앞으로는 Java프로그램 만들어서 배포할때는 VM최신버젼을 같이 배포하는 것을
잊으면 안될꺼 같습니다.
그리고 펄이나 파이썬은 자바랑 크게차이나지 않는것 같더군요.
그리고 어떤 분야에서 쓰느냐에 따라 다르지만 펄이나 파이썬은 문자열 처리같은
곳에서는 자바보다 뛰어나지요. (그래서 구글에서 Python을 쓰는지도..)
그리고 이건 개인적인 거지만, 썬이 자바를 지네맘대로 다룬다는게 제일 싫더군요.
Java는 이것 때문에 너무 많은 기회를 놓치고 있는건 아닐지요?
Python같은 경우에는 훨씬 자유롭죠. 필요한 경우 C나 C++로 확장이 가능하고,
실제 잘 다룰 경우 Java보다 나은 성능을 보일 수도 있을 것 같습니다.
어쨋든 웹이나 엔터프라이즈환경에서의 자바는 대세인것은 확실한 듯 합니다.
.NET을 좀 더 지켜봐야겠지만요..
음. JAVA가 Script Language 였나요? ;)
음. JAVA가 Script Language 였나요? ;)
음. JAVA가 Script Language 였나요? ;)
음. JAVA가 Script Language 였나요? ;)
위엣분께서 말씀하신 것처럼 순수 객체지향의 의한 오버헤드를감안한다면.
위엣분께서 말씀하신 것처럼 순수 객체지향의 의한 오버헤드를
감안한다면.. 그리고 조금씩이나마 성능이 향상되고 있는 JRE를
감안한다면.. 자바 언어 자체는 충분히 매력이 있지 않나..
하는 생각인데여.. 그저 객체지향 언어의 매력일라나..
저도 자바 땜시 짜증날 때가 종종 있긴 하지만..
자바에 대한 맹목적인 거부감이라면.. 혹시 많은 분들께서 느끼시
는 거부감이라는 게.. 객체지향에 대한 거부감은 아닐까요..
자바를 써도.. C++를 써도..끝까지 C로 하던 방식으로 하시는 분들을 많이
봐 왔거든여..
아니려나요..
마우스 지나간뒤 엉망이 되는 어슬픈 화면; 제가 SiS칩에 Penti
마우스 지나간뒤 엉망이 되는 어슬픈 화면
; 제가 SiS칩에 Pentium 150에 16램 쓸때는 그런 현상이 있었죠.
; 아주 자주... 그런데 Pentium III 500에 64램에서 돌리니까
; 그런 현상이 없어지더군요... 그건 Windows 화면제어 메카니즘과
; Java, 그리고 시스템의 속도에서 나오는 어쩔수 없는 현상이라 봅니다.
; 현재는 Java Swing에 대해 Component의 외관이 좀 구리다... 라는
; 단점외에는 생각 나는게 없습니다.
Qt에 비교해서 (개인적인 생각으로) SLOT 과 SIGNAL 개념에 비교하여
철지난 C의 callback 함수사용과 번잡한 Event 모델을 쓰는 것
; RAD툴을 지원하지 않는 Windows지원 프로그램치곤 그정도면 괜찮은거
; 아닌가요? Java Swing이나 Event처리등의 처리방식은 인정해 줄만하다고
; 생각합니다.
; (( 개인적으로 M$ Visual C++ SDK보고 훨 낫다고 생각합니다. ))
늦은 속도
; 이건 Windows의 내부 메카니즘이 구려서 그럽니다.
; Solaris나 Linux(Redhat 6.0)에서만 돌려도 전혀 느리지 않습니다.
; M$가 실력이 딸려서 그런거예요...
정작 LINUX나 FreeBSD에서는 Solaris에서처럼 지원되지 않는 것
; 으흠... FreeBSD는 JavaSoft에서 나온게 아니라 BSD관련 인원들이
; 만든겁니다. 차이가 있을 수 있죠.
; 하지만 Linux, Solaris용은 JavaSoft에서 만든겁니다.
; 그리고 제가 써본 결과 성능적인 차이나 결과적 차이는 없는거 같습니다.
M$의 대학교 투어 세미나를 들은적이 있는데, 젤 마지막에 Java가 망할 수
밖에 없는 이유와 C#이 뜰 수 밖에 없는 이유를 설명하는데, 그들이 Java를
깍아내리려고 사람들 앞에서 시연을 해주더군요.
C#은 Visual Studio.net 7.0 Beta1이고 Java는 놀랍게도 M$ Visual J++ 6.0에서
엔지만 빼서 테스트해주더군요. JavaSoft의 Java로 해주는게 아니라...
C#이 이름을 날릴수 있는건 .Com과 함께 부각되 Java가 .Com이 몰락한 뒤
과연 Java가 살아 남을 수 있을까라는 관계자들의 생각과 개발된지 어느정도
된 언어에서 나오는 여러가지 단점들을 이용한 M$의 선전때문이겠죠.
C#이 아직은 완벽히 시장에 나온것도 아니고, 써본 사람들도 그리 많지 않고,...
C#이 나오면 Java보다 더 많은 욕을 먹을 지도 모릅니다.
....
위에서 말한대로 님과 저의 생각에는 어느정도 차이가 있지만,
Java공부하기 싫어하는건 님이나 저나 같군요...
음...제 생각에는 음... 엔지니어로써 컴퓨터의 언어에 그렇게 연연할
음...제 생각에는 음... 엔지니어로써 컴퓨터의 언어에 그렇게 연연할
필요하는 없다고 생각됩니다...
정작 중요한 것은 그것이 어떻게 구성되어 있고, 어떻게 돌아가는냐
하는 것일 겁니다...
나는 C/C++/Java/ASP/JSP/... 이런 것을 할줄 안다고 말하시는 분들이
계신것 같은데. 글세요... 제 생각에는 자신의 생각을 구현할수 있는
언어를 1~2개정도만 할줄 안다면 그것으로 충분할듯.
물론 컴퓨터 언어가 나타났다가 사라지는 것은 사실이나
한번 인증받은 언어를 그렇게 쉽게 사라지지 않는것 같습니다.
대표적인 것이 C/COBOL/Fortran 등 아직도 사용하고 있죠... 한 30년되었나
이렇게 업무적인 페러다임이 변경되더라도 그것을 지원하고 또한
언어 역시 점점 더 발전해 가는것 같습니다....
특정 언어에 연연하지 마시고, 업무적인 부분에 대해 좀더 많은 공부를
하시는 것이 좋을듯.....
그리고 자바는 음.. 이제 어느정도 기업에 사용할수 있다고 생각되어지는
것 같습니다. 물론 저 역시 자바로 먹고 살지만요...
EJB, J2EE 등의 스펙이 발표되면서 기업의 업무에 적용하고자 많은
업체들이 노력하고 있는 것 같습니다..
물론 아직 응용 프로그램을 사용하기에는 약간의 문제가 있지만
그래도 웹상이나 기업의 비지니스를 구현하는 부분에서는 활용할수
있는것 같습니다...
그리고 M$에서 C#을 발표한다고 하는데.. 글쎄요.. 한 3년에서 5년정도
있어야 제대로 사용할수 있을듯... 자바가 1990년대 중반에 발표되어
거의 5년정도 지난시점에서 이제야 안정성이나 성능면에서 인정을 받고
사용되는 것과 같이 발표한다고 해서 곧바로 사용되거나 산업표준이되지
못하죠....
즉, 사람들이 인정할때까지 살아 남아야 하는데...산업표준으로 인정될지
음...의문이지만.. 하여튼 엔지니어로써 자신의 생각을 제대로 표현할수
있는 언어 한두가지만 알고 있다면 그것으로 충분하다고 생각됩니다.
여러가지 언어를 알고 그 특성을 잘 활용하는 것도 좋지만 그것은
글쎄요... 어느 전문 분야가 없이 이 언어로 구현된 부분을 저 언어로
번역하는 것을 하게 될 가능성이 높을것 같은 개인적인 생각이 듭니다...
기초를 탄탄히 하시기 빌며... 그럼...
C#때문에 갈등이 되신다는 점은 별 문제가 안될거 같은데요?아직
C#때문에 갈등이 되신다는 점은 별 문제가 안될거 같은데요?
아직 C#을 써보진 않았지만 C#이나 자바나 언어의 스타일이 거의 비슷하다
는 말을 많이 들엇기에 자바를 잘하는 사람이라면 금방 C#에 익숙해질 수 있으리라 생각합니다. MS에서 C#을 자바와 유사하게 만든이유중에 하나가 JAVA프로그래머를 C#쪽으로 끌어들일려구 그런식으로 만들지 않았나 생각합니다. 이런 문제에 대해선, 프로그래머는 특정 시스템 특정 언어 종속적이어선 안된다고 생각합니다. 현 시대의 흐름에 따라 유연하게 대처할 수 있어야 하지 않을까요..
토론의 개설자님은 실력이 보통은 넘는거 같은데 자바언어도 쉽게 익숙해질수 있으리라 생각합니다.
그리고 자바가 그렇게 생각처럼 재미없진 않거든요. 저는 자바의 객체지향
개념에 매료되어 지금은 1년이 조금 못되었는데 너무 재미있게 언어를 배우고 있는 중입니다.
- 마우스 지나간뒤 엉망이 되는 어설픈 화면음... 대체 어느 정
- 마우스 지나간뒤 엉망이 되는 어설픈 화면
음... 대체 어느 정도 사양의 컴퓨터를 쓰고 계세요?
전 cel500에 램256메가를 씁니다만...
리눅스에서도 스윙 프로그램은 무난하게 작동합니다.
netbeans 같은 큰 프로그램도 마우스가 지나간 뒤
엉망이 되는 건 한 번도 못봤는데..
- Qt에 비교해서 (개인적인 생각으로) SLOT 과 SIGNAL 개념에 비교하여 철지난 C의 callback 함수사용과 번잡한 Event 모델을 쓰는 것,
글쎄요 번잡한 이벤트 모델이라 ... 뭐 qt는 써보지 않아서
잘모르겠는데 제 생각에 자바의 이벤트 모델은 아주 효율적입니다.
또 구조 자체도 mvc 모델에 적합하도록 만들어져 있구요.
또 C의 callback 함수하고 비교하는 건 무리가 아닐까요 :)
- 순수 객체지향으로 인한 오버헤드 (당연한 것이지만...)
그대신 wora 를 얻었지 않습니까..
- 말처럼 되지 않는 플랫폼 중립,
대체 뭐가 중립이 안된다는 얘기인지
지금까지 나온 수많은 wora 프로그램은 뭔가요?
- 늦은 속도
1.3.1 정도를 쓰시면 요즘 평균적인 사양의 컴퓨터에선
전 느린지 모르겠던데요..
- 정작 LINUX나 FreeBSD에서는 Solaris에서처럼 지원되지 않는 것
bsd는 잘 모르니깐... 근데 linux에서 뭐가 지원이 안된다는 얘기지 --;
전 리눅스의 서버 쪽에선 잘 모릅니다만..
리눅스를 작업용 웍으로 쓰고 있거든요..
프로그래머에겐 아주 좋은 운영체계죠... :)
자바 프로그램 한 3년 했지만 linux에서 지원이
모자란다고 생각해본 적은 없는데...
이 글 포스팅 하신 분은 자바공부좀 더 하셔야 겠습니다..
특히나 디자인 패턴하고 UML을 관심있게
공부하신다면요...
게다가 (말로는) Java의 단점을 보완한 C#의 출현이 더욱 갈등스럽게 만들죠.
저랑 같은 생각이시군요 ^^;그런데 저는 님처럼 그렇게 실력이 뛰
저랑 같은 생각이시군요 ^^;
그런데 저는 님처럼 그렇게 실력이 뛰어나지도 않습니다.
젤 처음 접했던 BASIC 부터 지금까지 무수히 많은 언어들을 지켜봤지만
(사실은 눈만 동그랗게 뜨고 쳐다보기만...;;;)
제가 그 모든 언어들에 대해서 이렇다 저렇다 말할만큼
열심히 파보지도 못했기때문에 뭐라 말할수는 없습니다만
님처럼 저도 개인적으로 JAVA에 정이 가질 않습니다.
C가 나왔을때 엄청나게 파워풀한 언어라고 거의 모든 개발자들이
C에 끌려다니는것처럼,
비쥬얼툴이 첨 나왔을때 혁신적인 개발툴이라고 찬사를 아끼지
않으며 잡지에서도, 학교에서도 비쥬얼툴 사용법을 가르치고
그렇게 쉽게 프로그램도 아닌듯한 것들을 찍어내고 자랑스러워하던것처럼
지금의 자바도 그저 지금까지 다른 언어들이 나왔을때 개발자들을
매혹시켰던것처럼 유행이라고 생각합니다.
아니 어쩌면 지조없이 뜬다니깐 우르르 몰려가는 일부 개발자들이
보기 싫어서 자바를 혐오하는지도 모르겠습니다.
저는 아직도 C 공부를 계속 하고 있습니다.
개발자가 특정언어만 고집하거나, 특정언어를 혐오하는게 안좋은 습관이라는건
아주 잘 알고 있습니다만,
제가 아직 실력이 부족해서 이것저것 하다보면
하나도 제대로 되지 않을것 같아서 그런대로 오랫동안 사용했고
객관적으로 성능이 검증된 C 를 택해서 꾸준히 공부를 하고 있지요..
객체지향 프로그래밍을 위해서 간간히 C++ (Not VC++) 을 보고는 있습니다만
자바는 앞으로도 공부할 생각이 전혀 없습니다.
이런 이야기는 자바개발자분들의 이야기를 들어봐야 하는데
제가 쓰는글은 그저 자바가 싫다는 투정밖에 안되겠군요..
그러나 앞으로 몇년간은 자바가 주도할것같군요...
별로 마음에 안들지만.. 역시나 새로운 유행이 몰려오는...
^^; 꼬리로.. 아주 편협한 말이지만.. 제가 하고싶은 분야에서는
적어도 자바가 필요없네요..
하고 싶은 일을 꼭 하게 되는건 아니지만..;;;;;
아직은 시간이 있으니깐 도전해 보는것 뿐입니다. ^^
페이지