python or ruby?

noname81의 이미지

C로만 코딩하다가 객체지향 개념을 좀 잡고 싶은데요.
C++ 책을 보아도 너무 어려워서
좀 쉬운 언어로 접근해 보려고 합니다.

물론 자바가 있지만 이상하게 자바는 너무 느리다는 생각이 들고
그닥 배우고 싶은 생각이 안드네요.
혹, "객체지향을 배우려하면서 자바를 제외한다면 문제가 크다?"
라고 생각하신다면 지적 부탁드립니다.

Quote:
python or ruby
로 구글링 했더니
Should I Learn Python or Ruby next?
이게 나와서 좀 읽어 봤는데
대부분 파이썬을 권하더군요.

위 링크의 질문자가 말한 Rails with Ruby and Django with Python하고는 상관없이
OOP개념을 잡기 위해서 어떤 언어가 더 좋을런지요?

cinsk님의 이글을 읽어보니 파이썬 쪽으로 더욱 기울어졌습니다만...

keedi의 이미지

객체지향 개념을 잡고 싶다는 것이
객체지향의 검은 마법(구현 방법?)을 알고 싶은 것인지.
또는, 객체지향 스타일 코딩을 제대로 하고 싶은 것인지,
또는, 또 다른 이유인지...
에 따라 다르겠지만, 어느 언어로 해도 상관없을 것 같군요.

전자라면, 오히려 객체지향 기능을 가지고 있지 않은 언어가 더 나을테고,
후자라면, 제대로 객체지향인 언어가 낫겠죠.

전자라면 어떤 언어를 사용해도 상관없을테고,
후자라면 차라리 smalltalk 같은 것을 공부하는게 더 정확하다고 봅니다.

그게 아니라면 어짜피 객체지향을 지원하는 멀티패러다임 언어를 선택한다면,
ruby 든, python 이든 perl이든 Java든 별로 상관없다고 봅니다.

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Keedi Kim

----
use perl;

Keedi Kim

semmal의 이미지

언어는 중요하지 않습니다만, 지금 궁극적으로 쓰고자 하는 언어가 C++ 인 것 같은데, 그렇다면 루비나 파이썬이 좋은지에 대해서는 확답을 못드리겠네요.

OO에 대해서 개념적인 공부를 하신다면야 Smalltalk 계열의 언어를 써서 공부하는 것이 정석이고 좋은 판단입니다만, 문제는 C++가 Smalltalk 계열이 아니라는게 문제지요. 그래서 이런 언어에서 당연히 되는 것이 얄궃게도 C++에서는 안되는 경우가 있습니다.

그래서, 스몰톡이나 루비, 파이썬 등으로 OO에 익숙해지셨다면, Java를 공부하시는 것이 C++로 가는데 조금이나마 도움이 될 것 같습니다.

또한, Java와 C++의 갭도 적지 않기 때문에, C++의 OO도 나름대로 다시 공부를 하셔야 합니다. C++ 이 놈은 가끔식 OO를 하면서도 OO를 지켜서는 안될 때가 있어서 말이죠.

결론은, C++ 정말 잘 쓰기 어렵습니다아~
------------------------------
How many legs does a dog have?

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

이한길의 이미지

저도 C++을 위해서라면 JAVA에 한표입니다... 그리고 C++ㅇ르 정말 잘 쓰기 어렵다는 데 한표입니다.
저는 개인적으로 처음 OOP개념 잡는데 자바의 튜토리얼이 도움이 되었습니다.
그때만 해도 자바가 OOP의 정석인줄 알았습니다...

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.xo.st
http://hangulee.egloos.com/

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

cleol의 이미지

OOP 개념을 잡고 싶다면 일단 C++ 은 추천하지 않습니다. 다른 분들 말씀대로 잘 쓰기가 무척 어렵습니다. 많은 분들이 말씀하듯 문제는 언어가 아니라 개념과 습관(관용적인 사용법)인데, OOP 는 "문제 해결" 을 위한 전략의 하나이므로 구체적인 "문제와 해결 방안"을 가지고 공부하는 것이 좋습니다. 고로 "디자인 패턴"을 공부하는 것이 좋을 듯 합니다. 디자인 패턴에 대한 책들이 꽤 많이 나와있는데 GOF 같은 고전이 아닌 이상 대체로 자바를 사용합니다. 따라서 일단 자바를 공부하시는 것이 좋습니다. 분야에 따라 다르겠지만, 자바를 사용할 줄 아는 것이 파이썬이나 루비보다 대체로 인력 시장에서 경쟁력이 있으므로 실용적인 의미에서도 손해는 아닙니다.
정리하면 일단 자바를 간단히 익히시고, 몇가지 디자인 패턴을 공부하시면 좋을겁니다. 그 이후에도 가봐야할 곳들이 널려있지만 일단 그렇게 시작하시면 좋을겁니다. (OOP 를 잘 이해하기 위해서라도 OOP 가 아닌 것들을 공부하는 것이 중요합니다.)

noname81의 이미지

자바책부터 보기 시작해야겠네요.

다른 모든 분들께도 감사드립니다.


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

cleol의 이미지

노파심에 덧붙이자면^^; 자바 자체를 너무 자세히 알려고 하지는 마십시오. 적당히(좀 애매하지만..) 알고 넘어가시면 됩니다. 특히 Annotation 이나 java generic 은 신경 안쓰셔도 됩니다. 일단 몇 가지 다자인 패턴을 이해하고 사용할 정도가 된 다음에 필요하다면 다시 자바를 자세히 알아보시던가 다른 언어를 공부하시는 것이 좋다고 생각합니다. 많은 책이 자바를 사용하고, 현실적으로 알아둬서 좋기 때문에 자바를 추천했지만 자바는 그다지 표현력이 좋은 언어가 아닙니다. 지나가는 길목에 있는 장애물 정도로 생각하십시오. 넘어가기는 해야하지만 그 자체가 중요한 것은 아닙니다.

Darkcircle의 이미지

제가 뭐 자바 책을 이것저것 본 그런 경험이 있는것은 아니지만
내용도 탄탄하거니와 글쓴이가 객체지향 개념과 프로그래밍 패러다임 쪽으로
좀 강조하는 부분이 있더군요... 자바를 배우기에 앞서
패러다임의 전환을 하는덴 나름 좋은 책이라 생각됩니다.
===========================================
니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

keizie의 이미지

gtk+의 C 구현을 보다 보면 OOP라는 걸 구현하기 위해 C 문법 안에서 재주를 부린 걸 확인할 수 있었습니다. 단기간에 성과를 내긴 힘들지 몰라도 OOP에 대한 약간 저수준의 이해에 도움이 된다고 봅니다.

kmryu의 이미지

객체를 배우는데 언어는 아무 상관없습니다.

객체지향을 제대로 지원하는 언어로 객체를 이해하겠다.. 약 7, 8년전에 제 모습같네요.

익명 사용자의 이미지

전 객체를 배우는데 언어도 중요한 요소라고 생각합니다.
언어는 생각의 틀을 잡아주는 역할을 한다고 보거든요...
철학이 독일에서 유독 발전했던 것이라던가...
성악이 이탈리아에서 유독 발전했던 것이라던가...
언어가 주는 영향이 있었다고 봅니다.

C++이나 Java 로 객체의 개념을 배우는 것과
Smalltalk 로 객체의 개념을 배우는 것은 사뭇 다릅니다.

kmryu의 이미지

저는 모델링을 더 중요하게 봤습니다.
업무분석 뒤 객체를 파악해서 모델링을 잘 한다면 코드는 자연스럽게 객체지향적 형태를 가지게 되는게 아닌가 생각됩니다. 이때 언어에따라 현실을 모델링한 결과가 다르지 않기때문에 프로그래밍 언어는 상관없다고 한것이죠.

전 C++ 언어로 (굳이 어렵게) 객체지향적 프로그래밍을 시작했지만 Smalltalk를 알았다면 아마 C++ 책은 집어던졌을겁니다. 그런 점에서 언어는 중요하다고 생각합니다.

객체를 이해하는데 C 언어를 공부할때 그렇게 해맸던 포인트만큼 헷갈리는 레퍼런스라는 언덕을 넘어야 하는지.. 지금은 제가 왜 그렇게 C++ 언어에 집착했었나 후회스럽기도 하네요. 당시엔 누가 방향을 제시해주는 사람이 없었기도 했겠지만..
질문하신 분은 그러지 않기를 바라는 마음에 댓글을 달게되었습니다.

noname81의 이미지

콕 집어 주시면 안될까요?
떠먹여 달라는 것 같아서 죄송스럽지만
강컴에서 '모델링'으로 검색해봤더니
UML 책과 DB책이 나오던데요.

'클래스 구조의 이해와 설계 : UML, Java, C++을 활용한 객체지향 모델링 실전'
이런 종류의 UML책을 말씀하시는지요?
(디자인 패턴이 아닐까 생각하고 있습니다만...)

Quote:
전 C++ 언어로 (굳이 어렵게) 객체지향적 프로그래밍을 시작했지만 Smalltalk를 알았다면 아마 C++ 책은 집어던졌을겁니다. 그런 점에서 언어는 중요하다고 생각합니다.

위 문장을 보면 굳이 언어를 따지자면 Smalltalk쪽을 공부하라는 말씀이신 것 같은데 맞는지요?

해매고 있는 중생을 위해 방향 제시 좀 부탁드립니다.

------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

kmryu의 이미지

최근에 OO를 애기하면서 UML을 다루지 않은 책은 없을겁니다. 그래서 순수하게 UML이란 표기법을 설명한 책이 아니라면 보통 책의 전반에 초보자를 위해 OO란 무엇인지 잘 설명해줄듯 하네요.

요즘엔 이와관련해서(OO의 실무적 활용이 아닌 원론적 해설) 책을 읽어본 적이 없기에 추천은 못해드리겠습니다만 저는 Prentice Hall에서 출간된 Object-Oriented Analysis & Design 이란 책으로 개념적 OO를 공부했었습니다.
당시엔 원서가 아니면 객체지향을 공부하기 어려워서 원서를 샀을뿐.. 요즘은 번역서들이 많으니 공부하기엔 수월할껍니다.

이젠 Java를 공부해두시는것이 OOAD던, OOP던간에 책을 고르는데 있어서 선택의 폭이 넓고 자유로워지지 않을까 싶습니다. Smalltalk는 GOF 패턴책에서나 등장할까 거의 대부분의 책들이 Java 언어로 예제를 쓰니까요.

kmryu의 이미지

http://www.amazon.com/exec/obidos/ISBN=0136302459/stevenblackconsuA

이젠 찾기도 어렵네요. 코멘트에도 있는 애기지만 플랫폼이나 언어에 상관없이 OO를 공부하기에 좋은 책입니다. 그리고 읽어본바로 쉽습니다. 처음부터 차근차근 소프트웨어의 위기, OO의 등장배경, OO란, 멤버, 메세지란 등등.. 책의 1/3 이상 할애하면서 용어들을 잘 설명하고 있습니다. 뒤로 넘어가면 분석설계 애기가 나오는데 이때 UML을 사용하지 않고(UML이 표준이 아니었던 시절이라) 설명하는데 이런쪽은 addison wesley 출판사에서 나온 책들을 보는것이 좋겠습니다.

읽은지 참 오래된 책이고 정이 많이 가는 책중에 하나에요. 다시보니 감회가 새롭군요. -_-;

noname81의 이미지

얼른 구해서 읽어봐야겠습니다.
------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

sharefeel의 이미지

저도 kmryu님의 말씀에 찬성합니다.
언어란 것은 그 언어가 만들어질 당시의 'needs'가 반영된 것이고 그에따라 OO에 변형을 가하게 마련입니다.
C++가 C에다가 OO를 구현하려 하다가 어렵고 복잡하며 심지어 OO가 아니다라는 소리까지 듣고 있는 게 좋은 예입니다.
다른 언어들도 그 언어가 추구하는 바에 따라 OO를 변형(?)하여 적용하게 마련입니다. 정도의 차이는 있겠지만요..

만약 주력 분야에서 커리어를 쌓는데 도움을 얻기 위해서라면 언어 자체를 배우시는 게 낫겠지만,
그게 아니라 OOP에 대한 개념을 얻는 것이 목적이시라면 서적과 같은 정석적인 방법이 나을거라고 생각합니다.
===============
Vas Rel Por

===============
Vas Rel Por

noname81의 이미지

후자가 맞습니다.

Quote:
만약 주력 분야에서 커리어를 쌓는데 도움을 얻기 위해서라면 언어 자체를 배우시는 게 낫겠지만,
그게 아니라 OOP에 대한 개념을 얻는 것이 목적이시라면 서적과 같은 정석적인 방법이 나을거라고 생각합니다.

공부하실때 도움이 되었던 서적 좀 추천해 주실 수 있는지요?
------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

keedi의 이미지

다른 분들이 언급해주신 책들은 정석(Top Down)적인 접근(손해볼 것 없는)이죠.

후자가 맞고, 정석적인 접근이 뜬구름 잡는 것 같다는 느낌이 들어서,
거꾸로 객체지향의 구현이라는 측면에서 접근을 하신다면(Bottom Up)
Object Oriented Perl, Damian Conway, Manning 을 추천합니다.

대신 언어는 Perl입니다. :-)

장점으로는, 객체지향에서 다루는 개념을 모두 특정언어(Perl)을 이용해서 직접 구현합니다.
학부 또는 대학원의 소공 수업의 한 학기 텀 정도로 나오기도 하는 객체지향 구현하기 과제
수준에서 한 2~3배 정도까지의 테크닉과 개념을 같이 정리할 수 있습니다.

Perl이란 언어에 거부감만 없다면 훌륭한 책이라고 생각합니다. :-D

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Keedi Kim

----
use perl;

Keedi Kim

noname81의 이미지

익숙지 않아서
도전하기에 쉽지는 않을 것 같습니다.
답변 감사드립니다^^
------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

semmal의 이미지

그냥 Smalltalk를 써서 다양한 문제를 풀어보는 것이 더 도움이 될 듯합니다. 하다 못해 Ruby나 Python도 좋습니다. 간단하게는 IO(http://iolanguage.kr)라는 장난감 같은 언어도 있지요.
UML는 OOA에 관련되어 있을 뿐 OOP와는 직접적인 관련이 없습니다.
object-oriented programming의 의의는 polymorphism을 통해서 높은 수준의 abstraction을 수행하는 데 있습니다. OOA나 UML과는 길이 다릅니다.
제가 Java를 써보라고 한 것은 OOP의 개념을 확실히 깨달았을 때, C++로 넘어가기 위한 중간단계로 말씀 드린 것이지, 개인적으로 Java 언어자체가 OO를 익히는데 그리 도움이 된다고 생각하지는 않습니다.

Smalltalk/Ruby/Python과 같은 dynamic typing language에서의 OOP와 C++/Java와 같은 static typing language에서의 OOP는 상당히 많은 차이가 있습니다. 또한 C++/Java는 OO의 이론이 정립되기 전에 나온 언어이기 때문에 covariance와 contravariance를 지원하지 않습니다. covariance와 contravariance가 구현이 된 언어로 scalar와 sather가 있습니다. 궁금하시면 아무거나 써보시면 될 것 같습니다.
------------------------------
How many legs does a dog have?

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

noname81의 이미지

관련 서적 찾아본후에
궁금한 점이 있으면
다시 여쭤보겠습니다.
귀찮게 해드리는 것 같네요...
------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

fedorasix의 이미지

암꺼나 해도 되여.
객체지향 암것도 아님.
MVC로 막 짜면서 내가 잘 하구나 생각하다가
디자인 패턴 드가야 이래서 객체지향 이구나 하는거져.
KLDP 돌아다니다보면 마치 디자이너가 감각을 익히기 전에
포토샵을 해야할지 일러스트를 해야할지... 물어보는 질문이 태반이군요.

fedorasix의 이미지

fedorasix의 이미지

익명 사용자의 이미지

포인트가 이렇게 내려갔나요?

익명 사용자의 이미지

어떤 분이 디자인 패턴을 먼저 공부하라하신 것 같은데 저도 동감합니다. 전 프로그래밍 테크닉을 공부하는데에 가장 좋은 방법은 그걸 직접 사용하는 것이라고 생각합니다. 이론은 먼저 현실적인 사용법을 익힌 후에 하는 것이 좋다고 봅니다. 모든 분야가 다 그런 것은 아니겠지만 적어도 프로그래밍 테크닉은 실제로 문제를 해결하면서 사용을 해본 후에야 이론을 제대로 이해할 수 있다고 생각합니다. 그런면에서 디자인패턴이 딱이지요. 언어 역시 중요한데 뭐 현실적으로 자바말고는 대안이 없다고 봅니다. 다른 언어들을 사용해서 초보자에게 쉽게 디자인 패턴을 설명하는 문서를 본적이 없어서요. 혹 그런 문서가 있다면 다른 언어도 관계 없다고 봅니다.

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

저는 좋은 코드를 많이 보는 것이 도움이 된다고 생각합니다. 굳이 이름을 붙이자면 "거인의 어깨에 올라서는" 방법이랄까요.
소스 코드가 공개된 프로젝트도 상당히 많고, 규모 있는 프로젝트는 대체로 코드의 질도 괜찮은 것 같습니다. (물론 안 그런 것도 있습니다. 다만 대체로 자바 커뮤니티에서 작성되는 코드들이 볼만했습니다.)
물론 한 소프트웨어나 프레임워크의 코드를 전부 본다는 건 말이 안되고요, 관심 있는 부분만 떼어서 보는 것이 좋겠죠.
같은 목적의 여러 프로젝트를 비교해보는 것도 나름대로 공부가 됩니다.

hongminhee의 이미지

OOP를 배우고 싶으시면 Ruby가 낫지 않을까 생각합니다. 그렇지만 OOP와 함께 FP 스타일도 익히는 데는 Python이 나을 것 같습니다.

noname81의 이미지

Functional programming을 말씀하시는 건가요?
------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)


------------------------signature------------------------
Self-Pity

I never saw a wild thing
sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.

- David Herbert Lawrence (1885-1930)

hongminhee의 이미지

네, 그렇습니다.

klenui의 이미지

python나 ruby 중에 뭐라도 관계없는 거겠죠..
단 객체 지향을 공부하기 위해 python이나 ruby부터 시작한다는 건 분명 좋은 생각인것 같습니다.
c++을 아무리 공부해도 객체 지향 공부는 별로 안되더군요..
c++의 여러 기법들은 ruby나 python에서 약간의 속도를 희생해서 신경쓰지 않아도 되는 많은 것을
난해한 코드를 통해 신경 엄청 쓰면서 약간의 속도를 얻기 위한 것이라는 느낌을 많이 받았습니다.
(아직 c++은 능숙하지 않아서 정확한 표현이 아닐수도 있겠네요.)
현업에서야 약간의 속도가 '약간'이 아닐 수도 있지만 객체 지향 공부차원에서는 별 의미 없을 것 같습니다.

저는 효율보다는 로직이 중요한 경우 python을 주로 사용하고 있고 크게 만족하고 있습니다.
Ruby도 좋은 언어라는 이야기를 많이 들었습니다만, python에 만족하고 있어서 따로 공부할 필요성은 못느끼고 있구요..

hongminhee의 이미지

C++는 멀티 패러다임 언어이고 또 그것들을 C++ 스타일로 녹여냈기 때문에, OOP를 배우기 위해 C++를 배운다는 것은 그다지 좋지 않은 것 같습니다. 실제로 C++를 사용하다보면 OOP에 대한 통찰보다는 일반화 프로그래밍(generic programming)과 C++ 방식의 FP 스타일, 템플릿 메타프로그래밍 같은 부분에서 더 배울 것이 많습니다.

angel341의 이미지

이것저것 경험해 보다가 맘에 드는 것을 골라 하세요.
그래야 나중에 후회를 않함니다.