자바가 정말 쉬운 언어인가요?
문득 자유게시판에 올라온 글중에 "자바책" 관련 내용을 보고 평소 궁금했던게 떠올랐습니다.
자바가 대부분 쉽다라고 이야기들 하시는데 자바가 정말 쉬운가요?
이렇게 물어보는 이유는 제가 경험해본 자바는 모호해서 쉽지 않았기 때문입니다.
제가 모호하다는 표현을 쓰는것은 자바가 감추는게 너무 많아(주로 JVM 쪽에서) 명확하지 않은 언어란 느낌을 받았습니다.
또한 이런 느낌을 받은 배경에는 제가 apple BASIC부터 시작해서 MSX BASIC,
pascal, C, assembly, C++을 거치면서 주로 system쪽을 해왔기 때문입니다.
C++ 배울때 가장 넘어가기 힘들었었는데 이유는 그냥 논리적으로 받아들여야 될부분을
자연스럽게 물리적으로 해석하려 했기 때문입니다.
예를들면 class의 memory map은 어찌 될것인가? 함수 오버로딩은 어떻게 구현될것인가?
등등 이런식으로 생각을하니 C++을 처음 배울때 항상 의문 투성이였고 그래서 모호했었습니다.
결국 class의 memory map과 함수 오버로딩의 원리를 모두 파악하고 나서야 C++이 이해가 되더군요.
그러다가 2000년도에 처음으로 JAVA를 접했습니다.
저에게는 안좋은 기억밖에 없는데 첫번째로 최종 결과물이 너무 느렸다는것(당시의 PC 사정과 JVM 성능 때문이라 생각합니다.) 그리고 너무도 모호했다는 것입니다.
JVM을 믿어봐라고 이야기하는데 JVM을 어떻게 믿어라는 말인지.
지금 사용하는 processor도 못 믿을 판국에...
이게 JAVA를 처음 접하면서 부정적인 시각을 가지게된 원인이고 그로인해 JAVA가 쉬운 언어로 느껴지지는 않았습니다.
그리고 프로그래밍은 기본적으로 if, for, function call로만 조합하면 어떠한 프로그래밍도 가능하다라고 생각했는데 JAVA는 아닌것 같더군요. 이러한 control-flow보다는 오히려 API를 누가 더 많이 아느냐가 중요한것 같았습니다. 결국 JAVA의 플렛폼에 완전히 적응을 해야하는 것이죠.
JAVA를 디자인한 사람이 제임스 고슬링인가요?
프로그래밍 하는데 고슬링의 생각을 계속 따라야 하다는게 너무 거슬리더군요. 결국 느린 JVM에(2000년도 당시에), 대책없는 믿음에(JVM에 대한 신뢰), 이해가 안가는 구조(memory map, 동작 방식, 지금은 이해가 가지만...), API의 강요에 대한 거부감으로 인해 저에게 JAVA는 무척 싫고도 어려운 언어였었습니다.
그런데 사람들은 한결같이 JAVA가 쉽다고 말을 합니다.
저는 이 부분이 정말 이해가 안가서 이 글을 씁니다.
저는 JAVA가 어렵고 API 찾기 귀찮은 언어인데 왜 대부분의 사람들은 JAVA가 쉽고 편하다 느끼는걸까요?
소실이
소실이 아닙니다.
누군가 실수 할수 있다는 것이지요.
그 누군가의 실수를
그 누군가의 실수를 생각해 볼 때,
VM은 전 세계 개발자들이 공통적으로 사용하고 있는 일종의 프로그램입니다.
VM에서 일어나는 실수는 수 많은 사람들에 의해서 일단, 인식될 확률이 사용자가 적은 API나 프로그램보다 상당히 높습니다.
누군가가 하는 행동을 지켜보는 사람이 엄청 많다면, 그 사람의 실수를 누군가가 발견하고 잡아낼 확률이 지켜보는 사람이 없는 곳에서 누군가 하는 실수에 비해 확률이 낮겠습니다.
그런 의미에서
그런 의미에서 확률은 매우 낮을수 있을것 같습니다.
하지만 JVM에서 문제가 발생했다면 그 문제를 파악하는 것이 상당히 난해할거라 봅니다.
이런 문제는 상당히
이런 문제는 상당히 일반화 할 수 있습니다...
어떤 일을 함에 있어서 어디까지 알아야 하며 어디부터는 기존의 것을 신뢰해야 하는가...
일의 복잡도가 인간의 한계를 넘어가면서부터 그 이후는 선택과 집중의 영역으로 넘어갑니다.
알 수 있는 모든 일을 알아야 하겠다고 한다면, 물리학자가 되어야죠...
컴퓨터를 봤으면 전자공학을 알아야 하겠고 전자 공학을 이해하려면, 양자 역학과 수학, 재료공학고 알아야 하죠...
결국 물리로 귀결이 됩니다.
농사를 지을 때도 물리 공부하고 연애를 하면서도 물리 공부할 수는 없는 거 아닙니까...
무엇을 선택하고 무엇을 집중해야 하는가는 개개인의 선택이며 이 선택과 집중에 따라 쉽다 쉽지 않다가 나누어 질 수 있겠습니다.
나의 기준이 모든 다른 사람의 기준이 될 수는 없는 일 아닙니까...
인정합니다.
인정합니다.
덧붙이면 일의 효율 측면에서는 굳이 JVM이 들어가지 않아도 될것 같습니다.
API와 라이브러리 관점인것 같습니다.
그것도 일방적인
그것도 일방적인 기준이 될 수 없습니다.
효율이라는 것의 정의는 무엇입니까...
1) 사용자 입장에서의 일의 처리에 걸리는 시간
2) 시스템의 개발을 포함한 시간
어떤 것이겠습니까.
회사의 입장에서 무엇이 중요하며 시장 상황에서 무엇에 더 비중을 두어야 하는 지에 따라 C/C++로 할 수도 있고 VM이 들어가는 Java/C#을 쓸 수도 있습니다...
Java나 C# 등등에서 항상 강조하는 생산성... 유연성... 이런 것도 효율의 정의에 들어갈 수 있습니다.
인정합니다. 위에
인정합니다.
위에 말한 효율이란 2번을 이야기 한것입니다.
하지만 2번의 효율을 향상시키는데는 JVM이 큰 역활을 하지 않을수도 있다는 말입니다.
API와 라이브러리가 얼마나 파워풀하냐가 더 중요한 문제인것 같습니다.
그런면에서 JAVA나 C#은 파워풀하고요.
그리고 JAVA의 경우 메모리를 직접 건드리는 구조가 대부분 아니기 때문에
API 측면에서 개발하면서 버그가 생겨 디버깅하는데 지체하는 시간이 훨씬 줄어들겠죠.
어디까지나 이건 API나 라이브러리 관점에서 2번 효율의 문제이고
JVM이 해당 API 구성을 위해 무척 중요하긴 하나 직접적인 관련이 있다고 보기는 힘들다는 것이지요.
JVM이 직접 관련이
JVM이 직접 관련이 없다는 것은 수긍하기 어렵습니다...
VM에서 제공하는 API와 라이프러리가 그만한 성능과 인터페이스를 만들어 낼 수 있는 것은 그 밑 단을 이루고 있는 VM이 있기 때문입니다.
API와 라이브러리의 존재 자체를 가능하게 하는 VM이 직접적인 관련이 없다고 할 수 있겠습니까...
그래서 무척
그래서 무척 중요하긴 하다는 표현을 위에서 썼습니다.
API의 interface가 아닌 어떠한 일을 수행하는데 파워풀한 API측면에서
직접적인 관련이 없다는 것입니다.
참고 , 역사적 고찰: Sojourner Rover
1996년에 미항공우주국 nasa는 화성 탐사선 패스파인더 를 발사시켰다. 이 우주선이 우주 여행을 하여 화성 표면에 착륙하는 데
7개월이 걸렸다. 탐사선은 소저너란 이름의 로봇을 내보내 근처 지면을 탐사하고 읽어들인 정보를 우주선으로 전송하도록 하엿따.
그리고 탐사선은 이 정보를 다시 지구로 전송하였다. 1997년 7월 4일 탐사선은 화성의 표면에서 성공적으로 착륙하였다.
소저너는 그 동작을 제어하기 위해 하나의 80C85 마이크로프로세서를 사용한다. 2MHz의 클럭 속도로 동작하는 이 프로세서가
선택될 수 있었던 까닭은 이 8085 마이크로프로세서의 버전이 기능 수행면에서 우수하고, 지구의 대기 보호권에서 벗어난 자외선이
많은 우주 공간에서도 잘 작동하기 때문이다.
소저너의 컴퓨터는 8085 마이크로프로세서가 주소를 지정할 수 있는 64K이상의 메모리를 사용하며, 컴퓨터 기동시에 접근되는
16K ROM 을 가지고 있다. 이 ROM(실제로는 PROM)내의 프로그램은 탐사선을 기동시키고 메모리 관리를 초기화한다.
기동 후 이코드는 PROM을 사용할 수 없게 하고 64K RAM이 시스템의 주메모리로서 동작하도록 한다.
또한 소저너의 컴퓨터는 저장을 위해 176k ROM 과 512K RAM을 가지고 있다. ROM에는 컴퓨터가 주메모리에 적재하여
필요에 따라 실행되는 프로그램이 저장되어 있고, 프로그램에 의해 사용되는 데이터 테이블도 저장되어 있다.
RAM은 임시 데이터 저장소로서 사용된다. 비록 RAM이 메모리 칩으로 구성되었더라도 저장만을 위해 사용된다는 점에서
PC의 하드디스크와 매우 유사하다. 그러나 하드디스크는 우주 공간의 방사선과 힘든 행성간 여행을 견디지 못한다.
출처:
컴퓨터 시스템 구조(COMPUTER SYSTEM Organization & Architecture 165페이지,John D. Carpinelli)
즐거운 세상....
즐거운 세상....
개인적으로 궁금해서
개인적으로 궁금해서 연 쓰레드인데 JAVA 프로그래머와 C, C++ 프로그래머의 감정이 쌓이면서
점점 전쟁터가 되어 가는것 같습니다.
제가 먼저 JAVA에 대한 부정적인 시각을 내비춰서 그럴수 있을거라 봅니다.
하지만 보다 정확하게 제 입장을 말씀드리면
개인적인 취향에 의해 JAVA는 싫어하는 언어가 분명합니다.
그렇다고 해서 JAVA를 무시하거나 부정하진 않습니다.
위에 어떤분이 말씀하신것 처럼, 비행기 만들때 일일이 부품까지 신경쓸수도 있지만
오직 비행기가 목적이라면 표준 부품에 비행기를 빨리 잘 만드는것도 중요할테니깐요.
그리고 개인적인 취향으로 compiler와 processor 사이에 무언가가 끼이는 것을
싫어하긴 하는데 JVM의 유용성과 장점에 대해서 부정하는 것은 아닙니다.
만약 code에 문제가 있다면 JVM이 그 문제를 잡아줄수 있을테니깐요.
JAVA를 싫어하긴 하지만은 "JAVA 따윈 세상에서 사라져야해"라는 입장은 아닙니다.
"JAVA가 필요할것 같고, 장점도 있는것 같애. 하지만 난 싫어" 이런 입장이랄까요.
원래 이 스레드를 연 목적은 JAVA를 사람들이 쉽다라고 이야기하는데
정말 쉬운가가 이 스레드를 연 목적입니다.
그러면 쉽다면 정말 쉬워서 쉬운건지 아니면 잘 몰라서 쉽다고 느끼는건지 그것을 알아보고 싶었을 뿐입니다.
전쟁을 바란건 아니고요. 하지만 토론하다보니 저도 점점 전쟁에 참여하게 되네요.
싸우지 맙시다. 저도 그러지 않겠습니다.
안그래도 괴로운 세상에 서로 사랑하고 인정하며 좋게 좋게 토론했으면 합니다.
아무래도 많은
아무래도 많은 사람들이 쉽다고 이야기하게된 이유는
프로그래머가 처리해야할 일을 JVM 에서 처리하는게 몇가지 있기때문이 아닐까 생각합니다.
위에서 설명한 array 관련 예제나 memory leak에 대해서 고려하지 않아도 되는것처럼
좋은 프로그램을 작성하기 위해 C/C++ 에서는 고려해야하는게 100 가지라면 Java 에서는 고려해야하는 대상이 100 보다는 적습니다.
그래서 많은 사람들이 쉽다고 생각하는게 아닐까 생각합니다.
네.
네. 잘알겠습니다.
그런 이유라면 충분히 쉽다라고 이야기 할 수 있을것 같습니다.
JVM이 알아서 잘 처리해주니 개발자 입장에서는 든든한 조력자와 함께 한다는 느낌이 들겠네요.
귀찮은 언어와
귀찮은 언어와 어려운 언어는 다르다고 생각합니다.
자바가 어려운 언어인가 하는 비교는 어떤 언어와 비교하느냐에 따라 많이 달라지겠지만,
언어자체만 비교해 본다면 C#또는 C++과 같은 강한 형타입을 가지는 객체지향언어와의 비교에서 자바가 러닝 커브가 더 낮은것 같습니다.
예를들어 자바에는 물론 포인터도 없지만, 구조체나 전처리기, GOTO문법, 클래스 다중상속, 연산자 오버로딩이 제공되지 않기때문에
다른 언어와 비교하여 더 빠르게 배우게 배우게 되는것 같습니다.
물론 회사에서 CPU의 스택과 운영체제와 메모리 덤프를 꿰뚫고 있는 C++개발자들을 고용한다면 훨씬 더 좋은 품질의 소프트웨어를 개발할 수 있겠지만,
거의 대부분의 회사는 그러한 유능한 개발자를 고용하고 있지 못하는것이 현실입니다.
자바가 쉽다는 것은
자바가 쉽다는 것은 씨, 어셈블리, 씨뿔뿔에 비해서 "사용"하기 쉽다는 뜻입니다. 그런데 "쉽다"는 표현을 작동하는 방식을 파악하기 쉽다는 뜻으로 받아들이고 쉽지 않다고 주장하고 계신 것 같습니다. anfl님의 관점에서는 어셈블러가 씨보다 쉬울 것 같습니다만. 씨에 비해서 너무나도 "명확하"니까요. 뿐만 아니라 anfl 님의 관점에서는 python, ruby, ocaml, lisp 등등은 엄청나게 어려운 언어일 것도 같습니다.
제 생각엔 java가 어렵다는 이야기를 하면서 jvm을 언급하시는 것부터가 사람들이 생각하는 일반적인 "사용의 편이성"과는 완전히 다른 관점임을 드러내고 있습니다. 자바는 C나 C++보다 추상화 단계가 높기 때문에 그 하부단을 뼈속까지 다 파악하기는 당연히 어렵습니다. 그러나 그냥 하부단을 생각하지 않고 쓰면 당연히 쓰기 편합니다. 그 하부단을 "몰라도" 프로그래밍을 하는데 지장없기 때문입니다. 물론 자바도 최적화등을 고려하기 시작하면 시스템과 맞닿아 있는 수준까지 이해하는 것이 좋겠지만, 이는 자바가 쉽다 어렵다와는 다른 이야기입니다. 씨나 씨++은 아예 낮은 수준의 시스템을 모르고는 프로그래밍을 할 수 없는 언어이기 때문입니다.
그리고 API 이야기는 정말로 억지 같습니다.
"기본적으로 if, for, function call로만 조합하면 어떠한 프로그래밍도 가능하다라고 생각했는데 JAVA는 아닌것 같더군요"
이건 자바도 마찬가지입니다. 도대체 왜 자바가 아니라고 생각하시는 지 전 이해가 안갑니다.
"오히려 API를 누가 더 많이 아느냐가 중요한것 같았습니다. 결국 JAVA의 플렛폼에 완전히 적응을 해야하는 것이죠."
이건 C도 마찬가지 아닌가요? C도 C의 플랫폼에 적응을 한 사람과 못한사람 간에는 엄청난 차이가 납니다. 학부 1,2년생들을 보면 malloc이 어려워서 array를 크게 잡아서 때워버리는 학생이 꽤 많습니다. qsort 쓰는 법을 몰라서 sort를 구현해서 쓰는 사람도 많죠. 결국 씨도 API 많이 아는 사람이 더 많은 일을 할 수 있습니다. 물론 표준 API의 부피가 자바가 더 큰 것은 사실입니다만, 이는 씨의 표준 라이브러리가 제공하지 않는 많은 것들을 집어 넣었기 때문입니다. 그렇게 표준 API가 맘에 안 들면 만들어서 쓰면 되죠.
"프로그래밍 하는데 고슬링의 생각을 계속 따라야 하다는게 너무 거슬리더군요. 결국 느린 JVM에(2000년도 당시에), 대책없는 믿음에(JVM에 대한 신뢰), 이해가 안가는 구조(memory map, 동작 방식, 지금은 이해가 가지만...), API의 강요에 대한 거부감으로 인해 저에게 JAVA는 무척 싫고도 어려운 언어였었습니다."
씨에서 리치의 생각을 계속 따라야 한다는 건 너무 거슬리지 않으시던가요? 어셈블러 하면서 인스트럭션 셋을 디자인 한 사람의 생각을 계속 따르는 건요? 언어라는 것은 기본적으로 인간이 인공적으로 만들어내는 시스템이기 때문에 만드는 사람의 의도가 들어갈 수 밖에 없습니다. 호불호가 갈리는 것은 당연한 이야기이고, 씨의 디자인을 혐오하는 사람 또한 너무나도 많구요.
간단하게, 같은 기능을 하는 프로그램을 만들 때 고려할 사항이 더 적다는 측면에서 사람들은 자바가 쉽다고 하는데, anfl 님께서는 그 동작방식을 잘 알려면 이해해야할 것들이 더 많다는 의미에서 어렵다고 생각하시는 것 같습니다. 문제는 일반적으로 "언어가 쉽다"는 표현의 의미는 전자에 가깝다는 거겠죠.
우선 짚고 넘어가야
우선 짚고 넘어가야 될부분이 있는것 같습니다.
저는 이러저러한 점에서 제 관점에서 JAVA가 싫어 어려웠다는 것을 분명히 밝혔습니다.
제 관점을 몰랐던 것이 아니란 말이고, 또한 타인의 관점에 대해서도 어느정도 알았습니다.
정말 몰랐던것은 어떠한 언어에 대해서 대부분 쉽다라고 표현하는 것이 정말 쉬워서 쉽다라고 하는것인지?
아니면 잘 몰라서 쉽다라고 말하는 것인지 궁금했던 겁니다.
저는 이 문제에 대해 어느정도 결론을 내리고 있는데 그 결론이 사람들의 생각과 일치하는지 알아보기 위해 본 쓰레드를 열었습니다. 어느 정도는 답을 얻었고, 아직도 원하는 답을 얻지는 못했지만 굳이 얻지 못한다해서 문제될것은 없다고 봅니다.
한마디로 님께서 말씀하신 것들에 대해 제가 이해를 못해 본 쓰레드를 연것이 아님을 분명히 밝힙니다.
"그리고 API 이야기는 정말로 억지 같습니다."
라고 말씀하셨는데 이는 저뿐만의 생각이 아니라 JAVA를 싫어하는 많은 사람들이 공감하는 내용입니다.
때문에 억지라고 보기가 힘들다는 것이지요.
이는 님과 저의 취향, 혹은 그동안의 개발 성격이 달라 생기는 문제이지 억지라고 볼수 있는 사항은 아니라고 봅니다.
앞선 포스팅에서 저는 제 개인적인 관점임을 표현 하였거나 혹은 그렇다는 것을 내포하였기 때문에 특별히 님께 충고를 들을만한 소지는 아닌 상황인것 같네요.
어쨌던 님의 이야기는 잘 들었습니다.
덧붙여 말씀드리면
덧붙여 말씀드리면 python과 perl은 님 생각과는 다르게 쉽게 생각하고 잘쓰고 있습니다.
그리고
"씨에서 리치의 생각을 계속 따라야 한다는 건 너무 거슬리지 않으시던가요?"
==> 네. 거슬리지 않더군요.
"어셈블러 하면서 인스트럭션 셋을 디자인 한 사람의 생각을 계속 따르는 건요?"
==> PPC는 싫어하고, ARM, x86은 그저 그렇습니다. VLIW 계열은 나름 재미있어 합니다. 하지만 예전에 회사에서 만든 SRP란건 정말 싫어했었네요.
이상 답변이 되었는지 모르겠네요.
"python과 perl은 님
"python과 perl은 님 생각과는 다르게 쉽게 생각하고 잘쓰고 있습니다."
이 부분을 보니 저는 anfl님 관점의 "쉽다"라는 표현의 의미가 무엇인지 모르겠네요 ;; 제가 본 쓰레드에서 anfl님의 "쉽다"는 표현을 작동방식 혹은 구현방식이 쉽다는 의미로 사용하고 계셨다고 생각했는데, 그것도 아니었던 것 같습니다. 더 쉽게 전 anfl님 관점의 "쉽다"라는 표현이 무엇을 의미하는지 모르겠네요 ;;;
"저는 이러저러한
"저는 이러저러한 점에서 제 관점에서 JAVA가 싫어 어려웠다는 것을 분명히 밝혔습니다.
제 관점을 몰랐던 것이 아니란 말이고, 또한 타인의 관점에 대해서도 어느정도 알았습니다."
제가 마지막 두 줄에서 밝혔듯이 보편적으로 "쉽다"라는 표현이 의미하는 바가 anfl님의 관점에서 믿고 계시는 의미와는 다르다는 점을 밝히고 싶었을 뿐입니다. "어떤 프로그래밍 언어가 쉽다"는 표현의 의미를 관점에 따라 다르게 생각해야 한다면 서로 의사소통하기 쉽지 않을 겁니다. "어떤 의미로는 자바가 더 어렵다" 정도였다면 누구나 anfl님의 의도를 쉽게 받아들였을 것이라고 생각합니다. 이하는 사족입니다.
----
"충고를 들을만한 소지는 아닌 상황인것 같네요."
전 충고를 할 의도도 없었고, 제 글이 충고를 하고 있다고 생각하지 않습니다. 만약 제가 그런 의도를 가진 것처럼 글을 썼다면 그건 제가 글을 잘못 쓴 것이고, 사과드리겠습니다.
흥미로운 내용이라
흥미로운 내용이라 재미있게 잘 봤습니다.
제 생각에는 일반적으로 자바는 쉬운 언어라는게 맞다고 봅니다.
anfl님께서 본문에 언급하신대로, 대부분의 개발자들이 자바가 (상대적으로) 쉽다고들 하지요.
즉 이 질문에 대한 답은, 감히 제가 모든 자바 개발자들을 대표해서 말씀드릴 순 없지만;
정말 쉬워서 쉽다라고 하는게 맞습니다.
그 이유는 실제로 쉽기 때문이며 좀 더 정확하게는
위에 말한 대부분의 개발자들이 쉽다고 느끼기 때문이지요.
왠지 말장난 같지만, 쉽고 어렵다는건 상대적이기도 하지만
결국 어떤 언어나 그 외 대부분의 활동에 있어서 난이도를 말할 때에는
사람들이 평균적으로 느끼는 난이도를 말하게 되지요.
대부분의 사람이 자전거보다 스키나 보드를 어렵다고 생각하고, 실제로 더 어렵다고 말하지만
극지방에 사는 사람이나; 몇몇 특수한 케이스는 보드나 스키가 더 쉬울 수도 있지요.
예가 이상하다면 말씀해 주세요. :)
anfl님께서 느끼시는 어려움은 바로 극지방에 사시는 분이라 그런게 아닐까 합니다.
비꼬려는 뜻이 있는건 아니니 혹시 불쾌하시다면 미리 양해 부탁드립니다.
단지 말씀하신 것 처럼 주로 system 쪽의 프로그래밍을 해오셨기 때문에
많은 부분은 JVM에 의지해야 한다는 점에서 불편함을 느끼시는게 아닌가 합니다.
즉 태생적으로 시스템을 잘 이해하고 계시기 때문이 아닐까 합니다.
앞에서 두분이 아주 약간;; 억지스러운 논쟁을 하시던데,
일반적으로 우리가 사용하는 app 중에 자바로 만들어진 app 는 많이 없지만
실제 많이 사용되는 언어인 것은 사실입니다.
굳이 나누자면 자바는 비주얼 베이직 처럼 rapid 한 언어에 속하는데,
API를 잘 활용하면 확실히 C나 C++보다 빠른 개발이 가능하지요.
(물론 용도가 다르기 때문에 C를 사용해야 하는 부분은 분명 따로 있습니다.)
고슬링의 철학이 저와 잘 맞기 때문에 자바가 편한지는 잘 모르겠습니다만,
네이밍 룰과 API에 익숙해 지면 확실히 편한건 사실인 것 같습니다. :)
중요한 것은 말씀하신 control-flow는 자바에서도 중요하다는 것입니다.
말씀하신 그런 제어문은 당연히 자바에서도 똑같이 사용되며 API는
우리가 보통 추가적으로 해야하는 작업을 줄여줄 뿐이지요.
예를 들어 자바에서 제공하는 API 중에 문자열 파싱을 위한 StringTokenizer가 있는데
C에서는 이걸 따로 개발자가 구현해야 하지요. (물론 ATL은 예외로 해서요;)
위의 예를 제외하고도 많은 API가 개발자의 추가적인 작업을 줄여주지요.
그리고 API는 위에 언급한 네이밍 룰과, sun에서 제공하는 API 페이지를 이용하면
그리고 익숙해 지면 굉장히 편리하게 이용할 수 있습니다.
API를 많이 알면 좋은것은 사실이나 누가 더 많이 아느냐가 아주 중요한 내용은 아니며,
API를 몰라도 대부분의 프로그래밍이 가능합니다.
결국 JAVA API도 JAVA로 구현되어 있는 것이 대부분이지요.
글이 길어져서 저도 제가 뭘 이야기 하고 있는건지 잘 모르겠습니다만;;
자주 나오는 퍼포먼스 논쟁을 떠나서
확실히 쉬운 언어는 맞는거 같습니다. 대부분의 사람에게는요.
보통 글을 잘 남기는 편이 아닌데,
흥미로운 토론에 참여하고 싶어서 저도 글 남겨 봅니다.
Be the Miracle!!
Be the Miracle!!
이 글을 읽기 전까지
이 글을 읽기 전까지 사실 저는 사람들이 잘 몰라서 쉽다라고 이야기 하는게 아닐까라고 생각을 했었습니다.
여기서 또 쉽다 쉽지않다라는 모호한 주관적인 개념이 들어가는데,
제 관점에서 쉽다 어렵다는 첫째, 처음 배울때 쉬운가와 둘째, 잘 사용하기 위해 쉬운가입니다.
적절하진 않지만 예를들면 검도와 마라톤중에 초보자에게 물어보면 검도가 마라톤보다 많이 움직이지 않아 쉽다라고 이야기 할수가 있습니다. 하지만 검도 고수에게 물어보면 검도는 칼을 휘두른다고 되는것이 아니기 때문에 절대 쉽지 않다라고 이야기할 수 있습니다.
그래서 저는 사람들이 JAVA가 쉽다라고 이야기하는데 그 이유가 혹시 첫째 이유만으로 쉽다라고 이야기 하는 것은 아닐까라고 생각했었습니다.
어떤 언어든 제대로 잘 사용하기 위해서는 해당 언어의 구조와 원리에 대해 잘 알아야 한다고 생각합니다. JAVA를 예로 들면 JAVA의 class 계층구조, JAVA object등과 같은 추상적인 개념과, JVM과 같은 실질적인 개념등 JAVA의 깊은 부분에 대해 잘 알아야한다고 생각합니다.
자동차의 오토와 스틱이 있을때 오토가 처음 접근하긴 편하겠지만, 오토가 되었건 스틱이 되었건 자동차 경주를 잘하기 위해서는 자동차에 대해 잘 알아야 하는 이치와 같다고 봅니다.
하지만 이건 어디까지나 제 생각이였고 제가 JAVA를 사용하는 사람도 아니고 JAVA의 깊은 부분에 대해서 잘 아는편도 아니기에 그냥 그렇지 않을까라고 막연히 생각했었습니다. 하지만 이 생각의 또 다른 의문점은 JAVA는 원래 디자인 자체가 그러한 깊은 부분을 잘 몰라도 얼마든지 잘 사용할수도 있지 않을까?라는 생각도 있었고요.
하지만 덕분에 어느정도 의문점은 해소가 된것 같습니다. 제가 원래 특별히 관심 있는 주제가 아니면 이렇게 무리를 해서 파고드는 성격은 아닌데 이번에 전쟁에 휘말리면서 여기까지 온것 같습니다.
재미가 있네요. 직접적인 엔지니어링에서 손땐지 2년째 접어드는데 오랜만에 강호에서 칼싸움한 기분이 듭니다.
C/C++ 언어를
C/C++ 언어를 논리적으로 이해해서 정확하게 작성한 프로그램이 문제가 발생한다면 구현이 어떻게 작성된 것인지와 무관하게 구현이 잘못된 것입니다. 굳이 구현에 대해서 깊이 이해할 필요가 없습니다.
자바 언어는 지속적으로 유지보수되고 있는 신뢰할만한 명세서가 있으며 그 명세서에 따른 프로그램이 JVM에서 제대로 동작되지 않으면 "JVM이 잘못 실행하고 있구나 버그구나"라고 생각하는게 실용적입니다. 코어 2 듀오가 특정 코드를 제대로 실행못한다면 그 이유를 찾으러 실험실에 들어가겠습니까? JVM이 왜 제대로 실행하지 못하냐를 이해하는 것은 try-hard입니다.
지나치게 구현을 파고 드는 것은 특수화된 상황에 맞추어서 개념을 편협하게 해석하는 이유가 되기도 합니다. 포인터는 다 4바이트이지 않느냐 같은 불필요한 논쟁으로 갈 수도 있습니다.
- 죠커's blog / HanIRC:#CN
- 죠커's blog / HanIRC:#CN
이슈는 자바가 쉽다
이슈는 자바가 쉽다 아니다가 아니고 그냥 로레벨 강박증인 듯.
무슨 피해의식
인용 : "이슈는 자바가 쉽다 아니다가 아니고 그냥 로레벨 강박증인 듯."
무슨 피해의식 있으신가요? :)
흠... Creativeidler님이
흠...
Creativeidler님이 그냥 그렇게 남 씹자고 한 말이 아닌 거 같습니다...
솔직이 저도 이 글타래를 읽으면서 약간 그런 것을 느꼈구요...
저도 그렇습니다...
저도 지금 프로젝트를 진행하면서 같은 팀원들한테 종종 그런 말을 듣기도 합니다...
그런 자세한 것은 이 프로젝트에서 쓸 일 없으니까 몰라도 된다. 그런 일에 시간 뺐기지 마라.
지금 제가 하고 있는 일이 HW Validation 쪽이라서 디자인의 전체적인 동작 체계를 우선 이해하고 그 동작이 맞게 수행되고 있는가를 검증해야 하는데요...
자꾸 너무 자세한 하위 레벨을 들먹여서 가끔 핀잔을 듣곤 합니다...
어떻게 보면 그냥 욕하는 소리로 들릴 수도 있는데, 그게 밖에서 저를 보는 일반적인 시선일 수도 있거든요...
어감이 좀 강하지만, 실제로 프로그래머나 엔지니어 중에 로레벨 강박증이 있는 사람들이 꽤 되는 거 같습니다...
좋게 보면, 탐구의식이 강한 거고 어떻게 보면 또 강박증이고... 참, 적당히 하는 게 힘듭니다...
중요한 것은 너무 로레벨이나 디테일에 집중하다가 정작 중요한 것을 잃지는 말아야 한다는 거 같습니다... 선을 긋는 것이 중요하다랄까요... 둘 다 할 수 있다면야 금상첨화겠지만...
제가 처음부터
제가 처음부터 하고자 했던 이야기는 low level쪽 이야기가 아닙니다.
그냥 JAVA 이야기였습니다.
하지만 첫 이야기를 꺼내는 과정에서 자연스럽게 JAVA에 대한 제 부정적인 시각이
비추어지면서 상황이 꼬이게 되었네요.
그로인해 sDH8988L님과도 많은 이야기를 나누게 되었습니다.
이야기를 나누는 과정에서 많이 불편했습니다.
전 그냥 조용히 제가 원하는 것만 취하고 싶었을 뿐이였는데 무려 100개가 넘는 리플이 달리면서
논쟁의 핵심으로 떠오르고 있는게 달갑지 만은 않았습니다.
제가 low level쪽으로만 접근한다고 느끼셨다면
그건 아마 low level쪽으로 저에게 논쟁을 걸어오시는 분들에 대해서
제가 방어하면서 생긴 일이라고 생각합니다.
어쨌던 결국 잘못은 처음부터 JAVA에 대한 부정적인 시각을 비춘 제 잘못이 큽니다.
그리고 첨언하자면 제가 low level 강박증이 있을수 있다 느끼셨다는데
사실 저는 한창 엔지니어의 길을 걸어갈때 OOP, SE, Testing을 포함하여
high level에서도 잘하고 싶었습니다.
그래서 UML, OOP등을 되도록 많이 적용하기 위해 노력 했었습니다.
전 low level이던 high level이던 정말 다 잘하고 싶었습니다.
하지만 어느것 하나 세계 최고라 말할수 있을만큼 하지는 못했던것 같습니다.
그런데 저에게 한가지 확실한건 있습니다.
low level이던 high level이던 정말 잘하는 사람이라면 두 가지 다 잘할 수 있어야 하지 않겠느냐 입니다.
즉, 디테일에 집중하다 정작 중요한것을 잃는 사람이 아니라 숲도 보고 나무도 볼수 있는 사람이
진정 잘하는 사람이지 않을까 생각합니다.
물론 제가 그렇다는 이야기는 아닙니다. 말씀하신것 처럼 전 low level에 치우친 경향이 있습니다.
하지만 high level도 항상 지향하고 있습니다.
때문에 애초 제가 이 글을 올린것은 low level 강박증 때문에 올린것이 아니라는 것을 분명히 말씀드립니다.
확인을 원하신다면 제가 그간 이 쓰레드에 올린 제가 JAVA를 바라보는 시각에서 확인하실 수 있으실것입니다.
마지막으로 그냥 한말씀드린다면...
일에 있어서는 low level/high level 관점에 대한 선을 긋는게 중요할 수 있다 생각합니다.
목적은 항상 분명해야 하는 법이니깐요.
하지만 일이 아닌 훌륭한 엔지니어로써 살아가고자 한다면 과연 선을 긋는게 맞는 일일까라는 생각이듭니다.
오히려 그 선이 무한한 능력을 가진 자신의 능력을 규정짓는 벽이 되지 않을까 생각합니다.
High level에서 JAVA를 잘 알게 되었다면. 그리고 나서 JAVA를 진정 더 잘하고 싶다면.
JVM도 알아야 한다고 생각합니다.
그리고 JAVA 블로그들의 글을 보면 그런 사람들이 실제 존재하고 있습니다.
저 또한 얼마전에 그러한 사람을 직접 만난적이 있습니다.
그러면 굳이 규정 지을 필요가 있겠습니까. 어차피 대상은 JAVA가 됐건 JVM이 됐건 컴퓨터 시스템인데 말입니다.
메모리 용량의 한계가 있는 컴퓨터 시스템이라면 모르겠지만 인간의 능력은 무한하지 않습니까.
예... 이제, anfl님의
예...
이제, anfl님의 의도는 충분히 이해했습니다...
머 저도 쓸데없는 거 알려고 하지 말고 중요한 것만 해라 라는 의도로 말씀드린 건 아닙니다. 그 부분은 오해 없으셨으면 합니다...
그냥 Java를 바라보는 저의 견해와 anfl님의 견해가 달랐다는 정도가 가장 좋을 듯 합니다...
논쟁이 약간 격하게 흘러간 것은 개발자들의 자존심과 같은 부분을 건드렸기 때문이라고나 할까요?
Java가 정말 쉬운 언어일까요?
라는 제목은 그냥 그 뉘앙스가 잘 알지도 못하면서 쉽다고 하는 거 아니냐... 이런 의미로 받아들이기 쉽습니다....
아마도 그래서 약간은 공격적이지 않았나 합니다...
아뭏든, 이 글타래로 오랜만에 KLDP가 활성화된 거 같아서 보기에는 그리 나쁘지만은 않았습니다...
그럼 즐거운 프로그래밍합시다...
그 점에 대해서는
그 점에 대해서는 미안하게 생각합니다.
하지만 그럴 의도는 전혀 없었다는 것을 잘 아시리라 봅니다.
제 머리로는 이해가
제 머리로는 이해가 안되는 답글입니다. 누가 설명 좀-_-a
그 머리로 이해
그 머리로 이해 안되면 됐습니다.
이해 하실 필요 없습니다. ㅋㅋ
싫으면 그냥 싫은 거죠 뭐.
논란의 문제는 글 제목에서 오는 것 같습니다.
'자바가 정말 쉬운 언어인가요 ?'를 말 그대로 해석해서 보면
사실 자바가 어려운 언어는 절대 아니죠.
그런데 본문 내용을 보면 이 글 제목대로의 내용은 아니고,
'자바 컴파일러/런타임 구현의 이해가 쉬운가요 ?'가
원래 제목이 되었어야 하는 것 아닌가 하는 생각이 듭니다.
그래서인지 뭔가 글타래가 논지없이 흐르는 게 아닌가 싶네요.
아무튼 뭐 언어에 대한 호불호는 그냥 자기 취향이죠 뭐.
싫으면 그냥 싫은 것이고 좋은 점보단 싫은 점이 눈에 더 많이 띄고요.
며느리가 미우면 발 뒷축이 달걀같다고 나무란다잖아요. ;;
전 C++을 개인적으로 싫어해서 얘로 뭘 짜라면 막 짜증이 나더군요.
Basic, Fortran, Pascal, C, Java, C#, 뭐 등등 다 써봤지만,
옛날에 잠깐 본 Cobol과 더불어 가장 정이 안가는 느낌이예요.
상황상 어쩔수 없이 쓰기는 하지만요.
고슬링도 싫지만 스트라우스트럽은 더더더더 싫은 ㅠㅠ
아무튼 그냥 글 제목이 '자바 좋아하세요 ?' 정도였다면
또 다른 글타래가 되었을지도 모르겠다는 느낌이 듭니다.
좀더 주관적인 느낌들이 다뤄지는 글타래가 되었을듯도 하여서요.
자바가 C보다 쉽다고
자바가 C보다 쉽다고 느낄려면 몇가지를 전제해야 합니다.
JAVA가 빠르다고 하는데..
이것도 몇가지 전제가 필요하죠.
저야 C++쪽을 좋아하지만..
최근에는 디자인 패턴 책 보고 왜 JAVA가 어려웠는지 알게 되었습니다.
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
제가 할말을 대부분 하셨군요
Fe.head 님 말대로 입니다.
우리가 어떠한 프로그램을 짤때 "쉽다" 혹은 "어렵다" 라고 판단하는 것은
자신이 생각한 프로그램을 언어로 구현하는 단계에서 나타나는 것이 아닐까요?
그렇다면 객체지향 디자인을 토대로 구성한 프로그램을 자바로 짜는것과 씨로짜는것
어느것이 쉽다고 느껴질지는 당연히 답이 나올것이라 믿습니다.
자바로 씨 스타일처럼 짜는 사람이 어떻게 자바가 쉽다고 할수 있을까요?
씨로 객체지향 디자인을 구현하려면 어찌되겠습니까?
처음 배울때 모든 언어는 그게 그거 인거 같던데...쩝...
자바의 모든 클래스는 하나의 오브젝트로 시작되서 세분된것.
즉, 하나의 클래스를 사용하는 법을 알면 나머지도 배우기가 어렵지 않죠.
예를 들어, 스윙에서 하나의 컴포넨트를 오버라이딩하는법을 터득했다고 하면
나머지 컴포넨트들도 마찬가지로 구현할수잇듯이 말이죠.
하지만 객체지향을 모른다면 이것도 뜬구른 잡는소리겠고...
결국 자바가 어렵거나 쉬운게 아니라
그것을 받아드리는 사람의 사고방식이 어디에 짜마추어져 있고
자바를 어떻게 받아들이냐의 문제 아닐까여.
저에게 씨 스타일로 프로그램을 짜라하면 나는 답이 없다능...
---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.
http://jihwankim.co.nr
여러 프로그램 소스들이 있습니다.
필요하신분은 받아가세요.
여담으로, 아직
여담으로, 아직 배우는 입장에서, 학부생 관점으로 아예 JAVA의 언어적인 부분을 배제한다면
주변에서 JAVA를 어려워 하는 이유로 IDE 쪽에 초점을 맞춰서 얘기하곤 합니다.
(특히 이클립스로 JSP 배울땐 뭐 그리 설정할게 많은지...)
학부생 관점에서 C, C++은 MS VC++ 6.0 이 널리 퍼져있고 수업과정에서 계속 사용하기 때문에
너무나도 정겹죠. 특히 저희 학교처럼 JAVA가 커리큘럼에서 빠져있는 어처구니 없는 곳이라면 더더욱 그렇습니다.
IDE 없이 그냥 코딩하는건 아직 내공이 부족해서.... :0
아직 JAVA를 접해볼 일이 많지 않아서 그런데, 혹시 이클립스 말고 다른 IDE를 사용하시는게 있나요?
──────────────────────────────────
센스있는 개발자가 되고 싶습니다.
Blog : http://jhsieben.ivyro.net
──────────────────────────────────
──────────────────────────────────
센스있는 개발자가 되고 싶습니다.
Blog : http://jhyoon77.tistory.com
──────────────────────────────────
NetBeans가 요새 꽤
NetBeans가 요새 꽤 추격하고 있죠. 소수 매니아층은 IntelliJ를 쓰구요. 요즘 스윙이 빨라져서 이클립스보다 NetBeans가 빠른 느낌도 듭니다. 하지만 전 여전히 이클립스의 개념들이 좋아서 이클립스를 씁니다.
제가 학부 때 자바 배우던 생각이 나는군요. 그 때는 그냥 텍스트 에디터로 하다가 KAWA라는 게 나와서 그걸 썼더랬죠. simple yet powerful이라는 멋진 문구를 내세우던 게 기억이 납니다. 이후 JBuilder 1.0도 사서 썼었던 기억이...
사실 자바 자체는 쉽다고는 말 못해도 어렵다고 할 언어는 아닌데 자바를 둘러싼 것들이 참 어렵죠. 서블릿에 JSP에 각종 프레임웍에 XML에...
다른건 모르겠으나...굳이 껴들자면...
전혀 다른 이야기일수도 있는데요..
제가 만나본 같이 개발해본 개발자중에 c쪽 사람과 java쪽 차이는 물론 개개인이 다르지만..
환경 차이에 대한 이해도인것 같습니다. 물론 제 개인적 경험이지만요.
서버쪽은 주로 c로 하고 웹쪽은 java로 하는데..짜증나는 한가지는..
os환경이나.. 네트워크 상황 등등에 상관 없이 이런 이야기를 합니다.
"java에서는 이게 최선이예요.. os하고는 상관 없어요.."
열받습니다... 이러면..ㅡ.ㅡ
Java가 쉽다.....
Java를 먼저 공부했으면.... Java가 쉬운 겁니다.
별거 있나요?
C,C++,어셈블리까지 섭렵했다면...
Java가 쉬울리가 없겠지요...
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
...
이식성등 여러 이유로 인해서 qt4로 미들웨어를 개발중인데...
qt4 정말 편하더군요... 쉽고...
다른 파트에서는 이 미들웨어를 자바로도 개발하고 있습니다.
성능은 솔까말... 자바와 크게 차이 안납니다. 오히려 느린듯...
자바도 잘만들면... 정말 빠르더군요...
openbravo pos 같은 경우는 자바라는게 믿어지지 않을 수준...
비베보다 빠름..
양쪽다 이식성을 목적하기 때문에...감쳐진 부분이 많아서 일까요?
qt4로 개발하다 보니... 경우에 따라서는 자바보다는
c++이 쉬울 수도 있다는 생각이 들기는 합니다.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
좋은 정보
좋은 정보 정말 감사합니다.
으음..고수님들이 많으시군요..역시..
냐하하..개인적으로 무협지로 보자면
정파 사파에서 화경, 현경에 이르는 방식?
또는 검이 최고냐 도가 최고냐?
우습게 비교하자면 요렇게도 비교 될거 같네요.
도대체 자바로 뭘 하려고 그러시오?
CPU 버그 컴파일러 버그 그러시는데
도대체 자바로 뭘 하려고 그런 걱정을 하시는지?
저야 비즈니스 애플리케이션 개발을 업으로 하는지라 자바나 닷넷 같은 언어를 주로 사용하고 있습니다만
응용 애플리케이션이다 보니 8년이 넘는 세월동안 아직 그런 걱정은 하지 않았던것 같아 궁금해 물어 봅니다.
잘 가야지.
페이지