왜 스몰 토크 대신 루비를 사용하나요? [닫은]

Ruby는 주로 Ruby on Rails의 영향으로 인기를 얻고 있지만 현재 청소년기에 어려움을 겪고있는 것 같습니다. 루비와 스몰 토크 사이에는 많은 유사점 이 있습니다. 자기 부상 은 그 증거입니다. 좀 더 특이한 구문을 가지고 있음에도 불구하고 스몰 토크는 루비의 객체 지향적 인 아름다움을 모두 가지고 있습니다.

내가 읽은 내용에서 Smalltalk는 Ruby를 이길 것 같습니다.

• 성숙도 (1970 년대에 개발 됨)
• 안정
• 상업적 지원
• 분산 소스 제어 (텍스트 비교가 아닌 코드 구조 이해)
• VM의 여러 구현
• 크로스 플랫폼 지원
• 해변 웹 프레임 워크 A와 레일에 대한 강력한 대안

Ruby가 바퀴를 재창조하고있는 것 같습니다. 그렇다면 Ruby 개발자는 왜 SmallTalk를 사용하지 않습니까? Ruby에는 Smalltalk가없는 것은 무엇입니까?

기록을 위해 : 저는 스몰 토크에 대한 경험이 거의 또는 전혀없는 루비 사람이지만 이유가 궁금합니다.

편집 : 스크립팅의 용이성 문제는 GNU Smalltalk에 의해 해결되었다고 생각합니다 . 내가 아는 한, 이것은 당신이 일반 오래된 텍스트 파일에 스몰 토크를 작성할 수있게 해주 며, 더 이상 스몰 토크 IDE에있을 필요가 없습니다. 그런 다음 다음 을 사용하여 스크립트 를 실행할 수 있습니다 .

gst smalltalk_file

나는 Ruby 사용자보다 Pythonista에 더 가깝지만 Ruby에도 동일한 이유가 있습니다.

• Smalltalk의 아키텍처는 다소 고립되어있는 반면 Python과 Ruby는 통합을 용이하게하기 위해 처음부터 빌드되었습니다. 스몰 토크는 파이썬과 루비와 같은 방식으로 하이브리드 애플리케이션 지원을 얻지 못했기 때문에 '삽입 된 스크립팅 언어로서의 스몰 토크'라는 개념은 결코 포착되지 않았습니다.
  
  제쳐두고, 자바는 다른 코드베이스와 인터페이스하는 가장 쉬운 방법은 아니었지만 (JNI는 상당히 어색함), 그것이 마음을 공유하는 것을 막지는 못했습니다. IMO는 인터페이싱 인수가 중요합니다. 삽입의 용이성은 Python에 해를 끼치 지 않습니다. 그러나이 인수는 모든 응용 프로그램이이 기능을 필요로하는 것은 아니기 때문에 중간 정도의 가중치 만 유지합니다. 또한 이후 버전의 스몰 토크는이 문제를 실질적으로 해결했습니다.

• 대부분의 주요 스몰 토크 구현 (VisualWorks, VisualAge 등)의 클래스 라이브러리는 크고 상당히 가파른 학습 곡선으로 유명했습니다. Smalltalk의 대부분의 주요 기능은 스트림 및 컬렉션과 같은 기본 항목조차도 클래스 라이브러리 어딘가에 숨겨져 있습니다. 언어 패러다임은 또한 익숙하지 않은 사람에게는 문화적 충격의 일부이며 브라우저에서 제공하는 프로그램의 단편적인 관점은 대부분의 사람들이 익숙했던 것과는 상당히 다릅니다.
  
  전반적인 효과는 스몰 토크가 배우기 어렵다는 평판을 받았다는 것입니다. 정말 능숙한 스몰 토크 프로그래머가 되려면 상당한 시간과 노력이 필요합니다. Ruby와 Python은 배우기 훨씬 쉽고 새로운 프로그래머에게 속도를 더할 수 있습니다.

• 역사적으로 주류 스몰 토크 구현은 상당히 비싸고 실행하기 위해 이국적인 하드웨어가 필요했습니다 . 1983 년에 게시 된 net.lang.st80에서 볼 수 있습니다 . Windows 3.1, NT, '95 및 OS / 2는 적절한 기본 시스템 통합으로 스몰 토크 구현을 지원할 수있는 메인 스트림 하드웨어에 대한 최초의 대량 시장 운영 체제였습니다. 이전에는 Mac 또는 워크 스테이션 하드웨어가 Smalltalk를 효과적으로 실행할 수있는 가장 저렴한 플랫폼이었습니다. 일부 구현 (특히 Digitalk)은 PC 운영 체제를 매우 잘 지원했으며 일부 견인력을 얻는 데 성공했습니다.
  
  그러나 OS / 2는 그다지 성공적이지 않았고 Windows는 1990 년대 중반까지 주류를 이루지 못했습니다. 불행히도 이것은 플랫폼으로서의 웹의 부상과 자바에 대한 대규모 마케팅 추진과 동시에 발생했습니다. 자바는 1990 년대 후반에 대부분의 마인드 쉐어를 차지했고, 스몰 토크도 약간은 타락한 상태가되었습니다.

• Ruby와 Python은보다 일반적인 도구 모음에서 작동하며 특정 개발 환경과 밀접하게 연결되어 있지 않습니다. 내가 사용한 Smalltalk IDE는 충분히 훌륭하지만 구문 강조 기능이있는 멋진 편집기가 있고 발 밑에 있지 않기 때문에 Python 개발에 PythonWin을 주로 사용합니다.
  
  그러나 Smalltalk는 IDE와 함께 사용하도록 설계되었으며 (사실 Smalltalk는 원래의 그래픽 IDE였습니다) 다른 시스템에서 복제 할 수없는 멋진 기능이 여전히 있습니다. 하이라이트와 'Show it'을 사용하여 코드를 테스트하는 것은 Ruby에 대해 말할 수는 없지만 Python IDE에서 본 적이없는 매우 멋진 기능입니다.

• Smalltalk는 웹 애플리케이션 파티에 다소 늦었습니다. VisualWave와 같은 초기의 노력은 결코 끔찍한 성공을 거두지 못했으며 Seaside가 나올 때까지는 괜찮은 웹 프레임 워크가 Smalltalk 서클에서 받아 들여졌습니다. 한편 자바 EE는 홍보있는 장식품을 미쳐 결국 지루해지고 루비에 이동로 시작하는 완전한 수용 라이프 사이클을했다 -}
  
  아이러니하게도, 해변은 우리가 스몰 토크 타기를 찾을 수 있도록 감정가 사이에 마음 점유율을 조금지기 시작된다 인기로 돌아갑니다.

그렇긴하지만 스몰 토크는 운전 방법을 알아 내면 아주 좋은 시스템입니다.

아침에 출근하기 위해 집을 떠날 때, 나는 운전로에서 좌회전 또는 우회전을 결정하는 데 종종 어려움을 겪습니다 (나는 거리 한가운데에 산다). 어느 쪽이든 내 목적지로 갈 것입니다. 한 가지 방법은 교통 상황에 따라 사무실에 가장 빨리 도착할 수있는 고속도로로 연결됩니다. 나는 적어도 일부는 매우 빠르게 운전할 수 있고, 출근길에 예쁜 여자 한두 명을 볼 수있는 좋은 기회가 있습니다. :-)

다른 방법을 사용하면 완전히 나무를 덮은 상태로 매우 매혹적인 바람이 부는 뒷길을 여행 할 수 있습니다. 그 길은 꽤 즐겁고 두 가지 접근 방식 중 확실히 더 재미 있지만 고속도로를 탔을 때보 다 늦게 사무실에 도착할 것입니다. 각 방법에는 장점이 있습니다. 급한 날에는 보통 고속도로를 이용하지만 교통 체증이 발생할 수 있으며 사고가 발생할 가능성도 높아집니다 (서둘러 조심하지 않으면). 다른 날에는 나무가 우거진 길을 선택하고 운전하면서 경치를 즐기며 늦는다는 사실을 깨닫기도합니다. 속도를 높이고 티켓을 받거나 사고를 일으킬 가능성을 높이려고 할 수 있습니다.

어느 쪽도 다른 쪽보다 낫지 않습니다. 그들 각각은 장점과 위험을 가지고 있으며, 각각의 목표를 달성 할 것입니다.

귀하의 질문에 요점이 다소 누락되었다고 생각합니다. 당신은 당신이해야 선택 안 배울 둘!

진정으로 다음 프레임 워크 (vm, 인프라)를 선택할 수있는 위치에 있다면 무엇을 사용할지 결정해야하며, 애플리케이션이 수행 할 의도의 관점에서 장단점으로 구체적인 질문을 할 수 있습니다.

나는 스몰 토크 (좋아요)와 루비 (좋아요)를 사용했습니다.

집에서나 오픈 소스 프로젝트에서는 내가 좋아하는 모든 언어를 사용할 수 있지만 일을 할 때는 채택해야합니다.

나는 솔라리스, 리눅스, 윈도우즈 (98,2000, xp)에서 거의 똑같이 동작하는 스크립팅 언어가 필요했기 때문에 (직장에서) 루비를 사용하기 시작했다. 당시 루비는 평균 조에게 알려지지 않았고 레일이 없었습니다. 그러나 관련된 모든 사람에게 판매하는 것은 쉬웠습니다.

(왜 파이썬이 아닌가? 진실? 나는 터미널이 내 공간을 탭으로 변환하고 의도가 엉망이되었을 때 발생한 버그를 찾기 위해 일주일에 한 번 보낸다).

그래서 사람들은 루비로 코딩을하기 시작했습니다. 루비가 하늘의 구름이 아니라 너무 편안하고 즐거웠 기 때문입니다.

폴 그레이엄이 요약

확실히 대부분의 사람들은 자신의 장점에 따라 프로그래밍 언어를 선택하지 않습니다. 대부분의 프로그래머는 다른 사람이 어떤 언어를 사용해야하는지 듣습니다.

과

해커들에게 매력적이기 위해서는 그들이 작성하고자하는 종류의 프로그램을 작성하기에 좋은 언어 여야합니다. 그리고 그것은 아마도 놀랍게도 일회용 프로그램을 작성하는데 좋다는 것을 의미합니다.

그리고 Lisp 땅에 있었을 때 LISP를 smalltalk로 대체하려고

Ruby의 라이브러리, 커뮤니티 및 추진력이 좋습니다.

그렇다면 LISP가 여전히 Ruby보다 강력하다면 LISP를 사용하는 것은 어떨까요? LISP 프로그래밍에 대한 일반적인 이의는 다음과 같습니다.

1. 라이브러리가 충분하지 않습니다.
2. LISP 프로그래머를 고용 할 수 없습니다.
3. LISP는 지난 20 년 동안 아무데도 없었습니다.

이것들은 압도적 인 반대는 아니지만 확실히 고려할 가치가 있습니다.

과

이제 강력한 언어와 대중적인 언어 중 하나를 선택하면 강력한 언어를 선택하는 것이 좋습니다. 그러나 권력의 차이가 미미하다면 인기가 있다는 것은 여러 가지 좋은 이점이 있습니다. 2005 년에는 Ruby 대신 LISP를 선택하기 전에 오랫동안 열심히 생각했습니다. 최적화 된 코드 나 완전한 컴파일러 역할을하는 매크로가 필요한 경우에만 수행 할 것입니다.

그 반대입니다. 스몰 토크 구문은 가장 간단하고 강력한 프로그래밍 언어 구문 중 하나입니다.

언어가 매우 비슷하다는 것은 사실입니다. 이를 해석하는 얕은 방법은 Ruby를 Smalltalk 커버 밴드라고 부르는 것입니다. 더 합리적인 해석은 스몰 토크의 폐쇄 형 시스템이 그것을 분리 한 반면, 루비가 유닉스 생태계에 참여하고 태양 아래에서 모든 언어의 기능을 사용하는 습관은 무한히 더 부드러운 채택 곡선을 제공하고 Git과 같은 멋진 도구와 쉽게 통합된다는 것입니다.

자일스 보케 트

누가 말했는지 맞춰보세요? (인용문은 가깝지만 정확하지 않을 수도 있습니다) : "저는 항상 스몰 토크가 자바를 이길 것이라고 생각했습니다. 그렇게했을 때 '루비'라고 불릴 지 몰랐습니다."

드럼 롤 ....

...

대답은 ... 켄트 벡

Stephane Ducasse에는 다음과 같은 훌륭한 Smalltalk 책이 있습니다.

http://stephane.ducasse.free.fr/FreeBooks.html

따라서 Smalltalk 커뮤니티는 Ruby 및 Rails 커뮤니티만큼 많지는 않지만 여전히 큰 도움이 있습니다.

Ruby에는 Smalltalk가없는 것이 무엇입니까?

• 라이브러리 세트를 강화하는 주요 플랫폼 (IronRuby 및 jRuby)의 대규모 현재 지원
• 데이브 토마스와 같은 전도자들은 수년간 전국을 순회하며 그들의 언어로 복음을 전파했습니다. Java 컨퍼런스 에서 Dave가 Java를 모르고 Ruby를 선호한다고 말하는 것을 보았습니다 .
• 책꽂이에있는 강력한 현재 부동산
• Ruby의 제작자는 프로그래머에 대해 생각한다고 말했습니다. Ruby의 구문은 이러한 Zen 매력을 가지고있는 것 같습니다. 고정하기는 어렵지만 팬들을 자극하는 것 같습니다.
• Giles 와 같은 창의적이고 역동적 인 프레젠테이션과 마인드 셰어를 얻는 이 프레젠테이션

나는 당신의 요점이 잘 이해되었다고 생각합니다. 친구가 말했듯이 Ruby는 Smalltalk에 비해 "새 병에 담긴 오래된 포도주"일 수 있습니다. 그러나 때로는 새 병이 중요합니다. 와인은 적시에 적절한 장소에 있어야합니다.

나를 이긴다. 나는 루비를 확인하고 내가 그것을 얼마나 좋아하는지보기 위해 작은 프로젝트를하는 데 1 년을 보냈다. 루비와 함께 일할 때마다 나는 한숨을 쉬며 "나는 스몰 토크에서이 일을하는 것이 차라리 낫다"고 생각하기 때문에 나는 스몰 토크 편협한 사람이라고 생각한다. 마침내 나는 포기하고 스몰 토크로 돌아갔다. 이제 나는 더 행복해졌습니다. Happier가 더 좋습니다.

물론 "왜?"라는 질문을 던집니다. 특별한 순서없이 :

1. IDE는 내가 함께 일한 다른 것을 날려 버리기 때문입니다. 여기에는 IBM 메인 프레임의 ISPF에서 Microsoft의 Visual (. *)에 이르기까지 다양한 플랫폼이 포함되며 Visual Basic 4-6, Visual C ++ (다양한 구현), Borland의 Turbo Pascal 및 자손 (예 : Delphi), DEC의 항목 등이 포함됩니다. 문자 모드와 X-Windows 모두에서 시스템.
2. 이미지는 살기에 아름다운 곳이기 때문입니다. 나는 거기에서 내가 원하는 것을 찾을 수 있습니다. 어떻게해야할지 알 수 없다면 이미지 어딘가에 내가하려는 작업의 예가 있다는 것을 압니다 . 찾을 때까지 사냥 만하면됩니다. 그리고 그것은 자체 문서화입니다. 어떤 일이 어떻게 작동하는지에 대한 세부 사항을보고 싶다면 관심있는 클래스에서 브라우저를 열고 메서드를 보면 그것이 작동하는 방식입니다. (좋아, 결국 당신은 원시적이라고 부르는 무언가를 치게 될 것이다. 그리고 나서 그것은 "여기 드래곤이있다"지만, 일반적으로 문맥에서 이해할 수있다). Ruby / C ++ / C에서도 비슷한 일을 할 수 있지만 쉽지는 않습니다. 쉬울수록 좋습니다.
3. 언어는 최소한이고 일관성이 있습니다. 단항, 이진 및 키워드의 세 가지 메시지입니다. 실행 우선 순위도 설명합니다. 먼저 단항 메시지, 이진 메시지, 키워드 메시지 순입니다. 일을 돕기 위해 괄호를 사용하십시오. Dang 작은 구문, 실제로-메시지 전송으로 모두 완료되었습니다. (좋아요, 할당은 메시지 전송이 아니라 연산자입니다. 그래서 '반환'연산자 (^)도 마찬가지입니다. 블록은 대괄호 쌍 ([])으로 묶여 있습니다. 거기에 하나 또는 두 개의 다른 '마법'비트가있을 수 있습니다. 하지만 조금 ...).
4. 블록. 예, 저도 알고 있습니다. Ruby (및 기타)에 있지만, 말 그대로 사용하지 않고는 Smalltalk에서 프로그래밍 할 수 없습니다. 당신이있어 강제 를 사용하는 방법을 배울 수 있습니다. 때로는 강요받는 것이 좋습니다.
5. 타협이나 대안이없는 객체 지향 프로그래밍. 당신은 여전히 ​​똑같은 오래된 일을하는 동안 당신이 "객체를하는"척할 수 없습니다.
6. 뇌를 늘릴 것이기 때문입니다. 우리 모두가 익숙해 진 편안한 구조 (if-then-else, do-while, for (;;) 등)는 더 이상 존재하지 않으므로 새로운 것을 배워야합니다. 위의 모든 것 (및 그 이상)에 해당하는 것이 있지만 다르게 생각하는 법을 배워야 할 것입니다. 다르게 좋습니다.

다른 한편으로 이것은 메인 프레임이 지구를 지배하던 시절부터 프로그래밍을해온 사람의 엉망진창 일 수 있습니다. 우리는 눈부신 눈보라, 오르막길, 그리고 컴퓨터가 기억을 위해 도넛을 사용하는 작업을 위해 5 마일을 걸어야했습니다. 나는 루비 / 자바 / C / C ++ /에 대해 아무것도 가지고 있지 않습니다. 그것들은 모두 문맥 상 유용합니다.하지만 저에게 스몰 토크를 주시거나 저에게주세요 ... 글쎄, 아마도 Lisp 나 Scheme을 배워야하거나 ... :-)

스몰 토크 : 사람들은 ifTrue를 전달합니다 : [생각] ifFalse : [생각하지 않음]

루비 : 사람들은 거꾸로 생각하지 않는 한 앞으로 생각합니다

1) 메시지에 의한 Smalltalk의 RPN과 같은 제어 흐름은 Lisp와 비슷합니다. 규칙적이고 멋지지만 사람들이 이상합니다.

ㅋ을 - 2) 루비는 사람들이 사람들이 말하는 관용적 방법을 사용하여 코드를 작성할 수 있습니다 하지 않는 이유가 아니다.

업데이트 는 Smalltalk 샘플을 실제로 더 합법적 인 코드로 다시 작성했습니다 ..

Ruby는 현재 버즈 언어입니다. 70 년대에 개발 된 언어보다 지금 개발 된 소프트웨어를 마케팅하는 것이 더 쉽습니다.

커뮤니티! Ruby, 특히 Rails에는 훌륭한 커뮤니티가 있습니다. 스몰 토크를 엉망으로 만들면 스몰 토크에 대한 스크린 캐스트, 기사, 블로그 게시물 등이 많지 않은 것 같았습니다.

첫 번째 줄의 질문에 답하셨습니다. "Ruby가 인기를 얻고 있습니다."

• 있습니다 많은Ruby를 기반으로하는 흥미로운 모듈, 프로젝트 등 .
• 루비에서 무언가를하는 데 문제가 있다면 어딘가에서 도움을 찾는 것은 쉬운 일이 아닙니다.
• Ruby는 현재 많은 컴퓨터 에 설치되어 있습니다 (기본적으로 OS X, 많은 Linux 배포판에 포함되어 있으며 Windows 용 좋은 설치 프로그램이 있습니다.)-내가 사용한 컴퓨터에 기본적으로 smalltalk가 설치된 것을 보지 못했습니다.

한 언어가 다른 언어보다 우월하든 아니든 상관 없다. 웹 사이트) 너무 널리 퍼져 있기 때문입니다.

기본적으로 언어의 특정 장단점은 그 언어를 둘러싼 모든 것, 즉 커뮤니티보다 훨씬 덜 중요합니다.

Ruby (또는 다른 언어)는 우리가 혼란스러운 우주에 살고 있기 때문에 Smalltalk (또는 다른 언어)보다 더 인기가 있습니다. 재치 :

• Dave Thomas 자신이 "'10 분 안에 블로그를 구축하는 방법 '에 대한 비디오 이후 ... Ruby는 멋진 작은 틈새 언어에서'Rails 앱을 작성한 언어 '로 발전했습니다."( Ruby Conference 2010 기조 연설 ).
• 초기 스몰 토크 공급 업체가 엄청나게 청구했습니다.
• 스몰 토크는 30 년 전에 발명 되었기 때문에 오래되고 "죽은"언어 (예 : FORTRAN)로 많은 사람들에게 발생합니다.
• 기업은 스몰 토크 의 사용을 숨기는 경쟁 우위를 고려 합니다.

언어는 OO 기능에서 유사하지만, 스몰 토크의 킬러 장점은 라이브, 개방 환경 (다량 오해 '이미지')입니다. Smalltalk에서이 프로그래밍 예제 를 확인 하면 논쟁이 끝났습니다.

저에게는 Ruby가 가지고있는 것이 아니라 Ruby가 가지고있는 것이 아닙니다. 그리고 여기에없는 것은 VM과 완전한 환경이 필요하다는 것입니다.

스몰 토크는 훌륭합니다. 제가 OO 개념을 배운 곳이지만 사용하기 쉽도록 Ruby를 사용합니다. 좋아하는 편집기에서 Ruby 코드를 작성하고 명령 줄에서 실행할 수 있습니다.

그래서 저는 스몰 토크보다 루비를 선택했습니다.

한동안 Ruby와 함께 일해온 모든 사람들이 Smalltalk에 대한 막대한 빚을 인식하고 있다고 생각합니다. 이 중 한 사람으로서 스몰 토크보다 루비에 대해 어떤 점이 좋습니까? 엄밀히 말하면 언어 적 관점에서 보면 설탕이라고 생각합니다. Ruby는 의도적으로 매우 구문이 뛰어난 언어 인 반면 Smalltalk는 구문이 매우 최소화 된 언어입니다. Ruby는 기본적으로 Perlish 구문 설탕을 사용하는 Smalltalk 개체 모델입니다. 나는 설탕을 좋아하고 그것이 프로그래밍을 더 재미있게 만듭니다.

루비를하는 일을 아주 쉽게 찾을 수 있습니다. 나는 스몰 토크를 정말 좋아하지만 스몰 토크 틈새 시장에 진입하는 것은 사실상 불가능합니다. 해결 방법이 있지만 인기가있을 때 참여하지 않았다면 지금은 거의 불가능합니다.

다른 모든 이유는 언어를 제대로 배우기 위해 실제 작업에 집중하고 많은 시간을 할애해야하기 때문에 무의미 해집니다. 독립적으로 부유하지 않은 경우이를위한 가장 좋은 방법은 직장에서 노출하는 것입니다.

Smalltalk 배포판은 $ 1000USD의 배수로 가격이 책정되었지만 Ruby는 무료입니다.

Ruby는 Smalltalk에 아라비아 숫자는 로마 숫자에 해당합니다. 동일한 수학, 더 쉬운 구문.

저는 Smalltalk를 조금 해봤습니다. IDE는 제가 기억하는 한 가지입니다. Ruby가 IDE를 잘 지원합니까?

Ruby를 사용하십시오. 비즈니스 다리가있을 수 있기 때문에 Smalltalk는 그렇지 않습니다.

나는 개인적인 경험에서 말할 수 있습니다. 여전히 Smalltalk를 사용하고 있고, 그것을 좋아하고, 몇 가지 맛을 사용했습니다. 스몰 토크가 훌륭한 언어이고 당신이 언급 한 모든 것이지만, 일반 CIO / CTO가 새 프로젝트에서 스몰 토크를 사용하도록 설득하지는 못할 것입니다. 물론 보수적 인 CIO / CTO가 Ruby를 사용하도록 설득하기 어려울 수도 있습니다. 결국 장기적인 상업적 지원과 향후 시스템을 지원할 수있는 외근 직원을 찾을 수있는 능력을 원하면 매우 조심해야합니다. 예를 들어, Smalltalk는 90 년대 초반에 정말 큰 일이었고 IBM은 90 년대 후반에 대규모 투자를했습니다. IBM Smalltalk는 모든 비즈니스 애플리케이션의 다음 언어가 될 것입니다. IBM은 메인 프레임 시스템을 포함한 모든 것에 Smalltalk를 적용했습니다. 자바가 인기를 얻고 시장을 장악하고 스몰 토크는 틈새 시장이되었습니다. 1 년 이상 전에 IBM은 언어를 폐기했습니다 (그 용어는 일몰입니다). 또한 역사를 살펴보십시오. ParkPlace와 Digitalk은 Smalltalk 분야의 첫 번째 주요 상업 기업이 합병 한 후 폐업했습니다.

저는 스몰 토크와 루비를 모두 좋아합니다.하지만 루비가 제가 매일하는 일에 더 적합하고 제 마음에 더 가깝다는 것을 알게되었습니다 (실제로 말하자면). Ruby는 Smalltalk가 제공하지 않는 것은 무엇입니까?

• 텍스트 기반 스크립팅
• 낮은 구현 요구 사항 (더 많은 곳에서 실행)
• 배우고 정당화하기 쉬움 (Perl 및 Python 프로그래머는 문제 가 없습니다.
• 프로그램 이동이 더 쉬워졌습니다-텍스트 파일!
• 네이티브 환경과 잘 어울립니다.
• Java가 실행되는 모든 곳에서 jRuby가 실행됩니다.
• 더 크고 훨씬 더 활동적인 커뮤니티

일부는 gst (GNU Smalltalk)에 대해 언급했습니다. 문제는 여전히 남아 있습니다.

더 강력하고 빠르게 만드는 것을 사용하여 도전을 이길 수 있습니다.

우리 를 위해 집 프레임 워크 조금, 우리는 정말 해변의 상단에있는 우리의 초강대국입니다 만들었습니다.

저는 RoR 커뮤니티를 좋아하고 올바른 태도를 가지고 있습니다. 그것은 매우 가치있는 일입니다. 그러나 동시에 기술적으로 해변은 더 복잡한 문제에 대해 당신을 더 강하게 만듭니다.

오픈 소스를 사용하여 멋진 해변 웹 앱을 만들 수 있습니다.

dabbledb은 해변을 기반으로 한 sartup 였고, 헤이! Avi는 올해 6 월에 트위터에 판매했습니다!

나는 다른 사람들이 당신의 이니셔티브를 승인 할 때까지 기다릴 필요가 없다고 말합니다.

그냥 가세요. 완료하십시오. 작동하는 모습을 보여주세요.

당신은 혼자가 아닙니다. 우리는 같은 배에 있습니다.

로버트 마틴 (RailsConf 2009)의 흥미로운 관점 : "스몰 토크를 죽인 것이 루비도 죽일 수있다"

문제의 일부는 개발 환경이 런타임이라고 생각합니다. 이것은 많은 힘을 제공하지만 더 큰 학습 곡선을 제공합니다.

여기 Hello World 튜토리얼이 있습니다.

이것은 텍스트 편집기를 열고 텍스트를 복사하여 붙여넣고 저장을 누르고 컴파일러를 실행하는 방법을 알아야하는 다른 언어와는 매우 다릅니다. 환경을 사용하는 방법을 알아야합니다. 이 튜토리얼은 내가 실행할 수있는 기본 프로그램 (이 튜토리얼의 결함 일 가능성이 높음)을 만드는 방법도 보여주지 않습니다.

대부분의 다른 언어보다 일을 처리하는 데 드는 비용이 확실히 더 높습니다.

대부분의 언어에는 눈에 띄는 멋진 코드가 있습니다. 나는 스몰 토크에서 그것을 보지 못했습니다. 나는 또한 스몰 토크가 너무 오랫동안 사용되어 왔고 여전히 상대적으로 모호하기 때문에 약간의 오명이 있다고 생각합니다.

가장 큰 차이점은 Ruby가 USEAGE 측면에서 Perl과 훨씬 더 유사하다는 것입니다. 스몰 토크는 "스크립팅"언어에 대한 발판을 마련하지 못했습니다.

VM은 정말 멋지고 루비가 이와 비슷한 것을 가질 수 있기를 바랍니다. 그래서 우리는 루비로 작성된 OS의 모든 것을 메모리 공간의 객체로 취급 할 수 있기를 바랍니다.하지만 그때까지는 루비의 간결하고 짧은 구문, 작은 스크립트를 작성하고 나중에 다시 사용하십시오. Ruby는 perl의 모든 장점을 가지고 있으며 OOP는 perl의 OOP 해킹보다 스몰 토크와 훨씬 더 유사합니다.

나는 Jonke의 대답보다 더 나아가서, 모든 취향에 맞도록 거의 충분히 강력한 커뮤니티를 가진 많은 언어가 있으며, 이들 중 일부는 주류 인식을 가지고 있습니다 (즉, 관리자가 작동합니다).

언어의 기본을 배우는 것은 쉽지만 실제로 효과적으로 사용하려면 플랫폼과 도구, 구문 및 관용구를 배우는 데 충분한 시간을 투자해야합니다. IIRC, McConnell은 진정으로 능숙 해지는 데 약 3 년이 걸린다고 주장합니다.

이러한 점을 감안할 때 LISP 및 Smalltalk와 같은 언어에 많은 시간을 소비하는 것을 정당화하기는 어렵습니다. 비록 그것들이 흥미롭고 아마도 살펴보기에 교육적 일지라도.

논의 후발 자로서 Smalltalk 및 Lisp의 주요 문제점은 공유 호스팅에서 CGI 또는 FastCGI로 실행할 수 없다는 것입니다.

씻지 않은 대중은 VPS 또는 전용 서버가 필요하다면 절대 사용하지 않을 것입니다. IMHO Seaside는 거의 모든 것보다 우수하지만 Dreamhost 또는 Webfaction에서 실행됩니까?