Ruby는 무엇을 올바르게 했습니까 (또는 Rails입니까)? [닫은]


13

대부분의 프로그래밍 언어에는 사용 및 적용 가능성에 영향을주는 디자인 결정이 있습니다.

예를 들면 다음과 같습니다.

  • 파이썬은 코드의 유지 관리 성 / 가독성에 중점을 두 었으며 들여 쓰기는 언어 자체의 일부였습니다.
  • Java의 의도는 C ++보다 플랫폼 간 OOP '간단하고 친근한'것이 었습니다.
  • Objective-C는 당시 C ++의 미래를 알지 못하는 C를 중심으로 OO 래퍼로 구축되었습니다.
  • Erlang은 높은 내결함성과 동시 시스템을 위해 설계되었습니다
  • 웹 페이지의 동적 생성을 처리하도록 설계된 PHP
  • CoffeeScript 는 Javascript 의 좋은 부분 을 노출하고 OOP 구문 설탕을 추가하고 JS '뒤에서'의 뉘앙스 (글로벌 등)를 숨기 도록 설계되었습니다 .

각 프로그래밍 언어는 특정 틈새 IMHO를 활용하고 활용하려고했습니다. 위의 내용은 프로그래밍 언어의 기본 원칙이 무엇인지, 그리고 진화와 광범위한 채택 가능성을 지배 한 것에 대한 나의 관점입니다. 물론 더 많은 것이 있지만 목록은 예일뿐입니다.

그러나 저는 루비의 기반이되는 설립 원칙과 인기가 높아지는 것을 이해하기 위해 고심했습니다. 오늘날 루비의 기본 원칙은 무엇입니까? 아니면 Rails 프레임 워크를 디자인 한 사람의 천재입니까? 만약 후자가 Ruby가 Rails의 디자인을 더 좋거나 더 쉽고 더 빠르게 만들었다면? 어떤 의미에서?

제작자에 따라 가장 일반적으로 인용되는 이유는 '... 약한 유형의 프로그래밍 언어가 재미있다'는 것입니다. 새로운 프로그래밍 언어를 만드는 이유는 전혀 없습니다! 프로그래밍은 언어에 관계없이 순전히 재미 있습니다.

그렇다면 루비는 현재의 언어로 악용되지 않은 틈새 시장을 어떻게 사용 했습니까? 널리 채택 된 Ruby의 '강점'(USP)은 무엇입니까? 루비는 이전에 수행되지 않았거나 (매우 어려웠던) 무엇을 했습니까?

나는 루비 프로그래머가 아니라 루비 멍청한 놈이므로 혼란을 겪습니다.

면책 조항 : 이것은 화염 전쟁이 아니며 루비 대 프로그래밍 언어 유형의 답변을 찾고 있지 않습니다. 널리 채택 된 Ruby의 기반이되는 디자인 결정을 찾고 있습니다. 루비는 어떤 틈새 시장이 대중화되었다고 만족 시키나요?

답변:


11

루비는 여러 가지 이유로 이륙했다고 생각합니다.

  • Rails 프레임 워크. Rails는 웹 애플리케이션의 개발을 용이하게하고 개발자의 생산성을 높이기 위해 많은 유용한 패턴을 함께 모았습니다. Java의 장황하고 지루한 웹 개발 및 "one man show".NET 플랫폼과 비교하십시오. 몇 분 만에 웹 로그 웹 애플리케이션을 만드는 것은 놀라운 일이 아닙니다.
    Grails, Play!와 같은 많은 새로운 JVM 웹 프레임 워크에서 "레일 효과"를 볼 수 있습니다. 그리고 Spring Roo.
  • Twitter 및 Github와 같은 성공 사례. 스타트 업은 가능한 빨리 시장에 진출해야하며 Rails를 통해 가능합니다. 성공 사례는 증거였습니다.
  • 루비 프로그래밍 언어 자체는 아름답고 강력하며 표현력이 뛰어납니다. IMHO, Ruby는 Rails의 성공 비결입니다.
    오이와 시나트라의 아름다움, DSL의 아름다움을 보라.
  • 실험하고 혁신하는 것을 두려워하지 않는 열성적이고 용감한 커뮤니티.
  • (개인의 의견이며 중요한 이유는 아닙니다) 일본에서 만들어졌습니다. "Made in Japan"의 이미지를 능가하는 것은 없습니다.
    다른 나라에서 만들어진 프로그래밍 언어를 배우는 것은 새로운 사람들을 만나는 것과 같습니다. 재미 있고 교육적입니다.
    루비 / 일본, 오캄 / 프랑스, ​​루아 / 브라질, 리스프 / 화성 :)

5
" 원맨 쇼 .NET 플랫폼" 의 의미에 대해 궁금한 점은 이전에 들어 본 문구가 아닙니다.
Carson63000

2
Lisp / Mars의 경우 +1 그 곳은 하스켈?
Adam

2
하스켈 개발자 같은 작은 난쟁이의 군대가 혼란 OO 프로그래머의 의도와 함께 만든 지구 내 깊은 곳에서 온다
다니엘 Gratzer

1
@Adam "아틀란티스 문명"
Chiron

13

제목 질문에 직접 대답하지는 않지만 제기 된 몇 가지 사항 (예 : Ruby가 작성된 이유)을 해결합니다.

루비를 만든 유키히로 '마츠'마츠모토의 인용문.

  • "저는 Perl보다 강력하고 Python보다 객체 지향적 인 스크립트 언어를 원했습니다."
  • "루비가 전 세계의 모든 프로그래머가 생산성을 높이고 프로그래밍을 즐기며 행복하게하는 데 도움이되기를 바랍니다. 이것이 루비 언어의 주요 목적입니다."

기본적으로 Matz는 프로그래머의 행복을 위해 설계된 객체 지향 언어를 원했습니다.


1
그것은되어 매우 객체 지향. +in 1+1은 방법 이라는 것을 의미합니다 .
bpromas 2016 년

5

루비 (레일이있는 togehter)는 구성에 대한 관습을 대중적으로 만들었습니다 .

오래된 (비 루비 온 레일) 방식은

  • "birthday"라는 필드를 가진 "persons"데이터베이스 테이블을 정의하십시오.
  • "생일"특성으로 비즈니스 클래스 "개인"을 정의하십시오.
  • 데이터베이스와 비즈니스 클래스 간 데이터 전송을위한 헬퍼 클래스 작성
  • 목록에있는 사람이 어떻게 GUI를 만들 수 있습니까?
  • 한 사람의 속성을 편집하는 GUI 만들기

구성을 통해 규칙 이에 대한 기본 작업이 자동으로 수행됩니다 :

  • 당신은 코드에서 사람을 정의
  • 데이터베이스 테이블, 매핑, GUI 요소는 강력한 해석기 또는 코드 생성기에 의해 자동으로 생성됩니다.

반대로 : 첫 번째 주행에서 레일에서 루비를 배우는 것이 더 어려울 수 있도록 모든 cenventions를 배워야합니다.

장점 : 일단 규칙을 알고 나면 모든 루비 온 레일 개발자가 동일한 규칙을 따라야하기 때문에 다른 루비 온 레일 개발자의 코드를 이해하는 것은 매우 쉽습니다.

한편 컨피규레이션에 대한 컨벤션 은 많은 코딩 에코 시스템에 들어갔다


4

첫째, 루비는 "현재 언어"입니다. "1995 년 루비가 만들어 졌을 때 인기가 많은 언어"를 의미 할 것입니다.

나는 Perl을 좋아했던 것과 같은 이유로 Ruby를 좋아한다.

  1. 강력하고 표현력이 좋습니다. Java 또는 C ++의 5 줄 대신 1 줄의 Ruby 코드를 작성할 수 있습니다. 최소한의 소란으로 무시할 수없는 반복은 없습니다.

  2. 역동적입니다. 메서드와 속성을 런타임에 만들 수 있으므로 데이터베이스 테이블과 같이 외부 적으로 정의 된 사물을 대상으로 개체 정의를 복제하거나 응용 프로그램을 다시 작성하지 않고도 래핑 할 수 있습니다.

  3. 읽기 쉽고 포괄적 인 언어 ( Programming Ruby ) 에 관한 훌륭한 책이 있습니다 .

  4. 공용 도메인 패키지를위한 단일 리포지토리와 리포지토리에 대한 편리한 명령 줄 인터페이스가 있습니다.

그러나 나는 더 읽기 쉽기 때문에 Perl보다 Ruby를 더 좋아합니다.

Ruby와 Python을 비교하는 많은 페이지가 있습니다. 나는 둘 다 좋아합니다. 루비를 선호하지만 파이썬에 대한 경험이 제한적입니다.


프로그래밍 루비의 서문에서 (루비가 될 것) 펄을 대체하기에 충분할 것이라고 기대했던 것을 기억합니다.
Rig

@ kevin : 이것들은 언어의 특징 중 일부이며 잘 알고 있습니다. 그러나 나는 "재미 있고 약한 언어를 원한다"(또는 그 이유 자체가 충분히 큰가?) 이외의 '루비를 만드는 이유'를 알고 싶다.
PhD

1
@Nupul :이 일은위원회가하지 않습니다. Matz는 개념을 취하고 Ruby를 썼습니다. 그는 얼마 후 다른 사람들에게 그것을 보여 주었고, 그들 중 일부는 그것을 좋아했습니다. 이것이 LISP, Smalltalk, C, C ++, Pascal, Perl, Ruby 및 Python이 생성 된 방식입니다. 나는 그것이 대부분의 프로그래밍 언어와 동일하다고 생각합니다. 위원회 또는 기업 이니셔티브에 의해 소수만이 만들어졌습니다.
kevin cline
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.