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 프로그래밍에 대한 일반적인 이의는 다음과 같습니다.
- 라이브러리가 충분하지 않습니다.
- LISP 프로그래머를 고용 할 수 없습니다.
- LISP는 지난 20 년 동안 아무데도 없었습니다.
이것들은 압도적 인 반대는 아니지만 확실히 고려할 가치가 있습니다.
과
이제 강력한 언어와 대중적인 언어 중 하나를 선택하면 강력한 언어를 선택하는 것이 좋습니다. 그러나 권력의 차이가 미미하다면 인기가 있다는 것은 여러 가지 좋은 이점이 있습니다. 2005 년에는 Ruby 대신 LISP를 선택하기 전에 오랫동안 열심히 생각했습니다. 최적화 된 코드 나 완전한 컴파일러 역할을하는 매크로가 필요한 경우에만 수행 할 것입니다.
답변
그 반대입니다. 스몰 토크 구문은 가장 간단하고 강력한 프로그래밍 언어 구문 중 하나입니다.
답변
언어가 매우 비슷하다는 것은 사실입니다. 이를 해석하는 얕은 방법은 Ruby를 Smalltalk 커버 밴드라고 부르는 것입니다. 더 합리적인 해석은 스몰 토크의 폐쇄 형 시스템이 그것을 분리 한 반면, 루비가 유닉스 생태계에 참여하고 태양 아래에서 모든 언어의 기능을 사용하는 습관은 무한히 더 부드러운 채택 곡선을 제공하고 Git과 같은 멋진 도구와 쉽게 통합된다는 것입니다.
답변
누가 말했는지 맞춰보세요? (인용문은 가깝지만 정확하지 않을 수도 있습니다) : “저는 항상 스몰 토크가 자바를 이길 것이라고 생각했습니다. 그렇게했을 때 ‘루비’라고 불릴 지 몰랐습니다.”
드럼 롤 ….
…
대답은 … 켄트 벡
답변
Stephane Ducasse에는 다음과 같은 훌륭한 Smalltalk 책이 있습니다.
http://stephane.ducasse.free.fr/FreeBooks.html
따라서 Smalltalk 커뮤니티는 Ruby 및 Rails 커뮤니티만큼 많지는 않지만 여전히 큰 도움이 있습니다.
