JAVA가 KLDP에서 인기가 없는 이유?

blueiur의 이미지

고전 떡밥중 하나인 JAVA vs C 에 대해서 글을 읽다보면 KLDP 내에서는 java에 대해서 부정적인 인식을 가지고 있는 것으로 보입니다.

가만히 생각을 하다가 느낀게 해커 문화와 자바가 잘 어울리지 않아서 그런게 아닌가 하는 생각이 드네요.
- 그렇다고 자바 해커가 없다거나 실력이 없다는 이야기가 아닙니다 공격하지 말아 주세요:)

보다 정확히는 오래된 unix문화 자체가 simple is best 인데 자바는 그 자체로 굉장히 크고(예전에는 라이브러리/프레임웍이 컸었는데 이제 언어 자체도 커졌죠) 복잡하기 때문이 상대적으로 그런 인식이 생긴건 아닌가 싶기도 합니다.

어느 분께서는 C는 공부할 필요가 없는 언어라고 하시더라고요, 보는 그대로가 코드고 프로그램 그 자체라고 하시면서요.

또 상대적으로 쉽게 배울수 있다는 점도 한 몫 할꺼라 생각합니다.(그래서 많은 사람이 사용 하기도 하고요)
리눅서들이 윈도우를 바라보는 인식과 비슷하다고 할가요?

한마디로 정리하면, 자바와 같이 기업 시장을 목표로 하는(의도하던 의도하지 않던) 현대적 언어들은 상업적으로 이용하기에는 좋지만, 뿌리 깊게 내려오고 있는 해커 문화와의 이질감에서 멀리하게 되지 않나 한다 하는 생각입니다.

chunsj의 이미지

자바가 인기가 없다기 보다는 뭐든지 자바가 다 되는데 왜 이 "최고로 좋은" 자바를
모든일에 안쓰시나요? 류의 생각에 동의하지 않는 분들이 많은 것 아닐까요?

자바가 적합한 일이라면 아마 자바를 써서 업무를 하시는 분들도 많으실 껍니다.

semmal의 이미지

자바가 어떤면에서 안좋은지 정확히 알면서 싫어하는 분은 분명 대안으로 다른 언어를 쓰시고 계실테고, 잘 모르면서 싫어하는 분은 그냥 쓰지 말라고 하세요.

떡밥 올리는 누구는 사람 놀리는 것도 아니고, 쓰지도 않을 거면서 왜 꼬치꼬치 물어보는지 모르겠어요. 스스로 잘 모른다고 해놓구선, 몇 마디 주워들은 것 가지고 사람들 자존심 긁는 소리나 해대고 말이죠.

애초에 해볼 생각이 없었는데, 그래도 할까 말까 고민 중에, 안해도 되겠다는 확인 도장 맡으러 온 모양입니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

kds6221의 이미지

저도 읽어 봤는데요

그런것 같지는 않던데요 ^^

kasworld의 이미지

글 쓰신 분의 의견과 유사한 의견입니다만..

자바라는 언어가 그 탄생의 배경과는 관계없이

공장제 SI용도로 많이 쓰이기 때문에 소위(저를 포함한)
(코더와 대비되는 의미의)프로그래머들 사이에 인식이 나쁜것으로 보입니다.

C가 멋진 이유는 같은 일을 하기 위해서 초보가 선택할만한 방법이 있고
또 고수가 되면 더 좋은 방법을 알게되는 등의 언어의 깊이가 있다는 느낌을 받게 되는 반면에

공장형 생산용으로 진화를 거듭하고 있는 자바는 그 사용에 개성과 창의성를 말살 당하면서 일하게 된다는것 때문이겠지요.

하지만 이게 또 역으로 자바가 많이 퍼지고 대중화 되는 데 가장 중요한 요인 이라는게 재미있습니다.

대규모 프로젝트가 이루어 지기위해선 개발 방법의 정형화나 코드 품질의 일관성 등이 중요하고
또 코드의 생산성을 정량적으로 분석하고 일정/인원등의 필요 자원을 예측하기 위해선 반드시 필요한 일이니까요.

간단히 말해서 예전보다 해야 하는 일의 규모가 커지고 들어가는 모듈의 수가 늘어 났기때문에 예전에 한줄의 코드가 프로젝트에서 차지하던 비중이
이제는 한개의 단위 모듈(예를 들면 클래스,함수)와 같은 정도가 된 상황인거고 이상황에서 한줄 한줄의 코드를 잘 짜는 거보다는
각 단위 모듈을 어떻게 설계및 연결 하는냐가 더 중요한 정도로 복잡도가 올라갔다는 이야깁니다.
( 예전에는 프로젝트가 1000라인으로 구성되어 있었다면 이제는 1000클래스로 구성되어있는거지요. )

좀 심하게 말해서 더 이상 프로그램 언어는 중요하지 않은 상황이 되었다고 할 수 있을지도 모르겠습니다.

select99의 이미지

네.. 동의합니다.

을병.. 개발업체측에서는. 결코 효율적인 언어를 선택할이유는 없는것이죠..

자바로하면 100명투입할수 있는일을 C로해서 50명만투입해야할 이유가 없는것이죠..

성능이 느린만큼 더비싼장비를 투입할수 있는데 궂이 힘들게.. 효율을 강조할이유가 없는것도..

semmal의 이미지

역시나 자바에 대해서 잘 모르시는데 편견만 가지고 계시군요.

저도 자바 좋아하는 건 아닙니다만, 최소한 어디서 필요한지는 느끼고 있습니다. 자바가 필요한 분야에서 필적할만한 언어가 몇 개 있기는 합니다만, 확실히 거기에 C는 없습니다.

어짜피 평생 자바가 필요한 분야에서 일하지 않는다면 자바에 대해서 무슨 편견을 가지든 상관 없습니다. 그러나 쓰시는 C만 잘 쓰면 되지 다른 언어에 대해서 왈가왈부하실 필요는 없어보입니다.

자바를 배우시든, 다른 자바의 대안 언어를 배우시든, 제대로 좀 배우시고 말씀해주시면 좋겠네요. 수박 겉핥는다고 수박 맛을 느낄 수는 없습니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

select99의 이미지

님 뭔가 상당히 혼동하고 계시는듯합니다.

자바에 대한비판을 왜 님자신에대한비판이라고 생각할까요?

언어(도구가) 님자신인가요? 왜 님이 기분나빠하고그러세요?

저희는 어떤도구를 사용하든안하든그것의 장단점을따지고 평가할권리가 있습니다..

왜 우리가 쉬쉬하고 있어야하나요?

머항상이런얘기나오면 수박 겉핥기다어쩐다.. 머가 수박 겉핥긴가요..

semmal의 이미지

님이 더 혼동하고 계신 것 같은데요.

자신에 대한 비판이라고 생각하는게 아니라 잘못된 지식에 대한 비판입니다.

좀 제대로 알고 말하라고 하는게 이해가 안되나요?

이렇게까지 설명해도 못알아듣는 당신은 자바를 모르는게 분명합니다. 심지어 파이썬이나 루비도 잘 모르는게 분명합니다. 아마 C++를 쓰더라도 Qt같은 라이브러리도 써보지도 못했을테고, eclipse같은 개발도구도 접해보지 못한게 분명합니다.

어떤 도구를 사용하든 안하든 장단점을 따지는 권리를 가지고 있으시다고 하셨으니, 저도 잘모르는 당신의 장단점을 따져보니 그렇게 생각되네요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

select99의 이미지

참.. 답답하시네요...

논리적으로 따지시면되지.. 안된다고 그렇게도 상대를 공격하기 바쁘세요? 왜그런식으로 토론하시나요...

지금 자바프로젝트진행중인데 무슨말씀이세요.

semmal의 이미지

참 제가 더 답답합니다.

논리적으로 말을하고 논리적으로 따지세요.

하시는 자바 프로젝트가 어려움이 많겠습니다만 잘 되길 빌겠습니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

소타의 이미지

자바가 필요한 분야가 어딜까요? 그 분야에서 자바와 필적할만한 언어라면 어떤게 있는지 알려주세요;

blueiur의 이미지


필적한 언어로는 MS의 C#이 있겠죠?
이미 언어 적으로는 자바보다 훌륭하다고 생각합니다만 :)

자바[만] 할수있는 분야는 없습니다.
하지만 조금 더 [효율적] 으로 할수 있는 분야는 있겠죠.

darkmyth의 이미지

멀티 플랫폼이 아닐까요??

이식성이 좋다는게 제일 장점일듯 하네요

ldgood의 이미지

최고의 장점은 아니죠
스크립트 언어는 모두 멀티플랫폼입니다만...
자바는 엔터프라이즈 환경에서의 생산성이 최고 장점이죠.
------------------------------
모든것은 모든것에 잇닿아 있다.


------------------------------
모든것은 모든것에 잇닿아 있다.

semmal의 이미지

높은 생산성이 필요한 분야입니다. 즉, 코드의 작성이 쉽고, 빨리 결과를 볼 수 있고, 유지보수 또한 쉬워야 하는 분야는 모두 해당됩니다. 알고리즘에 집중해야하고 다른 부분에 대해서 노력을 덜 들이고 싶을 때도 마찬가지 이유로 자주 사용됩니다. 다른 플랫폼간의 호환이 필요하면 그건 덤이구요.

코드의 작성이 쉽다는 말은 싼 인력을 쉽게 뽑을 수 있는 것을 포함해서, 다른 분야의 개발자가 쉽게 적응할 수 있어야 한다는 말이기도 합니다. 때문에 문법이나 코딩 규칙은 간단하지만 반드시 지켜야하는 부분도 많습니다. 이러한 제한 사항은 코딩시에 발생할 수 있는 불명확한 문제를 다소 귀찮은 방법을 사용하기는 하지만 명확하게 만들어줍니다. 지키라는 규칙을 제대로 지켰는데 동작하지 않으면 대부분 컴파일러나 개발도구 문제라고 보면 됩니다.

또한 환경에서 곧바로 제공되는 아니면 너무나도 쉽게 구할 수 있는, 수많은 라이브러리와 프레임웍은 개인용이든 기업용이든 필요한 기능을 거의 갖추고 있어서, 대부분의 경우 필요한 로직만 짜서 넣으면 됩니다. 이 또한 귀찮은 온갖 규칙을 줄줄이 달고 있지만 설계나 구현, 확장과정에서 발생하는 문제를 줄여줍니다. 지키라는 규칙을 제대로 지켰는데 동작하지 않으면 이 역시 라이브러리나 프레임웍의 문제라고 보면 됩니다.

만들어진 프로그램이 자바의 언어/라이브러리/프레임웍 규칙에 적법하게 만들어져 있다면, 각 부분은 잘게 나뉘어져 코딩되어 있을테고, 문서화된 자료에 따라 각 부분 간의 연계만 파악하고 있다면, 개발에 참여하지 않은 인원이 오더라도 수정하는 것이 어렵지 않습니다.

C#은 자바와 거의 같은 접근 방식을 사용한다고 보면 됩니다. lisp이나 python, ruby 등은 언어적인 측면에서 더 쉽게 익힐 수 있고, 많은 양질의 라이브러리와 프레임웍을 제공하고 있으므로 자바의 분야에서 얼마든지 효과를 발휘할 수 있습니다.

웹이나 SI는 국내시장에서나 특화된 것이고, 세계적으로는 패키지 시장에서도 자바로 만들어진 제품은 많이 볼 수 있습니다. 알만한 기업용 그래픽스 툴, 설계 툴, 관리 툴 등이 자바로 만들어지고 있고, 많은 무료 툴도 자바로 제공되고 있습니다.

이렇게 성공한 언어가 알고보니 C보다 못하다면 자바로 개발하는 모든 개발자는 전부 그냥 바보인게죠. C에서 자바로 넘어간 사람은 무뇌아쯤 되나요? 제가 회사를 운영한다면, 학원 6개월 끊어도 제대로 못쓰는 C 초보보다는, 학원 3개월 끊고도 개발에 참여하는 Java초보를 선택하겠습니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

blueiur의 이미지

lisp이 언어적 측면에서 더 쉽게 익힐 수 있고 양질의 라이브러리와 프레임웍을 가지고 계신다는 거는 농담이시죠 ?
:)

참고로 제가 기업을 운영한다면, 6달 학원다닌 C초보나 3개월 학원다녀서 개발에 참여하는 자바 개발자 모두 절대로 뽑지 않겠습니다.

semmal의 이미지

lisp이 common lisp 하나만 보신다면 곤란합니다. 수많은 계열을 모두 lisp으로 적었을 뿐입니다. 각 dialect간에 차이가 있기는 하지만 lisp이 차지하는 분야가 결코 적지는 않습니다.

초보 어쩌구는 말이 그렇다는 거지요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

handan의 이미지

너무 이분법적으로 보시는건 아닌지 모르겠네요.
Java 던 C# 이던 C 던 C++ 이던 그 무엇이던 그것은 개발자의 도구일 뿐이지 개발자 자신이 아닙니다.
누군가 Java 를 공격하면 (이 쓰레드에서 그런 글을 보지는 못했습니다만...) 기분이 나쁠 수는 있겠습니다만, 그렇다고 해서 그걸 Java vs. 타 언어의 대결구도로 판단해버리면 우리 개발자는 너무나도 재미있는 것들을 많이 놓치게 됩니다.

저는 Java 경력이 다른 개발언어 경력보다 많습니다만, 다른 언어로 개발하는 것도 무척 해보고 싶습니다.
Java 가 아닌 언어로 개발하는 것도 충분히 재미있고, Java 와는 다른 도메인인 경우도 많기 때문이죠.

세상에 만능인 언어는 없습니다.
자기 도구는 자기가 골라 쓸 줄 알면 그만이니 그것으로 충분합니다.

semmal의 이미지

제 글이 그렇게 느껴졌다면 역시 제가 글을 쓰는데 재주가 없기 때문일 겁니다.

제가 결국 하고자 하는 말이, "세상에 만능인 언어는 없습니다."예요.

"이래서 자바가 엉터리예요." "이래서 씨가 엉터리예요"가 아니라 "필요하면 써라"라는 겁니다.

원래 모든 언어는 엉뚱한 분야가면 엉터리입니다. 애초에 거기에 쓰라고 만든 것도 아닌데 그런다고 까니깐 하는 말이지요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

oomymy의 이미지

SI 프로젝트에서 자바가 많이 쓰이는 것은 사실이지만,

자바가 SI 프로젝트에서만 쓰이는 것은 결코 아니죠.

Pure Java로 진행되고 있는 오픈소스인 Apache의 Hadoop/MapReduce를 보시면 이 분산시스템을 만드는 개발자들이 개성과 창의성이 없이 만들었다고는 결코 볼 수 없습니다.

개성, 창의성, 재미등을 결정하는 데 중요한 것은 머리속에 든 알고리즘과 설계이지, 프로그래밍 언어가 차지하는 비중은 작다고 봅니다.

soungno의 이미지

자바나 현대적 언어의 사용이 복잡도를 증가 시키고 개발 결과물에 대한 창의성과 개성을 말살 시킨다고 하셨는데요?

과연 그런지 현실을 좀 살펴 보셔야 할것 같습니다.
프로그램언어의 발달은 프로그램의 요구사항이 기하 급수 적으로 증가하고 그에 맞쳐 프로그램의 복잡도가 상상을 초월 할 정도 복잡해져 기존의 방법으로 더이상 고품질의 소프트웨어 를 생산하기 어려운 사항에 처해 졌습니다.
저런 사항이 발생한게 대략적으로 1990년대 이후의 사항입니다.
물론 저런 우려를 1960년대 부터 제기하고 연구한 사람들이 다수 존재 했고 그들은 데이터 은닉, 캡슐화, 모듈화, 추상화, 등 이런 문제를 해결 할 새로운 방법을 제시 하기 시작 했습니다.
지금이야 객체 지향 언어가 보편적으로 사용되고 소프트웨어 아키텍처, 패턴, 재사용성, 컴포던트 등이 일반적으로 사용되지만 저 당시는 그저 하나의 공상에 지나지 않았습니다.
그때 저분들의 반대 편에 서 계시던 분들이 고전적 언어를 지지하는 분들로 고전적 방법도 휼륭하고 아릅다게 구현할 수 있는데 왜 그렇개 복잡하게 문제를 해결해야 하는가? 의문을 제기하고 실제 거의20년 동안 새로운 방법은 빛을 보지 못했 습니다.

그런데 웹의 대중화 비즈니스의 전산화로 범대중적이고, 복잡한 시스템의 수요가 폭팔적으로 90년대 발생하게 되고 실제 소프트웨어 업계에서는 복접도의 관리에 대한 어려움에 봉착하게 됩니다.
결국 30년 전부터 주장되던 객체지향, 데이터 은닉 등을 수용하며, 이런 문제를 해결 하게 되는데요.
여기까지가 자바나 기타 현대적 언어의 탄생 배경을 나름되로 요약 해 봤습니다.

자바나 스몰토크,c# 등 현대적 언어들이 결코 전통적 언어보다 복잡도를 증가하는 목적으로 사용되지 않는 다는 겁니다.
만약 그런일이 있다면 그 프로젝트 관계 자들의 역량이 부족해서 발생한 문제 이겠지요
실제 c로 1000 라인 이상의 코드량이 필요한 HTTP 처리 애플리케이션은 단 4줄이면 C#으로 구현 가능 합니다.
물론 다른 클래스를 사용하므로 얻는 방법이지만 누가 어떻게 사용하는가 에 따라 애플리케이션의 복잡도는 틀려 진다고 생각 합니다. 단순이 어떤 언어를 사용해서 복잡도가 증가 하지 않는다는 것이지요.

두번째 혹시 한번이라도 엔트프라이즈 소프트웨어 개발에 참여 하신적이 있는지요?

SI 개발이 공장형 개발이라고 주장을 하시는데,
그 말은 단순히 코드의 열거 나 카피로 제품을 찍어내듯 생산한다는 말씀이지요?
기업은 이윤을 추구하는 집단 입니다.
즉 시장에 나와 있는 패키지 형의 소프트웨어를 통해 해결할 수 있는 기업는 절대 SI 프로젝트를 진행 하지 않습니다.
시장에 나와 있는 패키지 형의 기업형 소프트웨어들은 표준화된 기업환경에서 매우 휼륭하게 문제를 해결하고 사용할 수 있는 수준으로 제작 되어 져 있습니다.
가격도 SI 프로젝트로 소프트웨어를 제작 할때 보다 100배 정도 저렴하게 들어 갑니다.
그런데 왜 기업들이 비싼돈 들여 가며SI 프로젝트를 할까요?

기업들은 각 기업들 심지어 부서 팀 단위로 같은 일과 같은 업무라도 처리 방법이 조금식 상이 합니다.
이 것이 도메인 환경인데요.
이 도메인 환경과 요구사항에 맞는 소프트웨어가 공급이 되고 사용이 되어야만 비즈니스적 가치 를 추구 할수 있기 때문 입니다.
아무리 저렴하고 휼륭한 프로그램이라도 도메인이 요구하는 변화 무쌍하고 이해 안되는 가치를 추가 하지 못한다면 단 1원으 가치도 없어지니 100배의 비용을 지불하고서라도 SI 프로젝트로 맞춤형 소프트웨어를 개발하는 것 입니다.
그런데 그쪽의 주장되로 공장형으로 아무런 창의성과 개성도 없이 거저 표준화된 프로세스에 맞쳐 카피하고 찍어 내는 소프트웨어가 어떤 가치를 가지고 있을까요?
그렇게 일하는 회사는 몇년안에 시장에서 배척 당하고 사라지기 싶상 입니다.
실제 SI 개발에 참여하는 개발자들은 매일 같이 도메인 문제를 해결하기 위해(절대 논리적으로 발생할수 없는 요구사항도 많이 존재 합니다. 가령 1+1을 하면 특정 사항에서는 10000이 나와야 하는 것 처럼) 창의적이고 독창적인 문제 해결 방법을 고민하고 만들어 내고 있습니다.
도대체 코드라는 직군이 어디에 속하고 어떤 일을 한는 사람들인지 모르지만, 최소한 SI 개발을 하고 계시는 개발자 분들은 단순히 코드를 카피하고, 설계문서를 바탕으로 코드화 시키는 단순한 노가다를 하시는게 아니라는것을 이해 하셔야 할 것 같습니다.
아무리 휼륭한 설계도 의사 소통 도구 이상 할 수 없는 곳이 SI 프로젝트 입니다.
수분 전에 정의된 요구사항에 의한 설계 문서는 이미 낡고 변화된 요구사항을 반영하지 못하는 설계가 되어 버리는 일이 허다 하고, 또한 설계와 구현의 개념적 차이 에서 발생하는 오류는 절대 개발에 임하기 전에 알수 없기에 설계하고 설계되로 코드만 생산 해내는 개발 방법은 세상에 존재 하지 않습니다.
성공한 SI 프로젝트 곳곳에는 개발자들의 번뜩이는 창의성과 날카로운 통찰력에 의해 해결된 문제들이 수도 없이 존재하며, 그런 애플리케이션을 볼때 인간의 능력에 대한 경의로움 까지 느끼기도 합니다.

그리고 Si프로젝트가 생산성을 정량적으로 분석하고 일정 자원 등을 예측하기 위해 창의성을 말살 하는 자바 언어 같은 것들이 필요하다고 하셨는데요.

도대체 누가 생산성을 정량적 분석을 하고 일정/자원에 대한 예측을 언어적 관점에서 한다고 합니까?
그쪽 께서 말씀하시는 공장형 단순 코드 업무인 SI 프로젝트에서 가장 힘든 문제가 한정된 자원 하에 최대한의 비즈니스적 가치를 생산해 내는 것 입니다.
그냥 자동화된 공장에서 생산해내는 프로세르로 SI 프로젝트를 생각 하시니 아무런 문제 될게 없지요.
그저 하루에 3개 의 프로그램씩 제작 가능하니 1달이면 60개 만들수 있겠구나 뭐 이런 씩으로 생각하시는것 같은데요.
SI 프로젝트도 소프트웨어의 개발은 기계가 하는 것이 아닌 사람이 하는 것 입니다.
그리고 앞에서 밣혔듯이 정형화된 제품을 생산하는 것이 아닌 특정 한 목표를 하는 특별한 결과물을 만드는 것이고요.
이런것들과 또다른 요인으로 일정/자원에 대한 정확한 추정을 불가능하게 하는데요.
Si프로젝트에서는 그런 문제를 계속적 조정을 통해 해결 해나가고 있습니다.
매주 매일 매시간 매분 프로젝트 전반에 변화가 생기면 새로 추정을 하고, 추정 결과로 인해 발생하는 일정/자원 활당의 문제를 해결 해 나가며 프로젝트를 해나가는 것이지요.
솔직히 업무시간을 늘려 부족한 자원 문제를 해결 하는 방법도 많이 사용 되고 있지만 이런 방법은 얼마 가지 못해 그 효율성을 다해버려 지속적으로 발생하는 이런 문제를 해결하는데는 도움이 안됩니다.
또한 이런 프로젝트 관리적 이슈 사항 들은 복잡한 이해관계 자들이 존재하는데요, 가령 돈을 지불한 투자자, 실제 사용할 사용자, 프로젝트 사업을 하고있는 사업자, 개발을 담당하는 개발자, 설계자, 디자이너, 마케터 등등 수많으 이해관계자들의 균형을 맞추고 요구사항을 반영해서 문제를 해결해야 하는것 입니다.
결코 정형화 되고, 대량생산적 방법으로 프로젝트를 진행하고 애플리케이션이 만들어 지는 곳이 SI 프로젝트가 아님을 이해 하시기 바랍니다.
또한 자바라는 언어 자체도 그런 목적으로 사용되지 않는 다는 점도 명심하시기 바랍니다.

네 저는 SI 프로젝트를 업으로 살고 있는 8년차 코드 입니다.
그래서 그쪽의 이해 부족으로 작성하신 SI 비하 발언에 발끈해서 긴 글을 적어 봤습니다.
부탁 드립니다. 잘 모르시고 이해 하지 못하시는 분야 라도 무턱되고 비난하시지 말기를 바랍니다.
요즘 개발자들 사이에서 더욱더 Si를 천시하는 문화가 생기는것 같아 안타깝습니다.
대부분 SI 라는 것을 이해하지 못하고 살짝 1~2년 정도 해보고 힘든 업무로 떠나시는 분들이 푸념썩인 말들이 와전 되어 그렇게 되는 것 같아 더욱 안타 깝습니다.
제가 8년 동안 SI 를 경험 하면서 말씀드릴 수 있는 것은 좋다 나쁘다의 문제가 아닌 이곳도 인간이 사는곳이며, 아직도 도전해야 할 것이 많은 분야 라는 것 입니다.
전산을 모르는 제 친구들은 항상 저에게 이야기 합니다.
웹사이트 만들어 달라고, 네이버 같은거 만들어 바라고, 왜 게임은 안만드냐고?
이제는 전산을 잘아는 개발자들도 말 합니다. 왜 Si하세요?
저는 묻고 싶습니다. 왜 소프트웨어 개발을 하세요?

조금 언잖은 글이라도 개발자 로서 깊고 넓은 마음으로 이해 부탁드립니다.

잘 가야지.

지리즈의 이미지

c로 1000 라인 이상의 코드량이 필요한 HTTP 처리 애플리케이션은
그 구성이 천차 만별일 것이고,
그 효율과 성능에 대해서 논문도 수십편이 나올 것입니다.

하지만, C#이면 4줄로 끝나고..
사실상 이 프리메이드된 컴퍼넌트를 사용하는 것에 대해서 이견이 있을 가능성이 거의 없지요.

memcpy를 사용할 것인가?
아니면 독자적인 메모리 카피를 사용할 것인가?
아니면, 소프트웨어 구성상 차라리 복사를 사용하지 않고 포인터로 드라마틱하게 이 부분을 해결할 것인가?

C프로그래머들은 공돌이적인 마인드가 강하고 공학적인 측면에서 언어를 바라봅니다.
그렇기 때문에 창의성에 대한 개념도 아주 협소하지요.

이런 의미에서 java,C#은 전산공학(?)적인 측면에서 보면 C에 비교하면 창의성이 없는 언어입니다.

제한이 너무 많아요. 자바에서 운영체제 커널을 날려 버릴 수 있나요?

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

지리즈의 이미지

C를 보면 이 새퀴들 정말 여전히 0.001초에 목숨거네...
딱 이거죠.
웹페이지 0.001초 빨리 로딩된다고 누가 알아주나?

적절히 아름답게 추상화되어서,
재활용성이 극에 달하면, 0.001초 늦는게 아니라,
0.5초가 소모가 되더라도,
훌륭하고 창의력이 있는 코드입니다.

그럼 C 프로그래머들은 그럽니다.
"내 소스는 1MHz 6502 CPU에서도 1K 메모리만 소모하면서도 니들 소스가
Xeon CPU 쿼드 코어 8노드에 실행되는 것보다 빨라!"

그럼 자바 개발자들은 그럽니다.
"그래? 그럼 16노드로 늘리지... 뭐...
대신 니들 PPC에서 실행되게 포팅하느냐고 삽질할때 우린 놀면된다."

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

ldgood의 이미지

개념글
------------------------------
모든것은 모든것에 잇닿아 있다.


------------------------------
모든것은 모든것에 잇닿아 있다.

soungno의 이미지

객체지향 언어 개발자의 관점에서 보면 HTTP 처리 애플리케이션의 구조와 구성에 대한 고민부터 시작하겠죠.
커멘드 패턴을 이용하여 하부의 처리 프로세스를 캡슐화 할것인가? 커멘트 처리를 맞고 있는 객체 생성은 선형 생성 을 할 것인가? 아님 팩토리 생성을 할것 인가?
이미 어떤 문제에 대한 어떤 해결 방법으로 객체를 운영하면 어떤 이점과 어떤 불리한 점이 있는 지 수백권의 서적과 수천 수만의 논문이 나와 있고 나오고 있는 사항 입니다.
C#으로 구현하면 이견 꺼리가 없을 꺼라는 생각 자체가 너무 닫혀 계시는것 같습니다.

위임을 통해 처리를 할것인가? 상속을 통해 처리 할것인가? 아님 조합 을 통해?
그도 아님 적당한 프레임웍을 제작 할것인가? IOC, 관점지향, 조금더 드라마틱 하게 연출 할수 있는 부분이 객체 지향 언어 쪽에 존재 하지 않을까요?

공학적 측면이라는 것이 무엇을 뜻하는 것인지 이해하기 어렵습니다.
그리고 전산 공학적 측면에서 본다는 것도 어떤 시각인지 죄송하지만 이해하기 어렵습니다.

File fileKernel = new File("/boot/vmlinuz-2.6.28-11-generic");
fileKernel.delete();

삭제 되는데요 ㅡㅡ;;

잘 가야지.

지리즈의 이미지

자바나 C# 같은 언어들은 추상적입니다.
추상화,재활용 및 은폐성 같이 계량화하기 어려운 부분을 다루죠.
더욱 업무지향적입니다. 정확히 말하면 업무지향적으로 사용해야 더 효율적이죠.

반면, C는 주로 알고리듬 문제이고(이런 것을 위해서 C를 사용하죠)
수열과 방정식으로 그 알고리듬의 효율을 구체적으로 계량화해서 검증합니다.
이것이 바로 공학적인 측면으로 보면 됩니다.

능숙한 C 프로그래머는 C소스를 보면서 바로 어셈블리 코드를 봅니다.
이런 스타일의 사람은 자신이 짜는 VB소스를 실시간으로 C++로 번역해서 어셈블리 코드로 보기조차합니다.
그런데, 자바나 C#같은 것은
물론 알고리듬적인 해결책이 없다는 것은 아니지만,
도통 이것이 구체적인(여기서는 어셈블리 코드)로 연결되지가 않습니다.
이러면 골수 C 프로그래머들은 java나 C#같은 vm에서 코딩할 경우
마치 모래위에 성을 쌓고 있는 듯한 느낌이 듭니다.
게다가 세부적인 접근을 할 수 없기 때문에 답답하고
자신이 할 수 있는게 그다지 없기 때문에 자신의 창의성이 막힌다는 생각이 들죠.
(여기서는 실시간으로 어셈블리어로 바꿔서 리얼타임 튜닝을 하는 것을 의미합니다.)

훌륭한 C 프로그래머는 얼마만큼 구체적으로 접근하느냐가 실력이라면,
휼륭한 개체지향 프로그래머는 얼마만큼 현실세 계를 추상적으로 잘 분석해서 옮기느냐가 관건이죠.

이어진 글을 보면, 제가 자바가 창의성이 없다고 말하는 것이 아니라,
C프로그래머들의 관점에서 봤을 때는 창의성이 없다라고 느껴진다라는 것을 말하는 것을 알 것입니다.

결국 보는 관점이 전혀 다르다는 것이죠.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

codepage의 이미지

JAVA는 공장에 SI에 적합하고 주로 쓰이는 언어다 라고 주장하신 분에게 드리고 싶은 말이 많지만 짧은 몇마디로 대신하고자 합니다.
JAVA가 공장제 SI 라고(이렇게 표현하신 이유는 거의 SI = 노가다 라는 생각이 있으신 것 같은데) 하셨는데
SI의 본질은 고객의 요구사항을 얼마나 잘 이해하고 구현해 나가느냐가 핵심이지 노가다가 핵심은 아니지 않나요?
위의 답글을 다신 분은 좀 고차원적으로 표현을 하셨고 저는 좀 쉬운 말로 표현하면
고객 요구사항을 제대로 이해하지 못한다면 프로그래밍 언어가 무엇이고 몇명을 투입하느냐를 산정하지도
못할테니까요.
JAVA로 구현하면 개발 생산성은 일반적으로 빨라지지만 그것이 '일반적인 장점'은 되어도
반드시 SI용 언어라고 생각하는 것은 좀 너무 비약이 심하신 것 같다는 생각이 들고요
또한 창의성과 프로그래밍 언어와는 그렇게 많은 관련이 있어 보이지도 않습니다.
동일한 알고리즘을 서로 다른 프로그래밍 언어로 구현히 가능하고 중요한 것은 알고리즘(설계)지
노가다(구현)이 아니라는 것은 원래 '공장제 SI'라고 쓰신 분 정도 되면 아실 듯도 한것 같은데요.
혹시 님은 C로 POSIX 를 사용한 TCP/IP 통신 소프트웨어를 Linux, Solaris, HP True64, AIX등의 크로스 플랫폼 개발 환경에서
개발해 보신 적이 있으신지요?
그런 서버 프로그램 Aging Test하는 것이 한 플랫폼에서 최소 1주일은 걸릴 터인데.
한가지의 결과물을 얻기 위해서 그러한 일을 해야 하는 것이 진짜 '노가다'가 아닌지요?

JAVA는 JVM 버젼만 확인하고 카피해서 돌리면 바로 돌아갑니다.
그리고 남는 시간은 휴가 가서 노는 것이 진짜 인생을 즐기는 길이 아닐까요?
ROI로 보면 하찮은 멀티 플렛폼에서의 포팅 등에 시간을 낭비하지 말고요.

물론 무엇을 만드냐에 따라 적절한 수단이 있습니다.
운영체제를 JAVA로 만들 수는 없지요.

하지만 님의 글은 전체적으로 어떤 합리적인 근거가 없이 그저 자기 주장만하고 있는 것 처럼밖에 보이지 않습니다.

c0d3h4ck의 이미지

> 공장형 생산용으로 진화를 거듭하고 있는 자바는 그 사용에 개성과 창의성를 말살 당하면서 일하게 된다는것 때문이겠지요.

생산성이 꼭 기업을 위한 공장형 프로젝트를 위한 것 인가요?
오픈소스 프로젝트중에도 엔터프라이즈급 프로그램을 위한 프로젝트들이 많지요?
생산성 좋은 언어들 때문에 개인 또는 소수의 인원이 작업하는 오픈소스들도 속도를 낼 수 있는겁니다.

그리고 왜 자바가 창의성을 말살하는거죠?
창의성은 알고리즘에서 발휘될 때 높은 가치가 있는 것이지 코드레벨에서의 창의성이 얼마나 가치있는지
잘 모르겠군요.

handan의 이미지

저 역시 C 나 C++ 보다는 Java 로 밥먹고 산 기간이 더 긴지라 Java 언어를 생각하면 좀 더 편안한 느낌을 가지게 됩니다.
그런데, 간혹 Java 언어와 나 자신을 혼동하시는 분들이 있습니다.
Java 언어를 비판하면 자신이 공격당한다고 생각하시는거죠.

아무래도 Java 가 진입장벽이 낮기 때문에 어려워보이는 다른 언어보다 비판에 대해 민감해서 그런 것이 아닐까 싶습니다. (물론, 열혈 C 개발자분들은 OOP 를 무슨 괴물쳐다보듯이 하시긴 하지만 ^^)

API 만 잘 가져다쓰면 여타 제반사항은 몰라도 어느 정도 수준의 프로그램은 잘 뽑아낼 수 있는 언어가 Java 입니다.
앞서 어떤 분께서 말씀하셨듯이 Java 는 경력이 쌓일수록 OOP 적 디자인능력이 더 중요해지지 C 언어같은 코딩자체의 심오함이 깊어지지는 않습니다. (최근 Java 버전은 문법이 좀 복잡해지긴 했습니다만 그것과는 조금 다르죠.)

태생적으로 Java 로 개발을 시작하신 분들은 약간 추상적인 논리체계를 가지고 계시고, 좀 더 하위레벨의 개발언어로 개발을 시작하신 분들은 좀 더 실체적인 논리체계를 가지고 계시죠.

점점 Java 프로그래머의 수가 많아지면서 이런 문화적 차이가 두드러져보이는 것이라고 생각되네요.

이런 모습들을 보고 있으면 저는 C 와 어셈간, 혹은 C 와 C++ 간의 논쟁이 떠오르곤 합니다.
언어를 도구로 보지 못하고 자신과 동일시하는 모습은 개발자라면 누구나 거쳐가는 과정인지도 모르겠습니다.

oomymy의 이미지

C, Java 프로젝트를 해년마다(?) 번갈아가며 하는 저로썬 양쪽 진영의 이른바 '문화'차이를 잘 느끼고 있는데요.
(개인적으로 주로 시스템/네트워크 프로그래밍을 합니다.)

C 진영에서는 Java 진영 사람들이 API를 갖다쓰려고만 하지 알고리즘 및 효율적인 설계에는 약하고, 코드를 복잡하게 짜는 경향이 있다고 말합니다.

Java 진영에서는 C 진영 사람들이 요구사항 변경에 유연하게 대처할 수 있는 객체지향적 설계의 진수를 맛보지 못하고 무식하게 코딩한다고 말합니다.

저는 이러한 차이가 언어 및 그 언어가 기반으로 삼고 있는 패러다임의 차이일수도 있지만, 근본적으로 수행하는 프로젝트의 성격에서도 그 차이가 온다고 봅니다.

주로 C가 활용되는 임베디드/시스템프로그래밍에서는 요구사항 변경이 많지 않습니다. 대신 효율적이고 컴팩트하며 빠른 성능을 보이는 코드를 작성하는 일이 대부분입니다. OS가 제공하는 기능을 최대한 활용하면서 타이트하게 밀착해서 뭐랄까... 시스템의 성능을 최대한 뽑아내도록 프로그램을 짠다는 느낌이 듭니다.

Java가 주로 활용되는 대규모 프로젝트들에서는 요구사항 변경에 유연하게 대처하는 것이 가장 큰 과제입니다. 제가 전에 했던 Java 프로젝트에서는 일주일에 한 번씩 새로운 기능 추가나 기능 변경 요구가 들어오죠. 이에 잘 대처하기 위해선, 중복코드를 최대한 피하며, 변경이 발생해도 프로그램의 다른 부분에 영향을 미치지 않으면서 깔끔하게 코드를 유지해야 하죠. Java 진영에서 마틴 파울러류의 refactoring같은 이야기가 많이 나오는 것도 이런 배경에서 기인하는 것 같습니다.

재밌는 것은, 제가 위에서 예를 든 오픈소스 분산처리 및 파일 시스템 Hadoop같은 경우는 Java를 이용한 프로젝트이지만, C에서 얘기했던 성격을 많이 지니고 있습니다. 알고리즘에 많은 신경을 써서 효율성을 강조하고, 분산처리 및 파일 시스템이기 때문에 Scalability 및 fault tolerance를 보장하기 위한 아키텍처/디자인에 많은 신경을 쓰고 있죠. 요구사항 변경은 크지 않으므로 객체지향적으로 우수한 설계를 갖고 있진 않으며, 약간 C로 짠 듯이 알고리즘을 나열하는 스타일의 코드도 꽤 많죠. 이런 점을 살펴봤을 때 두 진영간의 소위 말하는 '문화'차이는 언어에서 기인했다기 보단 각각의 언어가 주로 사용되었던 프로젝트에서 발생한거라고 봅니다. (반대 예도 찾아보면 있겠죠. C로 엄청난 요구사항 변경을 수용해 내야 하는 프로젝트들은 설계에 무진 공을 들일 것입니다. 아마 OOP적 설계 요소는 거의 다 찾아볼 수 있겠죠)

최근들어 이런 시스템/네트워크 프로그래밍 쪽에 Java가 많이 쓰이고 있습니다. 적어도 오픈소스 진영에서는 상당히 인기이죠. 그 이유는 C에 필적할만한 성능을 내진 못하지만, 생산성이 대단히 좋거든요. 메모리 관리도 편리하고 네트워크 프로그래밍을 비롯한 각종 API들이 잘 갖추어져 있으며, 최근 들어서는 JVM의 성능이나 런타임 옵티마이제이션이 아주 좋아졌기 때문에 성능 그 자체도 큰 문제가 되지 않습니다.

또 하나 재밌는 점은 Java 언어가 주로 쓰이고 있는 프로젝트들의 성격입니다. 대부분 어떤 코드들을 최대한 빠르게 수행하여 최소한의 Response time을 내는 것보다는 어느 정도 reasonable한 response time을 내주면서 Scalability 보장이 훨씬 중요한 프로젝트들에서 Java 언어가 가장 많이 쓰이는 것 같습니다. 아마도 SI이니, 웹 프로그래밍이니 하는 곳이 이런 분야일 것 같습니다. 제가 예를 든 Hadoop도 마찬가지이죠. 성능이 필요하다면 장비를 더 투입하기만 하면 linear scalability가 보장되도록 시스템을 만드는 것이 중요한 프로젝트에서는 어떤 코드를 얼마나 빠르게 수행하느냐는 거의 관심사가 아닙니다. 이런 프로젝트들은 대부분 빠른 수행보다는 (디자인적이든, 아키텍처적이든) 좋은 설계를 추구하는 경향이 크죠.

반면, Java가 적합하지 않는 분야도 꽤 있습니다. Hadoop 프로젝트의 하부 프로젝트인 HBase에서 관련 논쟁이 있었습니다. HBase는 분산 데이터 저장소인데, 쉽게 말해 데이터베이스라고 보시면 되겠습니다. 이 프로젝트는 메모리관리가 대단히 중요합니다. 데이터를 메모리에 저장했다가 일정만큼 쌓이면 파일에 내려 저장해야 하는 일을 반복하기 때문에 compact한 메모리 관리가 필요하죠. 이런 분야에서는 Java의 약점이 금방 드러납니다. 물론, 가비지 컬렉션이 다양한 알고리즘이 있습니다만, 직접 메모리를 세세하게 관리하는 것에 비해선 아무래도 약점이 있기 마련이죠. 그래서 HBase 프로젝트를 진행하는 사람들은 이런 문제로 인해 서로 싸운 후, C++기반의 Hypertable 프로젝트로 갈라져 나오게 됩니다. 물론 Hypertable측의 의견에도 반론이 많이 있을 수 있습니다만, Java가 가비지 컬렉션의 편리함을 제공하는 대신 특수한 분야에서 메모리 관리를 세세하게 하지 못하는 제약도 있다는 것에는 모두가 동의하는 것 같습니다.

글이 길어졌는데, 제 요지는 handan님의 말씀대로 언어는 정말 '도구'에 불과합니다. 어떤 언어를 잘 다루는 것도 중요하지만, 다양한 언어를 잘 다루면서 적재적소에 가장 잘 맞는 언어를 이용하는 것이야 말로 진짜 능력이 아닌가 생각됩니다. 특히, 여러 언어를 배워보게 되면 문제 해결을 위한 각 언어들의 다양한 접근 방법을 배울 수 있게 되고, 이는 더 넓은 시야를 가질 수 있는 계기가 될거라 생각합니다.

semmal의 이미지

전 16년전부터 C를 썼고, 지금은 C/C++를 쓰고 있는 사람입니다. 그런데 제가 제일 싫어하는 언어가 C/C++/Java라는 겁니다. 저보고 C/C++/Java를 까라고하면 날밤을 세면서 깔 수도 있습니다. 학교 다닐 때 몇 번 해봐서 다시 한다고 어려울 것도 없습니다. 웃기는 건 제일 잘써먹는 언어 또한 C/C++/Java입니다. 단점을 요리조리 피해서 코딩하면 나름 괜찮은 작업결과가 나오기 때문입니다.

말도 안되는 이유로 폄하하지말고 말을 되는 이유로 까면 얼마든지 거들어드리죠. 뭐로 까야지 말이 되냐구요? 제대로 배우세요. 그럼 알게됩니다. 엉터리로 까서 자바 배우고 C배우는 다른 사람에게 피해주지 말라는 말입니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

youlsa의 이미지

참고자료입니다.
그냥 재미삼아... ^_^

프로그래머들 상호간의 "난 쟤보다 나아~" 차트.... 원본은 여기. pdf 버전도 있네요.

역시 예상대로 본좌의 자리는 Lisp 프로그래머들과 어셈블리 프로그래머들이 차지했네요.. 쌍방 상호 무시... ^^

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

댓글 첨부 파일: 
첨부파일 크기
Image icon programmers.JPG26.68 KB

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

blueiur의 이미지


루비가 펄을 무시하는게 재미있네요 :)
펄 해커님 들게서 화내실듯 ㅋ

youlsa의 이미지

그게... 그림 우하단에 보면 조그맣게 뭐라고 써있죠. ^_^
루비 프로그래머들께서 보시면 기분 나쁘실지도....

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

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

snowall의 이미지

번역해보니 이렇군요.

"루비 프로그래머들은 자신들을 다른 모든 종류의 언어 사용자들보다 우월하다고 생각한다. 단, 그들은 웹 프로그래밍 언어가 아닌 다른 언어의 존재를 알지 못하므로 펄 위에 두었다."

--------------------------
피할 수 있을때 즐겨라!
http://snowall.tistory.com

피할 수 있을때 즐겨라! http://melotopia.net/b

ifree의 이미지

프로그래밍 레벨의 가장 양 극단에 있는 두 언어가 최상위에 있다는게 인상적입니다.

MasterQ의 이미지

옆자리 인턴한테 이것을 보여줬더니 다음을 보내주는군요.

댓글 첨부 파일: 
첨부파일 크기
PDF icon programmer hierarchy (real).pdf32.15 KB
imyejin의 이미지

pure 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

댓글 첨부 파일: 
첨부파일 크기
Image icon programmer hierarchy (pure).jpeg124.69 KB

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

MasterQ의 이미지

Haskell 은 Type-safe하지 않다는 이유로 제외됐습니다. ㅎㅎ

imyejin의 이미지

뭐 Higer Order Theorem Prover들같은 거 말고 범용 프로그래밍 언어 중에서 type safe 한 언어가 뭐죠? -.-;;

혹시 이론적으로 type safety를 종이나 아니면 자동증명기로 증명했느냐 아니냐에 대한 것에 대한 것이라면, ML계열에서도 SML도 core에 대해서만 type safety를 종이에다 증명했지 확장 기능에 대해선 어차피 다 증명 안된 걸로 알고요, 특히나 OCaml은 SML이 답답해서 증명이나 그런 걸 떠나 실용적으로 쓸만한 툴을 만들자고 Xavier가 프랑스에서 치고 나간거고요.

무슨 근거로 하시는 말씀인지 그냥 농담으로 하시는 말씀이 아니라면 좀더 확실한 근거를 밝혀 주세요. 그냥 농담도 저렇게 아무 설명없이 한줄로 뜬금없이 던지면 재미가 없습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

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

MasterQ의 이미지

헉. 이 글에 답변이 달릴줄을 몰랐네요. 일반적으로 SML자체가 아주 type safe하다고 알려져 있기 때문이고 말씀하신대로 확장 기능을 제공하는 SML/NJ들은 예외가 될수 있겠습니다. Haskell은 type-safe에 대해서는 비교적 type-safe하지만 논란의 여지가 SML보다는 좀 더 제외된것이니까 별로 노여워 하실 필요는 없어 보입니다. (옆자리 인턴의 생각이 그래서 Haskell이 빠진것 뿐입니다)

type safety자체가 program hierarchy를 결정하는 이유는 처음부터 아니니까요.

imyejin의 이미지

그러니까 그 인턴분은 OCaml까지 적어 놓았으니 하는 말입니다 -_-;; MasterQ님께 할 말이 아니고 그럼 그 인턴분께 해야 할 말이네요.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

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

kslee80의 이미지

KLDP 에서, 라기보다는...
KLDP 에 오시는 분들이 Offline 상에서 Java 에 대한 악감정(?) 을 품고 오시는게 아닐까 싶네요.

(레벨로 사람을 따지는게 좀 그렇긴 한데...)
프로그래머 분들 중 일정 레벨 이상이 되시는 분들은 사실 필요한 분야에 맞는 언어를 고르고
사용하게 되고, 그쯤되면 C vs. Java 같은 주제는 그냥 한번 쓱 웃고 지나가겠죠.

(Case-By-Case 입니다만,)
하지만 아직 그 경지에 다다르지 못한 많은 수의 프로그래머 분들은
자신이 주로 사용하는 언어에 대한 자부심이 대단한 경우가 많고,
특히나 Java 와 같이 급속도로 그 활용 분야가 넓어진 언어의 경우에는 그 자부심이 하늘을 찌릅니다 ;;

그러다보니 은연중에 "Java 로 하면 다 된다" 라는 자신의 생각을 주변에 전파하게 되는 경우가 생기고,
특히나 Java 가 한참 성장할 시기에 Java 를 공부하는 프로그래머들의 수가 증가함에 따라
이러한 성향을 보이는 프로그래머도 급속도로 증가하게 되고,
그러다보니, 다른 언어를 사용하는 분들에게 일종의 성급한 일반화를 일으키게 된 거겠죠.
("Java 쓰는 넘들은 다른 언어 다 무시하더라." 라는 성급한 일반화...)

거기다가, 초창기 Java 의 경우는 VM 의 로딩속도가 무시무시했던 터라..
(요즘은 많이 개선된 듯 싶더군요)
C 프로그래머들에게 있어서는 저주받은 언어가 되어 버렸죠.

(사실, C vs. Java 의 수행속도를 비교하고자 한다면 Java VM 의 로딩속도를 제외하고 비교해야 하죠.
그리고 VM 의 로딩속도를 제외하게 되면 수행 시간 차이는 그리 크지가 않다고 생각합니다.)

하지만, 현재의 Java 의 모습을 보면 초창기에 Java VM 의 무시무시한 로딩 속도는 아쉽다는 느낌입니다.
Java VM 의 무시무시한 로딩 속도를 기억하는 사람들에 의해,
"Java 는 End-User App. 에는 부적합하다" 라는 개념이 생겨 버리고..
그로 인해 특정 분야에 특화된 언어로 발전해 버린게 아닌가 싶네요..

fender의 이미지

제가 추측하는 이유입니다 :

(1) 마인드의 차이

자바하면 생각나는 것이 무엇인가 '엔터프라이즈 하다'라는 것입니다. 위에도 언급한 분이 있지만 흔히들 *nix의 철학이 'simple is best'라고 하는데 자바가 추구하는 건 정반대인 경우가 많습니다.

사실 이 부분에 대한 제 생각은 절반은 동의한다는 것입니다. 자바쪽의 어떤 스펙이나 라이브러리, 제품들을 보면 가끔씩 엔터프라이즈하기 위해 엔터프라이즈한 선택을 하는 경우를 종종 보곤 합니다. 분명 크로스플랫폼에 대한 과도한 집착이나 설계상의 깔끔함에 집착해서 구현레벨에서 불필요한 오버헤드나 복잡함을 도입하는 경우가 있습니다.

실제로 KLDP의 자바 관련 스레드에서 자바에 대해 원론적으로 비판하는 분들이 이런 쪽의 논리를 펴는 경우도 꽤 많이 봤습니다. 다른 언어로 하면 훨씬 쉽고 단순한데 자바는 상업적인 이유로 일부러 불편하고 무겁게 만든다는 식입니다.

하지만 나머지 절반은 정말 그런 '엔터프라이즈'한 게 필요한 경우가 있습니다. 이에 대한 설명은 아래 이유와 많이 겹치는 관계로 이어서 쓰겠습니다.

(2) C/C++ 개발자의 반감 (이 부분은 위의 oomymy님이 거의 정확한 지적을 하셨다고 생각합니다)

모든 C/C++ 개발자가 그럴리는 없습니다만, 적지 않은 C++, 그리고 특히 C개발자가 자바에 대해 반감을 가지고 있습니다. 우선 KLDP에서도 수없이 이야기되던 성능에 대한 논쟁도 그렇지만 정말 중요한 이유는 주로 로우레벨을 다루는 C개발자와 엔터프라이즈급의 하이레벨을 자주 다루는 자바 개발자 사이에는 쉽게 다가서기 힘든 간극이 있다는 것입니다.

C에 어느 정도 익숙해진 개발자가 흔히 하는 착각은 모든 프로그래밍의 문제를 로우레벨로 이해한다는 것입니다. 물론 하이레벨만을 다루는 자바 개발자도 반대의 문제가 있을 수 있겠지만 상대적으로 OOP나 프레임워크 차원의 디자인 문제에 능숙한 정도의 개발자라면 최소한 기초적인 수준의 절차적 사고와 코딩능력이 있습니다. 자바를 아무리 익숙하게 다뤄도 이 걸로 디바이스 드라이버 같은 걸 쉽게 만들 수 없겠구나 하는 걸 상상하는 건 어려운 일이 아닙니다.

반대로 대학이나 취미로 C를 주로 배우고 상식선의 자바 지식을 가진 C 개발자라면 엔터프라이즈 개발에 통용될 정도로 하이 레벨의 객체지향 디자인이나 아키텍처, 프레임워크를 접해볼 기회가 거의 없습니다. 그러다보니 C 언어 기준으로 자바를 이해하게 되고 자바는 C보다 덜 강력하고 느린 이지모드 언어다 정도로 받아들이는 경우가 많습니다.

기본적으로 로우레벨 프로그래밍에서는 로우레벨의 시스템 콜이나 메모리 관리등이 강력하게 지원되는 것이 무엇보다 중요한 반면 하이레벨 프로그래밍에서는 모든 것에 앞서서 직관적으로 이해할 수 있는 개념을 쌓아 나갈 수 있는 구조가 필요합니다. 그래서 언어 자체적으로 인터페이스니 추상클래스니 접근자니 하는 OOP적 개념들이 녹아들어 있는 것이고 많은 수의 코어 클래스가 잘 알려진 디자인 패턴에 따라 설계되어있는 것이고, 이를 바탕으로 좀 더 크고 복잡한 문제를 다루기 위한 프레임워크와 라이브러리들이 계층적으로 쌓여있는 것입니다.

즉, 이런 식의 하이레벨 프로그래밍은 레고 블럭과 같습니다. 레고 블럭의 종류는 한정적이고 두 블럭을 접합하는 방법은 정해져있습니다. 하지만 그렇다고 레고 블럭을 쌓아서 만드는 결과물이 작고 단순한 것만 있는 것은 아니고 오히려 훨씬 단시간에 크고 복잡한 결과를 만들 수 있습니다.

물론 비슷한 모양을 예를들어 찰흙을 빚어서 훨씬 디테일하게 만들 수 도 있습니다만 비용이나 시간이 더 많이 들 것이고, 결정적인 문제는 한 번 굳어 버리면 재활용할 수 없는 찰흙과는 달리 요구 조건이 바뀌면 쉽게 일부를 허물고 다시 쌓는다거나 심지어 부분을 통째로 뜯어서 다른 작품에 재활용할 수도 있는 것입니다.

경험이 부족하지만 자신의 실력에 대해 자만하는 일부 C개발자들은 C언어는 강력하니까 자바와 같은 하이레벨 언어가 할 수 있는 것은 시간만 충분하고 개발자 능력만 있다면 C로도 훨씬 낫게 할 수 있을 것이라고 착각하고는 합니다. 경험이 많지 않고 C언어만 다뤄본 개발자는 기본적으로 추상적인 사고, 구조적인 사고에 취약합니다. 대신 구현 레벨의 여러 테크닉이나 마이크로 최적화, 시스템의 디테일 등에 강점을 가지고 있습니다. 따라서 기본적으로 그런 추상적 사고와 구조에 대한 설계능력이 요구되는 하이레벨 프로젝트를 직간접적으로 경험하기 전에는 자바의 장점을 이해하기 어렵습니다. 실제로는 하이레벨 개발능력 역시 로우레벨 능력 만큼이나 배우는데 많은 시간이 걸리고 어느 한쪽을 잘하면 다른 쪽은 자연히 잘할 수 있는 그런 것은 아닌데 이제 막 한가지 방법에 자신이 붙은 개발자 입장에서 그런 면을 이해하긴 어렵다고 봅니다.

vi/emacs vs IDE 논쟁도 조금 비슷한 측면이 있는데, vim에 충분히 익숙한 개발자라면 도대체 왜 무겁고 복잡하게 이클립스 같은 IDE를 쓰는지 이해 못할 수도 있습니다. 그리고 사실 이론적으로는 이클립스로 개발하는 자바 소스는 vim으로도 모두 작성 가능합니다.

하지만 아마 그 개발자가 실무에 투입되서 예를들어 천여개 클래스가 널려있는 프로젝트에서 수십개 클래스가 포함된 패키지를 리팩터링해서 다른 곳으로 이동 시켜야할 일을 경험해본다면 그 때서야 이클립스 같은 IDE를 쓰는 사람은 모두 vim을 배우기에 너무 게을러서 쓰는 것이 아님을 깨닫게 될 것입니다.

(3) 동적 스크립트 언어 개발자의 반감

위와 비슷한 이유로 리눅스에서 인기있는 동적 스크립트 언어 개발자들의 강한 타입형 언어인 자바를 '낡은' 기술로 취급하려는 경향이 있습니다. 물론 어떤 작업에 대해서는 동적 스크립트 언어가 훨씬 개발하기 쉽고 이해하기 쉽게 적용할 수 있을 것입니다. 하지만 반대로 일반 스크립트 언어 개발자가 흔히 접하기 힘든 기업 규모의 대규모 협업에서는 많은 일이 미리 약속된 API와 계층구조, 타입을 사이에 두고 일어나고 있습니다.

동적 언어로는 대규모 프로젝트를 하지 못한다거나 협업이 안된다는 뜻은 아닙니다만, 최소한 모듈단위로 대규모 협업을 한다면 컴파일 타임에 일부 오류를 잡아낼 수 있고 중간에 API가 변경되도 개발툴 차원에서 신뢰성 있는 리팩터가 가능하고 API에 아직 익숙하지 않은 개발자들이 점만 찍으면 메소드와 인자 목록을 자동으로 가져오는 등의 기능이 작은 규모의 개인 프로젝트보단 훨씬 중요하게 받아들여진다는 것은 쉽게 상상할 수 있습니다.

(4) 역사적 이유

역사적으로 선 마이크로시스템즈와 오픈소스 진영의 관계가 좋지 않았습니다. 특히 과거 자바의 라이센스에 대해 오픈소스화 할 것처럼 힌트를 줬다가 번복하기를 반복하는 등 신뢰를 떨어뜨리는 행동을 많이 했기 때문에 이후 회사가 오픈소스에 좀 더 적극적이 된 이후에도 반감이 남아있는 경우가 있습니다.

또한 과거 리눅스의 자바 구현은 성능도 좋지 않았고 오픈소스화된 지금도 GUI나 설치 등이 시스템과 잘 통합되어있지 않습니다. 그리고 자바가 널리 쓰이는 서버 환경은 일반 사용자가 볼 수 없는 곳에서 운영되고 있습니다. 반면 몇 안되는 일반 사용자 대상 자바 데스크탑 프로그램은 보통 못생겼고 깔기도 귀찮고 무거운 것이 사실입니다.

그런 경험들이 오랜 기간 지속되다 보니 자바에 대한 반감이 쌓이게 된 것이 아닌가 싶습니다.

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

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

vacancy의 이미지


kldp에서 Java보다 C 얘기가 많은건
아무래도 Java에 관심이 많으신 분들은
주로 Java 커뮤니티에서 활동하고 계시기 때문이 아닐까;
.. 하는 생각이 듭니다.

물론 여기가 C 커뮤니티는 아니지만,
*nix 계열과 C 언어는 사실 뗄래야 뗄 수가 없는 관계니까요.

그나저나 semmal님은 이 글타래를 쭉 보셨을때
본인 글들 말고는 그다지 공격적인 글이 없다는 생각이 안드시는지 ..
그냥 글 쓰는 재주 때문이라고 말하기엔 조금 부족한 감이 있네요.
그다지 안좋은 일이 있으셔서 잠간 그러신 거리라 믿습니다.

semmal의 이미지

아무래도 저는 이제 계속 눈팅만 해야할 것 같습니다. 이전에도 비슷한 불미스러운 일에다 업무로 인해서 잠깐 떠나있었는데...

다시 돌아온 요즘을 살펴보면 상당히 냉소적이고 날카로워져 있는게 사실인 것 같습니다. 아무래도 욱하는 성질이 더 심해진 것 같네요.

남들 이야기보다는 제 삶에나 충실해야겠습니다. 지적해주셔서 감사합니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

creativeidler의 이미지

제가 참견할 바가 아닌지는 모르겠는데, 이 글타래만 놓고 semmal님만 공격적이라고 하는 것은 공정하지 않습니다. 이 쓰레드는 이 앞의 자바가 빠르냐 C가 빠르냐의 연장선 상에 있는 것이고 그 쓰레드의 플레임에서는 여러 사람이 공격적인 멘트를 했죠. 그런데 여기서 semmal님만 공격적이라는 이야기를 하게 되면 마치 플레임 전체의 책임이 semmal님에게 있는 듯한 느낌을 줄 수 있습니다.

플레임이 일었을 때 플레임 참가자들에게 공격적이라는 공격(?)을 하는 것이 합당한가 하는 의문도 드는군요.

vacancy의 이미지


공정하지 못했다면 semmal님과 creativeidler님께 죄송합니다.

그저 제 개인적인 생각에 플레임이 일어난 이유가
semmal님의 글 때문이라고 생각했기 때문에 그렇게 적은 것이고요.
semmal님께서 의도적으로 플레임을 일으키셨다기보다는
일반적인 플레임과 다르게 초기부터 조금 공격적이시기에
무슨 다른 안좋은 일이 있으셔서 그러신건가 싶어
릴랙스하시면 좋을것 같아서 저렇게 적었습니다.
닉을 꽤 오래 전부터 접한 것 같아서 트롤이라고 생각하진 않았거든요.

아무튼 저런 생각 자체가 제가 주제넘었을수도 있고요.
제 개인적인 생각만 적은 것이고, 제 생각만 맞다고 생각하지는 않습니다.
기분 풀어주세요. ^^;

lain07의 이미지

그냥 학생입니다..만
자바의 매력은 몇년간 하면서 확실히 느꼈습니다.
개인적은 경험..혹은 느낌으로 C는 리눅스에 가깝다면 자바는 윈도우에 가까운 느낌이었습니다.
그냥.. 제 느낌입니다. 그것도 단편적인 부분밖에 접하질 못했죠.

___________________________
I like Small Linux.


___________________________
I like Small Linux.

select99의 이미지

잘못알고 계신분이 있는데.

C 는 고급언어이면서 저급언어의 장점까지 동시에 가지고 있는 언어로 유명한언어입니다.

C를 저급언어로 착각하는건 하이벨에만 사용되는언어와 비교해 놓고볼때
로우레벨프로그램에까지 널리쓰여지는 C는 저급언어인가? 라는착각마저 하는거 같습니다.

실제 사용을봐도 현대의 많은고급 언어들이 C문법과 흡사하게 따르고 있습니다.

또한 OOP가이렇게 널리 알려지기도 훨씬 이전에..이미 C에서는 OO적인프로그램이 가능했고..
지금도 물론 적절히 쓰이고 있습니다.

금방재미있는생각도 드네요..
C++에 적절한 클레스와 매크로를추가해주면 자바소스를 그대로 가져와 C++로 사용할수 있지 않을까하는..

fender의 이미지

글의 핵심을 잘못 짚으신 부분이 있는데요...

아무려면 그놈 사용자인 제가 gtk에서 처럼 C로 OOP를 구현하는게 원천적으로 불가능하다는 이야기를 했을까요...

하지만 언어 설계부터 코어 클래스의 구현에 이르기까지 OOP의 개념을 전제로 하고 만든 편이 아무래도 패턴과 컨벤션으로 OOP를 구현하는 쪽보단 훨씬 유리한 것도 사실입니다.

그리고 더 중요한 사실, 즉 원래 쓴 글의 핵심은 C가 OOP같은 객체지향 프로그래밍이 불가능하다는 게 아니라 주로 쓰이는 분야 자체가 디바이스 드라이버나 운영체제, 임베디드 같이 상대적으로 더 로우레벨이라는 점입니다.

이전 글타래에서 엔터프라이즈에서 자바를 널리 쓴다는 사실 자체도 부정하셨던 기억이 있기 때문에 어쩌면 이 것도 못믿겠다면 더 이상 할말은 없습니다.

하지만 최소한 제가 아는 범위 내에서는 C보다는 자바를 비즈니스 어플 같은 하이레벨 개발에서 훨씬 많이 쓰기 때문에 상대적으로 그 방면의 양질의 하이레벨 라이브러리와 프레임워크가 훨씬 많이 있다는 것입니다. 당연히 경험많은 개발자도 더 많고 노하우도 더 많이 쌓이고 돈이 몰리니 제품도 많이 나오지요.

자바로 3D 게임을 만드는 게 원천적으로 불가능한가요? 그렇게 생각하실지는 모르겠지만 실제로 게임엔진들도 몇몇 있습니다. 하지만 C계열의 언어로 하는 것이 훨씬 유리한 점이 많고 그런 이유로 더 양질의 게임엔진과 경험많은 개발자들이 C/C++ 쪽에 훨씬 많기 때문에 쓰지 않는 것 뿐입니다.

서버측 비즈니스 어플 개발 같은 하이레벨 분야에 C가 잘 안쓰이는 이유도 마찬가지구요.

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

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

select99의 이미지

"서버측 비즈니스 어플 개발 같은 하이레벨 분야에 C가 잘 안쓰이는 .."

C가 잘안쓰이다니.. 어이없군요... 무슨근거로 말씀하시는거죠?
많은 기업에서 아직도 서버프로그램이 C/C++로 되어 있습니다.
자꾸 웹만 생각하시는거 같은데.. 웹은 자바가많다하더라도 서버어플이 웹만있는게 아니죠.
사내업무용프로그램및 빌링,배치잡등 얼마나 많은데.. 자바로 된건 거의 없습니다.
클라이언트야.. C++Builder,파워빌더,델파이등여러가지가지만..서버쪽은 대부분 C/C++ 입니다.
아무리 java 프로젝트라하더라도 성능때문에 C/C++을 썩어 쓰는경우가 많습니다.

fender의 이미지

아무래도 저와는 다른 세계에 사시나 봅니다. 아니면 '비즈니스' 어플의 의미를 잘 모르시던가요.

다른 글타래에서 자바가 상업적으로 가장 많이 쓰이는 언어중 하나라는 사실 조차 부정하신 것을 보면 아마 전자 쪽에 가깝지 않나 싶습니다. 사시는 동네엔 안가봐서 모르겠지만 아마 그 쪽 세계에서는 서버 개발은 다 C로만 하나 봅니다.

그 동네의 C는 분명 저급언어이자 고급언어이고 자바 보다 성능은 물론 라이브러리 따위 필요없이 무조건 높은 생산성을 보장한다고 들었는데요 - 또 다른 글 타래에서 자바로 할 거 C로 하면 무조건 적은 비용으로 빨리 끝난다고 하셨죠?... 제가 아는 C언어는 그렇지 않으니까 아마 그토록 미워하시는 자바도 제가 하는 자바와 다른가 봅니다.

아... 지금 보니 아래 글에서 C와 자바가 포인터를 빼면 문법적으로 차이가 거의 없다고 하셨는데 그 동네 자바엔 인터페이스 같은 객체 지향 개념이 빠져있나 봅니다. 아니면 C가 워낙 강력해서 인터페이스나 접근자 같은 OOP개념도 몽땅 가지고 있던가요.

아무튼 좋은 동네 사시네요... 전 그냥 현실 세계에서 자바로 돈벌어 먹고 살겠습니다.

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

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

select99의 이미지

글을 항상극단적이며 잘못받아들이는경향이 있군요..

또한대부분은 완벽히라는말과 다른말인데 항상 과장이 더해지는군요.

예를들면 A반이 B반의 대부분의 학생을 데려갔다...

이말을 A반이 B반의 학생으로 으로만 구성되어있다고 잘못 이해하고 계시군요..

즉 A반은 B반의 학생들을 대부분 포함한 합집합일뿐입니다.

제가 애초 위에 그말이 나온건 자바는 고급언언데 C는저급언어로 잘못알고 계신분에게..
C의 포인터만빼고 대부분 자바에 존재하는 문법들일텐데...
그렇다면.. 자바또한 저급언어라는결론이지 않느냐 라는의미에서 한말입니다..

fender의 이미지

자바로 하면 무조건 C보다 느리고, 생산성 떨어지고, 돈도 많이 든다는 식으로 주장하시는 분이 상대방에게 '극단적'이고 '과장'을 한다고 반박하시니 흥미롭긴 하군요.

도대체 언제부터 고급언어와 저급 언어를 '문법'가지고 나눴던가요?

근데 자바로 실무까지 하신다면서... 정말로 포인터만 빼면 자바와 C 문법이 똑같던가요?

interface, class, new, private, protected, public, static, abstract, extends, implements, transient, final, synchronized, throw, throws, try, catch, finally, enum, ...

하긴 뭐 좀 '극단적'으로 '과장'해서 보면 파리도 새이긴 합니다.

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

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

select99의 이미지

님적은것중에 다른것만 골라적는다고 적으셨는지 모르지만.. 공통적인거도 있구요..

제가 위에 말씀드렸듯이.. A반에는 B반 학생들만 있는게 아닙니다.

A반에는 B반학생들만 있는거냐? 라고 또물으시는데.. 제글 제대로 안읽으시는군요..

fender의 이미지

자바와 C에 공통적인게 하나도 없다라고 한 사람이 있었나보네요? 전 그런 글은 못봤는데...

포인터'만' 빼면 C도 자바와 거의 똑같으니까 C도 고급언어라고 우긴 사람은 있었죠.

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

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

rubenz의 이미지

--> 이게 무슨 의미 인가요?
비즈니스 어플에서 하이레벨이란게 대규모,대용량, 처리를 말씀하시는건지요? 아니면 웹에서 일어나는 일을 처리하고 수행하는 의미 인지요? 궁금해서 그럽니다.

bookgekgom의 이미지

물론이죠.

같은 맥락으로 lisp 으로는 씨보다 더욱 유연하게 더 많은것들을 할수있겠죠.

그런데 중요포인트는

할수있는가 없는가가 아니라

사람들이 하고있는가 아닌가가 아니겠음?
---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

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

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

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

http://jihwankim.co.nr

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

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

소타의 이미지

단어의 차이인것 같은데요.. 저급 언어 <-> 하이레벨이 아니라 이게 상대적인 것 같습니다.
한 때는 C가 고급 언어라고 불리지 않았나요?
low level, high level 이 즈질이야~ 뭐 그런 의미의 저급 언어라는 표현이랑은 다르니까요.
후에 나오는 고급 언어들이 C문법을 차용하는건 그 개발자 층을 흡수하기 위함이 아닐까요? C의 문법이 절대적으로 최고다 라는건 아니니까요 ㅋ;

vacancy의 이미지


C는 현대에 와서는 고급 언어로 보기는 좀 어렵지 않나 싶네요.
물론 고급 언어를 정의하기 나름입니다만. ;;
어셈블리어와 기계어를 제외하고 C보다 더 저수준의 언어는 사실상 없으니까요.

그리고 많은 고급 언어들이 C문법을 부분적으로 차용하는 것만으로
C가 고급언어라고 말하기에는 어폐가 있죠.
그리고 C++를 제외하면 C와 흡사하다고까지 할만한 언어는 별로 없습니다.
Pascal이나 Cobol, Fortran보다 '상대적으로' C에 가까운 모양이긴 합니다만
C#, Java와 C 사이의 갭은 유사점보다 훨씬 많으니까요.
코가 닮았다고 닮은 사람은 아니잖습니까. ^^;

select99의 이미지

자바의경우 부분적 차용이아니라.. 포인터만빼고 거의 대부분 차용한거죠..
C프로그램할때 포인터 안쓰고 하면 자바인지 C 인지 구분이 안갈정도죠..

위에도 나왔듯이.. 저급이라 나쁘다는뜻이 아닙니다. 물론 고급이라해서 좋다는뜻도 아닙니다.
자바와 C 의 갭은 문법적 특징에서라기보다 구현방법과 수행상의차이지요.

vacancy의 이미지

오해가 있는데요. 제 말은 저수준 언어라 나쁘고 고수준 언어라 좋다는 뜻이 아니고요. ;;
솔직히 개인적으로 C, Java 양쪽 모두 코딩할 일이 많이 있고 둘다 싫어하는 언어인 것도 아니고 해서
별로 편견 같은 것도 없습니다. ( C++은 싫어합니다. -_-;; C나 C++이나 그게 그거라고 생각하지도 않습니다. )

아무튼 제 얘기는 연산자와 제어문 몇 가지, 부분적인 키워드들을 제외하면 공통적인 부분이 별로 없다는 말입니다.
두 언어 문법의 BNF 폼만 보셔도 어디가 얼마나 다른지 아실 겁니다.

수식 몇개 있는 함수 정도 짤 때는 비슷하겠지만 ..
(Primitive가 아닌) 변수를 선언하는 방법 (배열 등등),
타입을 선언하는 방법, 전처리기, 클래스 관련, 문자열 관리, 변수들의 scope, 등등 ..
완전히 차용했다고 보기 어려운 곳이 너무나도 많습니다. ;;
( 기본 표준 라이브러리들을 차치하고라도 말이죠. )

사실 양쪽 문법을 잘 아실 거라고 생각합니다만,
여유 있으실 때 BNF 폼을 비교해보시면 이렇게 생각할 수도 있겠다는 생각이 드실 겁니다.

-----

아무튼 위의 글과 관련해서 위키피디아에선 이렇게 말하고 있네요.

http://en.wikipedia.org/wiki/High-level_programming_language

The terms high-level and low-level are inherently relative. Some decades ago, the C language, and similar languages, was most often considered "high-level", as it supported concepts such as expression evaluation, parameterised recursive functions, and data types and structures, while assembly language was considered "low-level". Many programmers today might refer to C as low-level, as it lacks a large runtime-system (no garbage collection etc), basically supports only scalar operations, and provides direct memory addressing. It therefore readily blends with assembly language and the machine level of CPUs and microcontrollers.

feanor의 이미지

C는 저급언어 맞아요. 너무 저급해서 C로 Evolution 만들던 프로그래머들이 도대체 못해먹겠다 하고 C#을 쓰려고 Mono를 만들지 않았겠어요?

select99의 이미지

언어자체는 고급인데 로우레벨컨트롤이 가능한언어라고 하는게 정확한표현이죠..

매우오랫동안 사람들에게 그렇게 알려져왔고.. "고급언어 종류" 혹은 "고급언어 특징" 라고만 찾아봐도 많이 나올겁니다.

neocoin의 이미지

어셈블리 프로그래밍 주였던 세상에서 C가 태어나서 High Level Language 라고 분류되는 바람에 이후 나오는 모든 언어들에게 이름을 붙이는 고민을 안겨준것 같아요.

High High Language? Very High Language? Super Language?

최근 진입한 프로그래머의 경우 만약 Python, Ruby, Javascript(?)을 먼저 접했다면 String 제어조차 난감한 C를 Low Level Language라고 머리속에서 자리잡지 않을까요?

.... 진담반 농담 반입니다.

bookgekgom의 이미지

저도 씨를 저급으로 알고있었는데

옛날 문서에는 씨를 고급이로 말하고 있었습니다

고급이란 인간의 언어와 좀더 가깝고 쓰기 편한 그런 언어 아닌가요.

옛날에야 씨였겠지만 요즘은 자바나 씨샾정도가 고급언어겠네요.

뭐, 먼훗날 100 년후에는 씨샾이나 자바도 저급으로 변하는 시대가 올지도?

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

http://jihwankim.co.nr

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

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

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

http://jihwankim.co.nr

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

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

select99의 이미지

설사 고급언어 평가를 시대에따라 달리 재평가한다치더라도..

자바를 그리 차이를둘만큼 더나은 고급언어라 할수 없습니다..

또한 C는 스트링을 매우빠르고 정확하게 제어조작할수 있습니다.

자바는 지원라이브러리의 도움을 없이는 스트링조작이 난감한 언어입니다..
그래서 지원되지 않는기능을 하려할때는 난감한경우를 종종격지요..

fender의 이미지

무슨 스트링 조작이 그렇게 난감한가요?

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

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

hiseob의 이미지

자바의 string 도 C++ 의 string , MFC 의 CString , C# 의 string 들과도 그놈이 그놈으로 알고 있는데 이상하네요

오히려 C 가 더 난감하지 않은가 싶은데...

select99의 이미지

답글이 밑에 분한테 단다는게.. 좀잘못붙었네요.. 어쨋든...

--------------------------
저급언어 나쁜 뜻이 아니죠..

저급언어와 저수준제어 와 혼동하시는분들이 종종있군요.. 물론 님얘기가아니구 다른님들...

저수준에어를 한다해서 저급언어가 아닙니다.

어떤면에서.. 저수준제어가 가능한 언어는 고수준제어보다 훨씬 뛰어난 언어라할수 있습니다.

예를들면 자동차 운전대를 만들지 않았는데도 자동차를 능숙하게 몰고 가는거나 다름없습니다.
버튼만누르면 스스로 움직이는 고수준 자동차 제어는 제어적차원에서는 훨씬 쉬운일이지요.

하지만 어쨋건 둘중하나만한다면 고수준이나 저수준이나 둘다중요하겠지만요..
둘다 제어할수 있다면 금상첨화겠지요.

그러나 제어를위해 프로그래밍하는 자체를 두고 문법적측면에서 볼때 인간이 이해하기쉬운가를 두고
고급언어와 저급언어로 가릅니다.

그러나 고급언어와 저급언어의 사용상 으로써.. 고급언어는 주로하이레벨컨트롤을 많이하고...
저급언어는주로로우레벨컨트롤에 많이 이용되어 왔습니다.
하지만 그중 특이하게 C는 고급언어적 문법이면서 저급컨트롤에도 쉽게 이용할수 있다는 특징이 있지요.

즉, C는 고급언어이면서.. 저급언어들이 가진 장점까지 함께 취하고 있다는 의미입니다.
저수준제어를 한다고 저급언어라고 착각하시면 안됩니다.

(혹자중엔 저급언어를 저질언어로 치부하고 싶어하는 좀 무식한분도 있더군요)

fender의 이미지

계속 '고급/저급언어의 기준은 문법이다'라는 주장을 하시는데... 구체적으로 어떤 문법이 있으면 고급이고 어떤 문법이 없으면 저급언어라는 겁니까? 제가 열거한 OOP 키워드 같은 것들은 다 무시하시고 아무튼 포인터 빼면 똑같다고 하시는데... 그렇다면 나머지는 if, switch, for 따위인가요?

그런 기준으로 보면 어셈블리 빼면 모든 언어가 다 고급언어인지도 모르겠습니다. 그런 기준이 의미가 있는 건지는 모르겠지만 말입니다. 아무튼 그렇게까지 해서라도 C를 고급언어의 분류에 꼭 넣으셔야 겠다면 인정해 드리겠습니다.

그런데 애초에 'C도 고급언어다'라는 주장을 왜 시작하셨는지 잊어버리진 않으셨죠? 제가 고급/저급이란 언어적 특성 때문에 비즈니스 로직과 같이 고급 계층으로 갈 수록 상대적으로 고급언어가 유리하고 많이 쓴다고 했더니 '아니다, C도 자바만큼 고급언어니까 많이쓴다!'라고 반박하신 거 아니었습니까?

하이레벨의 특성은 무엇보다 추상화를 잘 다룰 수 있어야하고 이를 기반으로한 플랫폼, 라이브러리, 프레임워크 들이 모듈화 되어 잘 짜야 돌아갈 수 있는 환경이 되어야 유리합니다. 그런 이유로 OOP적인 접근이 인기가 있는 것이죠.

그런데 그 'if, switch, for'를 쓸 수 있어서 '고급언어'라는 C가 예컨대 자바나 C#보다 추상화된 설계나 OOP적 접근에 더 유리하다고 주장하실 수 있습니까? 아니면 실제로 그런 특성을 살려 비즈니스 어플 제작에 널리 쓰이는 플랫폼, 프레임워크, 라이브러리가 어떤 것들이 있습니까?

select99님의 반복된 주장에 의하면 C는 자바 만큼이나 고급언어이고 비즈니스 어플이든 서버 어플이든 자바로 만들 거면 C로 만들었을 때 훨씬 생산성, 비용, 성능 대부분 다 유리하다고 하지 않으셨습니까?

물론 gtk 처럼 C로도 OOP 흉내낼 수 있고 어쩌면 스프링 같은 고도로 추상화된 프레임워크도 만들어낼 수 있을지 모르죠... 그게 시작부터 OOP를 염두에두고 출발한 다른 언어들의 결과물보다 좋을지는 모르겠지만 말입니다.

그런데 그런 게 실제로 널리 쓰이고 있습니까? 없으면 새로 만드는데 드는 비용은 어떻게 할 건가요? 아니면 이전처럼 계속 C로 짜면 그따위 것 다 필요없다라고 우기실 겁니까? 스프링 하나만 놓고 보면 C로 똑같은 걸 짤 수있나요? 짠다면 맨먼스가 얼마나 될 것 같습니까? 아니면 이전처럼 'C로 짜면 그따위 것 다 필요없다'라고 계속 주장하실 건가요?

어플서버, DI 컨테이너, 트랜잭션 관리, ORM, 보안 프레임워크, 분산 캐쉬, 메시징, 템플릿엔진, 로깅, 테스팅, 워크플로우 엔진 등등... 'if, for, switch'만 가지고 C로 만들면 한 일 주일이면 다 뚝딱 짤 것 같나요? ㅎㅎ;

제가 만약 C언어에 대해 애착을 가지고 있다면 그런식으로 'C가 무조건 최고다!'라는 식으로 공연히 반감을 불러일으키는 무리한 주장은 안할 것 같습니다.

왜냐하면 C가 널리 쓰이고 있는 로우레벨 분야만 가지고도 C는 충분히 훌륭하고 효용성 높은 언어니까요.

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

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

select99의 이미지

무조건주장이 아니죠.. 그럼 이제무조건 자바로 써야한다~! 라는주장은 정당한가요?
자바는 이미 충분히 반감을 불러일으키고 있죠..
C가 로우레벨에 널리쓰이고 있으니 이제 하이레벨은 자바에게 양보좀해달라는건가요?
특성과 장단점따지는 자리가 무슨 협상하는자리 같군요.

님이 말씀하신 "어플서버, DI 컨테이너, 트랜잭션 관리, ORM, 보안 프레임워크, 분산 캐쉬, 메시징, 템플릿엔진, 로깅, 테스팅, 워크플로우 엔진 "
은 어디 자바프로그래머가 손수 짜나요? 손수짜보세요.. 그럼 C로 도 손수짜죠..
대체 C에 뭐가 없고.. 뭐가 안된다는겁니까?

C는 라이브러리 쓰지말구 손수짜라구요? 왜다짜죠? 있는게 좋으면 있는거 찾아 쓰면되고 불필요하면 안쓸수도 있고...
C하면서 C++은 쓰면안된데요? 왜죠?
님은 마치 C를 쓰면 큰일이나 날듯이 얘기하는군요.
C로 홈페이지 만들면 그게 그리 잘못된건가요?

fender의 이미지

자꾸 피장 파장 논리로 몰아가지 마세요...

(1) 저는 select99님이 '자바로 할 건 C로 하면 거의 대부분 더 적은 비용으로 빨리 만들 수 있고 성능도 좋다'라고 주장한 걸 적어도 5-6건 이상 인용할 자신있습니다. 자바 이야기만 나오면 모든 글타래에 비슷한 주장을 열심히 반복하셨으니까요. 그 뿐만 아니라 '자바는 돈벌려고 일부러 어렵게 만든거다' 같은 말씀도 하셨죠.

그런데 제가 '앞으로 자바만 써야 한다' 따위의 무식한 주장을 했다구요? ㅎㅎ; 제가 C에 대해 비슷한 주장을 한 걸 한 건이라도 인용하실 수 있으면 앞으로 자바 관련 덧글을 안달겠습니다. 공평하죠?

(2) '어플서버, DI 컨테이너, 트랜잭션 관리, ORM, 보안 프레임워크, 분산 캐쉬, 메시징, 템플릿엔진, 로깅, 테스팅, 워크플로우 엔진' 등등이 C에 뭐가 없고 뭐가 안되냐구요?

한번 위에 열거한 것들에 대해 C로 만든 자바나 C#에 있는 비슷한 수준 제품 하나씩만 예로 들어보세요. 자바나 C#에서는 각 분야에서도 여러 제품중에 쓸만한 걸 골라쓰는 판이지만 C로는 그런게 하나라도 있으면 인정해 드리죠. 역시 공평하죠?

(3) C로 라이브러리 쓰지 말라고 안했는데요? 있으면 찾아보시라는 거죠... 반면에 select99님은 자바에서 라이브러리 쓰지 말고 스트링 다루는게 C보다 약하다면서요? 라이브러리는 왜 안쓰는데요? ㅎㅎ; C에서 유니코드 문자열 라이브러리 안쓰고 다루는게 그렇게 쉽던가요? 또 자바 코어 API에 문자열 처리 관련해서 없는 건 또 뭡니까?

(4) 그리고 C++이요? C하고 C++이 같은 언어인가요? 아마 어떻게 보면 자바하고 C++차이보다 C++하고 C 차이가 더 클걸요? 뭐 정 C/C++ 합쳐서라도 무조건 자바보다 우월하다 주장하시는 것이 목적이라면 인정해드리겠습니다. 그러니 (2)에 대해서 C든 C++이든 아무거나 찾아보세요. 공평하죠?

(5) C로 홈페이지 만들면 잘못된게 아니죠. 누가 큰일 난댑니까? 반면에 C로 복잡한 웹사이트 만들어도 자바 보단 무조건 생산성 좋고 성능 좋다고 우겼으면 제대로된 근거는 대야하는 거죠... 근거도 없이 끝까지 지지 않으려고 토론(?)을 이어가는 건 잘못된 거 맞습니다.

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

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

feanor의 이미지

Quote:
어플서버, DI 컨테이너, 트랜잭션 관리, ORM, 보안 프레임워크, 분산 캐쉬, 메시징, 템플릿엔진, 로깅, 테스팅, 워크플로우 엔진

뭐 말씀하신 취지는 아닌 것 같지만 생산적으로 가자는 뜻에서,

보안: JBoss에서 쓰는 SAML 라이브러리가 C++과 Java로 동시 개발되고 있는 것으로 알고 있습니다.

캐시: 제가 분산 캐시에 대해서는 잘 모릅니다만 memcached는 C로 짠 프로그램이고 libmemcached(C) 같은 클라이언트도 훌륭합니다. memcached에만 한정해서 보면 자바보다 클라이언트가 나은 것 같습니다.

메시징: JMS 같은 표준 API가 있는 것은 아니지만 Qpid AMQP 클라이언트는 C++과 Java로 동시 개발되고 있습니다.

템플릿: ClearSilver(C)가 Velocity 보다 낫다고 봅니다. 다른 것들도 있지만 제가 써 본 것에 한정하겠습니다.

로깅: log4cxx(C++)는 log4j와 같은 곳에서 개발하고 있으니 아시리라 믿습니다.

테스팅: Check(C)가 xUnit 스타일로 깔끔합니다. 구글의 gtest(C++)도 쓰기에 좋습니다. dejagnu 등 입출력 테스팅을 하는 경우 언어를 타지 않습니다.

C++과 Java로 동시 개발되는 것들을 제외하더라도 libmemcached나 ClearSilver나 Check가 떨어지는 수준의 제품이라고는 생각하지 않습니다.

다만 Spring과 같은 통합된 프레임워크가 없어서 컴포넌트 통합이나 선정에 난점이 있다는 것은 옳은 지적인 것 같습니다.

fender의 이미지

사실 처음 열거할 때는 '각각'에 대해 모두 C/C++ 대안을 찾아보라는 식까지 논쟁(?)이 번질 줄 몰랐습니다 ㅎㅎ;

말씀하신 예와 같은 툴들이 존재하는 것은 알고 있었습니다. 특히 로깅, 테스팅 같은 경우는 log4*나 *unit이라는 이름만 봐도 같은 자바쪽의 전통에서 파생된 것이니까요...

feanor님께서는 이미 이해하고 계신 듯 하지만 다른 분들을 위해 취지를 좀 더 정확히 이야기 해보자면, 예를들어 열거한 보안이나 캐쉬, 등등의 개별 라이브러리들이 그런 기능을 필요로하는 프로젝트에 컴포넌트화되어 유기적으로 통합될 수 있는가 하는 문제가 중요하다는 점입니다.

예를들어 보안쪽에서 SAML을 예로 드셨는데 이는 프로젝트에서 인증 정보를 주고 받는 프로토콜로서 유용하게 사용할 수 있을 것입니다. 하지만 큰 그림을 보자면, 그 인증 정보를 비즈니스 단에 propagate하는 방법, 또 도메인 객체 수준의 보안을 적용하는 방법, 그리고 실제 다양한 백엔드 시스템과의 통합 방법 등에 대한 해법이 모두 제시되고 이들이 유기적으로 잘 동작할 때 프로젝트 전체의 보안 계층이 완료되는 것입니다.

그런 관점에서 이런 큰 그림에서의 통합을 이미 잘짜여진 시나리오에 따라 일관된 방법으로 구축하는 방법이 있느냐 없느냐는 상당히 중요합니다. 예를들어 자바 쪽이라면 spring-security 같은 프로젝트는 그런 큰 그림을 제공해주는 제품이지만 SAML 프로토콜의 C구현 모듈은 경우에 따라 그런 큰 그림에서 사용할 수 있는 한 컴포넌트의 역할로 제한됩니다.

memcached는 예컨대 ehcache나 oscache보다는 유연성이 조금 부족하다고 생각합니다. 특히 네트워크 관련한 부분이나 캐쉬를 저장, 관리하는 방식이 유연하지 못해서 아무래도 적용할 수 있는 범위가 이들 라이브러리에 비해서는 한정적일 듯합니다. 아마도 ORM 등 캐쉬가 필요한 라이브러리들과의 조합까지 따진다면 좀 더 논지를 강화하는 명확한 예가 될지 모르겠습니다.

이제까지 이야기한 모든 컴포넌트를 포괄하는 '큰 그림'의 시나리오를 하나 그려본다면 예를들어 데이터베이스에 ORM을 얹고 여기서 도메인 객체를 뽑아오는데 이 때 UI에서 인증된 사용자에 따라 권한이 없는 인스턴스를 필터링하고 성능을 위해 분산 캐쉬에 저장을 하는데 불필요한 직렬화 비용을 줄이기 위해 특정 갯수 까지는 디스크 등에 쓰지않고 메모리에서 관리를 한다 정도가 될 듯합니다. 템플릿 엔진을 끌어들이자면 UI를 흔히 쓰는 mvc로 구성하는 데 뷰를 템플릿으로 처리하고 액션 단에 앞서 말한 도메인 객체에서 뽑은 값들을 공유한다 해도 좋은 예가 되겠죠.

템플릿 엔진자체의 기능도 중요하긴 합니다만 예를들어 템플릿을 치환할 때 뒷단에서 사용하는 객체의 구조나 메소드 등을 사용할 수 있느냐 없느냐, 혹은 템플릿을 보안쪽과 통합해서 권한에 따라 서로 다른 템플릿을 적용할 수 있는냐 없느냐 하는 부분은 분명 생산성과 유지보수 측면에서 많은 차이를 보일 것입니다. 아무래도 뒷단에서 가져온 데이터가 잘 정의된 자바 객체이고 그 템플릿 엔진이 어플리케이션 서버 등의 보안쪽과 통합이 되어있어서 <tmpl isUserInRole="Admin">$project.components[0].name</tmpl>이런 식의 동작이 된다면 그렇지 못한 경우보다 편할테니까요. ClearSilver라는 제품은 처음들어봤습니다만 아마도 저런 식의 통합을 가능하기 위해서 HDF라는 객체를 일일이 만들어 준다는 건 상당히 지루한 작업이 될 것 같다는 생각은 듭니다. 물론 자바의 객체 구조를 바로 쓸 수 있는 Velocity라면 그런 문제는 없겠죠...

그런식으로 여러 라이브러리를 모아서 큰 그림을 그리는 구조를 잡는다면 앞서 언급된 개별 C/C++ 기반 단일 라이브러리들을 엮어 만들기는 훨씬 더 복잡하거나 심지어 불가능한 이야기가 될지 모릅니다. 그리고 그런 이유들이 언어 자체적으로 OOP를 염두에 두고 설계되고 전통적으로 하이레벨 개발에 널리 쓰이면서 일관성있게 통합된 스펙과 프레임워크들을 만들어온 자바가 그렇지 않은 C보다 해당 분야에서 유리할 수 있는지에 대한 설명이 될 것 같습니다.

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

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

select99의 이미지

무조건 변명하려하기보다 최소한 자신이한말은 인정하는자세를 가져보세요.
자신이 바로 직전에 한말도인정하지 않는자세로 무슨토론을 할까요.

애초 차라리 자바와 똑같은걸 만들어보라하시죠...
어이없게.. 자바이기때문에 있어야하는 패키지나 혹은 다른언어에선 그와 동일한형태가 아닌다른형태로 존재하는것을 다른언어에서 똑같은게 있냐하는자체도 웃기거니와. 그걸덩어리째 존재하냐를 따져 비교 하고 싶어하는것도 참 어이없습니다.

님은 정말 자바밖에 모르는것같군요.

fender의 이미지

무조건 C/C++에 유리하게 해석하고 싶어하는 마음은 잘 알겠는데요... 최소한 어설프게라도 알아야 우기는 것도 할 수 있는거죠...

C에 없는데 자바에만 있는 건 '자바이기 때문에 있어야 하는 거다'라구요?

feanor님이 예로 들어주신 log4cxx는 이름에서도 알 수 있듯이 자바의 log4j에서 나왔죠?
Check의 홈페이지 가보세요, 첫 화면에 Check는 자바의 JUnit에서 아이디어를 얻어 개발했다고 나옵니다.
SAML을 개발했다는 JBoss가 뭐하는 회사인지는 아시나요?

그리고 나머지 3가지도 모두 자바 API를 동시에 가지고 있는 제품이죠...

요약하면 모두 자바에서 이미 널리 알려진 제품을 C로 포팅하거나, 비슷한 개념으로 만들거나 아니면 최소한 C와 자바 API를 동시에 지원하는 제품들이라는 이야기인데요... 본인 주장대로 자바는 C보다 후져서 복잡한 라이브러리가 필요하다면 C는 왜 자바에 있는 걸 가져다 똑같이 만듭니까? ㅎㅎ;

장담하건대 아마 feanor님이 log4cxx나 Check 같은 거 소개 안하셨다면 로깅이나 단위테스트 따위도 '그 딴 거 C에서는 필요없다, 자바가 후져서 필요한거다'라고 우기셨을 겁니다. 안그런가요? ㅎㅎ;

어쨌건 자바를 포팅한거든 자바 API도 지원하는 제품이든 아무튼 있기는 있으니까 내가 이겼다!라고 의기양양하신 듯 한데... 그래서 지금 실무에서 저런 라이브러리들 조합해서 자바보다 편하게 SI도 하고 엔터프라이즈 어플도 만들고 그러고 있나요?

애초에 우기신 건 그거 잖아요. C도 자바 만큼 고급언어고 그러니 엔터프라이즈 개발에서도 많이 쓰고 있고 C에도 그런 개발에 필요한 건 다 있거나 없는 건 없어도 훨씬 쉽게 짤 수 있으니 없는거다라구요.

엔터프라이즈 개발하는데 사용하는 라이브러리의 연동과 통합성 고민하는게 '어이없다'는 발언이 어이가 없는 겁니다. 있으면 뭐합니까 아귀가 맞게 잘 돌아가고 성능뿐아니라 유지보수도 잘 되야 널리 쓰이는 거지... 한번도 안해보고 알지도 못하는 걸 끝까지 우기니까 어이가 없는 논리들이 나오는 겁니다.

그리고 전 자바밖에 모르는 건 맞습니다(사실 입문수준에서 다뤄본 언어는 꽤 많습니다만...) 그런데 저는 모르는 거 끝까지 우기지는 않아요.

아.... '본인의 말에 책임지는 자세'가 중요하다고 하셨는데 진짜 그렇게 생각하신다면 도대체 뭘 보면 자바의 문자열 처리가 C보다 불편한지나 설명해 주세요 ㅎㅎ;

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

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

select99의 이미지

배꼈다구요? 배꼈다 칩시다. 배낀들 어떤가요? (제가 필요하면 해당하는것을 만들것이라했습니다. 그게 필요한사람이 있었겠죠.)

그럼 자바는 C와 베이직 베낀건가요? 클레스도 베낀거고 if문과 for 문도 다배낀거죠?
자바 자체는 C로 만들어졌는데... 그럼 결국 C의결과물이고 C를쓰는거네요?
OS 자체는 C로 되어 있으니 C의 프로그램을 빌려쓰는거고 C 없이는 스스로 움직일수조차 없으면서 그런소리나오나요?
아니무슨 편가르기합니까?

그리고 어디 로깅라이브러리가 저거하나뿐인가요? 헤아릴수없이 흔하고 많습니다.
C 에서는 다른영역이나 역할에따른 라이브러리들의 통합이 당연히 되어야한다고 생각하기에..
그걸로 고민해본적잘없는거 같습니다.
자바는 버젼만 좀틀려도 서로 비틀어지고 안맞고 해서 맞는것끼리 자알 깔아야 재대로 돌더군요.

사실 전 위댓글에.. 그래도 인정하는글귀 하나정도는 있을줄 알았습니다.. 끝까지 인정하지않는 불굴의정신 대단하네요.
이제 인정하지 않고 다른화제로 돌려보고 싶으신거 같은데.

str = "123456789 는 그냥테스트용이다"
int i = random( );
incode( str[i], i );
if( strlen( str ) > i ) str[i] = 0;

while(*str == ' ') str++;
printf( str );

입력받은 스트링을 랜덤함수로 얻은값의 위치에 해당하는 문자를
incode 함수에 넣어 두값을 교환시키고
이후 i 가 스트링보다 작으면 문자열을 자르고
ltrim하고 str 을 다시 출력하라.

제가 위에도 언급했듯이 웬만하면 라이브러리 쓰지말고 해보시죠.
직접컴파일까지 안하더라도 대충이나적어보시죠.

myueho의 이미지

incode가 무엇을 하는 함수인지 모르겠습니다만,
그냥 딱 봐도 멀티바이트 문자 처리가 안 될 것이고, 세그먼트 오류도 보이고,
라이브러리를 쓰지 말라고 하시면서도 본인의 코드에서는 C standard library를 사용하시는군요?

select99의 이미지

네.. 당연히 그냥 무엇을 하는건지 요구사항을 알려드릴려했을뿐이지 저게 돈다고 짠게 아닙니다..
입력받고 하는거 다빠졌겠지만 그런거 보려고 짠게아니구요. 설마 main 도 없는데 돌려구요.

랜덤함수 길이초과하면 오류나겠죠.. 하지만 그런걸 보려고 말씀드린건아니고
저런식의 구현을 물은겁니다.정 못알아들으시면

strlen 함수 구현을 직접해드리지요..

int strlen( char *s )
{
int i;
for( i = 0; *(s+i); i++);
return i;
}

정도면 잘돌거라 봅니다.
자바도 위함수 직접만들수 있겠죠? 필료없으면 안써도 되구요.
또한 random 부분은 i = random() % strlen( str );
로 하고 i 선언도 윗쪽으로 올려두면 될듯하네요.

fender의 이미지

자바로 실무 프로젝트도 개발하신다면서 String.length()도 모르시나봐요? ㅎㅎ;

그런데 자바보다 훨씬 문자열 조작을 쉽고 정확하게 할 수 있다는 C에서는 저런 코드 없으면 문자열 길이도 모르나요? 또 유니코드나 멀티바이트는 어떻게 하죠?

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

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

select99의 이미지

하는방법다있으니 걱정마시고 위에꺼나 해보시죠..

말로만떼우지 마시고..

jick의 이미지

자,

이제 printf 함수도 구현해주세요.

* 그리고 printf 첫번째 인자로 그냥 임의의 str을 넣는 건 매우 위험한 코딩인 건 아시죠?
* 왠지 "우리 아빠가 힘 짱 쎄!" 수준의 토론이 되어가고 있다는 기분이...

myueho의 이미지

random 함수도요!
심지어 random()은 C 표준 라이브러리도 아니군요.

select99의 이미지

웬만하면 라이브러리 없이 작성하라 했지 아예 쓰지 않고 라고 안했습니다.
그리고 작성수준은 위와비슷한수준으로 하시면되다는의미에서 보여드린거구..
strlen 표준함수 없이도 직접만들수있다는거 보여드린거구.자바도 위구현하면서함께구현해보란거구.

말길을 못알아듣는건지.. 할줄모르니 그저 트집잡아 깽판놓자는격인지..
뭐 어쨋든알겠습니다. 첨부터 기대도 안했습니다.
뭘요구하는지 몰라서 못하는거 같지는 않고... 참유치해지는군요.
나도 안그래도 월말이라 정리할일도 많은데.
이제여기서 그만하죠. 그저말로만떼우려는데 지쳤습니다.

fender의 이미지

그러니까 제가 무슨이야기를 했고 뭘 인정안했냐구요? ㅎㅎ -ㅅ-; 비판을하건 우기건 간에 무슨 말을 하는지 주제는 놓치지 말아야죠 안그래요? 자 한번 제가 무슨 주장을 했는데 그게 어떻게 반박이 되었는데 제가 무얼 인정 안하는지 한 번 설명해 보세요.

본인의 주장은 기억 나세요? 자바가 할 수 있는 건 몽땅 C로도 더 잘할 수 있는데, 그 이유는 자바에 있는 데 C에 없는 라이브러리는 원래부터 필요없는 건데 자바가 후지니까 어쩔 수 없이 만든거고, 반대로 C에도 있는 기능은 필요하니까 만든거다. 이거 아닌가요?

논리 자체도 흥미롭습니다만, 문제는 거기에 대한 근거는 단 한 줄도 없다는 거죠... 그래서 구체적으로 예를 들어보자 해서 ORM이니 DI 컨테이너니 이야기가 나온거구요.

자, 상식적으로 따져봅시다. 님말대로 자바가 하는 걸 C로 훨씬 잘하려면 최소한 자바의 기능은 C에 다 있어야겠죠? 그래서 제가 자바에선 이런 저런 기능을 하는 라이브러리가 있다... 그랬더니 feanor님께서 그 중의 일부는 C에도 비슷한 게 있다고 하셨습니다. 사실 저도 그 중에 최소한 2개는 글쓰기 전부터 알고 있었구요.

그러니까 select99님께서 '거봐라 C에도 다 있지 않냐! 자 책임져라!'하고 득의양양해서 몰아붙이시는 거 아닙니까?

그런데 그게 말이 되려면, 그러니까 그 결과로 자바가 하는 건 C로 훨씬 쉽게 되려면,

(1) C에 있는 저 라이브러리들이 자바의 비슷한 라이브러리 보다 훨씬 뛰어나다.
(2) 언급되지 않은 ORM, DI 등의 경우 C에는 비슷한게 없지만 이는 select99님의 주장대로 애초에 쓸데없는 기능이거나 C에서는 별 어려움 없이 구현가능하다.

이래야 말이 되는 거 아닙니까?

근데 (1)부터 말이 안되는게 feanor님이 예로드신 라이브러리 중 3개는 자바의 포팅이고 나머지는 자바 API도 있다는 겁니다. 그러면 최소한 자바로나 C나 같은 걸 할 수 있다(사실 위에 적은 이유 때문에 그것도 아닙니다만...)라고 할 수 있는게 아닌가요? (2)번에 대해선 이전부터 계속 근거를 대시라고 했더니 C에 없는 것 따위 뭔지 알아볼 필요도 없다는 식으로 무시하고 계시구요. 제가 틀렸나요? ㅎ

전 select99님이 무작정 우기기를 계속하셔도 최소한 본인 발언에 대해 이 정도 기초적인 논리는 이해 하실 줄 알았습니다만 왠지 제가 과대평가를 한 것 같습니다. 대뜸 '그럼 자바는 C로 만들었으니 C가 최고겠네?'하고 대꾸하시는 걸 보니 말이죠. ㅎㅎ;

log4j 같은 로깅 라이브러리가 헤아릴 수 없이 흔하고 많으면 어디 한 번 나열해보세요. log4j 기능이나 제대로 이해하실 수 있다면 말이죠. printf 찍고 로깅이라고 우기실까봐 미리 힌트를 드리면 log4j의 핵심은 '컴파일 수정없이 원하는 로깅 정보를 원하는 방식으로 원하는 만큼 자세하게 기록한다'입니다.

아... 그리고 저 코드가 '자바의 문자열 처리는 C보다 엄청 불편하다'의 근거였습니까? -ㅅ-;;;;

근데... 죄송하지만 최소한 말은 되게 해놓고 충분히 설명 붙인 다음에 다시 도전하세요. 최소한 i가 어느 값이면 결과가 이래야한다거나... 어떻게 자신있어 하시는 C로 만든 예제가 저 같이 C언어 모르는 사람이 봐도 설명하고 코드하고 결과가 다릅니까? -ㅅ-;

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

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

select99의 이미지

개인적으로 쓰고 있는 lib 에포함된 klog 웹관련 변수들이 미연 변수명과 변수포인터가
(실제로는 함수포인터도 등록되기때문에 일종의 OOP구현방법과 유사한..)등록 관리되어 있고

로깅자체도 스크립트에서 제어가 가능하며
컴파일수정없이 데몬재시작조차 안해도 원하는만큼 원하는데로 찍는게 가능합니다.

님이먼저 화제전환했고.
설명도 충분히 드렸다 생각하고.
혹시나 모를까봐 C의 주요부분들 예시까지 드렸습니다.

그래도 모르면 뭘바라겠습니까..됬습니다.

fender의 이미지

노파심이 맞았군요. log4j의 개념에 대한 힌트까지 드렸는데 찾아보지도 않으신건지 아님 그냥 무시하시는 건지 엉뚱한 거 가지고 다된다 우기시는게요...

무조건 다된다고 우기는 쪽에 근거를 대라는 쪽이 역으로 '무엇이 되어야 하는가'에 대해 강의(?)를 하는 꼴이 안습입니다만 그래도 더이상 이야기가 '마징가 v 태권브이' 꼴로 안가게 하기 위해서 최소한의 개념 설명만 드리겠습니다.

log4j로는 예를들어 이런 걸 할 수 있습니다. 정해진 방법대로 우선 중요한 부분마다 로깅 코드를 써넣습니다.

그리고 프로덕션 환경에서는 과도한 로그로 인한 성능저하를 막기 위해 디버그 메시지는 무시하고 경고 수준 이상의 중요한 메시지만 파일로 써넣게 했습니다.

그런데 어느날 갑자기 알 수 없는 이유로 서버가 죽기 시작합니다. 그래서 치명적인 문제가 생기면 파일 뿐 아니라 이메일로 관리자에게 상황을 보고하고 싶습니다. 그냥 설정 파일에 치명적 수준의 오류에 대해 이메일을 보내는 어펜더만 추가하면 됩니다.

서버를 죽이는 의심이 가는 부분이 생겼습니다. 특정 부분의 코드에 국한된 문제인데 그렇다고 전체 디버그 메시지를 다 보고 싶지 않습니다. 설정 파일에서 해당 카테고리만 디버그 레벨의 로깅을 허용하게 바꿔줍니다.

운영을 하다보니 파일이 너무 많이 쌓여 관리가 힘듭니다. 설정 파일에서 파일 어펜더를 롤링 파일 어펜더로 바꿔주면 일단위 관리가 됩니다.

서버를 윈도우즈 머신으로 포팅하고 보니 왠지 이벤트로그에 메시지를 뿌리면 더 쉽게 관리가 될 듯 합니다. 역시 어펜더만 추가해 줍니다.

사용자가 몰리는 시간에 원격지에서 전용 GUI로 일목요연하게 카테고리별로 로그 메시지를 실시간 브라우징 하고 싶어졌습니다. 어펜더에 RMI 어펜더 추가하고 Chainsaw로 모니터하면 됩니다.

나중에 사용자들이 웹의 관리자 화면에서 특정 포맷에 맞게 HTML로 로그를 보고 싶다고 합니다. 어펜더에 레이아웃 패턴을 이용해 원하는 html로 만들어 주면 됩니다.

그러다가 이제는 날짜별, 중요도 별로 검색 까지 하고 싶다고 합니다. 문제 없습니다 그냥 JDBC 어펜더로 디비에 때려 넣으면 되니까요.

이제까지 이야기한 건 모두 log4j의 설정만으로 코딩한 줄 안하고 처리할 수 있는 일들입니다.

...

자 이제는 그 log4j에 필적한다는 'klog'로 어떻게 이런 일들을 더 쉽고 빠르게 할 수 있는지 보여주세요. log4j의 로깅 기능 정도 하는 라이브러리는 C에 흔하고 널려있다고 하셨는데 그 중에 고른 거니 아마 엄청 쉬울 거 같습니다. 더구나 자바에는 없는 함수 포인터라는 강력한 기능을 활용한다니 당연히 더 기능도 많겠죠?

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

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

select99의 이미지

역시나 별기능도 아닌걸 대단한것처럼 떠벌려두셨군요..

그건더간단히 해결되는거죠.그것도 기능이라고 뭐따로 되어 있어야 할수 있나요? 보통 로깅라이브러리중에.
로그레벨이라는게 있는것들도 있고 그로그레벨에따라(로그레벨설정) 로그들이 출력됩니다.

제가 일하는곳의 로깅기능도 그러하구요.
궂이 대단한 로깅라이브러리가 아니더라도 DEBUG 함수자체가 기본적으로 그런기능을가지고 있군요..

뭐똑같지는 않겠지만.
그런 비슷한기능은 아주흔한기능으로. 뭐별달리 특별한기능이라할수도 없습니다.
주변에 C좀 하시는분들한테 물어보세요 그런기능이 있나없나.
그리고 제가 누누히 말했듯이.. 그런기능이 필요할때 그때그때 만들어쓰는데 별로 어려움이 없기때문에.
그다지 그런라이브러리를 대단한양 그게없으면 안되는양하지도 않는다는것입니다.
해당하는필요한기능만 추가해넣어도 간단히된다는거죠.

또한 벌써몇번을 말씀드렸듯이.. 뭐뭐뭐 뭉쳐서 이건게 한꺼번에 뭉쳐진뭐가 있냐 라는질문이 참웃깁니다.
그게 머하러 뭉쳐져있나요.. 그러니가 자바가 무겁죠.뭐든지 뭉쳐서 덩어리로 굴러다니는게 그리좋은가요?
C 에서 안되는기능 구체적으로 말하라하였습니다. 기능요.. 님은 기능과 패키지를 구분도못하나보죠?

페이지