Ruby의 단점을 알려주세요.

호랑이의 이미지

제가 가장 즐겨 사용하는 스크립트 언어는 python입니다.
interactive interpreter가 정말 편하죠.
python이 좋기는 한데 oop 지원이 미비해서 아쉽습니다.
ruby는 제대로 된 영문 매뉴얼이 없어서 학습할 기회가 없었는데 몇 일 전에 가보니 Programming Ruby라는 책( 2판이 출판 됐었군요. ) 1판 전문이 올라와 있네요.
읽어보니 oop적인 면이나 언어적인 매력이 대단하군요.
많이 쓰이지 않았던 이유 중 가장 큰 이유가 영문 문서가 없었기 때문이라고 알고 있었는데 다른 단점이 뭐가 있을까요?
우선 perl, php, python에 비해서 라이브러리가 적을 것 같고, 성능이 떨어지지 않을까 싶습니다만?

알고 있는 단점 좀 알려주십시오.
결정적인 단점이 없다면 ruby를 즐겨 사용할까하는 생각이 듭니다.

File attachments: 
첨부파일 크기
Image icon Eclipse-syntax-coloring.png36.43 KB
alfalf의 이미지

spert wrote:
python이 좋기는 한데 oop 지원이 미비해서 아쉽습니다.

개인적으로 Python의 OOP 지원이 매우 뛰어나다고 생각하는데 spert님께서는 어떤면에서 OOP 지원이 미비하다고 생각되시는지 궁금합니다.

creativeidler의 이미지

파이썬도 OOP에 관한한 둘째 가라면 서러워할 언어입니다. OOP가 이유라서 파이썬을 버리겠다면 다시 생각해보세요.

그건 그렇고 파이썬과 루비의 비교라면 다음의 링크만한 자료가 흔하진 않을 겁니다.
http://c2.com/cgi/wiki?PythonVsRuby

호랑이의 이미지

alfalf wrote:
spert wrote:
python이 좋기는 한데 oop 지원이 미비해서 아쉽습니다.

개인적으로 Python의 OOP 지원이 매우 뛰어나다고 생각하는데 spert님께서는 어떤면에서 OOP 지원이 미비하다고 생각되시는지 궁금합니다.

생각나는 몇 가지 적어보겠습니다.
우선 처음으로 실망했던 것은 static 멤버 변수를 지원하지 않는 다는 것이었죠.
php도 5.0 버전 부터 지원하는 것으로 알고있습니다.

접근 제한자도 지원하지 않고 있죠. 대부분의 스크립트 언어가 지원하지 않지만 있으면 더 좋지요.
ruby에는 있더군요.

제일 싫은 점은 method의 첫 인자로 self를 써 줘야 한다는 것입니다.

>>> class Python:
	def __init__(self):
		self.msg = 'Hello World!'
	def out(this):
		print this.msg

		
>>> x = Python()
>>> Python.out(x)
Hello World!

위의 코드 같이 첫 파라메터로 객체를 전달해 줘야 한다는 것이죠.
Python.out(x) 걸 보면 네임스페이스 안의 함수에 구조체를 넘기는 것 같습니다.
self를 왜 굳이 써줘야 하는지 모르겠습니다.

ruby에서는 아래와 같은 코드도 가능합니다.

"gin joint".length 
-1942.abs 
kerz의 이미지

Quote:
>>> class Python: 
   def  __init__(self): 
      self.msg = 'Hello World!' 
   def out(this): 
      print this.msg 
       
>>> x = Python() 
>>> Python.out(x) 
Hello World!

python에서 메소드의 선언시에 첫인자로 self 같은것을 써주기는 하지만..

호출시에는

>>> x = Python()
>>> x.out()
Hello Word!

이렇게 해도 되지 않던가요? (아마 내부적으로는 동일한 동작을 하는것 같지만....)

그리고 python에서도..

>>>"gin joint".__len__()
9
>>> (-1942).__abs__()
1942

같은식의 사용이 가능합니다.

제가 ruby는 아직 접해보지 않아서 모르겠지만... python도 꽤 괜찮다는 생각입니다.

-----
늘 여유가 함께하길..

aeronova의 이미지

Quote:
접근 제한자도 지원하지 않고 있죠. 대부분의 스크립트 언어가 지원하지 않지만 있으면 더 좋지요.
ruby에는 있더군요.

private을 말씀하신거라면 "__"를 붙여서 해결할 수 있습니다. 다만, 완벽히 감추어지진 않지만요.

class sample_class:

    def __init__(self,Nmax=5):
        pass

    def __private_method(self,x):
         pass

It's better to burn out than to fade away. -- Kurt Cobain.

임창진의 이미지

주제와는 다르지만 ruby 를 시자해볼 생각이라고 하셔서 아직 시작하지 않으셨다면 Lua 를 추천합니다.

www.lua.org

이녀석을 알게된건 scite 라는 에디터에 scipt 언어로 같이 포함되면서 부터입니다.
python,ruby 처럼 라이브러리가 막강하지는 않습니다만
C/C++과 붙이기 매우 편하고 작으면 문법이 매우 재밌습니다.

그네들 말로는
A fundamental concept in the design of Lua is to provide meta-mechanisms for implementing features, instead of providing a host of features directly in the language.
이렇다고 합니다.
말그대로 oop 의 예를들면 직접지원하지는 않고 있는데 매우 간단한구현으로 oop의 기능들을 제공하는 예제가 여럿있습니다.

암튼 무지무지 재밌고 색다른 스크립트언어입니다.

nohmad의 이미지

루비의 표준배포 인터랙티브 인터프리터인 irb는 파이썬 기본 인터프리터 이상입니다. 루비는 GNU Readline을 사용할 수 있어서 탭 완성도 기본 지원되고, 스코프를 마음대로 이동할 수 있어서, 인스턴스 변수를 바깥이 아니라 인스턴스 내부에서 조사할 수도 있습니다.

확실히 self는 파서가 알아서 똑똑하게 처리해주는 것이 좋다고 생각합니다. 파서가 해야 할 일을 사람에게 떠넘기는 것은 좋지 않다고 생각합니다. 루비에서는 인스턴스 변수는 @을 붙이고, 메쏘드는 우선순위 메커니즘이 똑똑하게 찾아줍니다.

루비의 결정적인 단점은 느린 인터프리터 속도와 파이썬에 비해 풍부하지 못한 라이브러리입니다. 속도 문제는 차기 VM에서 상당 부분 해결될 수 있을 것 같고, 또 속도 문제는 상대적이서 지금도 응용 프로그램 수준에서 특별히 느리다는 생각은 들지 않습니다. 속도 문제가 있는 곳은 대부분 C나 C++, Java 등으로 래핑해서 쓸 수 있으니까요. 라이브러리쪽은 최근 루비 언어가 탄력을 받고 있기 때문에 계속 상황은 나아지고 있습니다.

루비는 스몰톡의 순수 객체지향 디자인과 펄의 유닉스 취향이 잘 결합되어 있고, 최근의 이슈인, 동적 타입 언어(Dynamic Typed Language)이자, DSL(Domain Specific Language) 면에 있어서도 가장 이상적인 언어라고 생각합니다.

alfalf의 이미지

spert wrote:
alfalf wrote:
spert wrote:
python이 좋기는 한데 oop 지원이 미비해서 아쉽습니다.

개인적으로 Python의 OOP 지원이 매우 뛰어나다고 생각하는데 spert님께서는 어떤면에서 OOP 지원이 미비하다고 생각되시는지 궁금합니다.

생각나는 몇 가지 적어보겠습니다.
우선 처음으로 실망했던 것은 static 멤버 변수를 지원하지 않는 다는 것이었죠.
php도 5.0 버전 부터 지원하는 것으로 알고있습니다.

접근 제한자도 지원하지 않고 있죠. 대부분의 스크립트 언어가 지원하지 않지만 있으면 더 좋지요.
ruby에는 있더군요.

제일 싫은 점은 method의 첫 인자로 self를 써 줘야 한다는 것입니다.

>>> class Python:
	def __init__(self):
		self.msg = 'Hello World!'
	def out(this):
		print this.msg

		
>>> x = Python()
>>> Python.out(x)
Hello World!

위의 코드 같이 첫 파라메터로 객체를 전달해 줘야 한다는 것이죠.
Python.out(x) 걸 보면 네임스페이스 안의 함수에 구조체를 넘기는 것 같습니다.
self를 왜 굳이 써줘야 하는지 모르겠습니다.

ruby에서는 아래와 같은 코드도 가능합니다.

"gin joint".length 
-1942.abs 

읽어보니 실제 Python의 OOP 지원이 미비하다기 보다는 윗분들이 설명해 주신것과 같이 Python의 OOP 지원 중 spert님이 아직 미처 파악하지 못하신 부분도 있고, 또, 원하시는 OOP 지원 형태와 Python이 지원이 다르기 때문에 그렇게 표현하신것으로 생각됩니다.
다만, "미비"라는 단어를 사용하셔서 Python OOP의 우수함에 대해 아직 Python을 접하지 못하신 분들이 오해할 수도 있게 만드신 부분에 대해서는 조금 아쉽네요.

꼬마앙마의 이미지

alfalf wrote:
spert wrote:
python이 좋기는 한데 oop 지원이 미비해서 아쉽습니다.

개인적으로 Python의 OOP 지원이 매우 뛰어나다고 생각하는데 spert님께서는 어떤면에서 OOP 지원이 미비하다고 생각되시는지 궁금합니다.

생각나는 몇 가지 적어보겠습니다.
우선 처음으로 실망했던 것은 static 멤버 변수를 지원하지 않는 다는 것이었죠.
php도 5.0 버전 부터 지원하는 것으로 알고있습니다.
==> 정말 불가능하나요? 저는 이럴경우 주로 튜플을 사용하는데...

접근 제한자도 지원하지 않고 있죠. 대부분의 스크립트 언어가 지원하지 않지만 있으면 더 좋지요.
ruby에는 있더군요.
==> 파이썬 사용하면서 접근 제한자 때문에 문제가 생긴적은 한번도 없습니다. 접근 제한자는 '못' 지원하는게 아니라 '안' 지원하는겁니다.

제일 싫은 점은 method의 첫 인자로 self를 써 줘야 한다는 것입니다.

>>> class Python:
	def __init__(self):
		self.msg = 'Hello World!'
	def out(this):
		print this.msg

		
>>> x = Python()
>>> Python.out(x)
Hello World!

일단... 코드가 틀렸네요.
파이썬도 됍니다.
x.msg = "Hello Python!" 이렇게 저장할수 있죠.
예를들어 이런것도 됩니다.
class a:
    pass
b = a()
b.Hello = "Hello"
print b.Hello

위의 코드 같이 첫 파라메터로 객체를 전달해 줘야 한다는 것이죠.
Python.out(x) 걸 보면 네임스페이스 안의 함수에 구조체를 넘기는 것 같습니다.
self를 왜 굳이 써줘야 하는지 모르겠습니다.

==> self는 클래스내에서 멤버변수에 접근하기위한 하나의 약속입니다. 싫으시면 안써도 상관없는데요?

ruby에서는 아래와 같은 코드도 가능합니다.

"gin joint".length 
-1942.abs 

당연히 파이썬도 돼죠.

루비의 단점이라면, 파이썬에 있는 유연한 자료구조가 없는것.

라이선스가 GPL인것.

속도가 느린것.

라이브러리가 적은것.

코드를 알아보기 어려운것.(펄보다는 쉽지만)

타이핑 하기 귀찮은것.(파이썬을 사용하다보면 말이죠.)

쓸만한 IDE가 없는것. GUI가 아직 불안정한것

기타 등등이 있겠네요.

호랑이의 이미지

꼬마앙마 wrote:

==> 정말 불가능하나요? 저는 이럴경우 주로 튜플을 사용하는데...


제가 알기로는 python에는 static property 지원을 안하기 때문에 singleton을 구현하기 위해서는 global 변수를 사용하는 것으로 알고 있습니다.
제가 모르고 있다면 튜플을 이용한 싱글턴 구현 좀 보여주실 수 있습니까요?

꼬마앙마 wrote:

==> 파이썬 사용하면서 접근 제한자 때문에 문제가 생긴적은 한번도 없습니다. 접근 제한자는 '못' 지원하는게 아니라 '안' 지원하는겁니다.

다른분 답변을 보니 어느정도 지원하고 있는 것으로 보입니다.
접근 제한자는 없어도 가능하지만 있으면 더 좋은 기능이라고 생각합니다.

>>> class Python:
	def __init__(self):
		self.msg = 'Hello World!'
	def out(this):
		print this.msg

		
>>> x = Python()
>>> Python.out(x)
Hello World!

꼬마앙마 wrote:

일단... 코드가 틀렸네요.
파이썬도 됍니다.
x.msg = "Hello Python!" 이렇게 저장할수 있죠.
예를들어 이런것도 됩니다.
class a:
    pass
b = a()
b.Hello = "Hello"
print b.Hello


뭐가 틀렸다고 하시는지 모르겠네요.
설마 x.out()을 쓸줄 몰라서 Python.out(x) 이렇게 호출했다고 생각하시나요?
Python.out(x) 문장은 정상적으로 실행되며, 함수에 구조체를 넘기는 구조를 표현하기 위해 쓴 것입니다.
예시로 들어주신 코드는 뭘 보여주려는 건지 모르겠습니다.

꼬마앙마 wrote:

==> self는 클래스내에서 멤버변수에 접근하기위한 하나의 약속입니다. 싫으시면 안써도 상관없는데요?

대부분의 다른 언어에서 쓰지 않아도 되는 코드를 써야 하는 건 즐겁지 않은 일이죠.
왜 쓸모 없는 약속을 만들었냐는 것입니다.
제가 든 예시 코드를 보시면 한 번은 self로 한 번은 this로 넘겼습니다.
정상 작동 하지만 좋아보이지는 않습니다.
싫으면 안써도 되나요? 꼭 써줘야 하는 것으로 알고 있는데 예시 크드 좀 보여주십쇼.

검색을 해보니 Ruby와 Python을 비교한 글이 상당히 많다는 것을 발견했습니다.
결론들을 보면 Ruby가 OOP를 더 잘 지원하고 있지만 둘이 크게 다르지도 않다고 하네요.
저는 여전히 python을 좋아하고 ruby도 공부해 볼 생각입니다.
python으로 싱글턴을 만들 때 전역변수를 써야 했을 때 실망했던 것과 매번 self를 써줘야 하는 일 때문에 python에서 아쉬움을 느꼈었기에 python oop가 아쉬웠던 것 뿐입니다.
답변 달아주신 분들 덕분에 python에 대해 좀 더 알게되서 기쁘군요.

lifthrasiir의 이미지

싱글턴을 만드는 것이라면 2.4부터 추가된 decorator를 쓰면 크게 어렵지 않을 것 같습니다. self를 매번 쓰는 문제는 어떻게 보면 선택의 문제라고 할 수도 있고 (메소드도 함수라면 그런 생각도 나올 수 있는 법이죠.) oop 지원 자체의 문제는 아니라고 생각합니다.

그럼에도 불구하고 몇 가지 면에서 아쉬운 점이 있긴 합니다. 접근 제한자와 static 변수에 대한 지적은 저도 공감하는데, __로 시작하는 이름을 자동으로 치환해 버리는 건 개인적으로 좀 깔끔하지 못 하다고 생각합니다. static 변수도 함수 자신에 클래스 속성을 넣을 수 있기 때문에 해결은 가능하긴 하지만 그리 좋아 보이지는 않는 해결책이죠. (매 번 함수 이름을 써야 하는...)

저도 파이썬과 루비를 둘 다 알긴 합니다만, 두 언어 중 어느 게 oop 지원이 좋다 안 좋다 하는 건 큰 의미가 없을 것 같습니다. (모든 개념을 구현 가능한 상태에서 self 같은 문제는 거의 취향이 되겠죠) 명료성에서는 전 루비의 손을 좀 더 들어 줄 것 같긴 하지만요.

- 토끼군

creativeidler의 이미지

self나 @나 똑같은 거 아닌가요. 기호만 다를 뿐. 둘다 this를 생략할 수 있는 다른 언어에 비하면 불편하죠.

호랑이의 이미지

creativeidler wrote:
self나 @나 똑같은 거 아닌가요. 기호만 다를 뿐. 둘다 this를 생략할 수 있는 다른 언어에 비하면 불편하죠.

뭔가 오해하셨나 봅니다.
self의 불편한 점은 self.property를 말한 것이 아니고.

class Example:
    def plus(self, a):        <- method의 파라메터에 써 줘야 하는 불편을 말한 것입니다. 함수에 구조체를 넘기고 있는 것이죠.
        return self.value + a <- 이곳에 써준 self를 말하는 것이 아닙니다.
nohmad의 이미지

creativeidler wrote:
self나 @나 똑같은 거 아닌가요. 기호만 다를 뿐. 둘다 this를 생략할 수 있는 다른 언어에 비하면 불편하죠.

위에 제가 적었는데, 루비에서 @은 인스턴스 변수에만 붙입니다. 인스턴스 변수는 기본으로 외부에서 접근하지 못하고attr(_reader|_writer|_accessor) 같은 클래스 메쏘드를 이용해서 속성으로 등록해줘야 합니다. 파이썬에서는 같은 인스턴스의 메쏘드를 호출할 때도 self를 붙여야 하는 반면 루비는 알아서 찾아줍니다. @var는 self.var에 비해 4자나 타이핑을 줄여줍니다.

그리고 this를 생략할 수 있는 것이 별로 장점은 아닌 것 같습니다. 네임스페이스 꼬일 걱정을 하느니 @으로 구분하는 것이 훨씬 낫죠. 다행히 루비에서 변수의 스코프는 이름만 보면, 전역인지($), 상수인지(대문자), 클래스로컬인지(@@), 인스턴스인지(@), 지역인지 알 수 있게끔 되어 있습니다.

nohmad의 이미지

꼬마앙마 wrote:
루비의 단점이라면, 파이썬에 있는 유연한 자료구조가 없는것.

라이선스가 GPL인것.

속도가 느린것.

라이브러리가 적은것.

코드를 알아보기 어려운것.(펄보다는 쉽지만)

타이핑 하기 귀찮은것.(파이썬을 사용하다보면 말이죠.)

쓸만한 IDE가 없는것. GUI가 아직 불안정한것

기타 등등이 있겠네요.

1. 어떤 유연한 자료구조를 말씀하시는 건가요?

2. 루비 인터프리터 및 런타임 라이브러리의 라이센스 구문이 좀 모호하긴 합니다만, 듀얼 라이센스 정책이어서 GPL로도 배포할 수 있고, 바이너리로 배포시 원본 소스(루비 그 자체)의 출처를 명시하면 된다고 쓰여져 있습니다. 표준배포 라이브러리들의 라이센스는 통일되어 있지 않기 때문에 조금 모호한 채로 남아 있습니다.

3. 속도는 최적화할 여지가 너무나도 많기 때문에 속도 문제가 방해가 되는 경우는 많지 않을 것 같습니다. 비교대상이 C/C++/Java 수준이라면 당연히 느릴 수밖에 없고, 비교대상이 펄이나 파이썬 같은 동급 언어라면 약간의 최적화 지식으로 근접한 속도를 내는 것이 어렵지 않다, 정도로 정리할 수 있을 것 같습니다. 사실 다른 더 중대한 약점에 비하면 속도 문제는 사소한 약점입니다. ;-)

4. 펄이나 파이썬에 비하면 양적으로나 질적으로 부족한 것이 사실입니다. 그래도 사용인구의 격차에 비하면 그 차이는 상대적으로 적은 것 같습니다.

5. 루비 코드를 알아보기가 어렵나요? IORCC(International Obfuscated Ruby Code Contest)의 캐치프레이즈 중 하나는 '루비로도 읽기 어려운 코드를 쓸 수 있다', 였습니다만 ;-), 얼마나 잘 읽히는가는 철저하게 주관적인 부분이라고 생각합니다.

6. 루비는 신택스 축약의 여지가 많고, 함수형 언어들처럼 메쏘드 연쇄를 잘 지원하기 때문에, 평균적으로 파이썬 코드에 비해 더 적은 타이핑으로 같은 일을 할 수 있습니다.

7. IDE 지원은 많이 부족합니다. 그러나 역으로 생각해보면, IDE 도움 없이도 코딩하는데 별로 불편하지 않아서 그런 것일 수도 있다고 생각합니다. 인텔리센스, 디버거, 리팩토링 등 IDE 도움을 받으면 좋은 것들도 있지만, vim/emacs만으로도 충분하다고 생각하는 사람들도 있으니까요. vim + screen + irb 정도의 조합이면 루비 프로그래밍하는데 별로 불편함을 못 느낍니다. GUI 툴킷은 Tk나 gtk, Qt 바인딩은 쓸만한 수준이라고 생각합니다.

j0nguk의 이미지

제목은 ruby의 단점에 관한 질문이었는데, python vs ruby가 되어버린 것 같군요.

단점은 역시 library의 부족인 것 같습니다. 저는 perl user인데, 깔끔한 문법 때문에 ruby에 많이 끌렸었거든요. 그래서 공부도 좀 하고 숙제할 때도 써먹고 하긴 했는데요, CPAN과 비교했을때 확실히 좀 부족하구요, (양과 관리 측면) perldoc과 같은 편리한 문서 보기에 좀 부족한 면이 있어보입니다.

제가 느낀 건 이정도...
결국 perl을 다시 쓰죠.

:wink:

nainu의 이미지

파이썬에 없는 static 변수가 혹시 PHP코드에 있는 아래의

class A
{
  function & get_instance ()
  {
    static $instance = null;
    if (!$instance) {
      $this->instance = new A;
  }
  return $this->instance;
}

할때의 그 static 변수라면, 이렇게 하면 됩니다.

class A:
  instance = None
  def get_instance (klass):
    if not klass.instance:
      klass.instance = A()
    return klass.instance
  get_instance = classmethod(get_instance)

  def __init__ (self):
    ....

파이썬에서 클래스 바로 아래 쓰는 변수는 클래스 변수입니다. 멤버변수가 아니죠.. 이걸 이용하면 static 변수 대용으로 사용 가능합니다.

lifthrasiir의 이미지

nainu wrote:
파이썬에 없는 static 변수가 혹시 PHP코드에 있는 아래의
class A
{
  function & get_instance ()
  {
    static $instance = null;
    if (!$instance) {
      $this->instance = new A;
  }
  return $this->instance;
}

할때의 그 static 변수라면, 이렇게 하면 됩니다.

class A:
  instance = None
  def get_instance (klass):
    if not klass.instance:
      klass.instance = A()
    return klass.instance
  get_instance = classmethod(get_instance)

  def __init__ (self):
    ....

파이썬에서 클래스 바로 아래 쓰는 변수는 클래스 변수입니다. 멤버변수가 아니죠.. 이걸 이용하면 static 변수 대용으로 사용 가능합니다.

아마 그 static 변수라는 것은 이런 코드를 의미할 것입니다.

function accumulator($value=null) {
    static $sum = 0;
    if(is_null($value)) {
        $sum = 0;
    } else {
        $sum += $value;
    }
    return $sum;
}

파이썬에서도 전역 변수를 쓰지 않고 다음과 같은 코드를 사용할 수 있습니다. 좀 번거롭다는 문제가 있지요.

def accumulator(value=None):
    try: sum = accumulator.sum
    except: sum = 0
    if value is None:
        sum = 0
    else:
        sum += value
    accumulator.sum = sum
    return sum

- 토끼군

creativeidler의 이미지

Quote:

그리고 this를 생략할 수 있는 것이 별로 장점은 아닌 것 같습니다. 네임스페이스 꼬일 걱정을 하느니 @으로 구분하는 것이 훨씬 낫죠. 다행히 루비에서 변수의 스코프는 이름만 보면, 전역인지($), 상수인지(대문자), 클래스로컬인지(@@), 인스턴스인지(@), 지역인지 알 수 있게끔 되어 있습니다.

그건 다행한 일이 아니라 단점 같아보입니다. IDE에서 하이라이팅으로 해결할 수 있는 문제죠. 이런 문제를 언어 차원에서 해결하고 있다는 것은 헝가리안 표기법과 같은 냄새를 풍기고 있다고 할 수 있죠.

익명 사용자의 이미지

다음 내용은 "깔쌈한" 언어들 대다수에 적용되는 이야기일 것 같습니다.

루비의 단점은 다른 언어에 비해 사용자가 적다는 것입니다. 물론 상대적인 이야기이므로 아무 가치 없는 발언 아니냐 생각할 수 있겠지만, 사용자가 점점 적어지다보면 어느 시점에 양적 변화가 질적 변화로 나타날 수 있습니다.

언어적인 면에서 보아, 루비가 파이썬보다 더 깔쌈하다고 생각합니다. 하지만 실용적인 면에서 주어진 시간 동안 해낼 수 있는 일의 폭과 깊이에서는 파이썬이 십중팔구 아직까지는 낫다고 봅니다.

깔쌈하다는 언어들은 신비롭게도 사용자가 별로 없습니다. 엘리티즘 때문인지 Worse is Better 때문인지는 모르겠으나, 어쨌건 사용자가 적으면 숨겨진 문제가 많고 손대지 않은 부분이 널려있습니다. 문턱이 높고, 한번 함정에 빠지면 엄청나게 헤맬 수 있습니다(Leaky Abstraction 등).

언어적인 면에서 어떤 언어가 우수한지는 생판 초보자에게 그 언어를 가르쳐보면 압니다. 우수한 언어일수록 근본 패러다임만 깨달으면 빨리 배우고 실수가 적습니다. 하지만 온실을 벗어나서 실제 다양한 로우,하이 레벨의 문제들을 풀려고 하다보면 만만치가 않습니다. 그러다보니 마음으로는 깔쌈한 언어를 좋아하지만 몸은 그럭저럭 견딜만하지만 일을 해낼 수 있는 언어 쪽으로 쏠리는 것 같습니다.

예를 들어 파이썬에서 이런 이런 일을 하고 싶다 하면 구글이나 메일링 리스트를 검색해보면 십중팔구 그런 라이브러리가 이미 있거나, 혹은 누가 질문으로 올리고 또 수십명이 답을 해놓았습니다. 루비는 아직 큰 차이가 있는 것 같습니다.

현재 루비의 가치는 특정 도메인(예컨대 간단한 스크립팅, 웹개발의 일부나 DSL 특히 EDSL)에 한정해서 빛난다고 생각합니다.

마음적으로는 루비를 좋아하는 사람이

nohmad의 이미지

creativeidler wrote:
Quote:

그리고 this를 생략할 수 있는 것이 별로 장점은 아닌 것 같습니다. 네임스페이스 꼬일 걱정을 하느니 @으로 구분하는 것이 훨씬 낫죠. 다행히 루비에서 변수의 스코프는 이름만 보면, 전역인지($), 상수인지(대문자), 클래스로컬인지(@@), 인스턴스인지(@), 지역인지 알 수 있게끔 되어 있습니다.

그건 다행한 일이 아니라 단점 같아보입니다. IDE에서 하이라이팅으로 해결할 수 있는 문제죠. 이런 문제를 언어 차원에서 해결하고 있다는 것은 헝가리안 표기법과 같은 냄새를 풍기고 있다고 할 수 있죠.

단순히 헝가리안 냄새라고만 말하는 것은 불충분합니다. 헝가리안 표기법이 문제가 되는 것은 이름공간을 난잡하게 만들기 때문입니다. 그러나 위의 기호들이 과연 이름공간을 난잡하게 만들고 있나요? 그렇게 생각하신다면 아마도 좀더 설명이 필요할 것 같습니다. 저는 아직 전역변수, 상수, 클래스로컬 변수, 인스턴스 변수, 일반 로컬 변수를 구분해서 하이라이팅해주는 IDE를 본 적이 없는데, 혹시 스크린샷이라도 보여줄 수 있습니까? 그리고 모든 사람이 똑같은 IDE를 사용하는 것은 아니기 때문에 이렇게 특수한 상황에서 IDE를 언급하는 것은 넌센스라고 생각합니다.

creativeidler의 이미지

Quote:
단순히 헝가리안 냄새라고만 말하는 것은 불충분합니다. 헝가리안 표기법이 문제가 되는 것은 이름공간을 난잡하게 만들기 때문입니다. 그러나 위의 기호들이 과연 이름공간을 난잡하게 만들고 있나요?

이름공간을 난잡하게 만든다는 것이 소위 말하는 namespace pollution을 말씀하시는 건가요? 그거라면 헝가리안 표기법과도 상관 없는 문제입니다. 제가 헝가리안 표기법 냄새를 언급했을 때의 헝가리안 표기법의 문제는 변수의 역할과 의미 정보가 아닌 구조 정보, 문법 정보가 변수명에 들어간다는 것이고 이 점에 관해서는 루비의 @, $들도 같은 문제입니다.

Quote:
저는 아직 전역변수, 상수, 클래스로컬 변수, 인스턴스 변수, 일반 로컬 변수를 구분해서 하이라이팅해주는 IDE를 본 적이 없는데

웬지 난 본 적이 없는데 정말 있긴 있냐, 있으면 어디 한 번 대봐라...하는 식의 뉘앙스가 느껴져서 기분이 썩 좋진 않군요. 혹시 스크린 샷이라도 보여줄 수 있냐구요? 제 말이 아주 거짓말처럼 보이시나보죠?

대부분의 메이저 자바 IDE가 지원하는 기능입니다. 물론 자바엔 전역이 없기 때문에 static 변수, 멤버 변수, 지역 변수 정도를 구분해주죠. 덧붙여 상수도 구분할 수 있구요. 물론 이클립스도 지원합니다. 딱 이 기능이 없더라도 변수 정보가 팝업으로 뜬다든지, CTRL 클릭 등으로 쉽게 정의한 곳으로 찾아갈 수 있다든지 보조 장치도 있기 때문에 변수의 scope를 몰라서 삽질하는 경우는 극히 드물죠. 넌센스니 뭐니 하기엔 너무 많은 IDE가 있답니다.

자바에 한정된 얘기 아니냐구요? 최소한 자바에 비해 ruby가 이런 점에서는 LanguageSmell이 있다라고는 말할 근거는 되겠죠. 즉, 자바에서 할 수 있다면, 루비든 파이썬이든 할 수 있는 일이라는 겁니다.

nohmad의 이미지

creativeidler wrote:
이름공간을 난잡하게 만든다는 것이 소위 말하는 namespace pollution을 말씀하시는 건가요? 그거라면 헝가리안 표기법과도 상관 없는 문제입니다. 제가 헝가리안 표기법 냄새를 언급했을 때의 헝가리안 표기법의 문제는 변수의 역할과 의미 정보가 아닌 구조 정보, 문법 정보가 변수명에 들어간다는 것이고 이 점에 관해서는 루비의 @, $들도 같은 문제입니다.

네임스페이스 오염과는 아무 상관없습니다. 제가 말한 난잡함은 프로그램의 로직과는 상관없는, 언어의 특성에 종속적인 이름들이 판을 친다는 의미 정도였습니다. 헝가리안 표기법은 프로그램의 '의미'와 상관없는 해당 언어의 문법과 관계된 정보가 '의미'를 잠식하기 때문에 나쁜 것입니다. 루비에서 @, $의 사용이 의미를 잠식하지는 않습니다. 고작 기호 하나가 어떻게 뒤따르는 이름들을 잡아먹을 수 있습니까? 그런데도 상당히 단정적인 어조로 말씀하시는 것에 대해 저는 그저 놀라울 따름입니다.

creativeidler wrote:
Quote:
저는 아직 전역변수, 상수, 클래스로컬 변수, 인스턴스 변수, 일반 로컬 변수를 구분해서 하이라이팅해주는 IDE를 본 적이 없는데

웬지 난 본 적이 없는데 정말 있긴 있냐, 있으면 어디 한 번 대봐라...하는 식의 뉘앙스가 느껴져서 기분이 썩 좋진 않군요. 혹시 스크린 샷이라도 보여줄 수 있냐구요? 제 말이 아주 거짓말처럼 보이시나보죠?

저야말로 기술 토론에서 이런 식의 반응을 접할 때마다 당황스럽습니다. "IDE에서 하이라이팅으로 해결할 수 있는 문제"라시길래 어떤 똑똑한 IDE가 변수의 스코프 정보까지 하이라이팅으로 보여주는지 놀라워서 물어본 거였습니다.

creativeidler wrote:
대부분의 메이저 자바 IDE가 지원하는 기능입니다. 물론 자바엔 전역이 없기 때문에 static 변수, 멤버 변수, 지역 변수 정도를 구분해주죠. 덧붙여 상수도 구분할 수 있구요. 물론 이클립스도 지원합니다. 딱 이 기능이 없더라도 변수 정보가 팝업으로 뜬다든지, CTRL 클릭 등으로 쉽게 정의한 곳으로 찾아갈 수 있다든지 보조 장치도 있기 때문에 변수의 scope를 몰라서 삽질하는 경우는 극히 드물죠. 넌센스니 뭐니 하기엔 너무 많은 IDE가 있답니다.

자바에 한정된 얘기 아니냐구요? 최소한 자바에 비해 ruby가 이런 점에서는 LanguageSmell이 있다라고는 말할 근거는 되겠죠. 즉, 자바에서 할 수 있다면, 루비든 파이썬이든 할 수 있는 일이라는 겁니다.

하이라이팅은요?

저도 바보는 아니기 때문에 메이저 IDE들이 얼마나 멋진 기능을 제공하는지는 대충 알고 있습니다. 일부 부러운 면도 있구요. 위에 제가 루비의 단점으로 썼다시피, 리팩토링, 소스 폴딩, 인텔리 센스, 그외 CVS를 비롯 각종 개발도구와의 연동 등을 제대로 지원하면서 미려한 UI를 가진 IDE가 루비쪽엔 거의 없습니다. 사실 이클립스 JDT 외에 지금 열거한 기능들을 제대로 만족시키는 '공개' IDE는 언어를 불문하고 찾기도 힘듭니다. 그러나 @과 $가 주는 명확성은 IDE가 못 따라옵니다. 코드만 보면 아는데, 굳이 컨트롤-스페이스를 누르거나 마우스를 클릭하거나, 코드 브라우저를 뒤져볼 필요가 없는 거죠.

다시 헝가리안 표기법의 문제로 돌아가면, @, $, @@ 등등이 명시적으로 네임스페이스를 분리시켜주기 때문에, 더 일반적이고 좋은 이름들을 자유롭게 사용할 수 있습니다.

juneaftn의 이미지

저를 포함 제 주변에서 Java 등의 IDE가 잘 갖춰진 언어와, Ruby나 Python 등 IDE가 그만큼 기능이 많지 못한 언어를 두루 잘 쓰는 사람들을 보면 그들의 생각은 거의 일관됩니다.

생산성, 편리함, 사고의 흐름(몰입) 등으로 보면
----
1)

동적인 언어 + 간단한 IDE(혹은 편집기) + xUnit

>

정적인 언어 + 복잡한 기능의 IDE

----
2)

동적인 언어 + 간단한 IDE(혹은 편집기) + xUnit

>=

정적인 언어 + 복잡한 기능의 IDE + xUnit

----

동적인 언어에도 Refactoring Browser들이 있긴 한데(최초의 자동 리팩토링 기능은 스몰토크라는 동적 언어에서 나왔죠), 자바랑 이클립스 쓸 때에 비해 1/10 정도의 빈도로 쓰게 되는 것 같습니다.

그런데 2번의 경우, 처음에는 왼쪽과 오른쪽이 거의 동등하지만, 프로그램의 요소들이 많아지고 복잡도가 올라가면 점점 동적인 언어쪽이 더 우세해지는 것 같습니다.

creativeidler의 이미지

Quote:
루비에서 @, $의 사용이 의미를 잠식하지는 않습니다. 고작 기호 하나가 어떻게 뒤따르는 이름들을 잡아먹을 수 있습니까?

반대로 질문을 해보죠. n, sz, m_ 등의 고작 한두 글자가 어떻게 뒤따르는 이름들을 잡아먹을 수 있습니까? @, $와 n, sz, m_ 등이 뭐가 그렇게 다른가요?

물론 전 헝가리안 표기법보다는 @, $, @@가 좀 낫다고 생각합니다. 이건 아예 문법 요소로 들어왔으니까요. 하지만 @와 m_는 개발자 입장에선 완전히 같은 역할을 하는데 기호라서 괜찮고 알파벳 들어가서 안된다면 뭔가 불공평한 발상 아닙니까?

Quote:
하이라이팅은요?

된다고 적은 것 같은데요?

Quote:
저야말로 기술 토론에서 이런 식의 반응을 접할 때마다 당황스럽습니다. "IDE에서 하이라이팅으로 해결할 수 있는 문제"라시길래 어떤 똑똑한 IDE가 변수의 스코프 정보까지 하이라이팅으로 보여주는지 놀라워서 물어본 거였습니다.

기술 토론이라고 아무렇게나 말해도 되는 건 아니겠죠. 그냥 본 적이 없어서 모른다면 "전 본 적이 없는데 어떤 IDE인지 가르쳐주시겠습니까?" 정도로 질문해야하지 않을까요? 몰라서 물어본다면서 혹시 스크린샷이라도 보여줄 수 있냐는 식으로 물으면 곤란하죠. 거기다 뒤에는 넌센스라는 표현까지 쓰셨죠. "당신의 주장은 죄다 넌센스입니다." 하면 기분 좋겠습니까?

Quote:
코드만 보면 아는데, 굳이 컨트롤-스페이스를 누르거나 마우스를 클릭하거나, 코드 브라우저를 뒤져볼 필요가 없는 거죠.

하이라이팅 되서 보면 바로 안다는 말, 안했던가요? 상수까지 구분해서 보여준답니다.

Quote:
사실 이클립스 JDT 외에 지금 열거한 기능들을 제대로 만족시키는 '공개' IDE는 언어를 불문하고 찾기도 힘듭니다.

공개를 찾는다면 많진 않습니다. 하지만 이 문제에서 꼭 '공개'여야할 필요는 없다고 봅니다. 눈을 상용으로 돌린다면 그 정도 제공하는 IDE는 적지 않습니다. 어차피 이클립스나 넷빈즈도 대기업의 막강한 지원을 등에 업고 성장한 것이기도 하구요. 그리고 그런 IDE가 없기 때문에 언어를 그렇게 만들었다? 뭔가 이상하지 않습니까?

Quote:

다시 헝가리안 표기법의 문제로 돌아가면, @, $, @@ 등등이 명시적으로 네임스페이스를 분리시켜주기 때문에, 더 일반적이고 좋은 이름들을 자유롭게 사용할 수 있습니다.

자꾸 네임스페이스란 표현을 쓰시는데 굳이 말하자면 틀린 표현은 아니지만 조금 다른 문제죠. 자바 같은 언어는 @, $ 없어도 마음대로 이름 쓸 수 있지 않습니까. 더 일반적이고 좋은 이름을 자유롭게 사용하기 위해서가 아니라 @, $, @@가 없으면 컴파일러조차 멤버 변수인지 지역변수인지 구분할 수 없기 때문입니다. 루비 문법상 어쩔 수 없는 문제죠. 이건 루비 뿐 아니라 변수 선언을 따로 할 필요가 없는 OOP 계열 언어에서 공통적인 문제입니다. 사실 이런 언어들에서는 self, @, $ 등도 없고 다른 장치도 없다면 IDE로도 해결할 수 있는 문제가 아니죠.

그렇다고 @, $ 등을 없애고 명시적인 선언을 해주는 게 낫다고 주장하고 싶은 생각은 없습니다. dynamic language로서의 장점이 훨씬 더 크니까요. 다만, 그렇다고 이게 단점이 아니라고 할 수는 없다는 것입니다. dynamic으로 가기 위해 어쩔 수 없는 희생이라 하더라도 냄새는 좀 난다... 그런 정도죠. 최소한 @이 m_보다 나은 점이 없다고는 할 수 있겠습니다.

creativeidler의 이미지

Quote:

2)

동적인 언어 + 간단한 IDE(혹은 편집기) + xUnit

>=

정적인 언어 + 복잡한 기능의 IDE + xUnit

이건 어떤가요?

동적인 언어 + 간단한 IDE(혹은 편집기) + xUnit

vs

동적인 언어 + 복잡한 기능의 IDE + xUnit

파이썬도 상용 IDE를 보면 남부럽지 않은 기능들 갖추고 있습니다. 동적인 언어는 IDE가 구려야 된다는 건 편견입니다.

익명 사용자의 이미지

creativeidler wrote:
Quote:

2)

동적인 언어 + 간단한 IDE(혹은 편집기) + xUnit

>=

정적인 언어 + 복잡한 기능의 IDE + xUnit

이건 어떤가요?

동적인 언어 + 간단한 IDE(혹은 편집기) + xUnit

vs

동적인 언어 + 복잡한 기능의 IDE + xUnit

파이썬도 상용 IDE를 보면 남부럽지 않은 기능들 갖추고 있습니다. 동적인 언어는 IDE가 구려야 된다는 건 편견입니다.

그렇게 되면 더 좋을 수도 있겠지만(그러나 항상 more가 better이지만은 않겠죠) 제 요지는 동적 언어에서 IDE가 이클립스 수준이 되지 않아도 이미 큰 이득이 있다는 이야기였습니다. 이클립스가 필요하냐 아니냐가 주요 논점이 아님을 주의해 주십시오.

nohmad의 이미지

creativeidler wrote:
Quote:
루비에서 @, $의 사용이 의미를 잠식하지는 않습니다. 고작 기호 하나가 어떻게 뒤따르는 이름들을 잡아먹을 수 있습니까?

반대로 질문을 해보죠. n, sz, m_ 등의 고작 한두 글자가 어떻게 뒤따르는 이름들을 잡아먹을 수 있습니까? @, $와 n, sz, m_ 등이 뭐가 그렇게 다른가요?

물론 전 헝가리안 표기법보다는 @, $, @@가 좀 낫다고 생각합니다. 이건 아예 문법 요소로 들어왔으니까요. 하지만 @와 m_는 개발자 입장에선 완전히 같은 역할을 하는데 기호라서 괜찮고 알파벳 들어가서 안된다면 뭔가 불공평한 발상 아닙니까?

별로 불공평하지 않은데요? m, sz 등은 문법에 없는 요소를 프로그래머들이 의도적으로 집어넣은 거라 원래의 의도였을 member varable, null-terminated string으로 자연스럽게 확장됩니다. 그리고 똑같은 명칭에 대해 누군가는 다른 이름을 사용할 가능성이 있다는 걸 염두에 두어야 합니다. @은 attribute를 연상케 하지만 이것은 문법이 강제하는 요소이므로 굳이 의도를 추측하고 확장할 필요가 없습니다. 'm_'으로 시작하는 이름은 멤버 변수라고 문법에서 강제한다면 아무도 좋아하지 않았겠지만 최소한 기호이기 때문에 의미 흐름을 방해하지 않아서 봐줄만 합니다.

creativeidler wrote:
Quote:
저야말로 기술 토론에서 이런 식의 반응을 접할 때마다 당황스럽습니다. "IDE에서 하이라이팅으로 해결할 수 있는 문제"라시길래 어떤 똑똑한 IDE가 변수의 스코프 정보까지 하이라이팅으로 보여주는지 놀라워서 물어본 거였습니다.

기술 토론이라고 아무렇게나 말해도 되는 건 아니겠죠. 그냥 본 적이 없어서 모른다면 "전 본 적이 없는데 어떤 IDE인지 가르쳐주시겠습니까?" 정도로 질문해야하지 않을까요? 몰라서 물어본다면서 혹시 스크린샷이라도 보여줄 수 있냐는 식으로 물으면 곤란하죠. 거기다 뒤에는 넌센스라는 표현까지 쓰셨죠. "당신의 주장은 죄다 넌센스입니다." 하면 기분 좋겠습니까?

존재하지도 않는 IDE 얘기를 한다면 그야말로 넌센스 아니겠습니까? 스크린샷을 보여달라고 하는 것이 왜 곤란한 일인가요? 정말로 있는지 확인해보고 싶으니 지금이라도 보여주시면 감사하겠습니다. 저도 어지간한 IDE는 최소한 구경은 다 해봤습니다만, 말씀하신 것처럼 하이라이팅으로 코드의 메타 정보를 명확하게 보여주는 IDE는 본 바 없습니다. 왜냐하면 하이라이팅이란 단지 주변 토큰과의 경계만 확정할 뿐 그 자체가 의미있는 정보가 되지는 않기 때문입니다. 빨간색이니까 멤버 변수, 녹색이니까 메쏘드, 이런 식으로 기억하는 사람이 있나요? 그리고 저는 '당신의 주장은 죄다 넌센스'라고 하지도 않았고, 특수한 문맥에서 IDE 얘기를 하는 것이 넌센스라고 했을 뿐입니다. 이런 식으로 구차한 얘기를 하는 것은 시간 낭비 같군요. 앞으로 가급적 이런 불필요한 얘기는 생략하고 주제에만 집중하기를 부탁드리겠습니다.

creativeidler wrote:
Quote:
사실 이클립스 JDT 외에 지금 열거한 기능들을 제대로 만족시키는 '공개' IDE는 언어를 불문하고 찾기도 힘듭니다.

공개를 찾는다면 많진 않습니다. 하지만 이 문제에서 꼭 '공개'여야할 필요는 없다고 봅니다. 눈을 상용으로 돌린다면 그 정도 제공하는 IDE는 적지 않습니다. 어차피 이클립스나 넷빈즈도 대기업의 막강한 지원을 등에 업고 성장한 것이기도 하구요. 그리고 그런 IDE가 없기 때문에 언어를 그렇게 만들었다? 뭔가 이상하지 않습니까?

우리는 지금 2000만원짜리 IDE 얘기를 하고 있는 것이 아닙니다. 언어 얘기를 하고 있습니다. 언어의 장단점을 얘기하는 데, IDE도 분명히 중요한 부분일 수 있습니다. createidler님에게는 그것만 보이실 수도 있겠지만, 그건 말리지 않겠습니다, 하지만 제발 "IDE가 없기 때문에 언어를 그렇게 만들었다" 이런 이상한 주장은 하지 말아 주십시요. 저는 언어의 디자인에 대해 얘기하고 있는 거지, 거대독점 기업이 얼마나 인심을 잘 쓰느냐의 문제를 얘기하고 싶지는 않습니다.

creativeidler wrote:
Quote:
다시 헝가리안 표기법의 문제로 돌아가면, @, $, @@ 등등이 명시적으로 네임스페이스를 분리시켜주기 때문에, 더 일반적이고 좋은 이름들을 자유롭게 사용할 수 있습니다.

자꾸 네임스페이스란 표현을 쓰시는데 굳이 말하자면 틀린 표현은 아니지만 조금 다른 문제죠. 자바 같은 언어는 @, $ 없어도 마음대로 이름 쓸 수 있지 않습니까. 더 일반적이고 좋은 이름을 자유롭게 사용하기 위해서가 아니라 @, $, @@가 없으면 컴파일러조차 멤버 변수인지 지역변수인지 구분할 수 없기 때문입니다. 루비 문법상 어쩔 수 없는 문제죠. 이건 루비 뿐 아니라 변수 선언을 따로 할 필요가 없는 OOP 계열 언어에서 공통적인 문제입니다. 사실 이런 언어들에서는 self, @, $ 등도 없고 다른 장치도 없다면 IDE로도 해결할 수 있는 문제가 아니죠.

그렇다고 @, $ 등을 없애고 명시적인 선언을 해주는 게 낫다고 주장하고 싶은 생각은 없습니다. dynamic language로서의 장점이 훨씬 더 크니까요. 다만, 그렇다고 이게 단점이 아니라고 할 수는 없다는 것입니다. dynamic으로 가기 위해 어쩔 수 없는 희생이라 하더라도 냄새는 좀 난다... 그런 정도죠. 최소한 @이 m_보다 나은 점이 없다고는 할 수 있겠습니다.

자바라고 특별히 좋은 이름을 자유롭게 사용할 수 있다기 보다는 사람들이 잘 대처하고 있다고 봐야겠죠. 이건 다른 언어들도 마찬가지입니다. 단지 다른 언어들에서는 좀더 명시적인 방식을 선호하고 있는 것 뿐입니다. 기호들을 사용하는 것이 '루비 문법상 어쩔 수 없는 문제'라기 보다는 그 방식이 더 좋다고 결정했기 때문입니다. 자바처럼 구현할려면 못할 것도 없겠지만 자바가 최선은 아니죠.

자바에는 좋은 IDE가 많음에도, 그리고 creativeidler님의 말씀처럼 자유로운 이름을 마음껏 쓸 수 있는데도, Doug Lea Notation을 쓰거나 존중하는 사람들도 많습니다. 아무리 IDE가 좋아도 코드 그 자체가 의미를 갖는 것이 중요하죠. 개인적으로 IDE의 화려하고 좋은 기능들이 코드를 읽고 쓰는 흐름을 끊는 경험을 많이 했기 때문에 저는 이런 심플한 방식이 장점이 많다고 생각합니다.

perky의 이미지

nohmad wrote:
루비의 표준배포 인터랙티브 인터프리터인 irb는 파이썬 기본 인터프리터 이상입니다. 루비는 GNU Readline을 사용할 수 있어서 탭 완성도 기본 지원되고, 스코프를 마음대로 이동할 수 있어서, 인스턴스 변수를 바깥이 아니라 인스턴스 내부에서 조사할 수도 있습니다.

파이썬의 기본 인터랙티브 모드도 당연히 GNU readline (또는 호환 readline 라이브러리)를 지원합니다. 자동 완성에서 파일명이 완성이 된다는 점이 엉뚱하게 생각되실 지도 모르겠지만.. :) 얼마든지 커스터마이즈가 가능하고 다른 인터랙티브 모드 셸들이 많이 있습니다.

nohmad wrote:
확실히 self는 파서가 알아서 똑똑하게 처리해주는 것이 좋다고 생각합니다. 파서가 해야 할 일을 사람에게 떠넘기는 것은 좋지 않다고 생각합니다. 루비에서는 인스턴스 변수는 @을 붙이고, 메쏘드는 우선순위 메커니즘이 똑똑하게 찾아줍니다.

최소한, 파이썬에서는 self처리가 파서가 할 일이 아닙니다. 파서는 파싱을 해야지 컴파일이라던지 네임스페이스 룩업이나 실행을 해서는 안 됩니다. 파이썬에서 self를 반드시 명시하는 이유는 네임스페이스 최적화를 위해서입니다.

파이썬의 지역 네임스페이스는 컴파일 타임(토크나이징이나 파싱 이후)에 모든 지역 네임스페이스 값들이 숫자로 인덱스가 돼서 바이트코드에 FAST 옵코드들로 저장이 됩니다. 따라서, 지역 변수의 개수는 실행 속도에 결정적인 영향을 미치며 지역변수냐 아니냐에 따라 룩업 속도 차이가 꽤 많이 납니다. 따라서, self를 쓰지 않고 묵시적으로 바깥 프레임들을 검사하게 한다면 파이썬의 네임스페이스 구조에서는 굉장한 속도 불이익이 따릅니다.

self를 쓰느냐 안 쓰느냐 하는 것은 단지 취향 차이일 뿐이며, 파이썬은 그 취향을 이용해서 최적화를 좀 더 하고 있을 뿐입니다.

You need Python

creativeidler의 이미지

Quote:
별로 불공평하지 않은데요? m, sz 등은 문법에 없는 요소를 프로그래머들이 의도적으로 집어넣은 거라 원래의 의도였을 member varable, null-terminated string으로 자연스럽게 확장됩니다. 그리고 똑같은 명칭에 대해 누군가는 다른 이름을 사용할 가능성이 있다는 걸 염두에 두어야 합니다. @은 attribute를 연상케 하지만 이것은 문법이 강제하는 요소이므로 굳이 의도를 추측하고 확장할 필요가 없습니다. 'm_'으로 시작하는 이름은 멤버 변수라고 문법에서 강제한다면 아무도 좋아하지 않았겠지만 최소한 기호이기 때문에 의미 흐름을 방해하지 않아서 봐줄만 합니다.

의미 흐름을 방해한다는 게 무슨 뜻인지 잘 모르겠네요. 문법이 강제하는 요소라는 이야기는 저도 했고 그래서 @가 헝가리안보다는 조금 낫다는 말을 했답니다. 그러나, 본질적으로 개발자에게 있어 @이 하는 역할은 m_과 같고 그런 면에서 같은 냄새를 풍긴다는 것입니다. 그리고 m_를 문법에서 강제한다면 아무도 좋아하지 않을 꺼라고 하셨는데 그렇다면 @를 문법에서 강제하는 건 좋아한다는 뜻인가요?

Quote:
스크린샷을 보여달라고 하는 것이 왜 곤란한 일인가요? 정말로 있는지 확인해보고 싶으니 지금이라도 보여주시면 감사하겠습니다.

거듭해서 "난 당신 말 못 믿겠으니 증거를 보여줘!" 라고 하시는데 이런 식이 무례하다는 생각은 해보신 적이 없나요? 그리고, 그 많은 IDE 중에서도 꼭 집어 님이 원하는 '공짜'인 이클립스를 말씀드렸는데도 스크린샷을 보여달라 함은 대체 무슨 의도인가요? 누구나 다운 받아서 확인해볼 수 있는 사항을 말했는데 '스크린샷을 보여줘' 한다면 '난 당신 말 못 믿겠어' 밖에 더 되나요.

Quote:
그리고 저는 '당신의 주장은 죄다 넌센스'라고 하지도 않았고, 특수한 문맥에서 IDE 얘기를 하는 것이 넌센스라고 했을 뿐입니다. 이런 식으로 구차한 얘기를 하는 것은 시간 낭비 같군요. 앞으로 가급적 이런 불필요한 얘기는 생략하고 주제에만 집중하기를 부탁드리겠습니다.

넌센스란 표현이 그렇게 막 해도 되는 말이 아니라는 말을 하고 싶었던 겁니다.

Quote:
거대독점 기업이 얼마나 인심을 잘 쓰느냐의 문제를 얘기하고 싶지는 않습니다.

주제에만 집중해달라면서 이런 말씀을 하시는 의도는 알 수가 없군요.

Quote:
createidler님에게는 그것만 보이실 수도 있겠지만, 그건 말리지 않겠습니다

상대의 말을 의심하는 것을 넘어서서 이제 상대의 지적 수준까지 깎아내리는 발언을 하고 있으십니다.

Quote:

자바라고 특별히 좋은 이름을 자유롭게 사용할 수 있다기 보다는 사람들이 잘 대처하고 있다고 봐야겠죠. 이건 다른 언어들도 마찬가지입니다.

자바라서 특별히 좋은 이름을 사용할 수 있다는 게 아니라 @, $가 없어도 좋은 이름을 사용할 수 있다는 주장을 하기 위한 근거로서 자바를 든 것입니다.

Quote:

단지 다른 언어들에서는 좀더 명시적인 방식을 선호하고 있는 것 뿐입니다. 기호들을 사용하는 것이 '루비 문법상 어쩔 수 없는 문제'라기 보다는 그 방식이 더 좋다고 결정했기 때문입니다. 자바처럼 구현할려면 못할 것도 없겠지만 자바가 최선은 아니죠.

제가 자바가 최선이라는 말을 하지 않았기 때문에 자바가 최선이 아니라는 말은 하실 필요가 없어보입니다만, 어쨋든 궁금한 게 있습니다. 어쩔 수 없는 문제가 아니라고 하셨는데 그 말씀은 선언 없이 변수를 쓸 수 있는 특징을 유지하면서 @, $ 없이 멤버 변수, 지역 변수를 구분할 수 있는 방법이 있다는 뜻인가요? 그것도 자바처럼? 어떤 방법인지 궁금한데 말씀해주시겠습니까?

Quote:
아무리 IDE가 좋아도 코드 그 자체가 의미를 갖는 것이 중요하죠.

바로 그겁니다. @는 의미 정보가 아니라 구조 정보이기 때문에 제가 문제 삼는 것이죠.
creativeidler의 이미지

Quote:
그렇게 되면 더 좋을 수도 있겠지만(그러나 항상 more가 better이지만은 않겠죠) 제 요지는 동적 언어에서 IDE가 이클립스 수준이 되지 않아도 이미 큰 이득이 있다는 이야기였습니다. 이클립스가 필요하냐 아니냐가 주요 논점이 아님을 주의해 주십시오.

논점에 대한 시각 차가 있는 듯 합니다. 제가 여기 끼어든 이유는 루비의 @, $, @@가 파이썬의 self.보다 낫다는 발언을 보고 여기에 이의를 제기하고 싶어서였고 그 이유 중 하나로 IDE에서 해결할 수 있는 문제를 루비에선 notation으로 해결하고 있다는 점을 들었습니다. 저에게 논점은 dynamic vs static이 아니라 IDE vs notation이었던 것이죠. 물론 어차피 이 notation이 dynamic이기 때문에 생긴 것이기는 하지만요.

익명 사용자의 이미지

nohmad wrote:

위에 제가 적었는데, 루비에서 @은 인스턴스 변수에만 붙입니다. 인스턴스 변수는 기본으로 외부에서 접근하지 못하고attr(_reader|_writer|_accessor) 같은 클래스 메쏘드를 이용해서 속성으로 등록해줘야 합니다. 파이썬에서는 같은 인스턴스의 메쏘드를 호출할 때도 self를 붙여야 하는 반면 루비는 알아서 찾아줍니다. @var는 self.var에 비해 4자나 타이핑을 줄여줍니다.

3자 인것 같습니다.
일반적인 키보드에서는 @를 사용하기 위해서는 쉬프트키 + 2를 눌러야 하니까요.

nohmad의 이미지

자꾸 불필요한 말씀을 보태시니 짧게 요점만 말하겠습니다.

creativeidler wrote:
의미 흐름을 방해한다는 게 무슨 뜻인지 잘 모르겠네요. 문법이 강제하는 요소라는 이야기는 저도 했고 그래서 @가 헝가리안보다는 조금 낫다는 말을 했답니다. 그러나, 본질적으로 개발자에게 있어 @이 하는 역할은 m_과 같고 그런 면에서 같은 냄새를 풍긴다는 것입니다. 그리고 m_를 문법에서 강제한다면 아무도 좋아하지 않을 꺼라고 하셨는데 그렇다면 @를 문법에서 강제하는 건 좋아한다는 뜻인가요?

@이 문법의 일부인 점이 좋습니다. 무시하기가 쉽다는 거죠. @var가 m_var 보다 var의 의미전달에 있어 더 낫습니다. 물론 이것은 취향의 문제입니다. 어차피 언어란 취향의 문제 아닙니까?

creativeidler wrote:
거듭해서 "난 당신 말 못 믿겠으니 증거를 보여줘!" 라고 하시는데 이런 식이 무례하다는 생각은 해보신 적이 없나요? 그리고, 그 많은 IDE 중에서도 꼭 집어 님이 원하는 '공짜'인 이클립스를 말씀드렸는데도 스크린샷을 보여달라 함은 대체 무슨 의도인가요? 누구나 다운 받아서 확인해볼 수 있는 사항을 말했는데 '스크린샷을 보여줘' 한다면 '난 당신 말 못 믿겠어' 밖에 더 되나요.

그렇게 생각하신다면 간단히 증명하실 수 있지 않습니까? 왜 무례하게 받아들이시는지 모르겠지만 creativeidler님의 말을 인용해보겠습니다.

creativeidler wrote:
그건 다행한 일이 아니라 단점 같아보입니다. IDE에서 하이라이팅으로 해결할 수 있는 문제죠. 이런 문제를 언어 차원에서 해결하고 있다는 것은 헝가리안 표기법과 같은 냄새를 풍기고 있다고 할 수 있죠.

어떤 똑똑한 IDE가 변수의 '스코프 정보'를 '하이라이팅'해서 보여주는지 정말로(!) 궁금했던 것입니다. 제 이클립스에서는 단순히 신택스 하이라이팅만 보여주는데, 코드 브라우저(이클립스 용어로는 outline perspective?)가 아닌 하이라이팅으로 표시해준다면 정말 굉장한 IDE라고 생각했던 것입니다.

creativeidler wrote:
Quote:
거대독점 기업이 얼마나 인심을 잘 쓰느냐의 문제를 얘기하고 싶지는 않습니다.

주제에만 집중해달라면서 이런 말씀을 하시는 의도는 알 수가 없군요.

이클립스는 IBM의 선심 아닙니까? 변수명 규칙과 같은 언어의 디자인과 관련된 문제에서 IDE를 얘기하는 것은 부적절합니다.

creativeidler wrote:
Quote:
createidler님에게는 그것만 보이실 수도 있겠지만, 그건 말리지 않겠습니다

상대의 말을 의심하는 것을 넘어서서 이제 상대의 지적 수준까지 깎아내리는 발언을 하고 있으십니다.

의심은 뭐고 또 지적 수준은 뭔가요? "그런 IDE가 없기 때문에 언어를 그렇게 만들었다?" 같은 황당한 얘기를 하시길래, IDE 밖에 안 보이시기 때문에 그런 게 아닐까 생각한 거죠.

creativeidler wrote:
Quote:
단지 다른 언어들에서는 좀더 명시적인 방식을 선호하고 있는 것 뿐입니다. 기호들을 사용하는 것이 '루비 문법상 어쩔 수 없는 문제'라기 보다는 그 방식이 더 좋다고 결정했기 때문입니다. 자바처럼 구현할려면 못할 것도 없겠지만 자바가 최선은 아니죠.

제가 자바가 최선이라는 말을 하지 않았기 때문에 자바가 최선이 아니라는 말은 하실 필요가 없어보입니다만, 어쨋든 궁금한 게 있습니다. 어쩔 수 없는 문제가 아니라고 하셨는데 그 말씀은 선언 없이 변수를 쓸 수 있는 특징을 유지하면서 @, $ 없이 멤버 변수, 지역 변수를 구분할 수 있는 방법이 있다는 뜻인가요? 그것도 자바처럼? 어떤 방법인지 궁금한데 말씀해주시겠습니까?

물론 선언이든 정의든 있어야겠죠. 루비에서는 인스턴스 변수를 외부에 공개하기 위해서는 attr_reader 같은 클래스 메쏘드를 이용해서 등록해주어야 합니다. 이것은 일종의 선언처럼 보입니다.

class K
  attr_reader :var
  def initialize
    @var = 123
  end
end

이로써 @var는 외부에 읽기 전용으로 공개됩니다. attr_reader가 하는 일은 var 라는 메쏘드를 정의하고, 그 메쏘드에서 @var를 리턴하는 일입니다.

class K
  def var
    return @var
  end
end

creativeidler wrote:
Quote:
아무리 IDE가 좋아도 코드 그 자체가 의미를 갖는 것이 중요하죠.

바로 그겁니다. @는 의미 정보가 아니라 구조 정보이기 때문에 제가 문제 삼는 것이죠.

그렇다고 상수를 대문자로만 쓴다던가 하는 이미 잘 확립된 규칙까지 문제삼을 필요는 없습니다. 더구나 @은 문법에서 강제된 사항이므로 고칠 수 없는 규칙입니다.

nohmad의 이미지

perky wrote:
파이썬의 기본 인터랙티브 모드도 당연히 GNU readline (또는 호환 readline 라이브러리)를 지원합니다. 자동 완성에서 파일명이 완성이 된다는 점이 엉뚱하게 생각되실 지도 모르겠지만.. :) 얼마든지 커스터마이즈가 가능하고 다른 인터랙티브 모드 셸들이 많이 있습니다.

그래서 위에 썼다시피 표준배포되는 인터랙티브 인터프리터를 비교한 것입니다. 사실 그전에 OP가 python 인터랙티브 인터프리터가 좋다고 한 것에 대해 제가 irb는 더 좋다는 걸 말한 거죠. 물론 파이썬 인터랙티브 인터프리터는 종류도 많고, 찾아보면 훌륭한 것들도 많겠지만, irb는 일부러 찾지 않더라도 속성 자동완성까지 지원하는 쓸만한 물건입니다.

perky wrote:
최소한, 파이썬에서는 self처리가 파서가 할 일이 아닙니다. 파서는 파싱을 해야지 컴파일이라던지 네임스페이스 룩업이나 실행을 해서는 안 됩니다. 파이썬에서 self를 반드시 명시하는 이유는 네임스페이스 최적화를 위해서입니다.

파이썬의 지역 네임스페이스는 컴파일 타임(토크나이징이나 파싱 이후)에 모든 지역 네임스페이스 값들이 숫자로 인덱스가 돼서 바이트코드에 FAST 옵코드들로 저장이 됩니다. 따라서, 지역 변수의 개수는 실행 속도에 결정적인 영향을 미치며 지역변수냐 아니냐에 따라 룩업 속도 차이가 꽤 많이 납니다. 따라서, self를 쓰지 않고 묵시적으로 바깥 프레임들을 검사하게 한다면 파이썬의 네임스페이스 구조에서는 굉장한 속도 불이익이 따릅니다.

self를 쓰느냐 안 쓰느냐 하는 것은 단지 취향 차이일 뿐이며, 파이썬은 그 취향을 이용해서 최적화를 좀 더 하고 있을 뿐입니다.

self를 쓰느냐 안 쓰느냐 뿐만 아니라 언어 스펙의 결정에 있어 따지고 보면 모든 것이 취향의 문제입니다. 그런데 이 취향의 문제 -- '디자인'이라는 좀더 그럴 듯한 이름으로 포장되기도 하는 -- 에 구현상의 이슈가 자주 개입하는 것은 '나쁜 냄새'라고 생각합니다. 물론 이 '나쁜 냄새' 역시 취향의 문제라면 취향의 문제죠. 세상만사가 그렇듯이.

creativeidler의 이미지

Quote:
자꾸 불필요한 말씀을 보태시니 짧게 요점만 말하겠습니다.

이런 말부터가 불필요할 뿐더러 상대방을 불쾌하게 만드는 말이라는 거, 모르시나요? 자기가 하는 말은 다 필요한 말이고 남이 하는 말은 다 불필요한 말? 자기가 좋아하는 루비의 @는 괜찮고 헝가리안의 m_는 싫고 파이썬의 self.도 싫다?

Quote:
왜 무례하게 받아들이시는지 모르겠지만 creativeidler님의 말을 인용해보겠습니다.

왜 무례하게 받아들였는지 친절하게 적어놨는데도 모른다면 읽지도 않고 답글을 다시는 것인가요? 그리고, 제가 스크린샷까지 떠서 님에게 보여줘야할 의무는 없는 것 같은데요? 걍 한 번 찾아보시죠. 어지간한 IDE는 다 봤다면서 그것도 한 번 안 봤습니까.

Quote:

물론 선언이든 정의든 있어야겠죠. 루비에서는 인스턴스 변수를 외부에 공개하기 위해서는 attr_reader 같은 클래스 메쏘드를 이용해서 등록해주어야 합니다. 이것은 일종의 선언처럼 보입니다.

선언이든 정의든 있어야한다는 말은 이미 dynamic language의 중요한 장점을 포기하는 것입니다. 그래서 루비의 문법상 @, $, @@는 필수불가결한 요소라는 겁니다. 님 생각처럼 명시성을 위해 필요 없는데 붙여놓은 요소가 아니라요. 외부에 공개하는 건 이미 선언이 있다면 공개하지 않는 멤버 변수는 어쩌시겠습니까.

Quote:

이클립스는 IBM의 선심 아닙니까? 변수명 규칙과 같은 언어의 디자인과 관련된 문제에서 IDE를 얘기하는 것은 부적절합니다.

제 주장이 뭔지 잘 모르시는 것 같습니다. 역시, 안 읽었죠? -_-++

Quote:
그렇다고 상수를 대문자로만 쓴다던가 하는 이미 잘 확립된 규칙까지 문제삼을 필요는 없습니다. 더구나 @은 문법에서 강제된 사항이므로 고칠 수 없는 규칙입니다.

@가 LanguageSmell이라는 주장에 대해 @는 문법에서 강제된 사항이니까 고칠 수 없다는 식의 반론은 뭔가 이상하다고 느끼지 않나요?

그리고 하나 더 덧붙이자면, self.이 길어서 싫다면 그건 제가 해결해드리겠습니다. 그냥 s.으로 쓰면 됩니다. 타이핑 수는 @와 같죠. 참고로 헝가리안 매니아인 제 후배 녀석은 m.으로 쓰더군요.

머, 구질구질하게 하나씩 반론을 달아봤습니다만, 어쨋든 최초에 제가 참여한 목적, 루비의 @는 파이썬의 self.에 비해 별반 나은 것이 아니며 헝가리안 표기법보다도 그리 나은 것이 아니라는 것은 충분히 입증한 듯 합니다. nohmad님 외에 이 주장에 이의를 제기하시거나 추가 설명을 요구하는 분이 없다면 전 여기서 마치렵니다.

nohmad의 이미지

creativeidler wrote:
왜 무례하게 받아들였는지 친절하게 적어놨는데도 모른다면 읽지도 않고 답글을 다시는 것인가요? 그리고, 제가 스크린샷까지 떠서 님에게 보여줘야할 의무는 없는 것 같은데요? 걍 한 번 찾아보시죠. 어지간한 IDE는 다 봤다면서 그것도 한 번 안 봤습니까.

왜 간단한 문제를 어렵게 만드시려는지 모르겠습니다. 자, 정리해봅시다. creativeidler님이 먼저 불충분한 근거로 단정을 하셨고, 저는 그에 대한 근거를 요구했습니다. 이게 왜 무례한 요구인지 저는 지금도 납득할 수 없을 뿐더러, 만일 이것을 무례라고 할 수 있다면 creativeidler님 역시 그 이상의 무례를 저질렀음을 말해두고 싶습니다. 제발 이런 문제는 더 이상 언급하지 않았으면 좋겠습니다(x 10). 우리가 무슨 상견례 자리에 와 있는 것도 아니고, 왜 이런 걸 따져야 합니까.

이 문제는 간단히 1) 변수의 스코프 정보를 하이라이팅으로 보여주는 장면을 스샷으로 첨부해서 증명하거나, 2) 용어상의 혼란을 해결하면 되는 거였습니다. 저는 아직도 creativeidler님이 '하이라이팅'이란 표현을 무슨 의미로 사용했는지 모르겠습니다. 제가 처음 이해한 것은 IDE의 '구문 강조(syntax highlighting)'의 의미였는데, 이것은 제가 아는 한 사실이 아닙니다. 그래서 좀더 일반적인 의미에서의 시각화 방식의 하나로써 '코드 브라우저'나 '아웃라인 패널'을 통한 표시, 또는 이클립스 고유의 code assist 같은 것을 의미하는 것일까라고도 생각했습니다. 어쨌든 갸우뚱한 상태로 혹시나 제가 느낀 '하이라이팅'이란 표현상의 혼동을 이해 못하실까봐 풀어서 말하기도 했습니다. 수차례에 걸쳐 제 언행으로 인해 감정을 상했다고 항의하시기 전에, 문제를 해결하기 위한 2가지 행동 중 하나라도 취했다면 어땠을까 싶습니다. 그럼 저는 그에 맞는 반론을 했을 것이고 더 이상 제가 납득 못할 감정의 소모는 없으셨을 것 같습니다.

creativeidler wrote:
선언이든 정의든 있어야한다는 말은 이미 dynamic language의 중요한 장점을 포기하는 것입니다.

선언이나 정의 없이, 거기에 자바처럼! 자바에서는 선언이나 정의가 있어야 멤버 변수가 될 수 있으므로 이것은 이미 논리적으로 모순입니다. 제가 적은 코드는 @ 없이 외부에서 인스턴스 변수를 사용하는 얘일 뿐이었습니다. 사실 외부에서는 아예 인스턴스 변수를 볼 수가 없습니다. 단지 메쏘드만 보일 뿐인 거죠. 루비의 @은 멤버 변수가 아니라 '인스턴스 로컬' 변수일 뿐입니다. 그런데 "dynamic language의 중요한 장점을 포기하는 것"이라는 말은 이해할 수 없군요. 참고로 루비에도 self가 있습니다. 이것은 파이썬의 self 보다는 자바의 this에 좀더 가까운데, 호출되는 스코프에 따라 클래스를 가리킬 수도 있고 인스턴스를 가리킬 수도 있습니다.

creativeidler wrote:
그래서 루비의 문법상 @, $, @@는 필수불가결한 요소라는 겁니다. 님 생각처럼 명시성을 위해 필요 없는데 붙여놓은 요소가 아니라요. 외부에 공개하는 건 이미 선언이 있다면 공개하지 않는 멤버 변수는 어쩌시겠습니까.

"필수불가결한 요소"라는 것이 무엇을 의미하는지 모르겠지만, @ 싫으면 안 쓸 수도 있습니다. 해시 객체 하나면 '인스턴스 로컬'이라는 조건을 충분히 구현할 수 있습니다. @@, $도 마찬가지입니다. 그런데 이걸 쓰고 안쓰고 하는 문제가 왜 문제가 되나요? 루비에선 이미 이것을 쓰는 것이 좋다고 결정했는데 말이지요. 외부에 공개하는 것도 attr_* 류의 클래스 메쏘드 도움 없이도 다 할 수 있습니다.

creativeidler wrote:
Quote:
그렇다고 상수를 대문자로만 쓴다던가 하는 이미 잘 확립된 규칙까지 문제삼을 필요는 없습니다. 더구나 @은 문법에서 강제된 사항이므로 고칠 수 없는 규칙입니다.

@가 LanguageSmell이라는 주장에 대해 @는 문법에서 강제된 사항이니까 고칠 수 없다는 식의 반론은 뭔가 이상하다고 느끼지 않나요?

creativeidler님의 'language smell' 주장의 근거는 @이 '구조 정보'를 포함한다는 것이었는데, 그래서 저는 CONSTANT_VARIABLE 같은 형태와 더불어 반론한 것입니다. 저는 구조 정보가 언제나 나쁜 것은 아니며, 표기법을 통한 해결 역시 상황에 따라 달리 논의해야 한다고 생각합니다. 단순히 헝가리안 냄새니까 나쁘다? 이것은 매우 단면적인 견해일 뿐 아니라, 헝가리안 표기법을 잘못 이해한 결과입니다.

사실 헝가리안 표기법은 '구조 정보' 같은 고차원적인 개념과는 무관하게 원래 타입이 없는 언어(BCPL)에서 타입 힌팅을 위해 사용하던 것이 C, C++ 등에서 변형되면서 몇가지 관습화된 타입과 한정어들의 약자로 정리된 것입니다. 그런데 이것을 확장해서, 헝가리안 표기법이 구조 정보를 표시하는 것까지 포함해버리면 헝가리안 표기법의 단점이 사라져버립니다. 기호를 특정한 의미로 사용하는 표기법은 무수히 많습니다. 유닉스의 쉘에서 $ 뒤에 오는 기호들, 파일시스템에서 . 으로 시작하는 파일이나 디렉토리는 숨겨진 것으로 간주하는 것, lisp/scheme의 destruct!, predicate? 함수 등등. 이 모든 것이 헝가리안 표기법의 냄새를 풍긴다면, 헝가리안 표기법의 진짜 나쁜 점은 은폐되어 버립니다.

표기법에 의한 암시적 규칙들은 '강제'이건 '관습'이건 각각의 맥락 안에서 의미를 갖기 때문에 그 내부를 이해한 상태에서 논의해야 합니다. 그런데 이런 맥락과 무관하게 이름 그 자체의 의미 외에 구조를 지시하는 표현 모두를 제거해버리고나서, IDE의 불완전한 힌트에만 의지해야 한다는 주장이 무슨 설득력이 있나요?

anarch의 이미지

개인적으로 Python을 좋아하고 Ruby를 개인적으로 안 좋아하는 사람입니다만.
저로써는 둘다 오픈소스 언어이고 (이런말을 하는 이유가.. 꼭 남은 파이를 나누는 듯한 느낌을 받아서 입니다..;;;) 흥미를 가지는 언어들입니다...

언어에 기호를 쓰면 영문자와 시각적인 차별을 줄수 있기때문에 적당히 쓰면
오히려 가독성이 높아 질수 있다고 생각되어 집니다.
하지만 자바나 파이썬이나 C#은 (자바의 어노테이션이나 파이썬의 데코레이터같은) 매우 쌩뚱맞은 곳에 기호를 쓰는 거 보면 쉽게 기호를 남발해서는 나중에 수습이 그다지 쉽지 않을까 생각됩니다.(뭐..제가 언어학자가 아니니까 걱정할 필요는 없지만.요.. :oops: )

개인적인 언어-유저의 입장으로는 파이썬의 객체-메소드의 첫 인자가 인스턴스 지시자(인스턴스 지시자라고 하나요?;;) 인것이 더 명확하게 보일수도 있겠다 생각이 드든군요..
저의 실력으로 고려해 보자면 타이핑이 빨라봤자입니다.ㅋㅋ;;(생각의 속도가 더 느립니다.ㅋㅋㅋ)

두 언어가 다른 메인-스트림 언어들보다 부족하다고 생각하는 점들은
표준 라이브러리들입니다..
자바의 경우도 매우 잘 정비된 네임스페이스-패캐지들이 있는데요..
(개인적으로는 java.io.* 이 System.IO.*보다 더 맘에 듭니다.;;)
파이썬은 표준 라이브러리가 좀 쳬계적으로 정리가 되었으면 하는 생각이 듭니다.
가령 py.io.* py.io.async.core ( 넘 자바 냄세가?;;) jython은 java.io.*; -_-;;

가까운 곳에 있는 Perl의 CPAN도 매력적이긴 하군요...(어떤지 잘은 몰라서.;;)

kylesmom의 이미지

파이썬의 라이브러리 이름에 문제가 있다는 데에는 전적으로 동감합니다.
shutil이 파일 관련 라이브러리인지.... os.system이 명령어를 실행할 수 있는 함수인지 직관적으로 알 수 있는 사람이 몇이나 될까요.
파이썬은 타이핑을 빨리하기 위해서 약어를 많이 쓰고 약어라도 대문자로 사용하지 않고 있죠.
매일 2시간정도 파이썬을 열심히 사용한다면 이런게 문제는 안되겠지만, 저처럼 한가지 언어만을 주로 사용하지 않는 사람에게는 이게 고역입니다.

ness4me의 이미지

평소 관심은 많았지만, 잘 모르고 있던 python & ruby 에 관하여 좋은 글들을 올려주시는 것에 감사드리며... :o

제가 조금~ 무지 조금~ 알고 있는 부분이 있어서, 이렇게 screen shot 을 올립니다.

익명 사용자의 이미지

위에서 classmethod를 보여 주셨는데, 저 경우에는 staticmethod를 사용하는 것이 일반적입니다. 2.4 버전을 사용한다면 다음과 같이 decorator를 이용할 수 있습니다.

class Klass:
    '''
    ex)

    >>> k = Klass()
    >>> k.static_method()
    haha
    >>> Klass.static_method()
    haha
    '''
    @staticmethod
    def static_method():
        print 'haha'

Singleton을 만들지 못하다니요? 다음과 같이 간단히 만들 수 있습니다.

class Singleton:
    '''
    ex)

    >>> class Mine(Singleton):
    ...     def __init__(self):
    ...         print 'Mine.__init__'
    ...
    >>> s = Mine.get_instance()
    Mine.__init__
    >>> s2 = Mine.get_instance()
    >>> assert s == s2 == Mine.get_instance()
    >>>
    '''
    @classmethod
    def get_instance(klass):
        if not hasattr(klass, '_the_instance'):
            klass._the_instance = klass()
        return klass._the_instance

static property가 없다는 것도 황당하군요. 저 위의 singleton 예제에서 _the_instance라는 프로퍼티를 동적으로 클래스에 심고 있습니다.

phil의 이미지

루비가 좋은 점은 딴 것도 많은데 nohmad님은 고작 self. 대신 @를 쓸 수 있으니 타이핑이 줄어든다는 점을 가지고(별로 장점 같아 보이지도 않습니다만) 소모적인 논쟁을 계속하고 계시는군요. 개인적으로 안타깝습니다. 위의 다른 분도 언급하셨지만 self.가 타이핑이 많다고 생각되면 m.이나 s.으로 바꾸면 됩니다. 다만 다른 프로그래머들이 self.를 많이 쓰니까 pseudo standard처럼 돼 버린 것이지요. 그리고 C++에서도 멤버에 따로 프리픽스 안 붙이고 파이선처럼 this->로 쓰는 사람들 많습니다. 3년 전까지 제 컨벤션이기도 했고요.

nohmad의 이미지

결국은 syntax highlighting을 의미하는 것이었군요. 위에도 썼듯이 토큰 경계의 구분 외에 IDE의 syntax highlighting 지원이 일반적인 수준에서 의미있는 정보를 준다고 볼 수는 없습니다. 물론 색맹이 아닌 어떤 사람이 중요한 도구로 사용할 수는 있겠지요.

phil wrote:
루비가 좋은 점은 딴 것도 많은데 nohmad님은 고작 self. 대신 @를 쓸 수 있으니 타이핑이 줄어든다는 점을 가지고(별로 장점 같아 보이지도 않습니다만) 소모적인 논쟁을 계속하고 계시는군요. 개인적으로 안타깝습니다. 위의 다른 분도 언급하셨지만 self.가 타이핑이 많다고 생각되면 m.이나 s.으로 바꾸면 됩니다. 다만 다른 프로그래머들이 self.를 많이 쓰니까 pseudo standard처럼 돼 버린 것이지요. 그리고 C++에서도 멤버에 따로 프리픽스 안 붙이고 파이선처럼 this->로 쓰는 사람들 많습니다. 3년 전까지 제 컨벤션이기도 했고요.

잡음이 많긴 했지만, 이런 사소한 문제도 한번쯤 건드려보는 것도 나쁘지 않다, 라고 생각하면 안될까요? 다른 좋은 주제는 또 다른 기회에 다뤄볼 수 있겠지요.

atie의 이미지

nohmad wrote:
결국은 syntax highlighting을 의미하는 것이었군요. 위에도 썼듯이 토큰 경계의 구분 외에 IDE의 syntax highlighting 지원이 일반적인 수준에서 의미있는 정보를 준다고 볼 수는 없습니다. 물론 색맹이 아닌 어떤 사람이 중요한 도구로 사용할 수는 있겠지요.
...

사소한 태클 하나, eclipse의 syntax coloring을 조금 손보면 아래 그림처럼 사용할 수 있습니다.
댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트

----
I paint objects as I think them, not as I see them.
atie's minipage

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.