책 좀 추천해 주세요
김승범
>
> "김승범" <musi...@bawi.org> wrote in message
> news:3DCE6E43...@bawi.org...
> >
> > 처음 질문하신 분께서 특별히 꼭 C를 배우려는 것이 아니라 일반적인
> > 프로그래밍을 공부하시려는 것이라면, C 그룹에서 이런 얘기 하기는
> > 좀 그렇지만 처음부터 C++을 배우시는 것도 괜찮습니다. :)
>
> 김승범님께 딴지를 거는 것은 아니라는 것을 미리 밝힘니다. :)
>
> 많은 분들이 처음 프로그래밍을 배우면서 C, C++ 아니면 자바로 시작을
> 하시는데,
> 처음 프로그래밍을 공부 하는 분에게 C++은 너무 어렵지 않나 생각됩니다.
글쎄요. 저도 옛날에 C를 먼저 배웠기 때문에 처음부터 C++를 배우는 것이
얼마나 어려울지 경험에 근거하여 말씀드리기는 어렵습니다.
하지만 저는 많은 분들이 C++에 대해 처음부터 너무 '어렵다', '복잡하다'는
선입관을 가지고 대하는 것이 아닌가 싶습니다. "Learning Standard C++ as
a New Language"<http://www.research.att.com/~bs/new_learning.pdf>와 같은
글을 보면 C++로는 단 몇 줄이면 되는 간단한 일을 하기 위해 C로는 얼마나
긴 코드를 작성해야 하는지 그 예를 볼 수 있습니다.
처음부터 모든 것을 배우려고 하면 당연히 어렵겠지요.
하지만 세부적인 사항들 신경 안 쓰고 그냥 막 쓰기엔 C++가 편하더라고요.
그만큼 추상화를 해 놓았으니까요.
[han.comp.lang.c++ 에도 교차투고합니다.]
>
> 차라리 그런 언어들 보다는 lisp 이나 아니면 새로 나온 펄, 파이썬 같은
> 언어가 더 재미 있고 배우기 쉽지 않을까요?
lisp에 대해서는 아는 바가 없고, Perl이나 Python이 좋은 언어라는 것은
저도 인정합니다. 다만 언어마다 주특기가 다르고 쓰임이 다르겠지요.
>
> C나 C++의 좋고 나쁨을 떠나서, 이들은 초보자가 감당하기에 힘든 부분을
> 처음부터 끌어 안아야 하는 점이 많은 것 같습니다.
구체적으로 몇 가지 예를 들어 주시면 얘기를 이끌어 나가기 더 좋겠습니다.
--
김승범
Jeong Kim
> Jeong Kim wrote:
> >
> > "김승범" <musi...@bawi.org> wrote in message
> > news:3DCE6E43...@bawi.org...
> > >
>
> 선입관을 가지고 대하는 것이 아닌가 싶습니다. "Learning Standard C++ as
> a New Language"<http://www.research.att.com/~bs/new_learning.pdf>와 같은
> 글을 보면 C++로는 단 몇 줄이면 되는 간단한 일을 하기 위해 C로는 얼마나
> 긴 코드를 작성해야 하는지 그 예를 볼 수 있습니다.
저도 C보다 C++가 처음부터 어렵다고 생각하지는 않습니다.
실은 위에서 제가 말씀드리려고 한것은 C++ 뿐만이 아니라 C, 자바 모두
어려운 것 같다 입니다.
> > 차라리 그런 언어들 보다는 lisp 이나 아니면 새로 나온 펄, 파이썬 같은
> > 언어가 더 재미 있고 배우기 쉽지 않을까요?
>
> lisp에 대해서는 아는 바가 없고, Perl이나 Python이 좋은 언어라는 것은
> 저도 인정합니다. 다만 언어마다 주특기가 다르고 쓰임이 다르겠지요.
일단은 프로그래밍을 배우는 입장에서 말씀드린 것입니다.
프로그래밍이란 것이 잘 아시다 시피, 프로그래밍 언어의 지식만 가지고
할 수 없는 것입니다.
프로그래밍의 (소프트웨어 개발) 과정을
"주어진 문제를 분석, 정의하고 답을 궁리해서 컴퓨터가 이해할 수 있는 코드를
작성한다" 라고 한다면,
처음 배우는 과정에서 가장 착실히 익혀야 할 것이, 문제의 분석, 정의와
답을 궁리하는 과정까지라고 생각합니다.
쉽게 배우고 익힐 수 있는 언어로 먼저 위의 과정을 익히고 이 언어를
통해 코드를 작성한다면, 어려운 언어를 익히는데 들여야 할 시간을
문제의 해결 자체에 집중 할 수 있을 것입니다.
또 lisp을 언급한 단편적인 이유중의 하나는,
프로그래밍에서 매우 자주 쓰이고, 또 유용한 재귀 호출과 같은 기술을
C나 C++보다 쉽게 받아들일 수 있기 때문입니다.
이렇게 다른 언어에서의 프로그래밍에 익숙해 지면, 또 쉽게 다른 언어의
새로운 특성을 받아들이고 익힐 수 있다고 생각합니다.
그리고 전적으로 사견입니다만, 일단 직업 프로그래머가 된다면 좋던 싫던
간에 C, C++ 또는 자바와 접하게 되는 것이 지금의 현실입니다.
처음부터 C, C++를 익혀서 계속 이들 언어에만 갖혀(?) 있는 것 보다는
새로운 패러다임을 가진 언어들을 (lisp이나 ML 같은) 처음 학습할 때
다루어 보는 것도 좋다고 생각합니다.
> > C나 C++의 좋고 나쁨을 떠나서, 이들은 초보자가 감당하기에 힘든 부분을
> > 처음부터 끌어 안아야 하는 점이 많은 것 같습니다.
>
> 구체적으로 몇 가지 예를 들어 주시면 얘기를 이끌어 나가기 더 좋겠습니다.
이전에 h.c.l.c에서 논의된 적이 있었던 ++ 연산자가 한 예가 될 수 있는 것
같습니다. 위치에 따라, 상황에 따라 여러가지 의미를 가진다는 것이 상당한
혼란을 가져다 준다고 생각됩니다. 지난 번의 쓰레드가 상당히 길어진 것이
그 예가 되겠지요.
lisp이나 Python, ML 같은 언어의 경우, 실행 또는 컴파일 시점에 타입을 결정
하기 때문에 타입이 미리 선언되어야 하는 C, C++ 보다 쉽고 편리하며, 더 안전
합니다.
또 정수형 타입 하나에, short, int, long, unsigned 등과 같이 여러가지를
고려해야 한다는 것은 초보자에게 스트레스가 될 것입니다.
성능을 생각하지 않는다면, double 타입과 스트링 타입만 있어도 어떤 프로그램이
던지 *불편을 느끼지 않고* 만들 수 있을 것입니다.
그리고, 간단한 자료 구조 하나를 만들더라도 C, C++의 경우는 꽤 복잡한 코드가
나옵니다. 이러한 경험도 C, C++가 복잡한 언어라는 예가 되리라 생각합니다.
그 외에도 배열, 포인터도 (*를 5개 쓴 코드도 본적이 있습니다. -_-)
초보자들이 학습할 때 어려움을 많이 느끼는 부분이라고 알고 있습니다.
Chong-Dae Park
> 또 정수형 타입 하나에, short, int, long, unsigned 등과 같이 여러가지를
> 고려해야 한다는 것은 초보자에게 스트레스가 될 것입니다.
> 성능을 생각하지 않는다면, double 타입과 스트링 타입만 있어도 어떤 프로그램이
> 던지 *불편을 느끼지 않고* 만들 수 있을 것입니다.
double로는 좀 불편하지 않을까요? 일단 loop만 해도...
--
박종대
--
"Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away"
- Antoine de Saint-Exupery
parkkh
int, double, string 정도는 있어야...
"Chong-Dae Park" <cdp...@jupiter.kaist.ac.kr> wrote in message
news:3dd24e52$0$59181$7a21...@news.kaist.ac.kr...
김승범
>
> "Chong-Dae Park" <cdp...@jupiter.kaist.ac.kr> wrote in message
> news:3dd24e52$0$59181$7a21...@news.kaist.ac.kr...
> > In han.comp.lang.c++ Jeong Kim <jeong@artifex_no_spam.com> wrote:
> > > 또 정수형 타입 하나에, short, int, long, unsigned 등과 같이 여러가지를
> > > 고려해야 한다는 것은 초보자에게 스트레스가 될 것입니다.
> > > 성능을 생각하지 않는다면, double 타입과 스트링 타입만 있어도 어떤
> 프로그램이
> > > 던지 *불편을 느끼지 않고* 만들 수 있을 것입니다.
> >
> > double로는 좀 불편하지 않을까요? 일단 loop만 해도...
>
> int, double, string 정도는 있어야...
음.. Perl에는 int/double/string의 구별도 없더군요.. ^^
--
김승범
Jeong Kim
>
> 음.. Perl에는 int/double/string의 구별도 없더군요.. ^^
명시적인 타입이 있는 경우에서 말씀을 드린 것입니다만,
초보자에게는 특히 구별이 없는게 낫지 않을까요?
Genie
요즘 나오는 대부분의 스크립트 언어들이 그렇것 같더군요^^
>
> --
> 김승범
Genie
"Jeong Kim" <jeong@artifex_no_spam.com> wrote in message
news:aqtfk4$iji$1...@news.kreonet.re.kr...
또 다른 관점에서 생각해 볼수도 있습니다.
대부분 처음 배우는 사람들의 경우는 문제 해결보다는 화면에 뭔가 출력된다는것
소리가 난다는 것등에 더 관심이 있는 경우도 많습니다. 처음부터 문제해결
루프 검증등을 언급하면 쉬이 지루해 하죠^^
제가 가르쳐 본 경험에 의하면 물론 문제해결이 가장 중요한 부분임에도...
주위를 환기시키는 차원에서 다른 잡다한 것들을 먼저 가르치는 것도 충분히
효과적이라는 생각이 드네염^^
좋은 글 잘 읽었습니다.^^
>
> --
> 김정희
> jeong@artifex_no_spam.com
>
>
>
Jeong Kim
news:aqtmb7$i4o$1...@news1.kornet.net...
>
> 요즘 나오는 대부분의 스크립트 언어들이 그렇것 같더군요^^
>
90년대 들어 타입체킹이 쓸만한 기술이 되면서, 이 것을 도입한 실용적인
언어들이 출현하는 것 같습니다.
C나 C++의 타입 시스템은 워낙 오래되었기 때문에...
Jun Woong
> "김승범" <musi...@bawi.org> wrote in message
> news:3DD260FC...@bawi.org...
> >
> > 음.. Perl에는 int/double/string의 구별도 없더군요.. ^^
>
> 명시적인 타입이 있는 경우에서 말씀을 드린 것입니다만,
> 초보자에게는 특히 구별이 없는게 낫지 않을까요?
>
typeless language 만 알고 있는 사람들에게 type system 을 갖춘 언어를
교육한 경험이 있으신지요? 저라면 type system 에서 typeless 로 넘어가는
과정을 택하겠습니다.
int *pi;
printf("%d\n", pi);
이렇게 적어놓고, printf() 의 %d 덕분에 pi 가 가리키는 정수형 대상체의
값을 올바르게 출력해준다는 주장을 들어야 한다면...
그럼...
--
Jun, Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul
Jun Woong
하지만, 대부분의 물리적인 시스템이 제공하는 type system 이기도 하죠 -
RISC 라는 것이 있죠. :)
어떤 분야에서는 프로그램을 쉽게 짜는 것이 목표인지 모르겠지만, 다른 분
야에서는 동일한 언어로 최적의 성능을 이끌어 내는 것이 목표입니다.
그럼...
--
Jun, Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul
Cell: +82 11 9116 6247
Web : http://c-expert.uos.ac.kr
Jeong Kim
news:nOtA9.1407$5o4....@news.hananet.net...
>
> 어떤 분야에서는 프로그램을 쉽게 짜는 것이 목표인지 모르겠지만, 다른 분
> 야에서는 동일한 언어로 최적의 성능을 이끌어 내는 것이 목표입니다.
>
혹시 타입을 명시적으로 지정해야 하는 언어로 만들어진 프로그래밍이,
그렇지 않은 언어보다 빠르다고 주장하시는 건가요?
프로그래머가 명시적으로 타입을 지정하지 않는다고 해서, 바인딩이 일어나지
않는 것은 아닙니다.
컴파일 시점에서 컴파일러가 자동으로 프로그래머의 일을 덜어 주는 것이지요.
대부분의 C implementation 보다 빠른 성능을 내는 '타입 선언이 필요없는'
즉 타입의 유추를 자동으로 하는 언어의 implementation들도 존재합니다.
Jun Woong
혹시 컴파일러가 선택하는 type binding 이 그 프로그램의 의도를 가장 잘
알고 있는 프로그래머가 손수하는 type binding 보다 더 낫다고 주장하시는
건가요?
수치 해석 분야에서는 single precision, double precision, extended
precision 도 프로그래머가 직접 선택해야 하고 물리적인 시스템이 그 선택
을 존중해야 한다고 요구하고 있습니다. (*) C99 의 <fenv.h> 가 괜히 추가
된 것이 아닙니다. 더 정밀한 데이터형의 선택은 더 좋은 성능과 올바른 결
과를 보장하는 분야가 있습니다. 어떤 한가지 방식이 무조건 우수하다, 그
렇지 않다라고 주장하는 것만큼 바보스러운 일도 없습니다.
모든 언어는 해당 언어가 가장 적합한 분야를 갖기 마련입니다.
그럼...
(*) 님이 C 프로그램에서 float 형만으로 연산을 한다고 해서 실제 물리적
인 시스템에서 float 형에 대응하는 precision 만으로 연산이 이루어진다고
생각하시는 건 아니리라 믿습니다.
Jeong Kim
>
> 혹시 컴파일러가 선택하는 type binding 이 그 프로그램의 의도를 가장 잘
> 알고 있는 프로그래머가 손수하는 type binding 보다 더 낫다고 주장하시는
> 건가요?
타입 선언이 필요 없는 언어들도 명시적으로 타입을 선언할 수 있습니다.
예를 드신 경우와 같은 때에 꼭 필요한 부분만 타입을 명시 하면 됩니다.
모든 경우에 손수 바인딩을 하는 것이 낫다고 말할 수는 없겠지요.
> 수치 해석 분야에서는 single precision, double precision, extended
> precision 도 프로그래머가 직접 선택해야 하고 물리적인 시스템이 그 선택
> 을 존중해야 한다고 요구하고 있습니다. (*) C99 의 <fenv.h> 가 괜히 추가
> 된 것이 아닙니다. 더 정밀한 데이터형의 선택은 더 좋은 성능과 올바른 결
> 과를 보장하는 분야가 있습니다. 어떤 한가지 방식이 무조건 우수하다, 그
> 렇지 않다라고 주장하는 것만큼 바보스러운 일도 없습니다.
타입 유추의 이점은 매우 많습니다.
이러한 타입 시스템을 가지고 있으면서 명시적인 타입 선언을 할 수 있는
언어가 그렇지 않은 언어에 비하여, *타입 시스템*에서 만큼은 우수하다고
말할 수 있겠지요.
Jun Woong
> "Jun Woong" <myco...@hanmail.net> wrote in message
> news:x0uA9.1408$5o4....@news.hananet.net...
> >
> > 혹시 컴파일러가 선택하는 type binding 이 그 프로그램의 의도를 가장 잘
> > 알고 있는 프로그래머가 손수하는 type binding 보다 더 낫다고 주장하시는
> > 건가요?
>
> 타입 선언이 필요 없는 언어들도 명시적으로 타입을 선언할 수 있습니다.
> 예를 드신 경우와 같은 때에 꼭 필요한 부분만 타입을 명시 하면 됩니다.
그렇다면, 교육적인 측면을 생각한다면 어차피 type system 의 교육이 필요
하다는 이야기가 되는 것이군요. 그럼 그들이 명시적인 type system 이 C
나 C++ 에 비해서 더 나은 점은 무엇인가요?
여기서 문제가 좀 얽혀 있습니다. 정리를 해보겠습니다.
제가 주장하려는 것은 typeless language 의 자동 type binding 과 명시적
인 type system 에 대한 이야기였습니다. 또 이와 같은 주제를 논할 때 C/
C++ 의 type system 에 대한 비판은 어차피 필요 없습니다. C/C++ 이 명백
한 typing 을 요구하여 얻을 수 있는 장점을 결국 typeless lang. 들도 동
일한 방식으로 얻는다는 이야기뿐이 되지 않기 때문입니다. 성격이 다른 문
제로 C/C++ 의 type system 에 대한 비판이 이루어졌다는 점을 지적하고 싶
은 것입니다. typeless lang. 들이 C/C++ 에 비해 독특할 만큼 뛰어난 type
system 을 제공하지 않는다면 말입니다 - 추상화가 더 깊어지고 명백해졌을
뿐이지 결국은 ALGOL 의 자식들일 뿐입니다.
>
> 모든 경우에 손수 바인딩을 하는 것이 낫다고 말할 수는 없겠지요.
프로그램을 장악하고 싶은 프로그래머에게는 자동 바인딩이 씁쓸하겠지만
모든 경우에 그럴 필요는 없다는데 동의합니다.
>
> > 수치 해석 분야에서는 single precision, double precision, extended
> > precision 도 프로그래머가 직접 선택해야 하고 물리적인 시스템이 그 선택
> > 을 존중해야 한다고 요구하고 있습니다. (*) C99 의 <fenv.h> 가 괜히 추가
> > 된 것이 아닙니다. 더 정밀한 데이터형의 선택은 더 좋은 성능과 올바른 결
> > 과를 보장하는 분야가 있습니다. 어떤 한가지 방식이 무조건 우수하다, 그
> > 렇지 않다라고 주장하는 것만큼 바보스러운 일도 없습니다.
>
> 타입 유추의 이점은 매우 많습니다.
> 이러한 타입 시스템을 가지고 있으면서 명시적인 타입 선언을 할 수 있는
> 언어가 그렇지 않은 언어에 비하여, *타입 시스템*에서 만큼은 우수하다고
> 말할 수 있겠지요.
>
결국, multi-paradigm language 인 C++ 이 C 보다 문제 해결 방식에서는
우수하다는 주장과 같군요. 님이 C/C++ 의 type system 이 구식이라 주장한
부분을 비유하자면, C 가 제공하는 문제 해결 방식이 C++ 에 비해 구식이라
는 주장과 같습니다. "구식" 은 단지 오래되었다는 의미만을 갖는 단어가
아닙니다 - "뒤떨어졌다" 는 늬앙스를 피하기가 어렵습니다. 하지만, C++
프로그램이 multi-paradigm degisn 을 지향하며 부분적으로 C 와 같은 절차
식 문제 해결 방식을 사용한다면...
그럼...
Jeong Kim
>
> 그렇다면, 교육적인 측면을 생각한다면 어차피 type system 의 교육이 필요
> 하다는 이야기가 되는 것이군요. 그럼 그들이 명시적인 type system 이 C
> 나 C++ 에 비해서 더 나은 점은 무엇인가요?
일단 *처음* 프로그래밍을 공부할 때는 타입 선언을 할 필요가 없는 언어가 낫지
않겠냐 하는 것이 제 주장입니다.
언젠가는 type을 선언하는 법을 배워야 겠지요.
> 여기서 문제가 좀 얽혀 있습니다. 정리를 해보겠습니다.
>
> 제가 주장하려는 것은 typeless language 의 자동 type binding 과 명시적
> 인 type system 에 대한 이야기였습니다. 또 이와 같은 주제를 논할 때 C/
> C++ 의 type system 에 대한 비판은 어차피 필요 없습니다. C/C++ 이 명백
> 한 typing 을 요구하여 얻을 수 있는 장점을 결국 typeless lang. 들도 동
> 일한 방식으로 얻는다는 이야기뿐이 되지 않기 때문입니다. 성격이 다른 문
> 제로 C/C++ 의 type system 에 대한 비판이 이루어졌다는 점을 지적하고 싶
> 은 것입니다. typeless lang. 들이 C/C++ 에 비해 독특할 만큼 뛰어난 type
> system 을 제공하지 않는다면 말입니다 - 추상화가 더 깊어지고 명백해졌을
> 뿐이지 결국은 ALGOL 의 자식들일 뿐입니다.
이제 부터는 초보자 학습과 관련된 이슈는 아닌 것 같네요.
일단 "typeless language"라는 표현은 적절하지 않은 것 같습니다.
타입 유추 기술을 가진 언어들은 strongly-typed language의 특성을 가지고
있습니다.
또 C/C++의 타입 시스템에 대한 비판이라고 하셨는데,
타입 유추 기술을 가진 언어들은 대부분 ALGOL의 자식들이 아닙니다.
이러한 타입 유추 기술은 대부분 함수형 언어에서 볼 수 있는데,
이러한 언어들은 ALGOL 그리고 그 후계자들과 같은 imperative language가
아닙니다.
언어의 스펙이 수학적으로 엄밀히 분석되어 만들어져 있고, 또 언어의 특성이
이러한 타입 유추를 가능하게 해 주는 것입니다.
하스켈과 같은 언어는 assignment도 불가능 하지요. 당연히 변수도 없고요.
> 프로그램을 장악하고 싶은 프로그래머에게는 자동 바인딩이 씁쓸하겠지만
> 모든 경우에 그럴 필요는 없다는데 동의합니다.
예전에는 어셈블리나 기계어로 손으로 바이너리를 최적화 하고 싶어하던
프로그래머들도 많았지요. :)
> > 타입 유추의 이점은 매우 많습니다.
> > 이러한 타입 시스템을 가지고 있으면서 명시적인 타입 선언을 할 수 있는
> > 언어가 그렇지 않은 언어에 비하여, *타입 시스템*에서 만큼은 우수하다고
> > 말할 수 있겠지요.
> >
>
> 결국, multi-paradigm language 인 C++ 이 C 보다 문제 해결 방식에서는
> 우수하다는 주장과 같군요. 님이 C/C++ 의 type system 이 구식이라 주장한
> 부분을 비유하자면, C 가 제공하는 문제 해결 방식이 C++ 에 비해 구식이라
> 는 주장과 같습니다. "구식" 은 단지 오래되었다는 의미만을 갖는 단어가
> 아닙니다 - "뒤떨어졌다" 는 늬앙스를 피하기가 어렵습니다. 하지만, C++
> 프로그램이 multi-paradigm degisn 을 지향하며 부분적으로 C 와 같은 절차
> 식 문제 해결 방식을 사용한다면...
타입 유추 자체의 이점이라고 하기는 뭐 하지만, 이러한 타입 유추는 언어의
특성과 강력한 타입 시스템을 기반으로 하기 때문에 이 타입 시스템의 장점을
이야기 해 보겠습니다.
강력한 타입 시스템은 매우 견고한 소프트웨어를 쉽게 (C/C++) 보다 작성할
수 있게 해 줍니다.
즉 컴파일러를 에러 없이 통과한 프로그램은 SEGV와 같은 에러를 절대 내지
않습니다. 프로그래머는 논리 에러에만 집중하면 되는 것입니다.
그리고, C++의 templete도 비슷하긴 합니다만, 함수가 타입에 얽매이지
않습니다. 즉 하나의 함수로, 타입은 다르지만 하는 일이 같은 함수를
매우 자연스럽게 표현할 수 있습니다.
또 대부분의 경우 타입을 명시적으로 지정할 필요가 없다는 그 자체만으로도
큰 이점이고요.
Jun Woong
>
> > 여기서 문제가 좀 얽혀 있습니다. 정리를 해보겠습니다.
> >
> > 제가 주장하려는 것은 typeless language 의 자동 type binding 과 명시적
> > 인 type system 에 대한 이야기였습니다. 또 이와 같은 주제를 논할 때 C/
> > C++ 의 type system 에 대한 비판은 어차피 필요 없습니다. C/C++ 이 명백
> > 한 typing 을 요구하여 얻을 수 있는 장점을 결국 typeless lang. 들도 동
> > 일한 방식으로 얻는다는 이야기뿐이 되지 않기 때문입니다. 성격이 다른 문
> > 제로 C/C++ 의 type system 에 대한 비판이 이루어졌다는 점을 지적하고 싶
> > 은 것입니다. typeless lang. 들이 C/C++ 에 비해 독특할 만큼 뛰어난 type
> > system 을 제공하지 않는다면 말입니다 - 추상화가 더 깊어지고 명백해졌을
> > 뿐이지 결국은 ALGOL 의 자식들일 뿐입니다.
>
> 이제 부터는 초보자 학습과 관련된 이슈는 아닌 것 같네요.
>
> 일단 "typeless language"라는 표현은 적절하지 않은 것 같습니다.
> 타입 유추 기술을 가진 언어들은 strongly-typed language의 특성을 가지고
> 있습니다.
타입 유추 기술을 가진 언어들의 typeless language 로의 특징을 말씀드리
는 것입니다. BCPL 같은 오리지날 typeless lang. 를 말씀드리는 것이 아닙
니다.
>
> 또 C/C++의 타입 시스템에 대한 비판이라고 하셨는데,
> 타입 유추 기술을 가진 언어들은 대부분 ALGOL의 자식들이 아닙니다.
> 이러한 타입 유추 기술은 대부분 함수형 언어에서 볼 수 있는데,
> 이러한 언어들은 ALGOL 그리고 그 후계자들과 같은 imperative language가
> 아닙니다.
> 언어의 스펙이 수학적으로 엄밀히 분석되어 만들어져 있고, 또 언어의 특성이
> 이러한 타입 유추를 가능하게 해 주는 것입니다.
> 하스켈과 같은 언어는 assignment도 불가능 하지요. 당연히 변수도 없고요.
>
음.. 오해의 시작점이 이것이었나요? 저는 LISP, Haskell 같은 함수형 언어
를 염두에 두고 이야기를 하던 것이 아니었습니다. thread 를 다시 검토할
필요가 있겠군요 - 제가 보았던 이야기의 시작은 Perl 입니다. Haskell 이
아닙니다. 그 앞 글들도 봤으면 상황을 이해하는데 도움이 되었겠지만, 개
인적으로 별로 흥미가 없는 글이라 볼 생각을 못했습니다.
] > > 음.. Perl에는 int/double/string의 구별도 없더군요.. ^^
] >
] > 요즘 나오는 대부분의 스크립트 언어들이 그렇것 같더군요^^
] >
]
] 90년대 들어 타입체킹이 쓸만한 기술이 되면서, 이 것을 도입한 실용적인
] 언어들이 출현하는 것 같습니다.
]
] C나 C++의 타입 시스템은 워낙 오래되었기 때문에...
님이 Perl 류의 스크립트 언어가 아닌 LISP 이나 ML 같은 함수형 언어의
데이터형 유추 시스템을 생각하며 C/C++ 의 type system 을 비판하신 것이
라면 전 더 이상 할 말이 없어집니다. 서로 다른 패러다임의 언어의 "우수
성"을 서로 주장하는 것만큼 어리석은 짓도 없습니다. 동일한 문제에 대해
전혀 다른 발생과 방법으로 접근하는데 어찌 세세한 도구나 특징이 문제가
될 수 있겠습니까?
[...]
>
> > > 타입 유추의 이점은 매우 많습니다.
> > > 이러한 타입 시스템을 가지고 있으면서 명시적인 타입 선언을 할 수 있는
> > > 언어가 그렇지 않은 언어에 비하여, *타입 시스템*에서 만큼은 우수하다고
> > > 말할 수 있겠지요.
> > >
> >
> > 결국, multi-paradigm language 인 C++ 이 C 보다 문제 해결 방식에서는
> > 우수하다는 주장과 같군요. 님이 C/C++ 의 type system 이 구식이라 주장한
> > 부분을 비유하자면, C 가 제공하는 문제 해결 방식이 C++ 에 비해 구식이라
> > 는 주장과 같습니다. "구식" 은 단지 오래되었다는 의미만을 갖는 단어가
> > 아닙니다 - "뒤떨어졌다" 는 늬앙스를 피하기가 어렵습니다. 하지만, C++
> > 프로그램이 multi-paradigm degisn 을 지향하며 부분적으로 C 와 같은 절차
> > 식 문제 해결 방식을 사용한다면...
>
> 타입 유추 자체의 이점이라고 하기는 뭐 하지만, 이러한 타입 유추는 언어의
> 특성과 강력한 타입 시스템을 기반으로 하기 때문에 이 타입 시스템의 장점을
> 이야기 해 보겠습니다.
>
> 강력한 타입 시스템은 매우 견고한 소프트웨어를 쉽게 (C/C++) 보다 작성할
> 수 있게 해 줍니다.
> 즉 컴파일러를 에러 없이 통과한 프로그램은 SEGV와 같은 에러를 절대 내지
> 않습니다. 프로그래머는 논리 에러에만 집중하면 되는 것입니다.
>
> 그리고, C++의 templete도 비슷하긴 합니다만, 함수가 타입에 얽매이지
> 않습니다. 즉 하나의 함수로, 타입은 다르지만 하는 일이 같은 함수를
> 매우 자연스럽게 표현할 수 있습니다.
>
그래서 어떤 네트워크 업체에서 라우터 시스템을 C++ 에서 C 로 다시 옮긴
것인지요? 혹은 야후가 C 에서 PHP 로 옮긴 건지요? 각 언어가 최적으로 사
용될 수 있는 분야는 서로 다릅니다. Perl 로 운영체제를 만들 수 있다고
생각이십니까? :) 누군가가 "우격다짐" 유머라며 그런 유머를 사용하더군
요.
!! 언어의 세세한 feature 에 대한 이야기를 하고 싶으시다면 최소한 같은
패러다임을 공유하는 언어에서 이루어져야 합니다!! 만약 누군가가 C++ 의
templete 을 들고나와 generic programming 의 우수성을 주장한다면, 제가
어찌 C 언어로 이에 대한 반론을 펼 수 있겠습니까? (DMR 자신도 그렇게는
안 합니다) 물론, C99 에는 type-generic math function 들이 추가되었기는
하지만, 그렇다고 C99 가 generic programming 패러다임을 갖춘 것이라 할
수는 없겠지요.
안타깝게도 서로 다른 언어를 심중에 둔 까닭에 스타일 문제 못지 않은 시
간 낭비가 된 듯 합니다.
Jeong Kim
>
> 님이 Perl 류의 스크립트 언어가 아닌 LISP 이나 ML 같은 함수형 언어의
> 데이터형 유추 시스템을 생각하며 C/C++ 의 type system 을 비판하신 것이
> 라면 전 더 이상 할 말이 없어집니다. 서로 다른 패러다임의 언어의 "우수
> 성"을 서로 주장하는 것만큼 어리석은 짓도 없습니다. 동일한 문제에 대해
> 전혀 다른 발생과 방법으로 접근하는데 어찌 세세한 도구나 특징이 문제가
> 될 수 있겠습니까?
사실 저도 의아스럽게 생각했습니다만,
"C나 C++의 타입 시스템은 워낙 오래되었기 때문에..."
이 한마디가 문제였군요.
이 자리에서 더 이상 "우수성"을 따지는 것은 저도 별로 하고 싶지 않습니다만,
그것을 따지는 것은 충분히 의미가 있습니다.
저는 C/C++과 ML과 같은 언어는 세대가 다르다고 생각합니다.
현재 C/C++가 시장을 장악하고 있지만, 그것이 꼭 이들의 우수성 때문만은
아닙니다.
이들의 이후 세대들에서 나온 새로운 기술, 새로운 패러다임이 우수하다는 것이
널리 받아들여진다면, 조금 더 편리하고 나은 환경에서 프로그래밍 할 수 있지
않겠습니까?
언어의 용도를 말씀하셨는데, C와 ML의 용도가 어떻게 다르다고 생각하십니까?
어셈블리어 대용으로서의 C가 아니라면, 많은 경우 현재 C/C++로 작성되고 있는
어플리케이션들이 ML로 (익숙하다는 가정하에) 더 쉽고, 빨리 그리고
견고하게 작성될 수 있습니다.
아래 홈페이지를 보시면, 함수형 프로그래밍 언어가 범용 프로그래밍 언어로서
어떻게 사용될 수 있는지 알 수 있습니다.
http://www.research.avayalabs.com/user/wadler/realworld/
관심이 있으실지 모르겠지만, 많은 분들이 함수형 언어는 느리다는 선입관을
가지고 계셔서 링크해 봅니다.
ML의 한 dialect인 Ocaml이 2등이군요.
http://www.bagley.org/~doug/shootout/craps.shtml
> 그래서 어떤 네트워크 업체에서 라우터 시스템을 C++ 에서 C 로 다시 옮긴
> 것인지요? 혹은 야후가 C 에서 PHP 로 옮긴 건지요? 각 언어가 최적으로 사
> 용될 수 있는 분야는 서로 다릅니다. Perl 로 운영체제를 만들 수 있다고
> 생각이십니까? :) 누군가가 "우격다짐" 유머라며 그런 유머를 사용하더군
> 요.
제가 생계를 위해 하고 있는 일이 GhostScript 개발입니다.
GhostScript는 대부분 C로 프로그래밍 되어 있고, 나머지는 PostScript로
프로그래밍 되어 있습니다.
C 소스 파일만 1000여개가 넘는 방대한 규모라 100여개 정도의 버그 갯수를
계속 유지하고 있는데, 대부분 메모리 관련 버그들입니다.
UMR, 메모리 릭, SEGV 이런 문제들...
그런데 같이 일하시는 분들 대부분이 함수형 언어에 매우 익숙하고,
또 한분은 lisp의 첫번째 implementation을 개발하셨을 정도 입니다.
(Mr. Peter Deutsch -- The Hackers 라는 책에도 나오지요.)
함수형 언어들은 인터프리터 개발에서 특별한 강점을 가지고 있고,
모두들 그걸 잘 알고 있지만, ML과 같은 언어로 GhostScript를 개발하지
못하는 이유는 단 하나,
GhostScript가 동작해야 하는 플랫폼에 (대부분 하드웨어 임베드)
맞는 컴파일러가 없기 때문입니다.
실제적인 측면에서 보면, C가 이런 면에서 아주 적합한 프로그래밍 언어
이지만, 순수하게 프로그래밍 언어만 놓고 따진다면 그렇지 않습니다.
> !! 언어의 세세한 feature 에 대한 이야기를 하고 싶으시다면 최소한 같은
> 패러다임을 공유하는 언어에서 이루어져야 합니다!! 만약 누군가가 C++ 의
> templete 을 들고나와 generic programming 의 우수성을 주장한다면, 제가
> 어찌 C 언어로 이에 대한 반론을 펼 수 있겠습니까? (DMR 자신도 그렇게는
> 안 합니다) 물론, C99 에는 type-generic math function 들이 추가되었기는
> 하지만, 그렇다고 C99 가 generic programming 패러다임을 갖춘 것이라 할
> 수는 없겠지요.
저 역시 세세한 feature에 대한 이야기를 하고 싶지 않습니다.
또 잘 모르기도 하고요.
Jeong Kim
>
> 안타깝게도 서로 다른 언어를 심중에 둔 까닭에 스타일 문제 못지 않은 시
> 간 낭비가 된 듯 합니다.
저는 간만에 재미 있었습니다. :)
제 생각을 정리해 볼 수도 있었구요.
Jun Woong님의 글 기사 늘 재미있게 읽고 있습니다.
사실 저는 10년 전 쯤에 White Book 한번 읽은 후에 C책을 제대로
읽은 적이 없어서, C에서 // 로 시작하는 코멘트가 있다는 것도
여기서 알았습니다.
Jun Woong
> "Jun Woong" <myco...@hanmail.net> wrote in message
> news:mbwA9.1414$5o4....@news.hananet.net...
> >
> > 님이 Perl 류의 스크립트 언어가 아닌 LISP 이나 ML 같은 함수형 언어의
> > 데이터형 유추 시스템을 생각하며 C/C++ 의 type system 을 비판하신 것이
> > 라면 전 더 이상 할 말이 없어집니다. 서로 다른 패러다임의 언어의 "우수
> > 성"을 서로 주장하는 것만큼 어리석은 짓도 없습니다. 동일한 문제에 대해
> > 전혀 다른 발생과 방법으로 접근하는데 어찌 세세한 도구나 특징이 문제가
> > 될 수 있겠습니까?
>
> 사실 저도 의아스럽게 생각했습니다만,
> "C나 C++의 타입 시스템은 워낙 오래되었기 때문에..."
> 이 한마디가 문제였군요.
>
> 이 자리에서 더 이상 "우수성"을 따지는 것은 저도 별로 하고 싶지 않습니다만,
> 그것을 따지는 것은 충분히 의미가 있습니다.
>
> 저는 C/C++과 ML과 같은 언어는 세대가 다르다고 생각합니다.
> 현재 C/C++가 시장을 장악하고 있지만, 그것이 꼭 이들의 우수성 때문만은
> 아닙니다.
언젠가 한빛미디어 홈페이지에서 C 언어의 성능에 대한 논쟁이 있었습니다.
C 언어가 별로 뛰어나지 않은 성능을 가진 언어임에도 많은 분야에서 C 언
어에 대한 맹신이 있다는 식의 논쟁이었습니다. 그 논쟁은 한빛미디어 측의
프래스 룸이라는 코너를 통해 기사화되었고, 본의 아니게 여기 저기 유명
홈페이지들에 무단 복제되기도 했습니다. 아마도 그 글을 보시면 제가 C 언
어에 대해서 가지고 있는 생각이 충분히 전달되지 않을까 생각합니다 - 제
홈페이지의 첫화면을 보시면 링크가 있습니다.
저는 단 한순간에도 C 언어가 모든 문제에 최상의 언어이다 라고 생각한 적
도 주장한 적도 없습니다. C/C++ 의 type system 이 오래되었다는 표현에
반론을 제기한 이유는, C/C++ 이 그런 type system 을 유지해야 할 필요성
을 가지고 있다는 사실을 배제하지 말아야 한다는 뜻이었고, 실제 동일한
패러다임의 다른 언어들이 도입한 type system 역시 결국 큰 차이는 없음을
이야기하기 위함이었습니다.
저는 C 를 매우 오랫동안 나름대로 깊게 공부하고 있는 사람이지만 C/C++
에 대한 부정적인 이야기에 당장 격분할 만큼 C 를 무조건적으로 두둔하는
사람도 아닙니다. 다만, 다른 언어에 비해 low-level 의 성격이 강한고 (따
라서 C 언어를 제대로 이해하기 위해서는 더불어 알아야 할 것이 다른 언어
에 비해 많습니다) 언어의 정의 자체가 비대하지 않다는 점에서, 또 C 의
철학이 맘에 들어 C 를 좋아하고 공부하는 사람입니다. 참고로, 저는 C++
에 대해서도 별로 좋은 감정이 없습니다. C++ 표준을 보신 분이라면 제가
C++ 을 좋아하지 않는 이유를 조금이라도 느끼실 수 있지 않을까 생각합니
다.
이 부분에 대해서는 저에 대해 절대 오해가 없었으면 합니다.
>
> 이들의 이후 세대들에서 나온 새로운 기술, 새로운 패러다임이 우수하다는 것이
> 널리 받아들여진다면, 조금 더 편리하고 나은 환경에서 프로그래밍 할 수 있지
> 않겠습니까?
>
> 언어의 용도를 말씀하셨는데, C와 ML의 용도가 어떻게 다르다고 생각하십니까?
> 어셈블리어 대용으로서의 C가 아니라면, 많은 경우 현재 C/C++로 작성되고 있는
> 어플리케이션들이 ML로 (익숙하다는 가정하에) 더 쉽고, 빨리 그리고
> 견고하게 작성될 수 있습니다.
C 가 많은 분야에서 오랫동안 사용된 이유는 언어 자체의 우수성 때문이 아
닙니다. 해당 분야를 적절하게 대체할 우수한 언어가 없었기 때문입니다.
지금 업체에서 일어나는 변화를 보더라도 C 가 많은 부분에서 다른 언어들
에게 자리를 내어주고 C 가 유효한 분야를 찾아간다는 것을 확인할 수 있습
니다 - 또한, C 표준 역시 그런 움직임에 발맞추어 따라가고 있습니다.
그럼에도 C 가 아직까지 갖는 장점이 있다면 언어 자체를 지원하는 환경이
어마어마하다는 것입니다. 즉, 새로 개발된 시스템이라 해도 기본적인 어셈
블리에 추가적으로 지원되는 언어가 대부분 C 입니다. 이는 C 언어가 갖는
compact 함이 (마땅히 적절한 우리말이 생각나지 않는군여) 빛을 발하는 순
간입니다. 현존하는 언어 중에서 이식성 있는 컴파일러를 제작하기 가장 쉬
운 언어가 C 가 아닐까 생각합니다. 컴파일러를 제작하기 쉽다는 것은 단지
언어의 정의가 단순하다는 것과 관련된 문제만은 아닙니다 - 컴파일러 분야
를 공부해 보셨다면 이해하시리라 믿습니다.
따라서, 개발자로서 C 를 알고 있다는 것은 그만큼 다양한 분야에 심지어는
미개척 분야에까지 보다 빠르게 적응할 수 있는 힘을 가지고 있다는 것을
의미합니다. 쉽게 이야기해 이식성있는 front-end 만 가지고 있고 해당 시
스템의 어셈블리어를 어설프게나마 파악하면 성능은 최적이 아니더라도 제
대로 된 C 컴파일러 하나 나오는 것은 시간 문제입니다.
님이 말씀하시는 다른 언어들이 안타깝게도 빛을 발하지 못하고 있다면 단
지 그러한 사실을 안타깝게 생각하시지만 말고 그 근본적인 이유를 생각해
보시기 바랍니다. 말씀하신대로 시장을 장악하는 힘은 "우수성" 이 아닙니
다 - 언어의 우수성이 시장 장악력을 보증해주지는 않습니다. 수많은 언어
가 널리 사용되길 바라며 탄생하지만, 또한 많은 언어가 이름 한번 알려보
지 못하고 죽어가고 있습니다.
>
> 아래 홈페이지를 보시면, 함수형 프로그래밍 언어가 범용 프로그래밍 언어로서
> 어떻게 사용될 수 있는지 알 수 있습니다.
> http://www.research.avayalabs.com/user/wadler/realworld/
>
> 관심이 있으실지 모르겠지만, 많은 분들이 함수형 언어는 느리다는 선입관을
> 가지고 계셔서 링크해 봅니다.
> ML의 한 dialect인 Ocaml이 2등이군요.
> http://www.bagley.org/~doug/shootout/craps.shtml
좋은 자료 감사드립니다.
>
> > 그래서 어떤 네트워크 업체에서 라우터 시스템을 C++ 에서 C 로 다시 옮긴
> > 것인지요? 혹은 야후가 C 에서 PHP 로 옮긴 건지요? 각 언어가 최적으로 사
> > 용될 수 있는 분야는 서로 다릅니다. Perl 로 운영체제를 만들 수 있다고
> > 생각이십니까? :) 누군가가 "우격다짐" 유머라며 그런 유머를 사용하더군
> > 요.
>
> 제가 생계를 위해 하고 있는 일이 GhostScript 개발입니다.
> GhostScript는 대부분 C로 프로그래밍 되어 있고, 나머지는 PostScript로
> 프로그래밍 되어 있습니다.
> C 소스 파일만 1000여개가 넘는 방대한 규모라 100여개 정도의 버그 갯수를
> 계속 유지하고 있는데, 대부분 메모리 관련 버그들입니다.
> UMR, 메모리 릭, SEGV 이런 문제들...
DMR 자신도 인정하지만, C 언어는 대형 프로젝트에 유용한 언어가 아닙니다.
언어 자체가 커널 같은 시스템 프로그래밍에 깊에 관련되어 발전해 왔기 때
문에 대형 프로젝트에는 적절하지 않은 언어적 기술을 많이 포함하고 있습
니다. 하지만, 단지 GhostScript 에서 발생하는 많은 문제가 C 언어 때문이
라는 이유가 언어를 함수형 언어로 대체해야 한다는 주장을 밑받침한다고
생각하지는 않습니다 - 너무 심한 논리적 비약이 있습니다.
>
> 그런데 같이 일하시는 분들 대부분이 함수형 언어에 매우 익숙하고,
> 또 한분은 lisp의 첫번째 implementation을 개발하셨을 정도 입니다.
> (Mr. Peter Deutsch -- The Hackers 라는 책에도 나오지요.)
>
> 함수형 언어들은 인터프리터 개발에서 특별한 강점을 가지고 있고,
> 모두들 그걸 잘 알고 있지만, ML과 같은 언어로 GhostScript를 개발하지
> 못하는 이유는 단 하나,
>
> GhostScript가 동작해야 하는 플랫폼에 (대부분 하드웨어 임베드)
> 맞는 컴파일러가 없기 때문입니다.
>
> 실제적인 측면에서 보면, C가 이런 면에서 아주 적합한 프로그래밍 언어
> 이지만, 순수하게 프로그래밍 언어만 놓고 따진다면 그렇지 않습니다.
그렇다면 이야기는 끝난 것입니다. 해당 플랫폼에서 컴파일러를 찾을 수 없
다면 혹은 쉽게 구현할 수 없다면, 그 언어가 아무리 우수하다고 해도 얻을
수 있는 것이 없습니다. C 언어는 언어 자체에 많은 문제점을 가지고 있습
니다. 또한, 그 누구도 (DMR 자신도) 그 부분에 대해서 변명을 하지는 않습
니다. 애초부터 엄격하게 디자인된 언어도 아니고, 당장 사용하기 위해서
이리저리 뜯어 고쳐진 언어가 C 언어입니다. 하지만, 시간이 20-30년이 지
난 지금은 어떻습니까? 심지어는 어설픈 PDA 에서 돌아가는 C 컴파일러도
있습니다.
비유에 비약이 있을 수도 있지만, 만약 자연 언어의 우수성을 평가할 수 있
다고 가정하고 특정 국가의 소수 민족이 사용하는 언어가 매우 경제적이고
배우기도 쉽다고 가정하겠습니다. 그 언어가 단지 우수하다는 이유만으로
여러 나라는 영어를 버리고 그 언어를 공용어 수준으로 채택해야 하고, 당
장 많은 학교에서는 그 언어를 가르쳐야 하겠습니까? 하고 많은 언어 중에
왜 우리나라의 교육 기관은 영어에 목을 매고 있는지 생각해 보시기 바랍니
다. 영어가 그렇게 우수한 언어입니까? 교육이라는 것은 실용성을 배제하고
이루어질 수 있는 것이 아닙니다. LISP, ML, Haskell 모두 좋지만, 배워서
당장 써먹기가 어렵다면 누가 배우려 할 것이며, 누가 가르치려 하겠습니까?
프로그래밍 언어는 생명체와 같습니다. 우수성이 인정되더라도 성장하길 바
라는 소수의 기대만으로는 자라주지 않습니다.
취미거리나 프로그래밍 언어 자체에 대한 탐구 과정에서는 우수한 언어가
중요성을 차지하겠지만, 단지 언어가 우수하다는 이유만으로 해당 언어가
교육에 사용되어야 한다는 근거는 되지 않습니다. 학생들이 집에 돌아가
LISP 컴파일러를 구하지 못해 머리 속에서만 프로그래밍을 한다면 이것이
올바른 프로그래밍 언어 교육이 되겠습니까? 또한, LISP 과제를 하기 위해
얼마 되지도 않는 자료를 찾아 영문으로 써진 논문을 번역하는 고충을 겪어
야만 하겠습니까?
저 역시 우수한 언어가 널리 퍼져 잘 사용되면 이에 불만을 가질 이유가 없
습니다. 하지만 님이 단지 함수형 언어의 우수성만을 바탕으로 함수형 언어
의 교육을 주장하는 것은 적절하지 않다고 생각합니다. Java 가 널리 쓰이
니 C 대신 Java 로 수업하자는 이야기가 나오고 있는 마당에, 과연 현실이
함수형 언어를 얼마나 받아들여줄지 저로서는 의심스럽습니다 - 실제적인
기반 없이는 상당히 어려운 일입니다.
이런 이야기를 하고 싶지 않아 처음 포스팅된 글을 피했던 것이지만 결국은
하게 되는군요.
Jun Woong
> "Jun Woong" <myco...@hanmail.net> wrote in message
> news:mbwA9.1414$5o4....@news.hananet.net...
> >
> > 안타깝게도 서로 다른 언어를 심중에 둔 까닭에 스타일 문제 못지 않은 시
> > 간 낭비가 된 듯 합니다.
>
> 저는 간만에 재미 있었습니다. :)
> 제 생각을 정리해 볼 수도 있었구요.
>
음... 시간 낭비라는 뜻은 이런 주제 자체가 무의미하다는 뜻이 아닙니다.
처음부터 서로 오해를 가지고 있는 부분을 알았다면 (님은 함수형 언어를
생각하고 계셨고, 저는 C 와 같은 패러다임을 공유하는 스크립트 언어들을
생각하고 있었습니다) 오해하고 있는 부분을 찾는 과정이 필요 없었을 것이
라는 표현이었습니다.
> Jun Woong님의 글 기사 늘 재미있게 읽고 있습니다.
> 사실 저는 10년 전 쯤에 White Book 한번 읽은 후에 C책을 제대로
> 읽은 적이 없어서, C에서 // 로 시작하는 코멘트가 있다는 것도
> 여기서 알았습니다.
>
C 가 아닌 다른 언어 (특히나 패러다임이 아예 다른 언어) 에 익숙하신 덕
분에 C 언어가 갖는 맹점을 제대로 파악하고 계신듯 합니다. 저 역시 그 부
분에 동감하고 있으며, C 언어에 대한 무조건적인 찬양을 하려는 의도는 아
닙니다.
다만, 다른 글에서도 말씀드렸듯이, 이런 주제의 논의에 참여하는 것을 별
로 좋아하지 않습니다. 물론, 해당 글이 완전히 잘못된 내용을 바탕으로 이
루어지고 있다면 사실 정정을 위해 뛰어들겠지만, 쓰래드의 내용을 보았을
때 제가 끼어들 여지 없이 충분히 근거 있고 합리적인 논의들이 오가고 있
었기에 괜히 물 흐려 놓는 꼴이 되지 않을까 하는 우려에서 관심을 두고 있
지 않았습니다. C/C++ 에 대한 type system 이야기는 perl 이야기 이후에
나온 것이라 (패러다임이 다른 언어에 대한 고려 없이) 진행된 것입니다.
앞으로도 좋은 주제로 이야기 나눌 수 있는 기회가 많았으면 합니다.
김 재석
> <싹독>
> 님이 Perl 류의 스크립트 언어가 아닌 LISP 이나 ML 같은 함수형 언어의
> 데이터형 유추 시스템을 생각하며 C/C++ 의 type system 을 비판하신 것이
> 라면 전 더 이상 할 말이 없어집니다. 서로 다른 패러다임의 언어의 "우수
> 성"을 서로 주장하는 것만큼 어리석은 짓도 없습니다. 동일한 문제에 대해
> 전혀 다른 발생과 방법으로 접근하는데 어찌 세세한 도구나 특징이 문제가
> 될 수 있겠습니까?
저는 좀 다른 생각입니다. C를 제안할 당시에는 적어도 Category theory라든
지 하는 것들이 프로그래밍 언어론에 파고들지 못한 시기였기 때문에 type 시
스템 자체만 가지고 비교하는 것은 다른 문제입니다. type inference system
이 91년 즈음에 와서야 어느 정도 궤도에 오른 것은 C/C++의 검증 구조를 오
래됐다고 할법 합니다. 아시다시피 C90은 89년에 제안됐으니 말입니다. 비록
패러다임이 다른 언어에서 쓰이고 있지만 type 시스템 자체는 그와는 별도로
어떤 것이 진보된 것인지 말할 수 있습니다. 몇 년뒤 Proof-carrying-code가
보편화되면 ML이나 Haskell에서 쓰이는 Milner-Mycroft Calculus도 구식이라
고 불릴지 모르지만 말입니다.
C가 만들어질 당시에 당시의 기술에 기반해서 문법이 만들어졌기 때문에 최근
의 이론들이 쉽게 반영되지 못하는 점은 못내 아쉽습니다. 당장 type 시스템
을 최근 이론을 발전을 반영하고자 하면 문법에도 칼을 대야 할 것 같으니...
--
TeX and EMACS live together in perfect harmony.
Jun Woong
news:3dd2f4ce$0$59183$7a21...@news.kaist.ac.kr...
> In han.comp.lang.c Jun Woong <myco...@hanmail.net> wrote:
>
> > <싹독>
> > 님이 Perl 류의 스크립트 언어가 아닌 LISP 이나 ML 같은 함수형 언어의
> > 데이터형 유추 시스템을 생각하며 C/C++ 의 type system 을 비판하신 것이
> > 라면 전 더 이상 할 말이 없어집니다. 서로 다른 패러다임의 언어의 "우수
> > 성"을 서로 주장하는 것만큼 어리석은 짓도 없습니다. 동일한 문제에 대해
> > 전혀 다른 발생과 방법으로 접근하는데 어찌 세세한 도구나 특징이 문제가
> > 될 수 있겠습니까?
>
> 저는 좀 다른 생각입니다. C를 제안할 당시에는 적어도 Category theory라든
> 지 하는 것들이 프로그래밍 언어론에 파고들지 못한 시기였기 때문에 type 시
> 스템 자체만 가지고 비교하는 것은 다른 문제입니다. type inference system
> 이 91년 즈음에 와서야 어느 정도 궤도에 오른 것은 C/C++의 검증 구조를 오
> 래됐다고 할법 합니다. 아시다시피 C90은 89년에 제안됐으니 말입니다. 비록
> 패러다임이 다른 언어에서 쓰이고 있지만 type 시스템 자체는 그와는 별도로
> 어떤 것이 진보된 것인지 말할 수 있습니다. 몇 년뒤 Proof-carrying-code가
> 보편화되면 ML이나 Haskell에서 쓰이는 Milner-Mycroft Calculus도 구식이라
> 고 불릴지 모르지만 말입니다.
Proof-carrying-code 건 Milner-Mycroft system 이건 다 좋은 이야기입니다.
하지만 중요한 것은 그와 같은 이론을 채용한 언어들이 *모든* 경우에 있어
서 고전적인 언어 기술에 비해 더 나은 성능을 제공하느냐는 것입니다.
Jeong Kim 님의 말씀대로 모든 경우에 구식 기술이 필요한 것은 아니지만,
아직도 필요한 분야가 상당수 남아 있고, 그와 같은 이론이 프로그래머의
의도를 100% 올바르게 파악하지 못한다면 역시나 선택되지 않는 분야가 있
음을 의미합니다. 단언컨데, 지금과 같은 C 의 발전 방향이면 앞으로 상당
한 기간동안, 혹은 C 가 존재의 위협감을 느껴 엄청난 변화를 모색한다면
C203X 정도면 모를까 C 에서는 Proof-carrying-code 등을 도입할 일은 없다
고 생각합니다. C 가 type checking 이나 프로그램의 안전성에 있어서 그토
록 느슨한 이유는 단지 C 언어를 디자인하는 사람들이 멍청해서가 아닙니다.
((void (*)(void))0)();
이 수식을 놓고 잘못되었다고 말할 수 있습니까? 물론 표준은 저 행동의 결
과가 정의되지 않느다고 이야기합니다 - 절대 "금지된다" 고 이야기하지 않
습니다. 저 수식은 어떤 임베디드 시스템의 전원을 제어하기 위해서 사용되
고 있습니다.
for (;;) {
/* 프로그램 전체 구조 */
}
프로그램의 전체 구조가 탈출 조건이 없는 무한 루프에 둘러싸여 있습니다.
이제 이 프로그램은 잘못된 프로그램입니까? 절대 프로그램이 종료되어서는
안 되는 분야가 있습니다. 프로그램 소스에 exit() 썼다가 욕만 잔뜩 얻어
먹는 분야가 있습니다.
extern void end;
대체 이 수식의 의미는 무어라 말입니까? UNIX 링커를 제작할 때 흔하게 사
용되던 선언 중에 하나입니다.
세제의 양을 자동으로 조절해주는 세탁기, 빨래의 종류를 자동 판단해주는
세탁기, 가장 최적의 물의 양을 조절하는 세탁기 모두 좋습니다. 하지만,
아직도 현실에서는 어머니가 꼼꼼하게 직접 하시는 손빨래가 필요합니다.
각종 첨단 이론들이 그만큼의 효과를 이뤄내지 못하는한 C 는 오늘도 소매
를 걷어 붙입니다.
이러한 현실적인 문제에 대한 숙고 없이 단지 우수하지 않음에도 널리 쓰이
고 있다는 사실 하나만으로 언어를 평가절하하는 것만큼 어리석은 행동도
없습니다. 오래 전에 함수형 언어를 선호하던 교수님과 이야기를 나누는 과
정에서도 그런 문제로 논쟁을 벌인 적이 있습니다. 물론 함수형 언어를 이
해하고 최신 언어 기술들을 이해하는 수준은 저하고 비교가 되지 않습니다.
하지만, 저는 최소한 지금 돌아가고 있는 현실들, C 표준화 위원회가 고민
하는 것들이 무엇인지를 알고 있습니다. 저 역시 지금까지도 C 언어의 정의
가 갖는 애매모호한 부분에 대해 지적하고 있지만, 그 속 사정을 알고나면
마음이 그리 편하지 않습니다. 그 논쟁 후에 강의실을 나가면서 한마디 던
졌습니다, "그럼 이번 학기 프로젝트로는 함수형 언어로 임베디드 시스템
OS 나 만들어 볼까요?" 권위에 도전한 대가는 학점에 반영되었습니다. :(
>
> C가 만들어질 당시에 당시의 기술에 기반해서 문법이 만들어졌기 때문에 최근
> 의 이론들이 쉽게 반영되지 못하는 점은 못내 아쉽습니다. 당장 type 시스템
> 을 최근 이론을 발전을 반영하고자 하면 문법에도 칼을 대야 할 것 같으니...
C 가 손쉽게 첨단의 이론을 받아들이지 않는 것은 (못하는 것이 아닙니다)
C 의 대중성을 유지하기 위해서 입니다. 실제로 지금 표준처럼 언어에 대해
구구절절 풀어쓰는 것보다 언어의 semantic 까지 모호하지 않도록 정의하는
이론이 없는 것이 아닙니다. 이는 C89 를 표준화하는 과정에도 대두됐던 문
제입니다. 하지만, 표준화 위원회가 두려워한 것은 그로 인해 C 의 대중성
이 사라질까 하는 문제였습니다. C 표준을 보기 위해서 공부해야 할 것이
더 많아진다면 그 어떤 컴파일러 제작자들이 C 표준을 이해하려고 노력하겠
습니까? 또한, 언어에 도입되는 모든 새로운 기술들은 이미 돌아가고 있는
수많은 프로그램들에게 어떤 영향을 주는가가 고려됩니다. 현재를 포기하고
장미빛 미래를 설계하는 것은 어차피 언어적 우수성이 떨어지는 C 로서는
자기 무덤을 파는 것과 같은 행동입니다.
첨단의 언어가 최신의 기술을 사용하고, 그런 기술을 자랑하는 것은 상관없
습니다. 하지만, 누군가가 C 에 대해서 그런 불만을 가지고 있다면 이는 모
든 현실적인 불편을 스스로 감수하면서 다른 언어를 선택해 사용할 때가 되
었다는 뜻입니다. 당장 눈을 돌려 보시기 바랍니다. 쓰고 싶어도 쓰지 못하
는 언어가 있는가 하면, 쓰고 싶지 않지만 써야 하는 언어가 있습니다. 이
것이 C 가 생명을 유지해가는 방법입니다. 결국 화단의 이쁜 꽃이 잡초 때
문에 말라 죽는다 해도 꽃에 그만큼의 생명력을 심어주지 못한다면 화단에는
잡초만 남습니다. 제가 보기에는 잡초의 그런 생명력과 단순함이 아름답기만
하군요.
김승범
>
> "김승범" <musi...@bawi.org> wrote in message
> news:3DD097C1...@bawi.org...
> > Jeong Kim wrote:
> > >
> > > "김승범" <musi...@bawi.org> wrote in message
> > > news:3DCE6E43...@bawi.org...
> > > >
> > > 처음 프로그래밍을 공부 하는 분에게 C++은 너무 어렵지 않나 생각됩니다.
> >
> > 하지만 저는 많은 분들이 C++에 대해 처음부터 너무 '어렵다', '복잡하다'는
> > 선입관을 가지고 대하는 것이 아닌가 싶습니다. "Learning Standard C++ as
> > a New Language"<http://www.research.att.com/~bs/new_learning.pdf>와 같은
> > 글을 보면 C++로는 단 몇 줄이면 되는 간단한 일을 하기 위해 C로는 얼마나
> > 긴 코드를 작성해야 하는지 그 예를 볼 수 있습니다.
>
> 저도 C보다 C++가 처음부터 어렵다고 생각하지는 않습니다.
> 실은 위에서 제가 말씀드리려고 한것은 C++ 뿐만이 아니라 C, 자바 모두
> 어려운 것 같다 입니다.
아, 그러셨군요. 제가 '오버'했네요. :-)
> 프로그래밍이란 것이 잘 아시다 시피, 프로그래밍 언어의 지식만 가지고
> 할 수 없는 것입니다.
> 프로그래밍의 (소프트웨어 개발) 과정을
> "주어진 문제를 분석, 정의하고 답을 궁리해서 컴퓨터가 이해할 수 있는 코드를
> 작성한다" 라고 한다면,
> 처음 배우는 과정에서 가장 착실히 익혀야 할 것이, 문제의 분석, 정의와
> 답을 궁리하는 과정까지라고 생각합니다.
정말정말 동의하는 내용입니다.
이런 측면에서 프로그래밍에 접근하는 좋은 책 있으면 소개 좀 해 주세요.
(아, 다시 이 글타래의 제목으로 돌아왔습니다. ^^)
>
> 쉽게 배우고 익힐 수 있는 언어로 먼저 위의 과정을 익히고 이 언어를
> 통해 코드를 작성한다면, 어려운 언어를 익히는데 들여야 할 시간을
> 문제의 해결 자체에 집중 할 수 있을 것입니다.
예, 그럴 수 있겠다 싶네요.
> 그리고 전적으로 사견입니다만, 일단 직업 프로그래머가 된다면 좋던 싫던
> 간에 C, C++ 또는 자바와 접하게 되는 것이 지금의 현실입니다.
> 처음부터 C, C++를 익혀서 계속 이들 언어에만 갖혀(?) 있는 것 보다는
> 새로운 패러다임을 가진 언어들을 (lisp이나 ML 같은) 처음 학습할 때
> 다루어 보는 것도 좋다고 생각합니다.
이도 일리 있는 것 같습니다.
저도 지금껏 lisp이나 ML 같은 언어를 접해 볼 기회가 없어서
그런 것들은 모르고 삽니다. --;
>
> > > C나 C++의 좋고 나쁨을 떠나서, 이들은 초보자가 감당하기에 힘든 부분을
> > > 처음부터 끌어 안아야 하는 점이 많은 것 같습니다.
> >
> > 구체적으로 몇 가지 예를 들어 주시면 얘기를 이끌어 나가기 더 좋겠습니다.
>
> 이전에 h.c.l.c에서 논의된 적이 있었던 ++ 연산자가 한 예가 될 수 있는 것
> 같습니다. 위치에 따라, 상황에 따라 여러가지 의미를 가진다는 것이 상당한
> 혼란을 가져다 준다고 생각됩니다. 지난 번의 쓰레드가 상당히 길어진 것이
> 그 예가 되겠지요.
까다로운 주제였죠.. comp.lang.c++.moderated에서도 prefix/postfix의
의미에 대해서 한동안 긴 토론이 있었습니다만..
하지만 어떤 언어든 깊이 파고 들어가면 까다로운 점은 나오기 마련이라고
생각합니다. 그리고 어떤 언어를 사용하기 위해 꼭 그 언어의 모든 면을
그렇게 깊이 알아야 하는 것도 아니고요.
>
> lisp이나 Python, ML 같은 언어의 경우, 실행 또는 컴파일 시점에 타입을 결정
> 하기 때문에 타입이 미리 선언되어야 하는 C, C++ 보다 쉽고 편리하며, 더 안전
> 합니다.
쉽고 편리할 수는 있겠지만 안전할 수 있는지는 잘 모르겠습니다.
보통 편리함과 안전함은 반대로 가지 않던가요? :-)
> 또 정수형 타입 하나에, short, int, long, unsigned 등과 같이 여러가지를
> 고려해야 한다는 것은 초보자에게 스트레스가 될 것입니다.
> 성능을 생각하지 않는다면, double 타입과 스트링 타입만 있어도 어떤 프로그램이
> 던지 *불편을 느끼지 않고* 만들 수 있을 것입니다.
초보자가 굳이 short, int, long, unsigned 등의 여러 가지를 고려해야
한다고 가르치는 곳이 있나요? 초보자에게는, 그리고 중급 이상의 실력과
경험을 가진 사람에게도 대부분의 경우에는, 정수형은 int로 충분합니다.
게다가 예전 16비트 시절과는 달리 요즘은 그냥 int라고만 해도 4바이트
씩이나 할당해 줘서 모자랄 일이 없으니 얼마나 좋습니까? :-)
언어가 제공하는 모든 기능을 초보자가 알아야 할 필요는 없죠.
>
> 그리고, 간단한 자료 구조 하나를 만들더라도 C, C++의 경우는 꽤 복잡한 코드가
> 나옵니다. 이러한 경험도 C, C++가 복잡한 언어라는 예가 되리라 생각합니다.
제가 아는 절차형 언어들에서의 자료 구조 정의는 다 비슷비슷했는데,
함수형 언어에서는 사정이 많이 다른가요? 제가 그쪽은 잘 몰라서..
>
> 그 외에도 배열, 포인터도 (*를 5개 쓴 코드도 본적이 있습니다. -_-)
> 초보자들이 학습할 때 어려움을 많이 느끼는 부분이라고 알고 있습니다.
반복되는 이야기이지만, 초보자가 어려운 코드에 주눅이 들 필요는 없죠.
저도 int (*devilson(int (*grandson[5])(int *px)))(int *px); 같은 선언
보면 무지 헷갈리고 한참 생각해야 됩니다. 하지만 평생에 한번 쓸까말까한
이런 것에 주눅들고 C/C++를 포기하지는 않습니다. :-)
아마도 초보자들이 언어의 어려운 기능에 주눅들고 좌절하는 것은
많은 언어 학습서들이 학습자의 진도에 맞게 단계적으로 설명하기보다는
기능별로 묶어서 설명을 하려 하기 때문이 아닐까 생각해 봅니다.
"자, 이번 단원은 포인터다. 여기서 포인터를 마스터하고 넘어간다!"
이런 식 아닌가요? 여러 가지를 조금씩 배워야 할 텐데 말이지요.
--
김승범
Jun Woong
> Jeong Kim wrote:
[...]
> > 프로그래밍이란 것이 잘 아시다 시피, 프로그래밍 언어의 지식만 가지고
> > 할 수 없는 것입니다.
> > 프로그래밍의 (소프트웨어 개발) 과정을
> > "주어진 문제를 분석, 정의하고 답을 궁리해서 컴퓨터가 이해할 수 있는 코드를
> > 작성한다" 라고 한다면,
> > 처음 배우는 과정에서 가장 착실히 익혀야 할 것이, 문제의 분석, 정의와
> > 답을 궁리하는 과정까지라고 생각합니다.
>
> 정말정말 동의하는 내용입니다.
> 이런 측면에서 프로그래밍에 접근하는 좋은 책 있으면 소개 좀 해 주세요.
> (아, 다시 이 글타래의 제목으로 돌아왔습니다. ^^)
>
이는 한 프로그래밍 언어에 대한 이야기가 아니라 프로그램의 디자인과 관
련된 문제라고 생각합니다. 프로그래밍 언어는 도구입니다. 일단 문제 해결
을 위한 방법론이 결정되면 적절한 부분에 적절한 언어를 선택하는 일만 남
은 것입니다. 물론 다양한 언어를 알지 못한다면 언어 선택의 폭이 좁아질
수 밖에 없습니다. 물론, 이는 지극히 이상적인 이야기입니다. 대부분의 경
우 현실은 2-3개 언어 중 하나를 선택하도록 요구하고 있습니다.
> > 그리고 전적으로 사견입니다만, 일단 직업 프로그래머가 된다면 좋던 싫던
> > 간에 C, C++ 또는 자바와 접하게 되는 것이 지금의 현실입니다.
> > 처음부터 C, C++를 익혀서 계속 이들 언어에만 갖혀(?) 있는 것 보다는
> > 새로운 패러다임을 가진 언어들을 (lisp이나 ML 같은) 처음 학습할 때
> > 다루어 보는 것도 좋다고 생각합니다.
>
> 이도 일리 있는 것 같습니다.
> 저도 지금껏 lisp이나 ML 같은 언어를 접해 볼 기회가 없어서
> 그런 것들은 모르고 삽니다. --;
>
그런 것들을 모르고 살아도 지금 현재의 컴퓨팅 산업에 일조를 할 수 있기
때문입니다. 다양한 패러다임의 많은 언어를 다룰 줄 아는 것은 사고의 폭
을 넓히고 문제 해결 방법에 대한 다양성을 부여해주지만, 현실을 그렇게
여유롭지 않습니다. "팀장님, 이 소팅 부분은 LISP 으로 처리하면 간단할
것 같은데요?" "컴파일러는 니가 만들래?" 이게 현실입니다. :(
> >
> > 이전에 h.c.l.c에서 논의된 적이 있었던 ++ 연산자가 한 예가 될 수 있는 것
> > 같습니다. 위치에 따라, 상황에 따라 여러가지 의미를 가진다는 것이 상당한
> > 혼란을 가져다 준다고 생각됩니다. 지난 번의 쓰레드가 상당히 길어진 것이
> > 그 예가 되겠지요.
>
> 까다로운 주제였죠.. comp.lang.c++.moderated에서도 prefix/postfix의
> 의미에 대해서 한동안 긴 토론이 있었습니다만..
>
정작 increment/decrement op. 를 B 언어에 추가한 KT 의 철학은 간단합니
다. (자꾸 이런 식의 대화체를 써서 죄송합니다만, 글이 너무 딱딱해지지
않기 위해서...) "덴당.. 이런 PDP-7 메모리는 코딱지만하자나? 이거 프로
그램을 가능한 간단히 번역할 수 있는 구조로 만들어아겠군. i = i + 1 보
다는 i++ (혹은 ++i), i+=1 로 쓰면 lexer 가 더 간단해 지겠지? 앞뒤로 붙
이는 것에 따라 의미를 다르게 하면 재밌겠군."
그리고는 할 일 없는 사람들이 increment/decrement 에 온갖 잡다한 철학을
집어 넣기 시작했습니다. 결론은 간단합니다. 프로그램은 프로그래머의 의
도를 표현하는 수단입니다.
> 하지만 어떤 언어든 깊이 파고 들어가면 까다로운 점은 나오기 마련이라고
> 생각합니다. 그리고 어떤 언어를 사용하기 위해 꼭 그 언어의 모든 면을
> 그렇게 깊이 알아야 하는 것도 아니고요.
>
동의합니다.
> >
> > lisp이나 Python, ML 같은 언어의 경우, 실행 또는 컴파일 시점에 타입을 결정
> > 하기 때문에 타입이 미리 선언되어야 하는 C, C++ 보다 쉽고 편리하며, 더 안전
> > 합니다.
>
> 쉽고 편리할 수는 있겠지만 안전할 수 있는지는 잘 모르겠습니다.
> 보통 편리함과 안전함은 반대로 가지 않던가요? :-)
>
ML 이 사용하는 Milner-Mycroft system 등은 그렇지 않습니다. 어려운 기술
이기는 하지만, 편리함과 안전성을 동시에 잡으려 하고 있습니다. 예를 들
면, C 언어는 "자동차가 돌아가려면 요기까지 기름을 채워라" 라고 말합니
다. 그런데 어떤 기름인지는 이야기하지 않고 있습니다. 등유를 채우느냐
무연 휘발유를 채우느냐에 따라 자동차의 성능과 특징이 달라집니다. 심한
경우 고장도 나죠. 함수형 언어가 채택하는 system 은 기름의 종류까지 검
사해준다고 볼 수 있습니다. 프로그램의 잠재적인 위험성도 놓지지 않는 것
입니다. 하지만, 자동차에 등유를 넣고 싶은 사람에게는 자동차가 시동도
걸리지 않을테니 답답할 것입니다.
> > 또 정수형 타입 하나에, short, int, long, unsigned 등과 같이 여러가지를
> > 고려해야 한다는 것은 초보자에게 스트레스가 될 것입니다.
> > 성능을 생각하지 않는다면, double 타입과 스트링 타입만 있어도 어떤 프로그램이
> > 던지 *불편을 느끼지 않고* 만들 수 있을 것입니다.
>
> 초보자가 굳이 short, int, long, unsigned 등의 여러 가지를 고려해야
> 한다고 가르치는 곳이 있나요? 초보자에게는, 그리고 중급 이상의 실력과
> 경험을 가진 사람에게도 대부분의 경우에는, 정수형은 int로 충분합니다.
> 게다가 예전 16비트 시절과는 달리 요즘은 그냥 int라고만 해도 4바이트
> 씩이나 할당해 줘서 모자랄 일이 없으니 얼마나 좋습니까? :-)
>
> 언어가 제공하는 모든 기능을 초보자가 알아야 할 필요는 없죠.
흠.. 그게 어려운가요? 솔직히 C 의 type system 이 어렵다고 생각하는 사
람들이 얼마나 편한 환경에서 지내다 왔는지 궁금할 뿐입니다. 저는 중학교
3학년때 Quick-BASIC 에서 C 언어로 넘어왔습니다. 제가 C 언어의 type
system 에서 어려움을 느꼈다면 그 크기 (비트수) 가 고정되지 않아 이식성
이라는 개념을 익히는 것이었습니다. 특정 시스템에서 일단 크기를 고정한
다면 정수형, 부동형이 분화된 개념은 간단합니다.
>
> >
> > 그리고, 간단한 자료 구조 하나를 만들더라도 C, C++의 경우는 꽤 복잡한 코드가
> > 나옵니다. 이러한 경험도 C, C++가 복잡한 언어라는 예가 되리라 생각합니다.
>
> 제가 아는 절차형 언어들에서의 자료 구조 정의는 다 비슷비슷했는데,
> 함수형 언어에서는 사정이 많이 다른가요? 제가 그쪽은 잘 몰라서..
솔직히 저도 절차형 언어에 익숙해져있는데 LISP 을 처음 다룰 때는 당황스
러웠습니다. 패러다임의 변화가 그 첫번째 이유였고, 수 많은 중첩된 괄호
가 두번째 이유였습니다. :)
> > 그 외에도 배열, 포인터도 (*를 5개 쓴 코드도 본적이 있습니다. -_-)
> > 초보자들이 학습할 때 어려움을 많이 느끼는 부분이라고 알고 있습니다.
>
> 반복되는 이야기이지만, 초보자가 어려운 코드에 주눅이 들 필요는 없죠.
> 저도 int (*devilson(int (*grandson[5])(int *px)))(int *px); 같은 선언
> 보면 무지 헷갈리고 한참 생각해야 됩니다. 하지만 평생에 한번 쓸까말까한
> 이런 것에 주눅들고 C/C++를 포기하지는 않습니다. :-)
대신 C 는 그 대중성과 긴 역사 덕분에 프로그램의 어려운 부분을 도와줄
수 있는 많은 도구들을 가지고 있습니다. 유도형의 개념을 알고 있다면 구
체적인 선언 방법은 cdecl 이 도와줍니다.
>
> 아마도 초보자들이 언어의 어려운 기능에 주눅들고 좌절하는 것은
> 많은 언어 학습서들이 학습자의 진도에 맞게 단계적으로 설명하기보다는
> 기능별로 묶어서 설명을 하려 하기 때문이 아닐까 생각해 봅니다.
> "자, 이번 단원은 포인터다. 여기서 포인터를 마스터하고 넘어간다!"
> 이런 식 아닌가요? 여러 가지를 조금씩 배워야 할 텐데 말이지요.
>
이 부분에 있어서는 저는 좀 다른 의견을 갖습니다. *물론 학습자의 수준을
고려한 튜토리얼 방식의 책이 중요하다는 사실에는 동의합니다* 하지만, 튜
토리얼은 한권으로 충분합니다. 터보 C 정복이나 K&R2 등은 모두 튜토리얼
방식을 택하고 있습니다 - 제가 본 튜토리얼 책은 이게 전부입니다, 그 이
후부터는 논문이나 레퍼런스 스타일의 책만을 보았습니다. 이 책을 모두 읽
고 나면 학습자의 수준을 고려한 점차적인 난이도로 큰 어려움 없이(?) 언
어를 마칠 수 있다고 생각합니다. 이제 문제는 언어의 체계가 보이지 않는
다는 것입니다. 조금만 난이도 있는 C 프로그램을 만나면 금방 진땀을 삐질
삐질 흘리다가 손을 놓아 버리고는 합니다. C 는 유독 각 부분이 연결되어
있는 언어입니다. 예를 들면, 선언을 모르면 데이터형을 이해하기 어렵고,
데이터형을 모르면 선언을 이해하기 어렵습니다. 이 둘을 구분하지 않고 섞
어 설명한다면 처음 초보자들이 어려움 없이 받아들일 수 있겠지만 언어과
프로그램의 구조가 머리속에서 분명히 그려지기는 어렵다고 봅니다.
K&R2 서문에는 BWK 인지 DMR 인지 모르겠지만, "C 언어는 큰 언어가 아니기
에 큰 책으로 제공될 필요가 없다" 라는 말이 있습니다. 많은 사람들이 그
말에 고개를 끄덕이며 "일리가 있어, 두꺼운 책들은 다 바보야" 라고 생각
합니다. 누가 진짜 바보인지 모르겠더군요. (부록을 제외한) K&R2 만을 읽
고 C 언어를 얼마나 이해할 수 있다고 생각하는지 모르겠습니다. 누군가가
이야기하더군요 - 그 말에 고개를 끄덕이는 사람들은 진정 K&R2 만 보고 C
언어를 완전히 이해하고 있느냐고? 정작 레퍼런스 스타일의 많은 책을 본
사람들이 K&R2 의 저 문장에 동의하고 있습니다 - 아이러니합니다. 그리고
초보자들은 K&R2 를 다 읽고도 (실제 학교 수업에 가장 많이 사용되는 교재
라 생각합니다) 대체 뭐가 뭔지 모르겠다고 이야기하고 있습니다.
Jun Woong
>
> >
> > 아마도 초보자들이 언어의 어려운 기능에 주눅들고 좌절하는 것은
> > 많은 언어 학습서들이 학습자의 진도에 맞게 단계적으로 설명하기보다는
> > 기능별로 묶어서 설명을 하려 하기 때문이 아닐까 생각해 봅니다.
> > "자, 이번 단원은 포인터다. 여기서 포인터를 마스터하고 넘어간다!"
> > 이런 식 아닌가요? 여러 가지를 조금씩 배워야 할 텐데 말이지요.
> >
>
> 이 부분에 있어서는 저는 좀 다른 의견을 갖습니다. *물론 학습자의 수준을
> 고려한 튜토리얼 방식의 책이 중요하다는 사실에는 동의합니다* 하지만, 튜
> 토리얼은 한권으로 충분합니다. 터보 C 정복이나 K&R2 등은 모두 튜토리얼
> 방식을 택하고 있습니다 - 제가 본 튜토리얼 책은 이게 전부입니다, 그 이
> 후부터는 논문이나 레퍼런스 스타일의 책만을 보았습니다. 이 책을 모두 읽
> 고 나면 학습자의 수준을 고려한 점차적인 난이도로 큰 어려움 없이(?) 언
> 어를 마칠 수 있다고 생각합니다. 이제 문제는 언어의 체계가 보이지 않는
> 다는 것입니다. 조금만 난이도 있는 C 프로그램을 만나면 금방 진땀을 삐질
> 삐질 흘리다가 손을 놓아 버리고는 합니다. C 는 유독 각 부분이 연결되어
> 있는 언어입니다. 예를 들면, 선언을 모르면 데이터형을 이해하기 어렵고,
> 데이터형을 모르면 선언을 이해하기 어렵습니다. 이 둘을 구분하지 않고 섞
> 어 설명한다면 처음 초보자들이 어려움 없이 받아들일 수 있겠지만 언어과
> 프로그램의 구조가 머리속에서 분명히 그려지기는 어렵다고 봅니다.
>
갑자기 hclc 에 종종 올라오는 일례가 생각나서 적습니다. 할 일이 없는 것
도 아닌데 자꾸 글만 올리고 있군요. :)
명칭이 갖는 scope, name space, linkage
대상체가 갖는 stroage duration
튜토리얼의 책은 이 개념을 모두 섞습니다. global 이니 local 이니 하는
용어를 도입하며 전혀 독립적인 개념을 섞어 놓습니다. 이 개념들을 따로
설명하면 학습자에게는 뜬 구름 잡는 이야기처럼 들려 당황스러울 수 있겠
지만 최소한 한번만 익히면 모든 프로그램에 나오는 명칭과 대상체에서 위
의 개념들을 해석해낼 수 있습니다. 하지만, 섞어서 교육한다면, 개념을 따
로 교육하는 것과 동일한 효과를 얻기 위해서는 이런 저런 신기하고 비일관
적인 규칙을 창조해야 하고, 그렇지 않은 경우에는 예제는 이해하지만 실제
프로그램을 이해하거나 작성하지 못하는 현상이 발생합니다.
김승범
>
> 김승범 <musi...@bawi.org>이(가) 아래 메시지를 news:3DD32720...@bawi.org에 게시하였습니다.
> > Jeong Kim wrote:
> [...]
> > > 프로그래밍이란 것이 잘 아시다 시피, 프로그래밍 언어의 지식만 가지고
> > > 할 수 없는 것입니다.
> > > 프로그래밍의 (소프트웨어 개발) 과정을
> > > "주어진 문제를 분석, 정의하고 답을 궁리해서 컴퓨터가 이해할 수 있는 코드를
> > > 작성한다" 라고 한다면,
> > > 처음 배우는 과정에서 가장 착실히 익혀야 할 것이, 문제의 분석, 정의와
> > > 답을 궁리하는 과정까지라고 생각합니다.
> >
> > 정말정말 동의하는 내용입니다.
> > 이런 측면에서 프로그래밍에 접근하는 좋은 책 있으면 소개 좀 해 주세요.
> > (아, 다시 이 글타래의 제목으로 돌아왔습니다. ^^)
> >
>
> 이는 한 프로그래밍 언어에 대한 이야기가 아니라 프로그램의 디자인과 관
> 련된 문제라고 생각합니다. 프로그래밍 언어는 도구입니다. 일단 문제 해결
> 을 위한 방법론이 결정되면 적절한 부분에 적절한 언어를 선택하는 일만 남
> 은 것입니다. 물론 다양한 언어를 알지 못한다면 언어 선택의 폭이 좁아질
> 수 밖에 없습니다. 물론, 이는 지극히 이상적인 이야기입니다. 대부분의 경
> 우 현실은 2-3개 언어 중 하나를 선택하도록 요구하고 있습니다.
제 생각과 그리 다르지 않은 말씀을 하고 계신데, 혹시 제 앞 글이
전달이 잘 되지 않은 것이 아닌지 모르겠네요.
제가 저 이야기를 한 것은, 주위에서 '언어는 알지만 프로그래밍은 모르는'
답답한 경우를 너무도 많이 보아왔기 때문입니다. 많은 이들이 도구는 잔뜩
가지고 있고 그 사용법을 애써 익혔는데, 정작 주어진 문제를 해결하기 위해
그 도구들을 어떻게 부려야 하는지 알지 못하는 꼴이라고 할까요?
프로그래밍 책에 나와 있는 예제들을 풀지 못할 때 대부분의 경우는 언어의
구체적인 측면을 이해하지 못해서가 아니라 전체적으로 어떻게 일을 시키면
된다는 개념이 서지 않아서인 것 같더라구요. 저는 그런 경우에 가상 코드
(pseudocode)로라도 프로그램을 적어 보라고도 합니다만..
그리고 시중에 언어, 문법을 가르치는 책은 많지만 일반적인 프로그래밍을
가르치는 책을 별로 보지 못했다는 것도 그 이유 중 하나이고요.
>
> > > 그리고 전적으로 사견입니다만, 일단 직업 프로그래머가 된다면 좋던 싫던
> > > 간에 C, C++ 또는 자바와 접하게 되는 것이 지금의 현실입니다.
> > > 처음부터 C, C++를 익혀서 계속 이들 언어에만 갖혀(?) 있는 것 보다는
> > > 새로운 패러다임을 가진 언어들을 (lisp이나 ML 같은) 처음 학습할 때
> > > 다루어 보는 것도 좋다고 생각합니다.
> >
> > 이도 일리 있는 것 같습니다.
> > 저도 지금껏 lisp이나 ML 같은 언어를 접해 볼 기회가 없어서
> > 그런 것들은 모르고 삽니다. --;
> >
>
> 그런 것들을 모르고 살아도 지금 현재의 컴퓨팅 산업에 일조를 할 수 있기
> 때문입니다. 다양한 패러다임의 많은 언어를 다룰 줄 아는 것은 사고의 폭
> 을 넓히고 문제 해결 방법에 대한 다양성을 부여해주지만, 현실을 그렇게
> 여유롭지 않습니다. "팀장님, 이 소팅 부분은 LISP 으로 처리하면 간단할
> 것 같은데요?" "컴파일러는 니가 만들래?" 이게 현실입니다. :(
그러니까 더욱 더, 처음 학습 단계에서 다른 패러다임의 언어를 접해볼
수 있다는 것이 의미를 가지는 것 아닐까요? 누구도 현업에서 LISP 등을
써야 한다고 말하지는 않았습니다.
> >
> > 아마도 초보자들이 언어의 어려운 기능에 주눅들고 좌절하는 것은
> > 많은 언어 학습서들이 학습자의 진도에 맞게 단계적으로 설명하기보다는
> > 기능별로 묶어서 설명을 하려 하기 때문이 아닐까 생각해 봅니다.
> > "자, 이번 단원은 포인터다. 여기서 포인터를 마스터하고 넘어간다!"
> > 이런 식 아닌가요? 여러 가지를 조금씩 배워야 할 텐데 말이지요.
> >
>
> 이 부분에 있어서는 저는 좀 다른 의견을 갖습니다. *물론 학습자의 수준을
> 고려한 튜토리얼 방식의 책이 중요하다는 사실에는 동의합니다* 하지만, 튜
> 토리얼은 한권으로 충분합니다. 터보 C 정복이나 K&R2 등은 모두 튜토리얼
> 방식을 택하고 있습니다 - 제가 본 튜토리얼 책은 이게 전부입니다, 그 이
> 후부터는 논문이나 레퍼런스 스타일의 책만을 보았습니다. 이 책을 모두 읽
> 고 나면 학습자의 수준을 고려한 점차적인 난이도로 큰 어려움 없이(?) 언
> 어를 마칠 수 있다고 생각합니다. 이제 문제는 언어의 체계가 보이지 않는
> 다는 것입니다. 조금만 난이도 있는 C 프로그램을 만나면 금방 진땀을 삐질
> 삐질 흘리다가 손을 놓아 버리고는 합니다. C 는 유독 각 부분이 연결되어
> 있는 언어입니다. 예를 들면, 선언을 모르면 데이터형을 이해하기 어렵고,
> 데이터형을 모르면 선언을 이해하기 어렵습니다. 이 둘을 구분하지 않고 섞
> 어 설명한다면 처음 초보자들이 어려움 없이 받아들일 수 있겠지만 언어과
> 프로그램의 구조가 머리속에서 분명히 그려지기는 어렵다고 봅니다.
그럴 수도 있겠군요.
하지만 저는 이 글타래에서 계속 언급되었던 것처럼 초보자의 입장에서
말씀드린 것입니다. 초보자에게는 그런 튜토리얼이 필요하다는 것이지요.
여담으로, 제가 '초보자의 입장에서'라는 표현을 지금 막 쓰기는 했지만,
정말로 초보자의 입장을 이해하기가 참 어렵다는 것을 느낍니다. 이미 시간이
꽤 지난 초보 시절에 제가 어떤 어려움을 겪었는지 기억도 잘 나지 않으니
말이지요. 아마도 당장 뭘 해야 한다는 절박함보다도 취미로 슬슬 공부를
해서(그래서 남들보다는 오래 걸려 배운 듯하고요)인지도 모르겠습니다만..
>
> K&R2 서문에는 BWK 인지 DMR 인지 모르겠지만, "C 언어는 큰 언어가 아니기
> 에 큰 책으로 제공될 필요가 없다" 라는 말이 있습니다. 많은 사람들이 그
> 말에 고개를 끄덕이며 "일리가 있어, 두꺼운 책들은 다 바보야" 라고 생각
> 합니다. 누가 진짜 바보인지 모르겠더군요. (부록을 제외한) K&R2 만을 읽
> 고 C 언어를 얼마나 이해할 수 있다고 생각하는지 모르겠습니다. 누군가가
> 이야기하더군요 - 그 말에 고개를 끄덕이는 사람들은 진정 K&R2 만 보고 C
> 언어를 완전히 이해하고 있느냐고? 정작 레퍼런스 스타일의 많은 책을 본
> 사람들이 K&R2 의 저 문장에 동의하고 있습니다 - 아이러니합니다. 그리고
> 초보자들은 K&R2 를 다 읽고도 (실제 학교 수업에 가장 많이 사용되는 교재
> 라 생각합니다) 대체 뭐가 뭔지 모르겠다고 이야기하고 있습니다.
원래 뭐든지 한번 깨우치고 나면 진리는 단순한 것 아니겠습니까? ;-)
아는 사람에게는 그 자체로 완전하게 보이는 교과서가 다른 많은
사람들에게는 충분치 않고 훨씬 더 두꺼운 참고서가 필요한 것과 비슷하죠.
--
김승범
김승범
>
> 갑자기 hclc 에 종종 올라오는 일례가 생각나서 적습니다. 할 일이 없는 것
> 도 아닌데 자꾸 글만 올리고 있군요. :)
>
> 명칭이 갖는 scope, name space, linkage
> 대상체가 갖는 stroage duration
:-)
>
> 튜토리얼의 책은 이 개념을 모두 섞습니다. global 이니 local 이니 하는
> 용어를 도입하며 전혀 독립적인 개념을 섞어 놓습니다.
튜토리얼이라고 해서 꼭 그래야 한다고는 생각하지 않습니다.
(반대로 튜토리얼 아닌 책들도 철저히 표준의 장절에 의한 것이 아니라면
얼마든지 이렇게 왜곡시킬 가능성이 있다고 보고요.)
물론 위의 개념들이 초보자가 익히기에 만만한 개념은 아닌 것은 압니다만,
꼭 그렇게 왜곡시키지도, 또 그렇다고 처음부터 질리게 만들지도 않으면서
올바른 내용을 차근차근 전달할 수 있는 방법이 있을 것이라 믿어 봅니다.
'구체적으로 어떻게?'라는 질문에 대해서는 답하기가 좀 어렵군요. -_-;;
> 이 개념들을 따로
> 설명하면 학습자에게는 뜬 구름 잡는 이야기처럼 들려 당황스러울 수 있겠
> 지만 최소한 한번만 익히면 모든 프로그램에 나오는 명칭과 대상체에서 위
> 의 개념들을 해석해낼 수 있습니다. 하지만, 섞어서 교육한다면, 개념을 따
> 로 교육하는 것과 동일한 효과를 얻기 위해서는 이런 저런 신기하고 비일관
> 적인 규칙을 창조해야 하고, 그렇지 않은 경우에는 예제는 이해하지만 실제
> 프로그램을 이해하거나 작성하지 못하는 현상이 발생합니다.
그렇습니다.
--
김승범
parkkh
int (*devilson(int (*grandson[5])(int *px)))(int *px);
이거 어떻게 해석해야 하나요?
해석하는 순서좀 알려주세요..
전 아직도 함수 포인터 같은건, 컴파일러가 문법 체크를 해줘야
긴가 민가 하면서 쓰는 포인터 맹이라서요..
아마도 c 를 배울때 첫단추를 잘못낀것이 아닌가 가끔 생각합니다.
Jun Woong
> Jun Woong wrote:
> >
> > 김승범 <musi...@bawi.org>이(가) 아래 메시지를 news:3DD32720...@bawi.org에 게시하였습니다.
> > > Jeong Kim wrote:
> > [...]
> > > > 프로그래밍이란 것이 잘 아시다 시피, 프로그래밍 언어의 지식만 가지고
> > > > 할 수 없는 것입니다.
> > > > 프로그래밍의 (소프트웨어 개발) 과정을
> > > > "주어진 문제를 분석, 정의하고 답을 궁리해서 컴퓨터가 이해할 수 있는 코드를
> > > > 작성한다" 라고 한다면,
> > > > 처음 배우는 과정에서 가장 착실히 익혀야 할 것이, 문제의 분석, 정의와
> > > > 답을 궁리하는 과정까지라고 생각합니다.
> > >
> > > 정말정말 동의하는 내용입니다.
> > > 이런 측면에서 프로그래밍에 접근하는 좋은 책 있으면 소개 좀 해 주세요.
> > > (아, 다시 이 글타래의 제목으로 돌아왔습니다. ^^)
> > >
> >
> > 이는 한 프로그래밍 언어에 대한 이야기가 아니라 프로그램의 디자인과 관
> > 련된 문제라고 생각합니다. 프로그래밍 언어는 도구입니다. 일단 문제 해결
> > 을 위한 방법론이 결정되면 적절한 부분에 적절한 언어를 선택하는 일만 남
> > 은 것입니다. 물론 다양한 언어를 알지 못한다면 언어 선택의 폭이 좁아질
> > 수 밖에 없습니다. 물론, 이는 지극히 이상적인 이야기입니다. 대부분의 경
> > 우 현실은 2-3개 언어 중 하나를 선택하도록 요구하고 있습니다.
>
> 제 생각과 그리 다르지 않은 말씀을 하고 계신데, 혹시 제 앞 글이
> 전달이 잘 되지 않은 것이 아닌지 모르겠네요.
>
같은 이야깁니다.. 적어 놓고 보니 같은 이야기군요. :)
> 제가 저 이야기를 한 것은, 주위에서 '언어는 알지만 프로그래밍은 모르는'
> 답답한 경우를 너무도 많이 보아왔기 때문입니다. 많은 이들이 도구는 잔뜩
> 가지고 있고 그 사용법을 애써 익혔는데, 정작 주어진 문제를 해결하기 위해
> 그 도구들을 어떻게 부려야 하는지 알지 못하는 꼴이라고 할까요?
> 프로그래밍 책에 나와 있는 예제들을 풀지 못할 때 대부분의 경우는 언어의
> 구체적인 측면을 이해하지 못해서가 아니라 전체적으로 어떻게 일을 시키면
> 된다는 개념이 서지 않아서인 것 같더라구요. 저는 그런 경우에 가상 코드
> (pseudocode)로라도 프로그램을 적어 보라고도 합니다만..
>
> 그리고 시중에 언어, 문법을 가르치는 책은 많지만 일반적인 프로그래밍을
> 가르치는 책을 별로 보지 못했다는 것도 그 이유 중 하나이고요.
>
음.. 솔직히 C 언어가 갖는 패러다임이 더 이상 사람들에게 신선함으로 다
가가지 못하는 것이 가장 큰 원인이 아닐까 생각합니다 - 아직도 신선함으
로 다가가길 바란다면 너무 욕심이 심한 거겠죠? :) 주어진 문제를 절차식
패러다임으로 해결하는 것을 더이상 "최신이다" 내지는 "시대를 따른다" 라
고 표현하는 사람은 없습니다. 일부 C 언어 원서를 보면 문제 해결 중심이
다 뭐시기다 해서 시도는 하지만, 결국 C 언어 설명과 프로그래밍 스타일에
공을 들이다 보면 일반 C 언어 서적이 되어 버립니다.
프로그래밍 디자인에 대한 서적들 (주로 원서들입니다) 이 있기는 하지만,
주로 객체 지향 개념이나 종종 generic programming 을 기반에 두고 있기
때문에 C 로 끌어다 쓰기에 어려운 점이 있습니다. 저도 개인적으로는 C 로
도 디자인만 잘 하면 OOP 의 90% 를 따라갈 수 있다고 주장은 하지만, 실제
OOP 를 개념적으로 완전히 파악하고 있지 않는 이상은 쉽지 않은 일입니다.
김승범님은 C++ 에도 친숙하신 듯 하니, 디자인 패턴이나 안티 디자인 패턴
분야를 다루는 책들이 도움이 되리라 생각합니다.
Jeong Kim
>
> 프로그래밍 디자인에 대한 서적들 (주로 원서들입니다) 이 있기는 하지만,
> 주로 객체 지향 개념이나 종종 generic programming 을 기반에 두고 있기
> 때문에 C 로 끌어다 쓰기에 어려운 점이 있습니다. 저도 개인적으로는 C 로
> 도 디자인만 잘 하면 OOP 의 90% 를 따라갈 수 있다고 주장은 하지만, 실제
> OOP 를 개념적으로 완전히 파악하고 있지 않는 이상은 쉽지 않은 일입니다.
>
아마도 C로 OOP의 90%를 따라갈 수 있다는 주장은 저도 동의 합니다.
GhostScript 코드를 보시면 근거가 될 것 같네요.
코드 스타일에 대한 많은 비판이 있긴 하지만, C로 OOP의 개념들을
잘 구현하고 있습니다.
아래에서 코드를 받아 보실 수 있습니다.
http://sourceforge.net/projects/ghostscript
하지만 문법이 만들어 질 때부터 OOP를 고려한 PL들에 비해 어색할 수
밖에 없겠지요.
Jeong Kim
> Jeong Kim wrote:
>
> > 프로그래밍이란 것이 잘 아시다 시피, 프로그래밍 언어의 지식만 가지고
> > 할 수 없는 것입니다.
> > 프로그래밍의 (소프트웨어 개발) 과정을
> > "주어진 문제를 분석, 정의하고 답을 궁리해서 컴퓨터가 이해할 수 있는
코드를
> > 작성한다" 라고 한다면,
> > 처음 배우는 과정에서 가장 착실히 익혀야 할 것이, 문제의 분석, 정의와
> > 답을 궁리하는 과정까지라고 생각합니다.
>
> 정말정말 동의하는 내용입니다.
> 이런 측면에서 프로그래밍에 접근하는 좋은 책 있으면 소개 좀 해 주세요.
> (아, 다시 이 글타래의 제목으로 돌아왔습니다. ^^)
저도 그런 책이 나오면 좋겠다는 생각은 많이 해 봤지만, 아직은 못본 것
같습니다. 어쩌면 제가 필요가 없어서 안 보였을지도 모르겠네요.
많은 초보자들이 "프로그래밍을 배운다 = 프로그래밍 언어를 배운다"로
알고 있는 상태에서 저런 책이 나와도 잘 안팔릴 수도 있겠네요.
Genie님이 다른 기사에서 말씀하셨듯이, 초보자들은 대부분 화면에 뭔가
나오거나 소리가 나는 것부터 당장 해 보고 싶어하더군요.
저도 그랬던 것 같습니다. :)
일전에 프로그래밍을 막 배우려는 사람에게, ActiveX 콘트롤을 이용하여
MP3 플레이어를 5분만에 만드는 것을 보여줬더니 매우 좋아하더군요.
일단은 위에서 언급한 등식이 참이 아니라는 사실부터 널리 받아들여 져야
할 것 같습니다.
저는 전산을 전공했습니다만은, 알고리즘 숙제를 잘 하고, 이산 구조 문제를
잘 푸는 친구 보다는, OpenGL을 이용해 멋진 그래픽 프로그램을 만들 수
있는 친구를 더 인정해주는 분위기 였던 것 같습니다. -_-;;;
> 이도 일리 있는 것 같습니다.
> 저도 지금껏 lisp이나 ML 같은 언어를 접해 볼 기회가 없어서
> 그런 것들은 모르고 삽니다. --;
저 역시 늦게 접했습니다.
하지만 C, C++ 프로그래밍을 하면서도 이러한 언어를 배우면서
익혔던 개념들이 도움이 되기도 하더군요.
> 하지만 어떤 언어든 깊이 파고 들어가면 까다로운 점은 나오기 마련이라고
> 생각합니다. 그리고 어떤 언어를 사용하기 위해 꼭 그 언어의 모든 면을
> 그렇게 깊이 알아야 하는 것도 아니고요.
저 역시 절대 동감합니다.
> 초보자가 굳이 short, int, long, unsigned 등의 여러 가지를 고려해야
> 한다고 가르치는 곳이 있나요? 초보자에게는, 그리고 중급 이상의 실력과
> 경험을 가진 사람에게도 대부분의 경우에는, 정수형은 int로 충분합니다.
> 게다가 예전 16비트 시절과는 달리 요즘은 그냥 int라고만 해도 4바이트
> 씩이나 할당해 줘서 모자랄 일이 없으니 얼마나 좋습니까? :-)
>
> 언어가 제공하는 모든 기능을 초보자가 알아야 할 필요는 없죠.
사실 말씀하신데로입니다.
저는 제가 예전에 C를 배울때 스토리지 클래스에 대해 공부하면서 혼란을
느꼈던 기억이 있어서 말씀드렸습니다.
> > 그리고, 간단한 자료 구조 하나를 만들더라도 C, C++의 경우는 꽤 복잡한
코드가
> > 나옵니다. 이러한 경험도 C, C++가 복잡한 언어라는 예가 되리라 생각합니다.
>
> 제가 아는 절차형 언어들에서의 자료 구조 정의는 다 비슷비슷했는데,
> 함수형 언어에서는 사정이 많이 다른가요? 제가 그쪽은 잘 몰라서..
함수형 언어들은 많은 경우 정의가 더 쉽습니다.
역시 강력한 타입 시스템 때문입니다만, 새로운 타입을 만드는 일이 매우
자연스럽고, 또 우리가 중, 고등학교에서 배웠던 수학적 개념들과
거의 1:1 매핑이 되거든요.
> 반복되는 이야기이지만, 초보자가 어려운 코드에 주눅이 들 필요는 없죠.
> 저도 int (*devilson(int (*grandson[5])(int *px)))(int *px); 같은 선언
> 보면 무지 헷갈리고 한참 생각해야 됩니다. 하지만 평생에 한번 쓸까말까한
> 이런 것에 주눅들고 C/C++를 포기하지는 않습니다. :-)
정말 어렵네요.
역시 맞는 말씀입니다. 제가 말씀 드리고 싶은 것은 비교적 최신 기술을
가진 언어들에서는 저런 표현을 만들기가 C/C++보다 쉽지 않거든요.
어찌 보면 자유를 덜 주고, 안전성을 추구한다고 할 수도 있겠네요.
김승범
>
> int (*devilson(int (*grandson[5])(int *px)))(int *px);
>
> 이거 어떻게 해석해야 하나요?
>
> 해석하는 순서좀 알려주세요..
기본적인 원칙은 안에서 밖으로(inside-out) 읽는다는 것입니다.
단 이는 영어로 읽을 때의 규칙인데, 처음에는 조금 덜 익숙하더라도
복잡한 선언은 영어로 읽는 것이 덜 헷갈리는 것 같습니다.
(제가 그쪽에만 익숙해 있어서 그런 것인지도 모르겠습니다만.)
영어라고 해봤자 pointer to, array of, function taking ... returning ...
정도만 있으면 되니까 너무 걱정하실 필요는 없습니다.
*a a is pointer to ...
a[n] a is array[n] of ...
... a(...) a is function taking (...) returning ...
그리고 *a[], *a() 와 같은 꼴이 나올 때는 a가 오른쪽의 [], ()와
먼저 결합합니다. 즉 *a[]는 a는 array of pointer to ...가 됩니다.
좀 더 쉬운 것부터 해 보죠.
------------------------------------------------------------------------
int (*grandson[3])(int *px);
------------------------------------------------------------------------
grandson은..
오른쪽에 [3]이 있으니 "array[3] of "
왼쪽에 *이 있으니 "pointer to "
int ()(int *px)가 남았으니 "function taking (int *px) returning int"
최종 답은 이를 연결하면 됩니다.
또 다른 연습 문제입니다.
------------------------------------------------------------------------
void (*f(char))(int);
------------------------------------------------------------------------
f는..
오른쪽에 (char)이 있으니 "function taking (char) returning "
[이제 void (*)(int)가 남았습니다]
왼쪽에 *가 있으니 "pointer to "
오른쪽에 (int)가 있으니 "function taking (int) "
왼쪽에 void가 있으니 "returning void"
실제로는 void (*)(int) 같은 것을 한 묶음으로 생각하는 것이 편합니다.
그럼 이제 최종(?) 관문입니다.
------------------------------------------------------------------------
int (*devilson(int (*grandson[5])(int *px)))(int *px);
------------------------------------------------------------------------
devilson은..
오른쪽에 (int (*grandson[5])(int *px)) ☞ "function taking ..."
int (*)(int *px)가 남는다 ☞ "returning ..."
전체적인 구조는 이렇게 둘로 나눌 수 있습니다. 간단하지요?
즉 devilson은 뭘 취하고 뭘 돌려주든지 아무튼 함수라는 걸 알았습니다.
devilson이 취하는 인자는 int (*grandson[5])(int *px) 하나인데, 여기서
grandson은 위에서 해본 것과 같은 꼴이고, devilson이 돌려주는 값은
int (*)(int *px), 즉 "pointer to function taking (int*) returning int"
입니다.
복잡하긴 하지만 차근차근 따져 보면 그리 어렵지만은 않습니다. ^^;;;
참고로, cdecl 같은 프로그램을 쓰면 단번에 알려주기도 합니다.
(제가 줄은 임의로 바꾸었습니다.)
cdecl> explain int (*devilson(int (*[5])(int *)))(int *)
declare devilson as function (
array 5 of pointer to function (pointer to int) returning int
) returning pointer to function (pointer to int) returning int
>
> 전 아직도 함수 포인터 같은건, 컴파일러가 문법 체크를 해줘야
>
> 긴가 민가 하면서 쓰는 포인터 맹이라서요..
>
> 아마도 c 를 배울때 첫단추를 잘못낀것이 아닌가 가끔 생각합니다.
자신을 가지세요. 기본 원리를 깨우치고 나면 별 것 아닙니다.
--
김승범
김승범
>
> 김승범 <musi...@bawi.org>이(가) 아래 메시지를 news:3DD34468...@bawi.org에 게시하였습니다.
> > 제가 저 이야기를 한 것은, 주위에서 '언어는 알지만 프로그래밍은 모르는'
> > 답답한 경우를 너무도 많이 보아왔기 때문입니다. 많은 이들이 도구는 잔뜩
> > 가지고 있고 그 사용법을 애써 익혔는데, 정작 주어진 문제를 해결하기 위해
> > 그 도구들을 어떻게 부려야 하는지 알지 못하는 꼴이라고 할까요?
> > 프로그래밍 책에 나와 있는 예제들을 풀지 못할 때 대부분의 경우는 언어의
> > 구체적인 측면을 이해하지 못해서가 아니라 전체적으로 어떻게 일을 시키면
> > 된다는 개념이 서지 않아서인 것 같더라구요. 저는 그런 경우에 가상 코드
> > (pseudocode)로라도 프로그램을 적어 보라고도 합니다만..
> >
> > 그리고 시중에 언어, 문법을 가르치는 책은 많지만 일반적인 프로그래밍을
> > 가르치는 책을 별로 보지 못했다는 것도 그 이유 중 하나이고요.
> >
>
> 음.. 솔직히 C 언어가 갖는 패러다임이 더 이상 사람들에게 신선함으로 다
> 가가지 못하는 것이 가장 큰 원인이 아닐까 생각합니다 - 아직도 신선함으
> 로 다가가길 바란다면 너무 욕심이 심한 거겠죠? :) 주어진 문제를 절차식
> 패러다임으로 해결하는 것을 더이상 "최신이다" 내지는 "시대를 따른다" 라
> 고 표현하는 사람은 없습니다. 일부 C 언어 원서를 보면 문제 해결 중심이
> 다 뭐시기다 해서 시도는 하지만, 결국 C 언어 설명과 프로그래밍 스타일에
> 공을 들이다 보면 일반 C 언어 서적이 되어 버립니다.
>
> 프로그래밍 디자인에 대한 서적들 (주로 원서들입니다) 이 있기는 하지만,
> 주로 객체 지향 개념이나 종종 generic programming 을 기반에 두고 있기
> 때문에 C 로 끌어다 쓰기에 어려운 점이 있습니다. 저도 개인적으로는 C 로
> 도 디자인만 잘 하면 OOP 의 90% 를 따라갈 수 있다고 주장은 하지만, 실제
> OOP 를 개념적으로 완전히 파악하고 있지 않는 이상은 쉽지 않은 일입니다.
패러다임이니 프로그래밍 디자인이니 하니까 무척 거창해 보이는데,
제가 뜻한 바는 그런 거창한 것이 아닙니다. 아주 단순한 것이지요.
예컨대 닳고 닳았을 '성적 처리 문제' 같은 것 있지 않습니까? 여러 학생의
데이터를 읽어들여 총점, 평균 같은 거 계산해서 출력하는 문제요.
이런 문제 풀이도 어디서 어떻게 시작해야 할지 막막해하는 사람들이
적지 않더라는 것입니다. 입출력이니 구조체니 필요한 언어적 기술은
다 배웠는데 말이죠.
이런 문제는 아무리 언어를 배운다고 해도 해결되는 것이 아니라는
것이지요. 그리고 각각의 언어적 기술도 '어떻게 쓰이는가'와
연계가 되지 않으면 무척 지루하고 어려울 수밖에 없고요.
--
김승범
Jun Woong
그렇게 말씀하시면 오버한 제가 쑥쓰러워지는 상황이... :)
> 예컨대 닳고 닳았을 '성적 처리 문제' 같은 것 있지 않습니까? 여러 학생의
> 데이터를 읽어들여 총점, 평균 같은 거 계산해서 출력하는 문제요.
> 이런 문제 풀이도 어디서 어떻게 시작해야 할지 막막해하는 사람들이
> 적지 않더라는 것입니다. 입출력이니 구조체니 필요한 언어적 기술은
> 다 배웠는데 말이죠.
>
음.. C 언어 책 중에.. "예제로 배우는 C 언어" 던가? 뭐 그런 책이 있습니
다. 성적 처리 같은 간단하지만 충분한 기능을 갖춘 프로그램을 각 장의 주
제로 잡고 그 프로그램을 만드는데 필요한 언어적 기능을 설명하는 방식으
로 진행합니다. C 언어를 교육할 때 좀 다른 방식으로 접근해보고 싶어서
그 책을 선택했었는데 결과에 대해서는 회의적입니다.
책 내용은 차치하고라도, 학습자가 가지는 각기 다른 흥미 (누군가는 MP3
player 를 만들고 싶어하고, 누군가는 3D Game 을 만들고 싶어하며, 누군가
는 알고리즘을 구현하고 싶어하고, 누군가는 작은 네트워크 관련 프로그램
을 만들고 싶어합니다, 심지어는 해킹을 해보고 싶어서 C 를 공부하는 사람
도 있었습니다) 를 만족시켜 주지 못하기 때문에 "따분함" 은 거의 비슷했
던 것 같습니다.
차라리 C 언어를 어느 정도 알고 계신 분들에게 상당히 까다로운 언어적인
문제를 퀴즈 형식으로 던지는 것이 지적 호기심을 자극하는데 더 도움이 되
지 않았나 생각합니다.
> 이런 문제는 아무리 언어를 배운다고 해도 해결되는 것이 아니라는
> 것이지요. 그리고 각각의 언어적 기술도 '어떻게 쓰이는가'와
> 연계가 되지 않으면 무척 지루하고 어려울 수밖에 없고요.
>
동기 부여가 중요하기는 하지만, 너무 강력한 (현란한 소리와 화면 등 가시
적인 효과에 치중한) 동기 부여는 무시 못할 부작용을 낳기도 합니다.
Taik-kyun Lim
> Jeong Kim <jeong@artifex_no_spam.com>이(가) 아래 메시지를 news:aqtnr2$ojs$1...@news.kreonet.re.kr에 게시하였습니다.>> news:3DD260FC...@bawi.org...
>> >
>> > 음.. Perl에는 int/double/string의 구별도 없더군요.. ^^
>>
>> 초보자에게는 특히 구별이 없는게 낫지 않을까요?
>>
>
> typeless language 만 알고 있는 사람들에게 type system 을 갖춘 언어를
> 교육한 경험이 있으신지요? 저라면 type system 에서 typeless 로 넘어가는
> 과정을 택하겠습니다.
>
> int *pi;
> printf("%d\n", pi);
>
> 이렇게 적어놓고, printf() 의 %d 덕분에 pi 가 가리키는 정수형 대상체의
> 값을 올바르게 출력해준다는 주장을 들어야 한다면...
>
음 어떤 말씀이신지 이해를 하지 못하고 있습니다. 좀더 자세히 말씀
하시는 바를 설명해 주세요. :-)
--
임택균 <http://www.mongmong.pe.kr/pgp/repository/mongmong_mongmong.key>
chitos
"Jeong Kim" <jeong@artifex_no_spam.com> wrote in message
news:aqtnr2$ojs$1...@news.kreonet.re.kr...
> "김승범" <musi...@bawi.org> wrote in message
> news:3DD260FC...@bawi.org...
> >
> > 음.. Perl에는 int/double/string의 구별도 없더군요.. ^^
>
> 명시적인 타입이 있는 경우에서 말씀을 드린 것입니다만,
> 초보자에게는 특히 구별이 없는게 낫지 않을까요?
>
> 김정희
> jeong@artifex_no_spam.com
>
>
저는 델파이도 합니다.
초보자에게는 구별이 없는 것이 좋지만 조금 더 들어가서 프로처럼
코딩하려면 오히려 진입장벽이 있더군요.
충분한 설명문서 없이 내부적인 동작이 어떻게 되는지 모르니까.
계속적인 좌충우돌로 찾아 해메게 되더군요!
언어별로 장단점이 있지만 난 지금의 C++에 후한 점수를 주고
십습니다.
chitos
희박하고 생각합니다. 모든 페러다임은 철학적인 기반을 가지는데 이를
명쾌하게 기술한 책이 없어서 우리는 헤메지 않은 가 싶습니다.
보통 거시적으로는 서양의 분석적 사고관과 동양의 분류학적 사고관에서
우리는 분류학적인 사고관에 익숙한데 저들의 책을 분석 쪽이니 접근하기
더욱 어렵다고 봅니다.
어떠한 시스템을 바라 보는 것에는 분석적인 사고방식에선 요소추출이
먼저지만 분류학적 스타일은 기능적인 분류부터 합니다.
그래서 요소를 설명하는 책은 대부분 미국의 책 스타일 하고 비슷하게
적어 놓고 "마음대로 꿈을 펼쳐라"라고 하면서 뒷일은 독자가 알아서 하라
고한다면 우리가 익숙한것은 사용처들의 전체 내용을 알고 그것에 대한
세부항목으로 들어가는 거죠.
그런데 분류학적인 견지는 전체에 대한 아웃라인은 인식하는 것에서 시작
하는데 지금의 따라가기식 책들은 아웃라인을 머리속에 만들기도 전에
상세접근을 하니 어리둥절할 수 밖에요!
그래서 책에는 "이 페러다임은... 이원적인 세계관에 근거하여 어쩌구 저쩌구"
하면서 철학적인 배경이나 특징, 그리고 한계를 먼저 충분히 설명하고
핵심아이템, 전반적인 흐름 등을 먼저 설명하면 다음에 각 섹션은 쉽게
보겠는데 이건 뜬금없이 본론이니까 힘들죠 그래도 원서에서 이러한
기술방법을 채택한 책이 있는데 이들이 다 명서로 인정되지만 우리나라에서
번역서 아닌 자신의 지필로 그렇게 내는 사람이 없더군요.
혹, 그런 책을 내면 수용하기 보다 비판하기 좋아 하는 사람들 때문에
내지 않는 것일 수 도 있겠죠!
다른 말인데요 우리가 알 수 있는 표현을 잘 못한다는 것은 국어교육의 폐단이
아닐까합니다. 제가 열심히 문서화를 해 봤는데 도대체 다시보면 무슨 말인지
모르게 작성 되니 말입니다.
문서화하고 이를 보는 다른이가 한 80%정돈 이해해야 되는데
그렇게 되지 않으니 말입니다. 특히 기술에 관계된 표현기법이나 이해들이
부족합니다. 특히 프로그래머라면 조어법을 잘해야 되는데 이도 정확한
의미를 표현하도록 훈련도 되지 않고요! 대충말하고 손가락으로 가리키면
이해해야 되는 사항이 다반사라고 할 수 있죠!
저도 정확한 표현이 부족합니다만 이를 훈련하거나 가르쳐주는 이가 없으니
항상 코딩하거나 문서작성에서 힘들 뿐입니다.
이거뭐 앞뒤 없이 주저리 주저리 하소연만 하는 군요!
"Jun Woong" <myco...@hanmail.net> wrote in message
news:r%MA9.1451$5o4....@news.hananet.net...