루비 : 나쁜 부분들

20

저는 최근 Crockford의 저서 "자바 스크립트 : 좋은 부분"을 읽었으며 기본 전제 중 하나는 프로그래밍 언어가 프로그래머가 피해야 할 잘못된 기능 세트를 가질 수 있다는 것입니다.

저는 루비 스트이고 언어를 좋아하지만 관점을 얻는 데 항상 가치가 있습니다. 그렇다면 루비에서 최악의 기능 (예 : 메소드, 클래스, 실습)은 무엇입니까? 여기서 나는 언어 자체의 장점이나 속도 등에 대한 논쟁을 시작하지 않을 것이다. 오히려 과거의 경험을 바탕으로 사용하기에 위험하고 번거롭고 고통스러운 기능에 대해 논의하고 싶습니다.

ruby

— 잭 킨 셀라
소스

1

나는 "end"라는 단어를 사용해야 만하는 팬이 아니며, "{"및 "}"과의 혼합이 더욱 성가신 것입니다. 파이썬 스타일의 구문이나 {&}을 바로 이해할 수 있습니다. 비록 이것에 대해 앞뒤로 논쟁 할 수는 있지만 궁극적으로 개인적인 취향과 관련이 있습니다. 누군가 루비가 파이썬과 펄의 가장 추한 부분을 취해 조립한다고 말합니다. 그래도 루비를 배우고 있습니다.

나는 실제로이 질문을 아주 좋아하고 답변을 기대하지만 그럼에도 불구하고 질문을 끝내기로 결정했습니다. 스택 오버플로에 적합하지 않다고 생각합니다 (너무 주관적이거나 논쟁 적이거나 개방적 인 것 등으로 인해).

— stakx

피해야 할 위험한 관행을 밝힐 수 있으므로 논의 할 가치가 있다고 생각합니다. 나는 당신의 요점을보고 질문을보다 좁게 편집했습니다.

9

이 질문이 어떻게 다른지 잘 모르겠습니다. 예를 들어 루비 언어로 개선하고 싶은 것은 무엇입니까? , 초보자에게 경고해야 할 Ruby Gotchas는 무엇입니까? , Ruby의 실제 문제는 무엇입니까? 루비의 고통에 대한 다른 가질 리언 질문. 심지어 플러스, 경우 이 질문은 그 다른 사람들로부터 자신을 차별화하는 진화, 그것은에 속하는 것 Programmers.SE ,하지에 StackOverflow.

— Jörg W Mittag

2

눈을 확인해야합니다.이 질문의 제목은 "Ruby : The Brad Pitts"라고 생각했습니다.

— oosterwal

8

Gary Bernhardt 의 Python vs Ruby : A Death to The Death를 시청해야합니다 . 그는 인용합니다 :

내가 루비에서 못생긴 것을 발견 한 것은 RSpec과 같은 놀라운 루비 소프트웨어를 가능하게하는 것이며, 파이썬이 결코 가질 수 없었던 것입니다 (현재 구현이 가능함).

그는 특히 파이썬에 대해 많이 이야기하지만 루비에서는 이상한 것들을 많이 만집니다. 가장 중요한 주제 중 하나는 원숭이 패치 입니다.

Ruby 객체 (다른 객체 지향 언어의 객체와 달리)는 개별적으로 수정할 수 있습니다. 항상 객체별로 메소드를 추가 할 수 있습니다. Ruby에서 객체의 동작 또는 기능은 해당 클래스에서 제공하는 것과 다릅니다.

이것은 많은 유연성을 제공하고 Ruby의 가장 인기 있고 복잡한 보석 중 일부를 강화하지만 일부 라이브러리가 핵심 방법을 수정했다는 사실을 깨닫지 않고 문제를 디버깅하려고하면 엉덩이에 물릴 수 있습니다.

— 미셸 틸리
소스

Javascript를 사용하면 객체를 그렇게 취급 할 수 있습니다.

— 0112

8

어떤 사람들은 루비 온 레일 (Ruby on Rails)이라는 관점에서만 루비를 생각합니다.

— davidk01
소스

7

최악의 기능은 open classes변경된 클래스의 현재 및 미래의 모든 인스턴스의 동작을 전역 적으로 변경할 수있게하는 것입니다.

이 기능의 문제는 Ruby 인터프리터가 정의를 발견 할 때 런타임 동안 이러한 (전역) 변경이 발생한다는 것입니다. 이는 객체를 인스턴스화하여 갑자기 동작을 갑자기 변경 한 후에도 오래 걸릴 수 있습니다.

큰 코드 기반에서는 버그를 찾기가 매우 어려울 수 있습니다. 특히 CLR 또는 JVM과 같은 Ruby의 약한 디버깅 스토리 eval와이 컨텍스트에서 다른 기능 (예 :)의 사용으로 인해 버그가 발생하기 때문에 이 글로벌 변화가 발생한 위치를 찾기는 매우 어렵습니다. 즉, '올바른'클래스가 문제를 일으키는 것으로 의심되는 지점에 이미 도달 한 경우! 내 경험상 당신은 문제가 실제 범인을 사용하여 물체에 나타나기 시작하면서 일반적으로 거위 추적으로 시작합니다.

따라서 가장 좋은 방법은 공개 클래스 사용을 중단 #extend하고 변경 사항을 ModuleIMHO가 훨씬 안전하고 이해하기 쉽고 테스트하기가 더 낫다는 것입니다.

새로운 행동으로 클래스를 확장하십시오 (즉, 기존 행동을 무시하지 마십시오)
오픈 클래스를 사용하는 모든 확장을 배치해야하는 소스 코드 트리에 정의 된 위치가 있습니다.
#eval공개 수업을 만드는 데 친구와 친구를 사용하지 마십시오
모든 공개 클래스 사용을 큰 가시적 차트에 표시하여 모든 개발자가 볼 수있는 차트를 만들고 변경 사항이 전체 코드 기반에 영향을 미치는 '건축 적 결정'이며 빠른 해킹 장소가 아니라는 점을 분명히하십시오. 현재 작업에

— 알렉산더 바티스티
소스

5

루비를 사용하지 않는 가장 큰 이유 : 빙하기 동안 북극에서 1 월의 당밀보다 느리다 . 벤치마킹 언어는 정확하지 않은 과학이지만 Ruby는 JavaScript 및 Python보다 훨씬 느립니다.

— 딤차
소스

그것은 나의 경험이기도했다.

— 척 스테판 스키

2

루비가 너무 느린 응용 프로그램은 무엇입니까? 내 말은, 당신이 느리다고 말할 때 당신을 믿지만 어떻게 그것이 당신의 목표에 도달하지 못하게 막았습니까?

— David

1

루비는 프로토 타입과 같은 것을 만들고 빠르게 만들고 싶을 때, 크지 않고 대량의 크 런칭을하지 않을 때 좋을 것이라고 생각합니다. 많은 CPU 사이클을 지속적으로 씹을 것으로 기대된다면, 좋은 프로그래머라면 C 나 C ++과 같은 것을 사용하는 것을 알고 있습니다.

— Jeff Welling

1

@David : 간단한 DNA 시퀀스 처리 코드에 Ruby를 사용하는 것을 고려할 것이지만 Python은 비슷한 틈새를 채우고 비슷한 기능을 가지고 훨씬 빠르기 때문에 아닙니다. 더 낮은 레벨로 가고 싶다면 D가 훨씬 빠르고 편리합니다.

— dsimcha

1

@Jeff : 동의하지만, C와 C ++는 쓰기 어려움입니다. Ruby와 같은 고급 언어의 요점은 이러한 고통을 최대한 다루지 않는 것입니다. 속도가 느릴수록이 목표를 달성하는 데 덜 도움이됩니다. 루비는 고급 동적 언어에서도 느립니다. 그와 NumPy / SciPy는 고급 동적 언어가 필요할 때 대신 Python을 사용하는 이유입니다.

— dsimcha

4

이것이 Ruby on Rails로 확장 될 수 있다면 :

데이터베이스 논리는 auto_increment필요하지 않고 없어야하는 테이블을 포함하여 모든 단일 테이블에 기본 키를 제공한다는 사실입니다 .
복합 키가 전혀 지원되지 않는다는 사실.

평범한 루비의 경우 내 그립은 표현력을 위해 안전을 교환하는 모든 언어와 동일합니다. 약간의 코드만으로도 많은 작업을 수행하는 것은 쉽지만 어떤 코드로도 큰 혼란을 겪는 것도 쉽습니다.

— 아 로스
소스

질문의 범위를 좁히면서 편집 한 내용을 참조하십시오. 편집이 포함 된이 질문이 승인되면 Rails에 대해 다른 병렬 질문을 시작하겠습니다.

1

죄송하지만 Rails 앱의 모든 테이블에 auto_incrementID 가 있어야하는 것은 아닙니다. 특히 has_and_belongs_to_many 관계에 대한 조인 테이블에는 명시 적으로 id 열이없는 것이 좋습니다.

— Brett Bender

@Brett-비교적 새로운 추가 기능입니까? 내가 2008 년 초에 그것을 가지고 놀았을 때는 분명히 그러한 기능이 없었습니다. 어쨌든 지금은 사용할 수 있다는 것이 좋습니다.

1

@aroth : 다른 사람들이 "상대적으로 새로운"것을 "지난 3 년 안에"를 의미한다고 생각하지 않습니다 :-)

Rails의 ActiveRecord에 대한 대안이 DataMapper 인데 ActiveRecord만큼 의견이 없습니다.

— Endy Tjahjono

3

루비는 메타 프로그래밍 (반사, 내성), 다중 패러다임 프로그래밍 및 역 동성을 드문 수준으로 수용합니다. 힘과 유연성으로 쉽게 발을 쏠 수 있습니다.

귀찮은? 루비는 읽기 또는 쓰기가 매우 어렵습니다. Bash 스크립트에 속하는 것처럼 보이는 코드를 보았습니다.

나쁜 습관? 일부 루비 스트는 지혜보다 영리함을 소중히 여깁니다. 그들은 영리함을 과시하는 속임수를 쓰고 공유하지만 읽을 수없고 깨지기 쉬운 코드를 만듭니다.

따로 : 자바 스크립트는 의도적으로 재해였으며 "좋은 부분"책은 숨겨진 아름다움을 추출하려고합니다. "한 가지 이상의 방법이있다"(즉, 융통성)를 대중화 한 언어 인 Perl은 "Perl, Best Practices"에서 비슷한 책을 가지고있다. Perl의 역사는 실험과 최고의 경험 중 하나입니다. "모범 사례"는 그 지식을 나타냅니다. 펄 6은 그 지식을 바탕으로 언어를 다시 부팅하는 것이 공정하다고 생각합니다. 루비도 비슷한 문제를 겪을 수 있습니다.

@James and for loops ... 루비에서 for 루프를 수행하면 ".each"가 호출됩니다. 따라서 "for"는 C 스타일 루프에 더 익숙한 사람들을위한 구문 설탕입니다. 그러나 Rubyist는 항상 .map, .inject, .each_with_object와 같은 반복자를 사용할 것입니다. 루비에서 "i = 0; i> 6; i ++"와 같은 for 루프를 작성할 필요가 없으므로 습관을 버릴 수 있습니다. @andrew ... 웅변 루비는 루프를 보증하지 않습니다.

— 오토 디 닥토
소스

-1

이것은 언어보다 프로그래머에 관한 것이지만 루비 프로그래머가 왜 루프를 싫어하는가?

나는 루비가 가지고 있음을 알고있다 :

someCollection.each do |item|
   ...
end

그러나 for 루프가 정확히 같은 일을하지 않는 상황에서 사용되는 것을 본 적이 없습니다.

나는 여러 번 물었고 이것에 대해 좋은 대답을 얻지 못했습니다.

그것이 단지 스타일 일이라면 받아 들일 수는 있지만 루비 프로그래머가 이것에 대해 실제로 일하는 것을 보았고 정말 궁금합니다.

— 제임스
소스

1

"키 누름이 적습니다."라는 대답을 얻었을 때 분명히 거짓입니다 ... :-)

— James

2

두 가지 이론 : 1) for루프를 사용 하는 것은 n00bs가하는 일입니다. Ruby로 C를 프로그래밍하는 사람들. 2) 루비에서는 블록이 많이 사용되므로 블록이 아닌 것을 사용하는 것은 추가적인 정신적 노력입니다.

— Andrew Grimm

3

방금 루비를 배우기 시작했지만 블록은 파이썬을 사용하려고 할 때 정말 좋아하고 그리워하는 것입니다. for 루프도 같은 일을합니까? 물론 나에게 이런 종류의 스타일은 for 루프보다 내 환경 설정에 더 적합합니다.

— Jetti

2

@andrew 솔직히 말하면, 당신의 첫 번째 대답은 내가 전에 요청했을 때 돌아온 쓰레기의 종류입니다. 미묘한 모욕을 가진 실제 이유는 없습니다. @ Wayne, @Jetti 및 @andrews 두 번째 답변 : 감사합니다. 그럼 충분히 공평 해

— James

1

for 루프에 대해 "향상된"(일명 <expression> do <value> do ...)을 의미한다면 # 각각 사용중인 외형과 일반적으로 사용되는 사촌 인 #inject, #collect, # 거부하십시오. 'C'스타일 인덱싱 된 루프 (일명 i = 0; i <무엇이든 ++ i)에 대해 이야기하는 경우 차이점은 a) "하나씩"오류는 불가능하고 b) 루프의 의도를 명확하게한다.- "각 요소마다 부작용을 일으킨다"는 의미. for 루프는 목적의 '요점'을 얻기 위해 전체 루프를 읽어야합니다.

— Alexander Battisti

-1

나는 일반적으로 다른 언어와 호환되도록 추가 된 것을 피할 것입니다. 예를 들어 Perlisms 및 for x in y.

— 앤드류 그림
소스

방금 Ruby 프로그래머와 for 루프에 대한 답변을 올렸습니다. 설명 할 수 있으면 감사하겠습니다 :-)

— James