대학 교재 이대로 좋은가?

mastercho의 이미지

제가 이번학기에 프로그래밍 언어론을 배웠습니다

그런데 왜 프로그래밍 언어를 배울까? 라는 생각을 들게 해주었습니다

제가 알기론 분명

요즘의 언어가 어떻게 발전되어 왔는지, 어떻게 발전할것인가를 이해하고

다른 여러 언어들과의 차이와 공통점을 이해 함으로써

언어들의 이해를 돕고자 하는 것이라 볼수 있을것이라 생각하고 있습니다

하지만 제가 본 프로그래밍 언어론책에서는 혼란과 혼돈만 줄뿐

프로그래밍 언어론을 배우는 이유를 전혀 알수가 없었습니다

http://kangcom.com/common/bbs_review/bbs_read.asp?seqid=808&GotoPage=&fst_code=

이것은 제가 강컴에 쓴 서평입니다 길지만 한번 읽어봐 주셨으면 좋겠습니다

도데체 이런책을 쓰는 저자 즉 교수들이 제대로된 프로그래밍 언어 지식을
가지고 있는지에 대해 의구심을 품지 않을수가 없었는데요

책에 대한 변으로 위에 말한 책 저자의 제자로 있었던 강사분들이

이렇게 이야기 하더군요

"원서나 대부분의 언어론 책들이 이런식이어서 이책도 그렇게 구성된거 같다"고
말을 하는것을 봐서
뭐 짜집기를 인정하는듯한 인상이었는데, 어째튼 책들이 다 이렇다면
이따위 프로그래밍 언어론책으로 프로그래밍 언어론을 배울 필요가
없다고 느껴졌습니다

차라리 C언어를 제대로 공부하면 여기서 말하는 내용보다 훨씬 더 많은것을
배울수 있다고 생각이 되거든요

---------------------------------------------------------------
학기 중 강의 시간 내내
이런 생각이 들었습니다 , 현재 쓰여진 프로그래밍 언어론책들은 당장 가져다 쓰레기통에 버려도 될만큼 허접한 내용들이 아닌가 하고요
-------------------------------------------------------------------
---이부분은 삭제 처리하고 읽어주시기 바랍니다 -_-;;;

보다 보다 , 너무 짜증나서 , 이런 생각마저 들더군요
내가 써도 이거보다 명확한 내용을 쓸수 있을거 같다는 생각이 들어버리는겁니다

어떤가요?
이대로 대학교재 괜찬은지요?

모 출판사관계자님에게 비밀리에 들은 이야기지만
대학 교재로 채택될때 , 책의 질로 평가하는게 아니라
교수들에게 연구비 명목으로 뒷돈에 의해 교재로 채택되는 경우가
태반이라고 합니다, 뒷돈을 주면서까지 교재로 채택되기는 싫다고

교재로 선정되기를 포기했다는 출판사 관계자님 말씀을 들으니
매우 씁슬하더군요

그것도 IT에서 일하는분이라면 누구나 아는 나름대로 유명한 출판사인데
그분입에서 그런 말을 들으니... 이대로 괜찬은지 , 안타깝습니다

여러분들의 생각은 어떠신지 듣고 싶네요

sangwoo의 이미지

책을 읽어보지 않은 저로서는 그 책 내용에 대한 의견은 언급할 수 없습니다만..
너무 일반론으로 말씀하신 게 아닐까요? 교과서의 문제점 비판은 그 교과서와,
저자에 한정되어야 옳지 않느냐는 생각입니다. 분명히 훌륭하고, 올바른
내용을 담고 있는 프로그래밍 언어론 교재도 있을 것이라고 생각하기 때문입니다.

----
Let's shut up and code.

mastercho의 이미지

sangwoo wrote:
책을 읽어보지 않은 저로서는 그 책 내용에 대한 의견은 언급할 수 없습니다만..
너무 일반론으로 말씀하신 게 아닐까요? 교과서의 문제점 비판은 그 교과서와,
저자에 한정되어야 옳지 않느냐는 생각입니다. 분명히 훌륭하고, 올바른
내용을 담고 있는 프로그래밍 언어론 교재도 있을 것이라고 생각하기 때문입니다.

저도 본적이 없는책의 내용을 가지고 싸잡아 모두 비난하는거 같아서
약간 찜찜하긴 했습니다

일단 저 책 하나로 한정 지어서 이야기가 나왔으면 좋겠습니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

juneaftn의 이미지

Programming Language Pragmatics by Michael Scott

2000년도에 이 책이 처음 나왔을 때 바로 구입을 했습니다. 상당히 탁월한 책입니다. 유명해져서 지금은 외국 유명대학에서 교재로 많이 사용하고 있는 것 같습니다.

일독을 권합니다. 프로그래밍 언어론 교재에 대한 편견을 일소해 줄 것입니다.

fibonacci의 이미지

저는 PL을 잘 배워서(운이 좋아 꽤 능력있는 분에게서 배웠습니다. 이분 몇년 강의하시다가 우리나라 대학이 싫어서 다시 미국으로 가셨죠 -_-; 이름은 거론하지 않겠습니다) PL과목 자체에 대한 불만은 없습니다. 제가 알고 있는 PL과목은 "언어를 초월한 프로그래밍의 센스를 배우는 과목" 입니다.

선생님도 좋았지만, 교재도 너무나 마음에 들어서 긴 얘기는 안하고 교재 소개만 합니다. 1996년도에 들었던 교재입니다. Scheme이라는 언어로만 진행되는 책입니다. 저는 아는게 C밖에 없었던지라 이게 무슨 소용이 있을까 회의적이었지만, 한학기를 Scheme과 지내보고 저의 코드가 얼마나 논리적, 체계적으로 바뀌었나 실감했습니다.

Structure and Interpretation of Computer Programs, Harold Abelson and Gerald Jay Sussman, MIT PRESS

http://mitpress.mit.edu/catalog/item/default.asp?sid=C3D9A91C-D94D-4720-88F9-F7C32A175354&ttype=2&tid=4412

No Pain, No Gain.

fibonacci의 이미지

mastercho wrote:

모 출판사관계자님에게 비밀리에 들은 이야기지만
대학 교재로 채택될때 , 책의 질로 평가하는게 아니라
교수들에게 연구비 명목으로 뒷돈에 의해 교재로 채택되는 경우가
태반이라고 합니다, 뒷돈을 주면서까지 교재로 채택되기는 싫다고

교재로 선정되기를 포기했다는 출판사 관계자님 말씀을 들으니
매우 씁슬하더군요

우리 학교에서도 모 선생님이 자기 교재를 강매하고, 그 교재 없으면 수업도 못듣게 했다는 그런 말이 있던 선생님이 있습니다. 어디 학교에나 그런 선생님은 다 있는가봅니다. -_-; 보통 교수님들이 책을 쓰는 경우, "출판물에 의하여 연구업적을 늘리기 위한" 경우가 상당히 많아서, 만만한 원서 대강 번역하는 경우가 태반입니다. 그나마 대학원생들에게 번역을 시키는 경우도 많답니다. -_-; 왠만하면 원서를 사보시기를..

No Pain, No Gain.

Viz의 이미지

저번에 한번 언급했지만, 자신이 교재로 쓰이는 책을 번역했지만-그래서 그책을 구입하면 그 교수님에게 돈이 돌아가지만- 자네들의 실력을 위해서 되도록이면 원서를 구입하라고 하시는 교수님도 있습니다. :)

모든 학교 교재가 그런 문제점을 가지고 있다고 생각하지는 않습니다. 몇몇 못된 교수님들의 모습이 너무 일반화되는 것은 아닌가 걱정을 해 봅니다.

ps. 위에서 언급한 책이 공룡책이랍니다~

ps2. 교재로 쓰인 국내서 중 쓰레기다... 할만한 것이 있긴 하군요. 전공은 아니였지만 산업공학개론 책이 그랬답니다. :( 책을 산다음에 그 책을 쓴 교수를 찾아가 돈 물어내라고 할지 심히 고심했다는... :)

My Passion for the Vision!

envia의 이미지

대학 교재 중에서 좋은 책도 있고, 나쁜 책도 있겠지요. 안좋은 책은 교재로 안쓰면 되는 건데, 누구의 저서라는 이유로 자격 미달의 책들이 교재로 쓰이는 것이 문제라고 생각합니다.

몇몇 교수분들이 외국 교재를 짜집기해서 만든 책 중에 나쁜 책들이 꽤 있는 것 같은데, 잘 모르시는 분들이 짜집기 할 경우 그런 일이 생기는 것 같더라고요. (교수분들도 자기 연구 분야가 아니면 잘 모를 수도 있습니다.)

Open Textbook Project 같은 것도 있으면 괜찮겠다는 생각이 드네요. 여러 사람의 시각에서 접근하면 더 좋은 책이 나올 것 같습니다. :D

덧붙여서... fibonacci님이 말씀하신 SICP는 상당히 재미있는 책입니다. PL과는 약간 거리가 있을지도 모르겠지만, 프로그래밍을 보는 새로운 눈을 주는 것 같습니다. 저도 강추! 8)

인터넷을 통해 무료로 볼 수도 있습니다. ^^ http://mitpress.mit.edu/sicp/

----

It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]

cjh의 이미지

PL교재라는 것이 현대 언어로만 설명되어 있지 않습니다. 그 책이 번역본인지 저서인지는 모르겠습니다만, 아마 책 지은 분도 기존의 PL교재(원서들)을 많이 참고했을 것이라 여겨집니다.

언뜻 필요없거나 들어본적도 없는 고대 언어(e.g. ADA, PL/I, SNOBOL, ALGOL...)에 대해서 배우는 것은 제 생각에는 그만한 가치가 있다고 봅니다. 현대적 언어의 특징이나 상세한 점에 대해서 파고드는 것도 좋겠지만 PL의 역사와 각 언어의 특징(그것이 지금 관점에서 보면 어처구니없는 - SNOBOL에 대해 처음 봤을 때 그런 생각을 했지만)에 대해서 통시적으로 살펴보는 것도 나쁘지는 않다고 생각합니다. 결국 그런 고대 언어의 흥망 속에서 현재의 언어들이 구성된 것이니까요. 솔직히 PL수업때 그런거 들어보지 않으면 전혀 알 수 없는 사실도 많이 있습니다. 컴파일러가 애초부터 없는 언어들도 많이 있었을 것이고, 그런 것을 모두 풀어서 보여주기란 어렵습니다.

아마 C/C++로 현업 프로그래밍을 하셨다면 교단에서 책을 쓰는 저자보다 더 C/C++에 대해서 잘 알 가능성이 높습니다! 그런것이 학문을 하는 사람과 엔지니어링을 하는 사람의 차이가 아닐까요. 가령 큐의 인터페이스 이야기를 하셨는데 그런 류의 자료구조(stack, queue)등에 put/get등의 공통 인터페이스를 붙이든 아니면 addq, deleteq식으로 별도로 이름을 붙이든 하는 것은 저자와 님의 관점 차이이지 그건 비난받을 일이 아닙니다.

아마 저도 유닉스 기초 수업을 처음 듣는데 지금은 쓰지도 않는 UNIX v7이나 SunOS 4 이야기같은 거 하면서 요즘의 Linux/BSD에 대해 거의 다루지 않는다면 아마 강사 때려주고 싶을 겁니다. :) 하지만 수업이라는 것이 학원은 아니니까요...

--
익스펙토 페트로눔

mastercho의 이미지

cjh wrote:
언뜻 필요없거나 들어본적도 없는 고대 언어(e.g. ADA, PL/I, SNOBOL, ALGOL...)에 대해서 배우는 것은 제 생각에는 그만한 가치가 있다고 봅니다. 현대적 언어의 특징이나 상세한 점에 대해서 파고드는 것도 좋겠지만 PL의 역사와 각 언어의 특징(그것이 지금 관점에서 보면 어처구니없는 - SNOBOL에 대해 처음 봤을 때 그런 생각을 했지만)에 대해서 통시적으로 살펴보는 것도 나쁘지는 않다고 생각합니다. 결국 그런 고대 언어의 흥망 속에서 현재의 언어들이 구성된 것이니까요. 솔직히 PL수업때 그런거 들어보지 않으면 전혀 알 수 없는 사실도 많이 있습니다. 컴파일러가 애초부터 없는 언어들도 많이 있었을 것이고, 그런 것을 모두 풀어서 보여주기란 어렵습니다.

물론 역사적인 관점에서 의미가 있다고 볼수 있습니다
일단 도퇴가 되었다는것은 그만큼 언어가 쓰이지 않았다는것이고
쓰이지 않았다는것은 단점이 컷다고 볼수 있는것입니다

이런점에서 옛것을 알고 새로운것을 안다면 좋은 일이지만

옛것을 역사적인 관점에서만 알고 그거에서 그친다면
현대적인 언어을 이해하는데 도움을 주지 못하고
프로그래밍언어 역사를 배우는거 가치이상을 배울수 없다고 봅니다
단지 여러 프로그래밍 언어 코드를 늘어놓은다고 옛것을 제대로
배울수 있는것은 아니죠
[대부분 표준조차 찾을수 없고 어떻게 정의 되어 있는지 그 시대에
살아서 써본사람이나 겨우 알수 있다면, 그 정확하지 않은 프로그래밍언어로 왈가 불가 하는건 별 의미가 없어 보입니다]

역사를 배우는 이유가 역사에서 배울수 있는게 있었기때문에
배우는것이라 본다면 , 이건 아니라고 봅니다

애니악 컴퓨터라든지 고전적인 8비트 컴퓨터 기본적인 개념을 배우는것이
컴퓨터 역사를 배우것 이상의 가치를 가지기 힘든거와 마찬가지지요

한마디로 말하면 전공이 아니라 교양이라 말할수 있겠네요
[교양을 3학년 과목으로 배우기에는 좀 과한게 아닐까요?]

만약 8비트 컴퓨터가 현재의 컴퓨터의 기본적인 구조와 같다는 식으로
말하면 오류가 될수 있는게 아닐런지요?

저는 그런 관점에서 말하고 있는것입니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

vacancy의 이미지

아마 예전에 대학에 너무 실습이 없다고 글을 쓰셨던 분이 아니신가
얼핏 기억을 떠올려봅니다. -_-a

저같은 경우는 Ravi Sethi의 Programming Language를 교재로
Programming Language 강의를 들었고요.
과제는 C/C++, Java, Prolog, Scheme 등으로 코딩했던것 같네요.
( 더 있었던가 -_-a 기억이 잘 안나네요. 수업시간엔 ML, Ada 등등도 다루긴 했습니다만. )

여튼 저도 책이 나쁜 것보다, 교재 선정에 문제가 있는 것 같습니다.
자기 책 나쁘게 쓰는거야 뭐 할수 없죠.
( 명저를 이상하게 번역하는 건 정말 나쁘다고 생각합니다만. -_- )
하지만 그런 책은 팔아주지 말아야하는건데, -_-a
강좌가 여럿 개설되었을텐데 좋은 교수님을 고르셨더라면 좋았을것같네요.
( 근데 원서로 강의하는 분들이 많지 않나요 ? -_-a )

저도 fibonacci님과 같이 PL 강의는
언어 자체보다는 '아 이런 방식의 구현 가능하구나' 하는
센스를 만들어주는 강의라는 생각이 드네요.
그래서 다양한 Language들을 접해보고 다뤄보는 것 자체가
큰 도움이 된다고 생각합니다.
( 특히 저도 Scheme같은 Functional Language는 한번쯤 배워둘 가치가 있는것 같더군요. )

그나저나 서평에 대해 좀 궁금한게 있는데요.

Quote:
[의심이 나시는분은 count++ = 값; 을 해보시면 count의 ++가 임시값을 리턴한다는것을 확인할수 있습니다]

count++ 는 lvalue가 아니니 count++ = value; 는 틀린 문장같은데
컴파일이 되나요 ? 안될것같은데 신기하네요. -_-a

그리고 '직교성을 가진'이라는 말은 언뜻 떠올리기에 orthogonal 같습니다.
( 워낙 여기저기 많이 쓰이는 단어이니 -_-; 흐, 아니면 말고요. )
orthogonal 이 거기에서 어떻게 쓰인 건지는 잘 모르겠네요.

에, 파스칼에서 첨자의 집합으로 열거형을 쓸수 있다는 걸
굳이 언급하고 있는 이유는, ( 제 생각입니다만. )
C언어에 비해 정수형과 열거형이 상대적으로 엄격히 분리된편이라서같네요.
선언 자체도 아마

Var I : Array [ EStart .. EEnd ] of Integer;

.. 처럼 열거형을 넣어서 할 것 같은데요.
( 파스칼을 하도 예전에 써서 맞게 쓴건지 잘 -_-a )
C에선 '정수=열거형'으로 단정지어 생각하지만, 파스칼에선 그게 아니었던것 같아서요.
( C++이 C와 Pascal 사이쯤으로 엄격할것같네요. Casting이 필요하니까요. )

그리고 함수 내의 함수의 경우는, 현재까지도 쓰이고 있고
제 생각엔 상당히 바람직하다고 생각하는데요.
C였나 C++의 GCC Extension에서도 쓰이고 있고,
Object Pascal 기반인 Delphi에서도 쓰이고 있죠.
함수 내의 함수는 주어진 함수 내에서만 valid 하기 때문에,
달랑 한 함수에서만 사용될 함수의 scope를 넓게주는것보다는
더 구조적이고 깔끔하게 프로그래밍하는데 도움이 된다고 생각합니다.
( 블럭개념으로 사용되는게 아니라 scope만 다를 뿐 실제 함수로 처리됩니다. )
그 책에 나와있는 방식이 뭔진 잘 모르겠지만요. -_-a

그리고 Queue의 in/out method를 표현하는 단어는 많습니다.
사실 가장 적절하다고 생각하는건 enqueue/dequeue 같네요.
하지만 put/get이나 add/delete 모두 괜찮다고 생각합니다.
queue 밖에서 보면 넣고 빼는것이지만,
queue입장에선 데이터가 더해지고 데이터가 삭제되는 것이니까요.
그정도의 융통성은 줘도 될것 같네요.

하여간 좋은 책을 고르셔서 다시 한번 보셔도 좋겠습니다.
다음에 다른 강의를 신청하실때는
미리 강의하실 분과 교재에 대해 알아보시면 더 좋을것 같고요.
하도 천차만별이라서. -_-a

vacancy의 이미지

Quote:
물론 역사적인 관점에서 의미가 있다고 볼수 있습니다
일단 도퇴가 되었다는것은 그만큼 언어가 쓰이지 않았다는것이고
쓰이지 않았다는것은 단점이 컷다고 볼수 있는것입니다

도태(!)된 언어가 반드시 좋지 않고 배울 가치가 없는건 아닙니다.
예를 들어 Functional Language 들은 실제로 많이 쓰이지는 않지만,
Function의 의미나 디자인에 대해 한번 생각해볼수 있게 해준다고 봅니다.
Structured Programming Language인 Pascal도
사실 C보다 구조적으로 훨씬 깔끔하죠.
개선된 OO Pascal은 Java/C#에도 영향을 주었고요.
C나 C++이 현장에서 많은 장점을 가지고 현재까지 살아남아 있지만,
다른 언어들도 그 못지 않은 장점들과 아름다움이 있다고 생각합니다.

'이런 언어가 있었군' 류의 생각이 아니라,
'이런 방식으로 프로그래밍할 수도 있다' 류의 마음가짐을 가지고
배우면 더 좋을것 같네요.

mastercho의 이미지

vacancy wrote:
count++ 는 lvalue가 아니니 count++ = value; 는 틀린 문장같은데
컴파일이 되나요 ? 안될것같은데 신기하네요. -_-a

안된다는것을 표현한것입니다 -_-;
잘못 이해하신거 같네요 , 제가 잘못 표현했을지도

임시객체를 리턴했는데 거기다 값을 대입했으니 당연히 오류가 난다라는 의미를
잘못 받아 들이신듯

vacancy wrote:
C에선 '정수=열거형'으로 단정지어 생각하지만, 파스칼에선 그게 아니었던것 같아서요.
( C++이 C와 Pascal 사이쯤으로 엄격할것같네요. Casting이 필요하니까요. )

C언어에서는 일반적으로 열거형이 정수형으로 진행되는게 맞긴 하지만

enum mytype {One=1,Two=2,MY_DOUBLE=3.1};
이런식으로도 선언이 가능합니다

이러면 C에서도 열거형은 정수라는 법칙이 깨어지죠

단 이러면 첨자로 사용할수 없습니다

vacancy wrote:
함수 내의 함수는 주어진 함수 내에서만 valid 하기 때문에,
달랑 한 함수에서만 사용될 함수의 scope를 넓게주는것보다는
더 구조적이고 깔끔하게 프로그래밍하는데 도움이 된다고 생각합니다.
( 블럭개념으로 사용되는게 아니라 scope만 다를 뿐 실제 함수로 처리됩니다. )
그 책에 나와있는 방식이 뭔진 잘 모르겠지만요. -_-a

사실 대부분의 프로젝트가 화일 범위에서 사용하기때문에 파일 범위의 static으로 선언해서 쓰지
일반적으로 그렇게 쓰이지는 않습니다

혹시 함수안에 함수를 선언해 쓰시는분이 계신지요?

그리고 요점은 이거라기 보다
함수 내부의 함수가 자신을 포함하는 외부함수의 변수 내용까지 알고
있다는것입니다, 함수라 함은 모듈화되어 있고 블랙박스화라고도 볼수 있는데

내부의 함수가 자신을 포함하는 외부의 선언된 변수를 마음대로 사용한다면
이야기가 많이 다르지 않을까요? [전역변수도 아니고...]

책에서는 이게 당연하다는듯이 다루고 있습니다

vacancy wrote:
'이런 방식으로 프로그래밍할 수도 있다' 류의 마음가짐을 가지고
배우면 더 좋을것 같네요.

말씀이야 옮지만 , 대충 어중이 떠중이 언어를 같다 대충 붙여서 얼버무린다는것이 문제입니다
그래서인지 위에 말씀하신것처럼 긍정적인 사고를 하고 싶어도 잘 안되네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

jj의 이미지

말씀하신만큼 안좋은 책이라면, 그렇게 흥분하실 필요 있는지... ^^

글의 제목이 좀 부적절한 감이 없지 않군요.

저도 강의 들을때 상당히 비판적인 시각을 많이 가진 편이었는데, 뒤돌아보면, 제가 가진 협소한 지식을 바탕으로 그것들을 평가하느라 진짜 알맹이를 놓친건 아닌가 하는 생각이 들을때가 있더군요.

PL이 Postfix 연산자의 semantics로 논쟁을 벌일만큼 한적한 분야는 아닌것 같습니다.

--
Life is short. damn short...

zoops의 이미지

학교에 따라 또 교수나 강사에 따라 좀 틀리겠지요..
하지만 저도 학교 다닐때 많이 느꼈던 부분입니다.

그리고 또 하나 덧붙이자면..
좋은 교재도 중요하지만... 제대로 가르치는것도 굉장히 중요합니다.
수업들을때 이걸 왜 듣나... 했던 것들이 졸업후에 사회에서 정말 중요한거였는데... 왜 그렇게 가르쳤을까.. 했던것들이 꽤 있네요..

- zoops -

chunsj의 이미지

함수안 함수는 GCC에서 되기 때문에 써본적이 있습니다. 외부의 변수를 내부에
써 또 쓰는 것이 문제가 꼭 되나요? Java에서의 핸들러나 매크로 같은
것으로 보시면 문제가 될 일이 아닌 것 같은데요? 꼭 모듈화라는 것에
집착을 하실 필요는 없다고 봅니다. 물론 길게,길게 써 진 것이라면 알아보기
힘들기는 하겠지만... :-)

mastercho wrote:
vacancy wrote:
count++ 는 lvalue가 아니니 count++ = value; 는 틀린 문장같은데
컴파일이 되나요 ? 안될것같은데 신기하네요. -_-a

안된다는것을 표현한것입니다 -_-;
잘못 이해하신거 같네요 , 제가 잘못 표현했을지도

임시객체를 리턴했는데 거기다 값을 대입했으니 당연히 오류가 난다라는 의미를
잘못 받아 들이신듯

vacancy wrote:
C에선 '정수=열거형'으로 단정지어 생각하지만, 파스칼에선 그게 아니었던것 같아서요.
( C++이 C와 Pascal 사이쯤으로 엄격할것같네요. Casting이 필요하니까요. )

C언어에서는 일반적으로 열거형이 정수형으로 진행되는게 맞긴 하지만

enum mytype {One=1,Two=2,MY_DOUBLE=3.1};
이런식으로도 선언이 가능합니다

이러면 C에서도 열거형은 정수라는 법칙이 깨어지죠

단 이러면 첨자로 사용할수 없습니다

vacancy wrote:
함수 내의 함수는 주어진 함수 내에서만 valid 하기 때문에,
달랑 한 함수에서만 사용될 함수의 scope를 넓게주는것보다는
더 구조적이고 깔끔하게 프로그래밍하는데 도움이 된다고 생각합니다.
( 블럭개념으로 사용되는게 아니라 scope만 다를 뿐 실제 함수로 처리됩니다. )
그 책에 나와있는 방식이 뭔진 잘 모르겠지만요. -_-a

사실 대부분의 프로젝트가 화일 범위에서 사용하기때문에 파일 범위의 static으로 선언해서 쓰지
일반적으로 그렇게 쓰이지는 않습니다

혹시 함수안에 함수를 선언해 쓰시는분이 계신지요?

그리고 요점은 이거라기 보다
함수 내부의 함수가 자신을 포함하는 외부함수의 변수 내용까지 알고
있다는것입니다, 함수라 함은 모듈화되어 있고 블랙박스화라고도 볼수 있는데

내부의 함수가 자신을 포함하는 외부의 선언된 변수를 마음대로 사용한다면
이야기가 많이 다르지 않을까요? [전역변수도 아니고...]

책에서는 이게 당연하다는듯이 다루고 있습니다

vacancy wrote:
'이런 방식으로 프로그래밍할 수도 있다' 류의 마음가짐을 가지고
배우면 더 좋을것 같네요.

말씀이야 옮지만 , 대충 어중이 떠중이 언어를 같다 대충 붙여서 얼버무린다는것이 문제입니다
그래서인지 위에 말씀하신것처럼 긍정적인 사고를 하고 싶어도 잘 안되네요

ppangi의 이미지

쓰레드의 제목이 거창하길래 들어와 봤더니 책 하나 욕하는 거군요. -.-

전에도 mastercho님의 글을 보면 소모적인 논쟁이 좀 많더군요.

새로운 대안의 제시 없이 협소한 지식과 비판적인 시각만 가지고 이야기 하는 것은 별로 도움이 안 될 것 같습니다.

Have a Learning Mind.

singlet의 이미지

mastercho wrote:
vacancy wrote:
C에선 '정수=열거형'으로 단정지어 생각하지만, 파스칼에선 그게 아니었던것 같아서요.
( C++이 C와 Pascal 사이쯤으로 엄격할것같네요. Casting이 필요하니까요. )

C언어에서는 일반적으로 열거형이 정수형으로 진행되는게 맞긴 하지만

enum mytype {One=1,Two=2,MY_DOUBLE=3.1};
이런식으로도 선언이 가능합니다

이러면 C에서도 열거형은 정수라는 법칙이 깨어지죠

단 이러면 첨자로 사용할수 없습니다

무슨 말씀이신지... :( 일반적인 경우가 아니라 표준에 지정된 유일한 경우입니다. C 에서든 C++ 에서든 같습니다. (C90 은 표준 문서를 갖고 있지 못해 확인할 수 없습니다만)

Quote:
C99 6.7.2.2.2: The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int.

Quote:
C++98 7.2.1: ... An enumerator-definition with = gives the associated enumerator the value indicated by the constant-expression. The constant-expression shall be of integral or enumeration type.

어느 implementation 에선가는 그런 선언을 허용하는지도 모르겠습니다만, 혹 설령 있다면 명백히 비표준임이 분명합니다.

mastercho wrote:
vacancy wrote:
함수 내의 함수는 주어진 함수 내에서만 valid 하기 때문에,
달랑 한 함수에서만 사용될 함수의 scope를 넓게주는것보다는
더 구조적이고 깔끔하게 프로그래밍하는데 도움이 된다고 생각합니다.
( 블럭개념으로 사용되는게 아니라 scope만 다를 뿐 실제 함수로 처리됩니다. )
그 책에 나와있는 방식이 뭔진 잘 모르겠지만요. -_-a

사실 대부분의 프로젝트가 화일 범위에서 사용하기때문에 파일 범위의 static으로 선언해서 쓰지
일반적으로 그렇게 쓰이지는 않습니다

혹시 함수안에 함수를 선언해 쓰시는분이 계신지요?

PL 하고는 전혀 상관없는 사람이지만, 가능하다면 그렇게 쓸 수 있기를 바라는 사람 중 하나입니다. C/C++ 에서 불가능하기 때문에 쓰지 않을 따름이지요. (extension 은 가급적 사용하지 않는 주의입니다) 그럼에도 불구하고 지역 클래스를 이용해서 흉내내는 경우는 종종 발생합니다만.

mastercho wrote:
그리고 요점은 이거라기 보다
함수 내부의 함수가 자신을 포함하는 외부함수의 변수 내용까지 알고
있다는것입니다, 함수라 함은 모듈화되어 있고 블랙박스화라고도 볼수 있는데

내부의 함수가 자신을 포함하는 외부의 선언된 변수를 마음대로 사용한다면
이야기가 많이 다르지 않을까요? [전역변수도 아니고...]

책에서는 이게 당연하다는듯이 다루고 있습니다

Quote:
C++98 9.8.1: Declarations in a local class can use only type names, static variables, extern variables and functions, and enumerators from the enclosing scope.

C++ 표준에서조차 지역 클래스는 함수 내에 정의된 이름, 정적 변수, 열거형 등에 접근할 수 있는데, 이것도 크게 잘못된 것입니까? 어차피 지역함수(C/C++ 에 존재하지 않지만)나 지역 클래스는 그 scope, 즉 이 경우는 외부의 함수 밖에는 알려지지도 않고 알려져서도 안되므로 도대체 문제가 될 이유가 없지 않습니까? 왜 그걸 책에서 당연하다는 듯이 다뤄서는 안되는지 자체가 전혀 이해가 가질 않습니다.

mastercho wrote:
vacancy wrote:
'이런 방식으로 프로그래밍할 수도 있다' 류의 마음가짐을 가지고
배우면 더 좋을것 같네요.

말씀이야 옮지만 , 대충 어중이 떠중이 언어를 같다 대충 붙여서 얼버무린다는것이 문제입니다
그래서인지 위에 말씀하신것처럼 긍정적인 사고를 하고 싶어도 잘 안되네요


글쎄요... 죄송스럽습니다만, 기껏해야 중급자 수준에나 다다를지도 의심스러운 저 같은 사람의 눈에도 발견되는 잘못을 너무나 많이 범하고 계셔서, 어중이 떠중이라고 비하하시기에는 대단히 이른 것 같습니다. 부족한 지식만으로 특정 책을 욕하시기보다는(죄송) 자신의 오류 또한 돌아보시고 다른 언어나 다른 사고방식에도 억지로라도 좀 사고를 열어두셔야 하지 않을까요.
snaiper의 이미지

함수안에 함수라...pascal로 static scope 쪽을 배우시는 듯 보여지는군요. 함수안에 함수가 외부 함수의 변수를 엑세스를 한다는 점에 대해 무척 거부감이 드시는 모양이네요 ^^
뭐 PL 책에 어떤 언어는 dynamic scope 로 변수 찾아가기도 한답니다. 함수 콜한 순서대로 변수를 찾아가는 ..그런 상당히 복잡한 방식이라고도 볼 수 있죠. 이런 걸 보시면 더 놀래시겠군요. ^^:

여튼간에 mastercho 님은 비판적인 책 읽기라는 점은 참 좋은데, 왜 그렇게 되었어야 하는지를 따지지 않고, 그렇게 되면 안된다라는 점에서만 접근하고 계시네요. 이런건 별로 바람직한 책 읽기 방법은 아닌 것 같습니다. 그리고 특정 책에 대한 욕하기에는 솔직히 이 쓰레드에 답 달리는 게 좀 아까운 생각이 들고요, 차라리 대학 교재가 앞으로 어떤 식으로 발전되어 나가면 좋겠는지 등의 발전적인 주제가 더 좋을 것으로 보입니다.

Bini의 이미지

Quote:

물론 역사적인 관점에서 의미가 있다고 볼수 있습니다
일단 도퇴가 되었다는것은 그만큼 언어가 쓰이지 않았다는것이고
쓰이지 않았다는것은 단점이 컷다고 볼수 있는것입니다

모든프로그래밍언어가 그런건 아닙니다.
어떤 언어의 장단점도 중요하지만 언어가 만들어진 때도 그만큼 중요하죠...
가끔 스몰톡이나 Ada가 90년대 중반쯤 만들어 졌다면 어땠을까 하고 생각해봅니다.
Java나 C++은 때를 잘타고 난 언어라는 생각이 드네요...

방준영의 이미지

그린 내용이 몇년째 책에 수록되어 팔리고 있는 주요 원인은 국내 독자들의 피드백이 매우 저조하기 때문입니다. 문제가 있으면 출판사나 저자에게 직접 이야기를 해야 할 텐데, 전혀 상관없는 사람들에게 불평을 한다고 문제는 개선되지 않는 것이죠.

죠커의 이미지

mastercho님이 언급하신 부분에 대해서는 왜 나쁜지를 모르겠군요. (전 아직 그 책을 읽지 못했고 그 책이 나빠서 화나셨을수도 있겠습니다만...)

다른 부분에 대해서는 다른 분들이 지적하시니 다른 부분은 넘어가구요.

함수내에 함수가 있는 것은 매우 편합니다. extract method란게 refactirong에 있습니다. 클래스내라는 scope가 정해져 있어서 이런게 가능하듯이 함수내라는 scope가 정해진 함수도 매우 유용하게 쓰입니다.

dynamic scoping은 lisp의 훌륭한 특성중의 하나입니다. 이런 기능들은 차후에라도 c++에 들어왔으면 좋겠다고 생각합니다.

panreo의 이미지

한빛미디어 기획1팀 유경희라고 합니다.

출판사에 몸담고 있는 입장에서 이런 주제가 언급되다 보니 발걸음이 안 떨어져한말씀 드리고 가려고 합니다.

기획하는 입장에서 "how"도 중요하지만 "what"에 대한 고민을 많이 하게 됩니다. 그래서 최대한 독자의 목소리에 귀를 기울리려고 하지만 나이를 먹음에 따라 귀도 어두워지고, 눈으로라도 보기 위해 설문 등을 요청하면 "답변율 zero에 도전하는 설문 항목 덕분인지 그다지 호응이 높지 않답니다.

그래서 방준영님 말씀처럼 적극적인 피드백 부탁드린다는 말씀드리려고요....
저희도 이윤을 추구하는 기업인데 남의 다리 긁는 책 만들고 싶겠습니까?
"what"이든 "how"든 여러분이 적극적인 의견을 주신다면 100% 반영은 힘들더라도 조금씩 프로토콜을 맞추다보면 제대로 통신이 되겠죠...
문제점이 있다는 거 자체가 문제지만.... 굳이 변명을 하자면 사람이 하는 일인지라 완벽할 수는 없음을 감안해서 사후든 사전이든 적극적인 의견 제시바란답니다.

각 출판사 게시판은 광고성 글만 올리라고 만들어 둔 것이 아니랍니다.

그럼 "오늘마져도" 즐거운 주말들 되시길 바라며....
전 이만..... :lol:

방준영 wrote:
그린 내용이 몇년째 책에 수록되어 팔리고 있는 주요 원인은 국내 독자들의 피드백이 매우 저조하기 때문입니다. 문제가 있으면 출판사나 저자에게 직접 이야기를 해야 할 텐데, 전혀 상관없는 사람들에게 불평을 한다고 문제는 개선되지 않는 것이죠.
mastercho의 이미지

방준영 wrote:
그린 내용이 몇년째 책에 수록되어 팔리고 있는 주요 원인은 국내 독자들의 피드백이 매우 저조하기 때문입니다. 문제가 있으면 출판사나 저자에게 직접 이야기를 해야 할 텐데, 전혀 상관없는 사람들에게 불평을 한다고 문제는 개선되지 않는 것이죠.

그렇지 않아도 스티븐스님의 신간 서적은 김치하 역자분에게 맡기지

말아달라고 피드백 -_-; 했답니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

mastercho의 이미지

snaiper wrote:
함수안에 함수라...pascal로 static scope 쪽을 배우시는 듯 보여지는군요. 함수안에 함수가 외부 함수의 변수를 엑세스를 한다는 점에 대해 무척 거부감이 드시는 모양이네요 ^^
뭐 PL 책에 어떤 언어는 dynamic scope 로 변수 찾아가기도 한답니다. 함수 콜한 순서대로 변수를 찾아가는 ..그런 상당히 복잡한 방식이라고도 볼 수 있죠. 이런 걸 보시면 더 놀래시겠군요. ^^:

여튼간에 mastercho 님은 비판적인 책 읽기라는 점은 참 좋은데, 왜 그렇게 되었어야 하는지를 따지지 않고, 그렇게 되면 안된다라는 점에서만 접근하고 계시네요. 이런건 별로 바람직한 책 읽기 방법은 아닌 것 같습니다. 그리고 특정 책에 대한 욕하기에는 솔직히 이 쓰레드에 답 달리는 게 좀 아까운 생각이 들고요, 차라리 대학 교재가 앞으로 어떤 식으로 발전되어 나가면 좋겠는지 등의 발전적인 주제가 더 좋을 것으로 보입니다.

그렇게해서는 안된다는 관점에서 접근한다는 말씀 ...
정확히 집으신거 같습니다

일단 왜 그런 가닥으로 방향을 잡았는가는....
이미 폐기된 언어에서 사용하거나 , 어디서도 거의 사용하지 않는 코드기때문입니다

많이 사용한다고 무조건 좋은 코드라고도 볼수는 없지만 , 어째튼 그런 방법을
거의 사용하지 않고 있습니다. 추측으로는 나쁘기때문에 사용되지 않은거라고 볼수 있습니다

함수내 함수 방법은 C언어에서는 이미 나중에 나온 언어로써 전에 가지고 있던 이런 언어들의 방법을 취하지 않았습니다
언어들간에 서로 영향을 준다고 봤을적에 , 좋지 않았기때문에 그렇게 쓰이지 않은것입니다, 말하자면 모듈성과 명확성이 떨어진다고 본게 아닌가 싶습니다

게다가 차후에 나오는 언어들은 자바 [C#은 확인 못햇음] 내부안의 다른 블럭 조차 모듈성침해와 애매함 나타낼수 있다하여 블럭외부의 변수와 같은 변수를 블럭내에 선언할수 없습니다, 이것이 단순히 자유롭다라는 차원에서 본다면
상당히 아이러니 하네요 , C++에서의 자유로움은 복잡하다며 눈에 가시로 여기시는분이 많은데 , 파스칼이나 고전 언어에서 쓰는 복잡함이나 애매함은 괜찬으신건지?

CN wrote:
mastercho님이 언급하신 부분에 대해서는 왜 나쁜지를 모르겠군요. (전 아직 그 책을 읽지 못했고 그 책이 나빠서 화나셨을수도 있겠습니다만...)

다른 부분에 대해서는 다른 분들이 지적하시니 다른 부분은 넘어가구요.

함수내에 함수가 있는 것은 매우 편합니다. extract method란게 refactirong에 있습니다. 클래스내라는 scope가 정해져 있어서 이런게 가능하듯이 함수내라는 scope가 정해진 함수도 매우 유용하게 쓰입니다.

dynamic scoping은 lisp의 훌륭한 특성중의 하나입니다. 이런 기능들은 차후에라도 c++에 들어왔으면 좋겠다고 생각합니다.

함수내의 함수 선언은 이미 C에서도 가능합니다
단 구현은 다른곳에서 정의해야 하죠

그리고 C에서는 그렇게 쓰이지 않은 이유가 좋지 않았기때문에
그렇게 쓰이지 않는다고 볼수 있을거 같습니다

리펙토링 관점에서 본다면 static으로 선언해 외부로 노출시키지 않으면 되니까요

100이면 99.9의 코드가 함수내 함수 선언을 쓰지 않고
어떠한 책에서도 함수내 함수를 소개해주고 있지 않습니다
[있다면 소개해 주십시오]
또한 함수라는 개념이 모듈의 개념이기때문에 , 함수가 전역이 아닌 다른 함수의
내부 변수를 자유롭게 참조한다는게 바람직하다고 전혀 보아지지 않습니다

물론 자유로운 사고로 보자면 굳이 거부할 필요는 없지만 모듈화된 프로그래밍에 그리 도움이 될거 같지 않네요, 그리고 쓰이지도 않고요

그리고 제가 크게 문제 삼았던것은
9장내내 함수내 함수 방법이 일반적인 프로그래밍 언어의 방법인양
떠들면서 끝났다는것입니다
완전 조선일보를 보는듯했죠 , 특정언어의 일부분을 마치
일반적인 부프로그램 즉 함수의 개념으로 소개를 했다는겁니다
[이게 요즘 언어에서 쓰이는 방법은 아니죠]

프로그래밍 언어를 배우는것이 결국 요즘 쓰이는 언어나 감각을
익히는데 도움이 되고자 하는거라면
이거에 역행하는거와 다름없다고 봅니다

결국 C/C++나 자바 C# 혹은 기타 언어를 하더라도
이런 지식은 도움이 되지 않을거라 생각이 됩니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

mastercho의 이미지

singlet wrote:

무슨 말씀이신지... :( 일반적인 경우가 아니라 표준에 지정된 유일한 경우입니다. C 에서든 C++ 에서든 같습니다. (C90 은 표준 문서를 갖고 있지 못해 확인할 수 없습니다만)

다시 해보니 안되네요 , 나중에 다시 확인해 보겠습니다
분명 전에 gcc로 컴파일 되어서 저도 놀랬던기억이 있습니다

singlet wrote:
PL 하고는 전혀 상관없는 사람이지만, 가능하다면 그렇게 쓸 수 있기를 바라는 사람 중 하나입니다. C/C++ 에서 불가능하기 때문에 쓰지 않을 따름이지요.

윗글이 제 답변이 있습니다

singlet wrote:
]
Quote:
C++98 9.8.1: Declarations in a local class can use only type names, static variables, extern variables and functions, and enumerators from the enclosing scope.

C++ 표준에서조차 지역 클래스는 함수 내에 정의된 이름, 정적 변수, 열거형 등에 접근할 수 있는데, 이것도 크게 잘못된 것입니까? 어차피 지역함수(C/C++ 에 존재하지 않지만)나 지역 클래스는 그 scope, 즉 이 경우는 외부의 함수 밖에는 알려지지도 않고 알려져서도 안되므로 도대체 문제가 될 이유가 없지 않습니까? 왜 그걸 책에서 당연하다는 듯이 다뤄서는 안되는지 자체가 전혀 이해가 가질 않습니다.

지역 클래스가 함수내에 정의된 이름, 정적 변수,열거형등을 접근할수 있다는말이 도통 이해가 가질 않네요 ,그냥 자신의 블럭범위안에서 선언할수 있다는 말을 아닌가요?
이게 어떻게 다른 곳에서 접근할수 있다는 말인지 이해가 가지 않네요

singlet wrote:

글쎄요... 죄송스럽습니다만, 기껏해야 중급자 수준에나 다다를지도 의심스러운 저 같은 사람의 눈에도 발견되는 잘못을 너무나 많이 범하고 계셔서, 어중이 떠중이라고 비하하시기에는 대단히 이른 것 같습니다. 부족한 지식만으로 특정 책을 욕하시기보다는(죄송) 자신의 오류 또한 돌아보시고 다른 언어나 다른 사고방식에도 억지로라도 좀 사고를 열어두셔야 하지 않을까요.

글세요 , 다른 사고를 단순히 거부했다 치부하시지 마시고
거부한 이유를 한번쯤 생각보셨으면 합니다

물론 저도 좀더 열린 사고를 가져 보도록 하겠지만

함수는 모듈화 되어야 하고 블랙 박스화 되어야 한다는
저와의 접근 자체가 저와 많이 틀리시네요

그리고 제가 말하고자 한점...를 정확히 읽어주셨으면 좋겠습니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

snaiper의 이미지

이미 폐기된 언어에서나 사용하는 방법이라...이미 폐기되었는지는 어떻게 알고 계시는지가 궁금하군요. 알게 모르게 우리 주위에서는 쓰는건 아닌지요?
여튼 간에 PL 이라는 학문은 왜 그렇게 되었어야 하는지를 판단하고 비평하는 학문이라고 볼 수 있습니다. 우리 같이 배우는 사람에게는 언어를 선택하는데 있어서 판별하고 통찰력 있게 분석할 수 있는 능력을 주는 학문이라고도 할 수 있습니다.
말씀하시는 근거로서는 왜 그런 코드가 사용되어서는 안된다는 것인가를 판별하기가 부족한 것 같습니다. 현대 언어에서는 안 쓰기 떄문에 그렇다라는 것 근거가 부족합니다. PL 배우셨다면 readablility 나 writablility 등의 제시된 기준에 의해서 저건 저렇고 이건 이렇고 해서 결과적으로 안 좋다는 겁니다 라고 해야 제대로 된 비평이라고 할 수 있습니다.
그리고 한가지 짚어볼 점은 pascal 에서는 그렇게 쓰고 c에서는 그렇게 쓰지 않았던 것이 선택의 문제라고 생각하지는 않으시는지요? 다른 예로 들어 C++에서 multiple inheritance 가 java 와 같이 C++ 이후에 나온 언어에는 존재하지 않는 것이 단지 나쁘기 떄문인 것인가요? 버림으로써 쓰기 어려워진 것들은 없을런지요.
어떤 언어의 특징이 여기선 있고, 저기선 없는데 그 언어가 최신이라고 해서 이전 언어가 나쁘다는 건 좀 문제가 있다고 봅니다. 언어 설계자가 설계 기준을 세울 때 이런 것은 나의 언어에서는 필요없어 또는 설계 기준에 맞지 않아 라고 해서 뺸 것은 아닌지 생각해보세요.

mastercho의 이미지

snaiper wrote:
이미 폐기된 언어에서나 사용하는 방법이라...이미 폐기되었는지는 어떻게 알고 계시는지가 궁금하군요. 알게 모르게 우리 주위에서는 쓰는건 아닌지요?
여튼 간에 PL 이라는 학문은 왜 그렇게 되었어야 하는지를 판단하고 비평하는 학문이라고 볼 수 있습니다. 우리 같이 배우는 사람에게는 언어를 선택하는데 있어서 판별하고 통찰력 있게 분석할 수 있는 능력을 주는 학문이라고도 할 수 있습니다.
말씀하시는 근거로서는 왜 그런 코드가 사용되어서는 안된다는 것인가를 판별하기가 부족한 것 같습니다. 현대 언어에서는 안 쓰기 떄문에 그렇다라는 것 근거가 부족합니다. PL 배우셨다면 readablility 나 writablility 등의 제시된 기준에 의해서 저건 저렇고 이건 이렇고 해서 결과적으로 안 좋다는 겁니다 라고 해야 제대로 된 비평이라고 할 수 있습니다.
그리고 한가지 짚어볼 점은 pascal 에서는 그렇게 쓰고 c에서는 그렇게 쓰지 않았던 것이 선택의 문제라고 생각하지는 않으시는지요? 다른 예로 들어 C++에서 multiple inheritance 가 java 와 같이 C++ 이후에 나온 언어에는 존재하지 않는 것이 단지 나쁘기 떄문인 것인가요? 버림으로써 쓰기 어려워진 것들은 없을런지요.
어떤 언어의 특징이 여기선 있고, 저기선 없는데 그 언어가 최신이라고 해서 이전 언어가 나쁘다는 건 좀 문제가 있다고 봅니다. 언어 설계자가 설계 기준을 세울 때 이런 것은 나의 언어에서는 필요없어 또는 설계 기준에 맞지 않아 라고 해서 뺸 것은 아닌지 생각해보세요.

설계 기준이 바뀐이유가 나름대로 있으리라 봅니다 --;

하지만 여태 답변중에서 가장 의미 심장하네요 :)

개정판을 매년 내면서 책의 달라진것이 고작 그림 표 옮기기 수준이라니
화가 많이 난거 같습니다 , PL이라는 항목에서 볼때 너무 세세한 언어를
다루는것이 아니긴 하지만 ,잘못된점이 많이 뛰었고
부프로그램 장에서는 아예 현대적 언어의 방식은 배제한체
PL/I 와 파스칼의 함수내 함수 방법만 집고 넘어가는 아니함을 보여
무지 화가 났었습니다

제가 이 책을 보는 입장이 , 현대적인 언어를 좀더 잘 이해하고자 한것인데
전혀 부합하지 못했기 때문이죠

어째튼 : ) 이번 토론으로 제가 부족했던점을 좀 더 생각해 볼수 있었던거 같습니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

vacancy의 이미지

함수 내의 함수가 자신을 포함하는 함수의 변수에
접근할수 있는것이 이상하다면
일반 함수들이 전역 변수에 접근하는 것도 이상한 거죠.

함수가 다른 함수의 안쪽에 존재한다는 것의 의미는,
안쪽의 함수에서 무엇을 할수 있고 안할수 있고도 중요하겠지만,
( 어차피 이상한 걸 하려고 들면 어떻게든 할수 있지 않나요 ? 특히 C에선- )
안쪽의 함수가 외부에 알려지지 않는다는 것이 중요한 겁니다.

예를 들어 A라는 함수가 B라는 함수에서만 사용된다고 하면,
굳이 A가 file scope를 가지고 다른 함수에 알려질 필요가 없죠.
그런 경우 B 함수 안쪽에 선언하면 이를 명백하게 보여줄수 있습니다.
이게 더 아름답다고 생각하지 않으시는지요 ? -_-a
( 캡슐화도 이쪽이 더 잘 되어 있죠. )
C에서 이런 것들이 지원되지 않는건 그저 단순화하기 위한것 같은데요.

그리고 파스칼에서 열거형이 정수형과 다르다는 의미는,
열거형이 정수형이 아닌 실수형도 될수 있다는 뜻이 아니라,
열거형은 그저 열거형이라는 얘깁니다.
정수형으로 바꾸기 위해서는 서수형 연산(함수?)인 ord, pred, succ 등을
사용하게 되어 있고요. ( 기억이 가물가물하네요 -_-a )
너무 C/C++에 익숙하셔서 생각의 범위가 한정되신것 같네요.
그리고 추가적으로 파스칼에는 아주 편한 집합형도 있죠. 흠,

또 .. 자꾸 폐기된 언어들이라고 하시는데요.
제 생각에도 폐기라기보다는 선택의 문제라고 보고요.
직접 사용하지 않으신다고 해서 폐기된 언어는 아닙니다.
예를 들어 Object Pascal 기반의 Delphi 같은 경우는
현장에서 매우 많이 사용되고 있습니다.

mastercho의 이미지

일단은.... 여러 분들의 말씀을 들어보니

제가 성급하게 말했던부분이 있는거 같습니다

시정되어야 할거 같은데

여기서 대부분 이의를 제기하는 분들의 말씀중 상당수는
제가 말하고자 하는 주된 목적과는 좀 벗어난부분이 있습니다

제가 표현을 잘 하지 못한점이 있기때문이 아닌가 싶습니다

뭐 일단 여기 토론에 참여하신분들이 책을 안읽어보신분들이기때문에
정확히 토론을 하기 힘들거 같기도 합니다

일단은 명백히 저도 인정되는부분은 서평에서 수정을 좀 하고

좀더 제가 주장하는바가 명확하도록 글을 다시 추가 해야겠습니다

그럼

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

M.W.Park의 이미지

왠지 동문일것같은 느낌이 팍팍옵니다.
이 교수님께서 C++도 강의하시지 않았던가요? 흐흐흐... 8)

fibonacci wrote:
저는 PL을 잘 배워서(운이 좋아 꽤 능력있는 분에게서 배웠습니다. 이분 몇년 강의하시다가 우리나라 대학이 싫어서 다시 미국으로 가셨죠 -_-; 이름은 거론하지 않겠습니다) PL과목 자체에 대한 불만은 없습니다. 제가 알고 있는 PL과목은 "언어를 초월한 프로그래밍의 센스를 배우는 과목" 입니다.

선생님도 좋았지만, 교재도 너무나 마음에 들어서 긴 얘기는 안하고 교재 소개만 합니다. 1996년도에 들었던 교재입니다. Scheme이라는 언어로만 진행되는 책입니다. 저는 아는게 C밖에 없었던지라 이게 무슨 소용이 있을까 회의적이었지만, 한학기를 Scheme과 지내보고 저의 코드가 얼마나 논리적, 체계적으로 바뀌었나 실감했습니다.

Structure and Interpretation of Computer Programs, Harold Abelson and Gerald Jay Sussman, MIT PRESS

http://mitpress.mit.edu/catalog/item/default.asp?sid=C3D9A91C-D94D-4720-88F9-F7C32A175354&ttype=2&tid=4412

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

perky의 이미지

mastercho wrote:
snaiper wrote:
이미 폐기된 언어에서나 사용하는 방법이라...이미 폐기되었는지는 어떻게 알고 계시는지가 궁금하군요. 알게 모르게 우리 주위에서는 쓰는건 아닌지요?
여튼 간에 PL 이라는 학문은 왜 그렇게 되었어야 하는지를 판단하고 비평하는 학문이라고 볼 수 있습니다. 우리 같이 배우는 사람에게는 언어를 선택하는데 있어서 판별하고 통찰력 있게 분석할 수 있는 능력을 주는 학문이라고도 할 수 있습니다.
말씀하시는 근거로서는 왜 그런 코드가 사용되어서는 안된다는 것인가를 판별하기가 부족한 것 같습니다. 현대 언어에서는 안 쓰기 떄문에 그렇다라는 것 근거가 부족합니다. PL 배우셨다면 readablility 나 writablility 등의 제시된 기준에 의해서 저건 저렇고 이건 이렇고 해서 결과적으로 안 좋다는 겁니다 라고 해야 제대로 된 비평이라고 할 수 있습니다.
그리고 한가지 짚어볼 점은 pascal 에서는 그렇게 쓰고 c에서는 그렇게 쓰지 않았던 것이 선택의 문제라고 생각하지는 않으시는지요? 다른 예로 들어 C++에서 multiple inheritance 가 java 와 같이 C++ 이후에 나온 언어에는 존재하지 않는 것이 단지 나쁘기 떄문인 것인가요? 버림으로써 쓰기 어려워진 것들은 없을런지요.
어떤 언어의 특징이 여기선 있고, 저기선 없는데 그 언어가 최신이라고 해서 이전 언어가 나쁘다는 건 좀 문제가 있다고 봅니다. 언어 설계자가 설계 기준을 세울 때 이런 것은 나의 언어에서는 필요없어 또는 설계 기준에 맞지 않아 라고 해서 뺸 것은 아닌지 생각해보세요.

설계 기준이 바뀐이유가 나름대로 있으리라 봅니다 --;

하지만 여태 답변중에서 가장 의미 심장하네요 :)

저도 도태된 역사를 배우는 것에 대해 옹호하는 입장에서 한마디 달아 봅니다.
컴퓨터 과학이 변하는 방향은 수학처럼 그 자체 학문이 지향하는 바에 따라 움직이는 학문과는 다릅니다. 컴퓨터 과학은 어디까지나 컴퓨터 공학과 기타 공학, 인지과학, 정보기술산업 등의 관련 기술들의 영향을 끊임없이 받고 있으며 다시 새로운 과학을 제공해주는 것으로 발전하는 학문입니다.

따라서, 아무리 현대에 MS윈도우가 시장을 거의 완벽하게 장악하고 있고, 인텔의 386 아키텍처가 거의 대부분의 집에 들어가 있더라도, 이것이 컴퓨터 과학에 의한 최적의 선택이라기 보다는, 시장 상황과 여러가지 힘의 논리와 적절한 임의의 변수들로 인해 지금까지 내려왔으며, 그 상황을 다시 컴퓨터 과학이 돌려받고 있습니다. (최근 컴퓨터 과학과 컴퓨터실들에도 대부분 윈도우와 인텔 컴퓨터가 있고 조교들도 윈도우밖에 몰라서 윈도우용 i386 exe파일로 숙제를 내야하는 것만 봐도..)

그렇지만, 한때는 전부였지만 시장 점유율이 계속 낮아지고 있는 메인프레임들이나 엔드유저 시장에서는 그다지 눈에 띄지 않는 유닉스쪽에서도 배울 것은 계속 있으며, 옛날에 여러 이유로 시장에서 소멸한 CP/M, DR/DOS, BeOS 같은 것들도 그들이 새로이 구현했던 좋은 개념들과 그 영향들, 그것이 생기게되고 발전하게 된 과정에 대해서 배운다면 충분히 새로운 아이디어를 많이 얻을 수 있습니다.

제가 얼마 전에 알게된 것으로 "char이 ANSI C에서는 8비트가 아니라는 것"이 있습니다. 물론 70년대 중반 이후로는 대부분의 기계들이 8비트를 1바이트로 채택해오고 있어서 현대 언어만을 익혀온 사람들은 char이 8bit가 아닐 수 있다는 사실에 대해서는 전혀 모를 수 있습니다. 물론 저도 그렇지만.. :) 그렇지만, 60년대부터 개발을 계속해온 동료 개발자들은 8비트가 1바이트로 시장에서 압도적인 지지를 받기 이전의 20년간의 역사를 소개해주면서, 왜 그렇게되었는지, 다른 아키텍처에서 택한 6비트, 9비트, 16비트, 64비트의 경우에는 각각 어떤 장점이 있는지 상세히 설명할 수 있었습니다.

물론, 이런 것들을 안다고 해서 특별히 연봉이 오르거나 취직이 잘 되거나 하지는 않겠지만, 어떤 기술이 과학적으로든, 시장논리로든 지지를 받기 전에 있었던 여러 경쟁자들에 대해서 서로 비교를 할 수 있다면 그 기반 지식으로 발전 구조의 끝만 아는 사람보다 훨씬 넓은 시야를 확보할 수 있고, 그만큼 더 많은 아이디어의 원천과, 미래를 대비할 수 있는 힘을 갖을 수 있다고 생각합니다.

프로그래밍 언어론의 경우에도, 이 쓰레드에서 비판하고 계신 책은 읽어보지 않아서 잘 모르겠지만, 과거의 언어들을 주로 다루거나 현재는 컴파일러조차 구할 수 없는 언어를 주로 배우게 되더라도 그에는 나름대로 가치가 있다고 생각합니다. 꼭 현대 언어들이 내려오게 된 ALGOL계열 언어들이 아니더라도요.. :) 물론 fibonacci님께서 추천하신 SICP의 경우에는 최고겠죠~

저는 어릴 때 TIME LIFE에서 나온 비싸고 별 쓸모 없어보이는 15권짜리 풀컬러 컴퓨터 역사책을 선물 받아서 아주 심심할 때마다 조금씩 여기저기를 보았습니다. 그 책들에서는 지금 생각해보면 CPU가 나오게 된 계기와 배비지의 미분기나 파스칼의 계산기 같은 CPU가 나오기 전의 아키텍처들, 최초의 프로그래밍 언어인 프랑칼퀼이나 어셈블리가 등장하게 된 계기와, 어셈블리를 쓰는 것을 반대했던 폰 노이만 같은 과학자들의 얘기를 많이 다루고 있어서, 얼마전까지만해도 정말 쓸모없는 이야기책이구나하고 그냥 보아 넘겨 왔습니다. 그런데, 대학을 들어온 이후에 나뭇가지의 끝이 이것저것 결국은 그 책에서 읽었던 뿌리들과 엮어지는 것을 보면 "도태의 역사"를 배우는 것도 많은 도움을 주는 것 같습니다.

삼국지 결말은 결국 위나라가 촉, 오를 멸망시키고 사마씨가 정권을 잡는다로 끝나지만, 삼국지에서 배울 수 있는 것은 위나라가 이겼다는 것과 사마씨가 정권을 잡았다는 것이 다는 아닐 것입니다.

You need Python

죠커의 이미지

mastercho wrote:
함수내의 함수 선언은 이미 C에서도 가능합니다
단 구현은 다른곳에서 정의해야 하죠

그리고 C에서는 그렇게 쓰이지 않은 이유가 좋지 않았기때문에
그렇게 쓰이지 않는다고 볼수 있을거 같습니다

리펙토링 관점에서 본다면 static으로 선언해 외부로 노출시키지 않으면 되니까요

100이면 99.9의 코드가 함수내 함수 선언을 쓰지 않고
어떠한 책에서도 함수내 함수를 소개해주고 있지 않습니다
[있다면 소개해 주십시오]
또한 함수라는 개념이 모듈의 개념이기때문에 , 함수가 전역이 아닌 다른 함수의
내부 변수를 자유롭게 참조한다는게 바람직하다고 전혀 보아지지 않습니다

물론 자유로운 사고로 보자면 굳이 거부할 필요는 없지만 모듈화된 프로그래밍에 그리 도움이 될거 같지 않네요, 그리고 쓰이지도 않고요

제가 착각한 부분이 있군요. 선언을 정의로 착각했습니다. 다른 분이 gcc의 중첩된 함수에 대해서 언급하셔서 그 부분에 대해서 말씀하신줄 알았습니다. gcc의 확장인 중첩된 함수를 이용하면 함수내에서 세부적인 모듈화를 할수 있다는 장점이 있다. 정도의 의미로서 적었습니다.

다시 생각해보니 어떤 함수를 그 함수를 직접 쓰는 다른 함수에서 선언을 한다는 것 정도의 의미인것 같은데요. A 함수를 B함수에서 사용한다면 B함수는 A함수를 알고 있다고 생각합니다. B함수에 A함수에 대한 선언이 있던 없던간에 말입니다. 선언이 있냐 없냐가 모듈의 독립성을 보장하지 못한다고 봐야 할겁니다.

C언어 프로그래머들이 그러한 방법을 쓰지 않는 것은 그게 더 편해서라고 봅니다. 순간순간 필요한 선언들을 함수에 써주는 것 보다는 한꺼번에 묶어두고 매크로 가드로 중복되지 않도록 해두고는 마음껏 불러서 써주는게 더편하기 때문일 것 같습니다.

juneaftn의 이미지

퍼키씨의 글에 동감합니다.

과거를 배우는 것, 그리고 과거에서 현재적 가치를 찾는 것, 그리하여 늘 과거를 새롭게 하는 것은 참으로 중요합니다.

이것과 더불어 고전읽기를 권합니다.

http://no-smok.net/nsmk/_bf_f8_c0_fc_c0_c7_c1_df_bf_e4_bc_ba

프로그래밍언어론 책 한권을 보아가면서 거기에서 인용하는 60,70,80년대 문헌들을 찾아 읽어보세요. 새로운 통찰을 얻을 것입니다.

지리즈의 이미지

perky wrote:
대학을 들어온 이후에 나뭇가지의 끝이 이것저것 결국은 그 책에서 읽었던 뿌리들과 엮어지는 것을 보면 "도태의 역사"를 배우는 것도 많은 도움을 주는 것 같습니다.

공감갑니다.

Unix 개론책을 보면, 거의 대부분
Unix의 계통도(?)가 초반에 언급되기 마련이고,
전 늘 맛배기 정도로만 여기어 왔는데...

나중에 필드에서 여러 Unix Clone들에서 코딩을 접하다보니,
"아 정말 그 그림한장이 이렇게 까지 유용할줄은 "이라는
생각을 했습니다.

There is no spoon. Neo from the Matrix 1999.

mastercho의 이미지

perky wrote:
저도 도태된 역사를 배우는 것에 대해 옹호하는 입장에서 한마디 달아 봅니다.
컴퓨터 과학이 변하는 방향은 수학처럼 그 자체 학문이 지향하는 바에 따라 움직이는 학문과는 다릅니다. 컴퓨터 과학은 어디까지나 컴퓨터 공학과 기타 공학, 인지과학, 정보기술산업 등의 관련 기술들의 영향을 끊임없이 받고 있으며 다시 새로운 과학을 제공해주는 것으로 발전하는 학문입니다.

따라서, 아무리 현대에 MS윈도우가 시장을 거의 완벽하게 장악하고 있고, 인텔의 386 아키텍처가 거의 대부분의 집에 들어가 있더라도, 이것이 컴퓨터 과학에 의한 최적의 선택이라기 보다는, 시장 상황과 여러가지 힘의 논리와 적절한 임의의 변수들로 인해 지금까지 내려왔으며, 그 상황을 다시 컴퓨터 과학이 돌려받고 있습니다. (최근 컴퓨터 과학과 컴퓨터실들에도 대부분 윈도우와 인텔 컴퓨터가 있고 조교들도 윈도우밖에 몰라서 윈도우용 i386 exe파일로 숙제를 내야하는 것만 봐도..)

그렇지만, 한때는 전부였지만 시장 점유율이 계속 낮아지고 있는 메인프레임들이나 엔드유저 시장에서는 그다지 눈에 띄지 않는 유닉스쪽에서도 배울 것은 계속 있으며, 옛날에 여러 이유로 시장에서 소멸한 CP/M, DR/DOS, BeOS 같은 것들도 그들이 새로이 구현했던 좋은 개념들과 그 영향들, 그것이 생기게되고 발전하게 된 과정에 대해서 배운다면 충분히 새로운 아이디어를 많이 얻을 수 있습니다.

제가 얼마 전에 알게된 것으로 "char이 ANSI C에서는 8비트가 아니라는 것"이 있습니다. 물론 70년대 중반 이후로는 대부분의 기계들이 8비트를 1바이트로 채택해오고 있어서 현대 언어만을 익혀온 사람들은 char이 8bit가 아닐 수 있다는 사실에 대해서는 전혀 모를 수 있습니다. 물론 저도 그렇지만.. :) 그렇지만, 60년대부터 개발을 계속해온 동료 개발자들은 8비트가 1바이트로 시장에서 압도적인 지지를 받기 이전의 20년간의 역사를 소개해주면서, 왜 그렇게되었는지, 다른 아키텍처에서 택한 6비트, 9비트, 16비트, 64비트의 경우에는 각각 어떤 장점이 있는지 상세히 설명할 수 있었습니다.

물론, 이런 것들을 안다고 해서 특별히 연봉이 오르거나 취직이 잘 되거나 하지는 않겠지만, 어떤 기술이 과학적으로든, 시장논리로든 지지를 받기 전에 있었던 여러 경쟁자들에 대해서 서로 비교를 할 수 있다면 그 기반 지식으로 발전 구조의 끝만 아는 사람보다 훨씬 넓은 시야를 확보할 수 있고, 그만큼 더 많은 아이디어의 원천과, 미래를 대비할 수 있는 힘을 갖을 수 있다고 생각합니다.

프로그래밍 언어론의 경우에도, 이 쓰레드에서 비판하고 계신 책은 읽어보지 않아서 잘 모르겠지만, 과거의 언어들을 주로 다루거나 현재는 컴파일러조차 구할 수 없는 언어를 주로 배우게 되더라도 그에는 나름대로 가치가 있다고 생각합니다. 꼭 현대 언어들이 내려오게 된 ALGOL계열 언어들이 아니더라도요.. :) 물론 fibonacci님께서 추천하신 SICP의 경우에는 최고겠죠~

저는 어릴 때 TIME LIFE에서 나온 비싸고 별 쓸모 없어보이는 15권짜리 풀컬러 컴퓨터 역사책을 선물 받아서 아주 심심할 때마다 조금씩 여기저기를 보았습니다. 그 책들에서는 지금 생각해보면 CPU가 나오게 된 계기와 배비지의 미분기나 파스칼의 계산기 같은 CPU가 나오기 전의 아키텍처들, 최초의 프로그래밍 언어인 프랑칼퀼이나 어셈블리가 등장하게 된 계기와, 어셈블리를 쓰는 것을 반대했던 폰 노이만 같은 과학자들의 얘기를 많이 다루고 있어서, 얼마전까지만해도 정말 쓸모없는 이야기책이구나하고 그냥 보아 넘겨 왔습니다. 그런데, 대학을 들어온 이후에 나뭇가지의 끝이 이것저것 결국은 그 책에서 읽었던 뿌리들과 엮어지는 것을 보면 "도태의 역사"를 배우는 것도 많은 도움을 주는 것 같습니다.

삼국지 결말은 결국 위나라가 촉, 오를 멸망시키고 사마씨가 정권을 잡는다로 끝나지만, 삼국지에서 배울 수 있는 것은 위나라가 이겼다는 것과 사마씨가 정권을 잡았다는 것이 다는 아닐 것입니다.

물론 프로그래밍 언어 역사를 통해 언어를 대우는것에 불만은 없습니다만은, 이 책에서 소개해주는 방식으로는 말씀 하신거와 같은 지식은 없을 수 없을거 같습니다..

어째튼 교재로 이런 책을 배웠다는게 수치스럽다는 생각마저 듭니다

OS 이론의 국내 저자책을 봐도 외국 OS 책을 고대로 배껴다 쓴부분이 있는 것을 발견했습니다.

국내 교수의 저질 배껴쓰기로 이런것을 배워야 한다는게 아쉽습니다

쩝, SICP로 배우셨다는 분이 부럽네요......

앗참!, 참고로 SICP 그 책 번역중이라고 합니다 :)

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

죠커의 이미지

mastercho wrote:
앗참!, 참고로 SICP 그 책 번역중이라고 합니다 :)

정말인가요. 멋진일이군요.!!

mastercho의 이미지

CN wrote:
mastercho wrote:
앗참!, 참고로 SICP 그 책 번역중이라고 합니다 :)

정말인가요. 멋진일이군요.!!

http://bbs.kldp.org/viewtopic.php?p=111928#111928

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

avelose의 이미지

흐음 대학교재라..
대학이라고 할 수도 없는 곳 출신이라서.. 교재들이 나뻐도 불평하는 이들이 없었습니다. 쩝. 교재에 대부분은 공부가 끝나고 거의 다 버렸을 정도로... 한권 남아 있네요. 교수님이 강의를 끝까지 끝내 주시지 않아서 독학하려고 보고 있었던 운영체제론.(책은 형편없음에도.. 그냥 본다는.... 생긴 것은 실하게 생겼는데.. 내용은 언제적 것인지 의심스럽다는.. 아무리 원리만 이해해도 된다지만.. )

아. fibonacci님(피보나치? 수열인가요?) 어쨋든.. 지방의 어느 공대 출신이신 것 같은데.. 혹시 교수님이 중국분 아니셨나요?? 흐음. 어쩜 아닐지도 모르겠지만... 그분 같은데.. 흐음. 현재도 왕성한 활동을(opie를 요피용으로 포팅해 주시고 계시죠.) 아니라면 대략 민망하군요. 쩝. 이글 못 읽으시길..

'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'

sozu의 이미지

전 이제 석사 들어가는 학생인데요.

저같으면 저런 교재를 쓰는 분의 강의는 듣지 않을겁니다.

다행히 저희학교에는 거의 100% 외국서를 사용합니다;
(물론 번역서도 있지요;;)

그리고 프로그래밍 언어론...

저희학교는 컴파일러를 전공하시는 나이 많으신 교수님이 PL 까지 가르치시는데

정말 잼있고 알찹니다. 죽이죠..ㅋㅋ 인기 과목입니다.

책도 책 나름이지만 PL같은 이론적인 과목은 노하우가 중요한듯 싶구요

제 소견으로는

PL 은 언어의 차이점을 배우는 것은 아니라고 생각합니다;;

프로그래밍 언어가 생기면서 나는 문제점에 대한 여러가지 역사적인 제안들부터

프로그래밍 패러다임에 따른 변화들

프로그래밍 언어가 가지는 특성 등등을 배우는게 아닌가 싶네요

형식 언어론이나 컴파일러론까지 들어보시면...

좀더 잼있지 않을까 싶네요^^;;

그냥 생각나는데로 적어봤습니다^^;;;

-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

fibonacci의 이미지

avelose wrote:
아. fibonacci님(피보나치? 수열인가요?) 어쨋든.. 지방의 어느 공대 출신이신 것 같은데.. 혹시 교수님이 중국분 아니셨나요?? 흐음. 어쩜 아닐지도 모르겠지만... 그분 같은데.. 흐음. 현재도 왕성한 활동을(opie를 요피용으로 포팅해 주시고 계시죠.) 아니라면 대략 민망하군요. 쩝. 이글 못 읽으시길..

제가 말씀드린 교수님은 미국에 사시는 한국분입니다. ^^; 저는 수학 전공 학생인데, 컴퓨터 전공과목도 흥미가 있어서 같이 들었었고요. SICP를 교재로 개설된 과목들이 제가 있던 학교말고도 개설되었던것 같네요. 요새는 별로 채택하는 곳이 없다는데 안타깝네요.

No Pain, No Gain.

차리서의 이미지

fibonacci wrote:
저는 PL을 잘 배워서(운이 좋아 꽤 능력있는 분에게서 배웠습니다. 이분 몇년 강의하시다가 우리나라 대학이 싫어서 다시 미국으로 가셨죠 -_-; 이름은 거론하지 않겠습니다) PL과목 자체에 대한 불만은 없습니다. 제가 알고 있는 PL과목은 "언어를 초월한 프로그래밍의 센스를 배우는 과목" 입니다.

선생님도 좋았지만, 교재도 너무나 마음에 들어서 긴 얘기는 안하고 교재 소개만 합니다. 1996년도에 들었던 교재입니다. Scheme이라는 언어로만 진행되는 책입니다. 저는 아는게 C밖에 없었던지라 이게 무슨 소용이 있을까 회의적이었지만, 한학기를 Scheme과 지내보고 저의 코드가 얼마나 논리적, 체계적으로 바뀌었나 실감했습니다.

Structure and Interpretation of Computer Programs, Harold Abelson and Gerald Jay Sussman, MIT PRESS

http://mitpress.mit.edu/catalog/item/default.asp?sid=C3D9A91C-D94D-4720-88F9-F7C32A175354&ttype=2&tid=4412

헉! :shock:

교수님에 관한 이야기와 교재에 관한 이야기로 보아, 어쩌면 저와 같은 교수님으로부터 저와 같은 강좌를 들으신 분이실지도 모르겠습니다. 저는 교수님 안식년 바로 전 해인 1998년 가을 학기에 그 강좌의 '막차'를 탔었습니다. 피보나치님께서는 1996년에 들으셨다니 제 선배님이실지도 모르겠군요.

게다가, 제 경우에는 학번 끝자리가 짝수여서 원칙대로라면 다른 교수님(어느 분이셨는지는 기억하지 못하지만)의 분반 강의를 들었어야했는데, 막 전과하여 한 달 가량 늦게 강의에 합류하던 저를 당시 학과장이셨던 교수님께서 배려(?)하셔서 그냥 당신의 분반으로 넣어주셨습니다. 말 그대로, 정말 "운이 좋았던" 케이스죠.

비록 지금 제 전공이 PL은 아니지만, 여전히 제 전공 분야인 정형 증명 이론과 상당히 밀접한 관계가 있기도 해서, 지금도 PL의 원론적 이해에 관해 욕심이 많습니다. 그리고, 보는 시각에 따라서는 넓디 넓은 PL의 세계 중에서 빙산의 일각만을 비추고 있을 뿐인지도 모르지만, 역시 위의 교재(Sussman)는 '생각하는 힘과 발상의 폭'의 한계를 넓혀주는 데에 아직까지도 중요한 지침이 되고 있죠. 기본적으로 Scheme이라는 함수형 언어를 이야기하고 있긴 하지만 어디까지나 소재일 뿐이고, 특히나 절차형 기계와 절차형 언어의 세계에만 상대적으로 훨씬 익숙한 풍토에서는 새로운 세계로의 창문 역할을 크게 해줄 것입니다. 상대적인 비교 평가같은걸 할 수 있을만큼 많은 책을 읽어본 것도 아닐 뿐더러, 애초에 평가 자체를 할 수 있을만큼 내공이 튼튼하지도 못하지만, 일단 위의 교재는 '공부해서 절대로 손해나지 않을' 책이라는 것까지는 자신있게 말 할 수 있겠습니다.

다른 분야도 크게 보면 마찬가지겠지만, 일단 PL 영역에만 한정하여 이야기하자면, 특히 대학원 강좌나 학부4학년용 고급PL 강좌가 아닌 기초 PL 강좌일수록 강좌로부터 학생들이 꼭 얻었으면 하는 가장 중요한 몇 가지 중 하나가 바로 '편협하지 않은 넓고 열린 사고'입니다. 이 스레드에 이미 몇 번 언급된 이야기긴 하지만, PL의 역사를 이해하는 것은 그래서 중요한 일입니다. 비록 깊이 들어가진 못하더라도 PL과 그 주변 세계의 역사를 폭넓게 이해함으로써,

    + 태초에 기계(폰 노이만 기계)의 원리가 어땠으며
    + 이 원리에 기반한 프로그래밍의 원초적인 출발이 무엇이고
    + 이때의 발상이 무엇이었으며
    + 당시부터 수학이나 논리학 등 다른 학문은 무엇을 해오고있고, 이들로부터 집합 이론이나 분류 이론(category theory의 적절한 번역은 무엇일까요?), 정수론, 함수론, 증명이론, 타입 이론 등을 PL이 어떻게 수용해왔으며,
    + 당시부터의 산업 모델이나 비용 상황이 어떻게 변천해왔고 어떤 요구조건을 만족시키길 원하고 있으며,
    + 결과적으로 이후 새로이 등장하는 발상은 어땠고, 서로간에 어떻게 영향을 주고 받았으며
    + 무엇이 왜 도태(?)되었고 또 무엇은 왜 아직까지 살아남았으며, 도태된 것같지만 사실은 보이지 않는 저변에 살아숨쉬는 오래된 발상들은 무엇이며,
    + 그 결과 각각의 세계(문제를 생각하는 세계, 해법을 생각하는 세계, 만드는 세계와 풀이를 사용하는 세계 등등) 에 어떤 영향들을 어떻게 주어왔으며,
    + 만일 이 출발점이나 대전제가 바뀐다면 (즉, 폰 노이만 기계가 아닌 전혀 다른 차원의 기계가 등장한다든가) 어떤 발상이 어떻게 PL에 도입될 수 있을까
    + 그리고 앞으로 우리는 PL에 관해서 어떤 새로운 발상을 도입해볼 수 있을까

등등의 사고를 경험해볼 수 있는 중요한 기회 중 하나가 바로 학부의 PL 강좌가 아닐까 합니다.

여기에는 교재도 교재지만 그 강좌를 진행하는 교수님이나 학생들의 마인드도 크게 한 몫을 하지않을까합니다. PL 강좌가 특정 언어를 잘 다루는 프로그래머(혹은 심지어 코더)를 양성하는 학원 강좌로 전락하는 경우도 간간히 들리더군요. 직접 경험한적은 없으니 확언할 수는 없지만 말이죠.

PS: 지금까지 이곳 저곳에서 피보나치님의 필명을 여러 번 뵈었었는데, (아닐 수도 있지만) 동문이실 수도 있다는 것을 여태 모르고 있었습니다. 게다가, 혹시 제쪽에서만 몰랐던 것이라면 더더욱 죄송합니다. 아울러, 공개적인 게시판에 개인적인 인사를 남기는 것에 대해서도 다른 모든 분들께 사과드립니다.

PS2: 대체 BBCode의 리스트 태그는 어찌 사용하는걸까요? 잠시 수정하던 작업을 중단하면서까지 이리저리 테스트를 해봐도 도통 올바른 사용법을 알 수가 없군요. T_T

[/]

--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!

crazydak의 이미지

http//www.amazon.com/exec/obidos/tg/detail/-/0321193628/qid=1073312830//ref=sr_8_xs_ap_i0_xgl14/104-4467064-6731935?v=glance&s=books&n=507846

전 이책의 3rd에디션으로 PL을 배웠습니다..

현재는 PL을 거의 쓰지 않는 업종에서 일하고 있습니다만.. 그당시에 그리고 이전직장에서는 굉장히 큰 도움이 되었던 수업으로 기억되고 있습니다...

저에게 있어서 배움은 가르치시는 분과의 코드(?)가 잘 맞는 것이 굉장히 중요했습니다만..PL수업의 강의 스타일이 저와 잘 맞아서 매우 재미있게 들었던 기억이 납니다..

이 쓰래드를 읽으며 책장에 꼽혀있는 대학교때의 한권 한권 보게되었는데요...

늘 그렇겠지만 후회가 많이 남는 책들이 많이 있습니다..

공룡책...(...조심조심 공부했으면..D는 피할수 있었으련만...)
컴퓨터 네트웍스 Tanenbaum 3rd ed. pratical hall..(코드 따지지 않고 공부했으면...C-는 피하지 않았을가..)
Software Engineering sommerville 5th ed addison wesley(drop안하고 수강했으면 저렇게 새책은 아닐텐데.....흑흑...)

그래도 대학교때의 제자신의 열정을 되찾고 싶습니다...

회사가 하도 뒤숭숭하여 과거가 그립네요...