Ruby의 단점을 알려주세요.

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

class sample_class:

    def __init__(self,Nmax=5):
        pass

    def __private_method(self,x):
         pass

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

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

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

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

생각나는 몇 가지 적어보겠습니다.
우선 처음으로 실망했던 것은 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!

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가 아직 불안정한것

기타 등등이 있겠네요.

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

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

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

- 토끼군

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 바인딩은 쓸만한 수준이라고 생각합니다.

파이썬에 없는 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 변수 대용으로 사용 가능합니다.

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

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

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

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

하이라이팅은요?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

물론 선언이든 정의든 있어야겠죠. 루비에서는 인스턴스 변수를 외부에 공개하기 위해서는 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

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

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

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

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

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

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

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

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

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

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

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