나는 이것을 대답으로 게시하지 않을 것이지만 Xeoncross는 나에게 물었다.
Erik Max Francis는 다음과 같이 썼습니다.
"Brandon J. Van Every"는 다음과 같이 썼습니다.
파이썬보다 루비가 더 좋은 점은 무엇입니까? 나는 무언가가 있다고 확신합니다. 무엇입니까? 파이썬 사람들보다는 루비 사람들에게 이런 질문을하는 것이 훨씬 더 합리적이지 않습니까?
예를 들어, 자신의 목적에 파이썬 커뮤니티의 "사회학 연구"가 포함되어 있다면, 그 커뮤니티에 질문을하는 것은 다른 곳에 두는 것보다 정보에 대한 정보를 더 많이 공개 할 가능성이 높습니다. :-). 개인적으로, 나는 마지막 OSCON에서 Dave Thomas의 하루 루비 튜토리얼을 따라갈 수있는 기회를 기쁘게 생각했습니다. 구문 차이의 얇은 베니어 아래에서 Ruby와 Python이 놀랍게 유사하다는 것을 알았습니다. 어떤 언어 집합 중에서도 최소 스패닝 트리를 계산하는 경우 Python과 Ruby가 처음으로 통합 될 두 잎이 될 것입니다. 중간 노드 :-).
물론, 나는 루비, 각 블록의 끝에서 바보 "종료"를 입력 (보다는 unindenting)의 지친받을 수 있나요 -하지만 나는 똑같이-바보 입력 방지하기 위해 어떻게해야합니까 :
파이썬이에 요구하는
시작 의를 각 블록, 그래서 거의 세척입니다 :-). @foovs
와 같은 다른 구문 차이 self.foo또는 Ruby vs Python에서 대소 문자의 중요성은 실제로 나와 관련이 없습니다.
다른 사람들은 의심 할 여지없이 그러한 문제에 기초하여 프로그래밍 언어를 선택하고 가장 인기있는 논쟁을 일으킨다. 그러나 그것은 파킨슨의 법칙 중 하나 일 뿐이다 (문제에 대한 토론의 양은 문제에 반비례한다) 실제 중요성). 내가 중요하게 생각하는 파이썬의 한 가지 차이점은 파이썬의 호의적이지만 다른 사람들은 그 반대의 생각 만 할 것입니다. 파이썬 (C에서와 같이)에서 함수를 호출하려면 항상 호출하는 객체 바로 뒤에 괄호를 붙여 "호출 연산자"를 적용합니다 (마지막 괄호 안에는 호출에 전달하는 인수가있는 경우). 인수를 전달하지 않으면 괄호가 비어 있습니다). 이것은 특별한 경우, 예외, 임시 규칙 등이없는 상황에서 객체에 대한 참조를 의미하는 것으로서 연산자가 포함되지 않은 객체에 대한 단순한 언급을 남깁니다. Ruby에서 (파스칼에서와 같이) 인수를 사용하여 함수를 호출하려면 인수를 전달합니다 (일반적으로 괄호로 묶는 경우는 아니지만). 그러나 함수가 인수를 취하지 않으면 암시 적으로 함수를 암시합니다. 이것은 많은 사람들의 기대를 충족시킬 수 있습니다 (적어도, 과거 프로그래밍 경험이 파스칼이나 그와 유사한 "임시 호출"(예 : Visual Basic과 같은 다른 언어)을 사용했던 사람들)-그러나 나에게 이것은 단지 객체에 대한 언급은 객체에 대한 참조 또는 객체에 대한 호출을 의미 할 수 있습니다. 객체의 유형에 따라-객체를 언급하여 객체에 대한 참조를 얻을 수없는 경우에는 명시 적으로 "이것에 대한 참조를 제공하십시오. 전화하지 마십시오!"를 사용해야합니다. 그렇지 않은 연산자. 나는 이것이 함수 (또는 메소드, 또는 다른 호출 가능한 객체)의 "일등성"과 객체를 부드럽게 교환 할 수있는 가능성에 영향을 준다고 생각합니다. 따라서 나 에게이 특정 구문 차이는 Ruby에 대한 심각한 블랙 마크입니다.하지만 다른 사람들이 왜 더 격렬하게 동의하지 않더라도 다른 사람들이 그렇지 않을지를 이해합니다. 구문 아래에서, 우리는 기본 의미론에서 몇 가지 중요한 차이점을 알게됩니다. 예를 들어 Ruby의 문자열은 C ++에서와 같이 변경 가능한 객체입니다. 파이썬에서는 그것들이 변하지 않습니다 (자바에서와 같이, 또는 C #을 믿습니다). 다시 말하지만, 이미 익숙한 것으로 주로 판단하는 사람들은 이것이 Java의 장점이라고 생각할 수 있습니다 (물론 Java 또는 C #에 익숙하지 않은 경우 :-). 필자는 불변의 문자열이 훌륭한 아이디어라고 생각합니다. (Java가 독립적으로 이미 파이썬에 있던 아이디어를 재창조했다고 생각하지는 않습니다.) "변경 가능한 문자열 버퍼"유형도 마음에 들지 않습니다. (그리고 Java 자체의 "문자열 버퍼"보다 사용하기 쉬운 것이 이상적임); 그리고 함수형 프로그래밍 언어와는 별도로 Java를 공부하기 전에 친숙 함으로 인해이 판단을 내리지 않습니다. 자신이 이미 잘 알고있는 것에 의해 주로 판단하는 사람들은 이것이 Java의 장점이라고 생각할 수 있습니다 (물론 Java 나 C #에 익숙하지 않은 한 :-). 필자는 불변의 문자열이 훌륭한 아이디어라고 생각합니다. (Java가 독립적으로 이미 파이썬에 있던 아이디어를 재창조했다고 생각하지는 않습니다.) "변경 가능한 문자열 버퍼"유형도 마음에 들지 않습니다. (그리고 Java 자체의 "문자열 버퍼"보다 사용하기 쉬운 것이 이상적임); 그리고 함수형 프로그래밍 언어와는 별도로 Java를 공부하기 전에 친숙 함으로 인해이 판단을 내리지 않습니다. 자신이 이미 잘 알고있는 것에 의해 주로 판단하는 사람들은 이것이 Java의 장점이라고 생각할 수 있습니다 (물론 Java 나 C #에 익숙하지 않은 한 :-). 필자는 불변의 문자열이 훌륭한 아이디어라고 생각합니다. (Java가 독립적으로 이미 파이썬에 있던 아이디어를 재창조했다고 생각하지는 않습니다.) "변경 가능한 문자열 버퍼"유형도 마음에 들지 않습니다. (그리고 Java 자체의 "문자열 버퍼"보다 사용하기 쉬운 것이 이상적임); 그리고 함수형 프로그래밍 언어와는 별도로 Java를 공부하기 전에 친숙 함으로 인해이 판단을 내리지 않습니다. 불변의 문자열은 훌륭한 아이디어라고 생각합니다 (그리고 Java가 독립적으로 이미 파이썬에 있던 아이디어를 재발 명했다고 생각하지는 않습니다). "변경 가능한 문자열 버퍼"유형도 신경 쓰지 않을 것입니다. 이상적으로 Java 자체의 "문자열 버퍼"보다 사용하기 쉬운 것이 좋습니다.); 그리고 함수형 프로그래밍 언어와는 별도로 Java를 공부하기 전에 친숙 함으로 인해이 판단을 내리지 않습니다. 불변의 문자열은 훌륭한 아이디어라고 생각합니다 (그리고 Java가 독립적으로 이미 파이썬에 있던 아이디어를 재발 명했다고 생각하지는 않습니다). "변경 가능한 문자열 버퍼"유형도 신경 쓰지 않을 것입니다. 이상적으로 Java 자체의 "문자열 버퍼"보다 사용하기 쉬운 것이 좋습니다.); 그리고 함수형 프로그래밍 언어와는 별도로 Java를 공부하기 전에 친숙 함으로 인해이 판단을 내리지 않습니다.모든 데이터는 불변입니다. 알고있는 모든 언어에는 가변 문자열이 있었지만 Java에서 불변 문자열 아이디어를 처음 보았을 때 (파이썬을 배우기 전에 잘 배웠습니다), 즉시 나를 훌륭하게 맞았습니다. 고급 프로그래밍 언어의 참조 의미론 (기계에 더 가깝고 C와 같은 응용 프로그램과는 다른 언어에 가장 적합한 값 의미론과는 대조적으로) 일류의 내장 문자열 (예 : 결정적) 데이터 유형.
루비는 기본 시맨틱에 몇 가지 장점이 있습니다. 예를 들어 파이썬의 "리스트 대 튜플"을 제거하면 미묘한 차이가 있습니다. 그러나 대부분 점수는 (단순히 크고 단순하고 미묘한 영리한 구별은 눈에 띄는 마이너스 차이로 유지) 루비에 대한 것입니다 (예 : 폐쇄 및 반 개방 간격, a..b 및 a. .B [누구가 있다고 주장하고자 분명 , 바보 -?)하는 인] -! 이럴 물론). 다시 말하지만, 언어의 핵심에서 유사하지만 미묘하게 다른 많은 것들을 마이너스가 아닌 플러스로 생각하는 사람들은 물론 내가 세는 방법에서 이러한 "다른 방법으로"를 계산할 것입니다.
생각으로 이러한 비교에 의해 현혹하지 마십시오 두 언어는
매우다른, 당신을 염두에 두십시오. 그렇지 않습니다. 그러나 "capelli d' angelo"와 "spaghettini"를 비교하라는 요청을 받으면,이 두 종류의 파스타는 다른 사람과 구별 할 수없고 당신이 준비하고 싶은 접시에서 서로 바꿔 먹을 수 있다는 점을 지적한 후에 필연적으로 길이와 지름이 눈에 띄게 다른 방법, 가닥의 끝이 다른 경우가 아닌 테이퍼 방식 등의 현미경 검사로 이동하는 이유-개인적으로 카펠 리가있는 이유를 시도하고 설명하기 위해 '모든 종류의 국물에 파스타로 안젤로이지만 파스타와 같은 스파게티를 선호합니다. 오래된 얇은 파스타 형태 (올리브 오일, 다진 마늘, 다진 고추, 잘게 썬 멸치, 예를 들어-마늘과 후추를 얇게 썰지 않고 얇게 썰어 놓으면 스파게티 니의 더 얇은 소멸보다는 스파게티의 건강한 몸을 선택해야합니다. 또는 심지어-나는 이단자입니다 ...! -라이트 민트 ...] 잎-접시를 제공하기 전에 마지막 순간에). 죄송합니다. 해외 여행 중이며 잠시 파스타를 먹지 않은 것으로 나타났습니다. 그러나 비유는 여전히 꽤 좋습니다!-) achoview를 포기하고 대신 신선한 봄 바질을 추가하는 것이 좋습니다. -라이트 민트 ...] 잎-접시를 제공하기 전에 마지막 순간에). 죄송합니다. 해외 여행 중이며 잠시 파스타를 먹지 않은 것으로 나타났습니다. 그러나 비유는 여전히 꽤 좋습니다!-) achoview를 포기하고 대신 신선한 봄 바질을 추가하는 것이 좋습니다. -라이트 민트 ...] 잎-접시를 제공하기 전에 마지막 순간에). 죄송합니다. 해외 여행 중이며 잠시 파스타를 먹지 않은 것으로 나타났습니다. 그러나 비유는 여전히 꽤 좋습니다!-)
그래서 파이썬과 루비로 돌아가서 우리는 두 가지 큰 문제를 겪습니다 (언어의 관점에서-라이브러리를 떠나고 도구 및 환경과 같은 다른 중요한 보조 도구, 각 언어를 포함 / 확장하는 방법 등) 지금은-어쨌든 각 언어의 모든 구현에 적용되지는 않습니다 (예 : Jython vs Classic Python은 Python 언어의 두 가지 구현입니다!) :
루비의 이터레이터와 코드 블록 대 파이썬의 이터레이터와 생성기;
모든 내장 클래스를 포함하여 기존 클래스를 "재 개설"하고 런타임에 동작을 변경하는 기능을 포함하여 Ruby의 TOTAL, 무제한 "동 적성"(파이썬의 방대하지만 제한된 동
적성) 내장 클래스 및 해당 인스턴스
개인적으로, 나는 1 번의 세탁을 고려 합니다 (차이가 너무 깊어서 다른 사람들이 접근하고 다른 것을 수정하는 것을 쉽게 볼 수 있었지만, 개인적으로는 플러스와 마이너스가 거의 균등하게 올라갑니다). 그리고 [2] 중요한 문제-루비를 "팅킹"에 훨씬 더 적합하게 만드는 문제이지만, 대량 생산 응용 프로그램에 사용하기에는 파이썬이 더 적합합니다. 두 언어가 대부분의 다른 언어보다 훨씬 동적이기 때문에 결국 내 POV와의 주요 차이점이 그에 달려 있어야한다는 점에서 재미 있습니다. 여기는 물론 "Spinal Tap"입니다. 루비에서나는 할 수있다 ! 즉, 내장 문자열 클래스를 동적으로 변경하여
a = "Hello World"
b = "hello world"
만약 a == b
"같음! \ n"인쇄
그밖에
"다른!"인쇄
종료
"같음"으로 인쇄합니다. 파이썬에서는 내가 할 수있는 방법이 없습니다. 메타 프로그래밍의 목적, 실험 프레임 워크를 구현하는 등의 경우, 루비의 놀라운 동적 능력은 매우
정치. 그러나 우리가 많은 사람들이 개발하고 다양한 소스의 모든 종류의 라이브러리를 포함하여 더 많은 사람들이 유지 관리하고 클라이언트 사이트에서 프로덕션에 들어가야하는 대규모 응용 프로그램에 대해 이야기하고 있다면 ... 매우 역동적 인 언어, 대단히 감사합니다. 나는 어떤 라이브러리가 자신의 문자열에 의존하는 다른 관련되지 않은 다른 라이브러리를 무의식적으로 깨뜨리는 아이디어를 혐오합니다. 대규모 프로그래밍. 어떤 모듈이라도 다른 "비밀하게"의 행동에 영향을 주도록함으로써,
그러한 대규모 응용 프로그램에 Ruby를 사용해야한다면 코딩 스타일 제한, 많은 테스트 (모든 것이 변경 될 때마다 다시 실행되어야 함-전혀 관련이없는 것 등)에 의존하려고합니다. 이 언어 기능의 사용을 금지합니다. 그러나 처음에는 기능을 갖지 않는 것이 더 좋습니다. 제 생각에 특정 수의 내장 기능이 "네일 다운"될 수 있다면 파이썬 자체가 응용 프로그램 프로그래밍을위한 더 나은 언어가 될 것입니다. 예를 들어,
len("ciao")누군가가
모듈 len에서 이름의 바인딩을 변경했는지 여부에 대해 걱정하지 않고 4 __builtins__입니다. 결국 파이썬이 내장 기능을 "네일 다운"하기를 바랍니다.
그러나 내장 리 바인드 리 바인딩은 더 이상 사용되지 않으며 파이썬에서는 거의 사용되지 않기 때문에 문제는 사소합니다. Ruby에서는
다른 언어 의 너무 강력한 매크로 기능 (예 : Dylan과 같은)이 비슷한 위험을 내 자신의 견해로 제시하는 것처럼 나를 주요하게 생각합니다 (Python이 강력한 매크로 시스템을 얻지 않기를 바랍니다. "사람들이 언어 자체에 포함 된 고유 한 도메인 별 작은 언어를 정의하게한다"라는 매력과는 상관없이 IMHO는 응용 프로그램 프로그래밍에 파이썬의 훌륭한 유용성을 손상시킬 것입니다. 모든 프로그래머의 마음에 숨어 있습니다 ...).
알렉스