Tại sao sử dụng Ruby thay vì Smalltalk? [đóng cửa]

Ruby đang trở nên phổ biến , phần lớn là do ảnh hưởng của Ruby on Rails, nhưng có vẻ như nó hiện đang phải vật lộn với tuổi mới lớn. Có rất nhiều điểm tương đồng giữa Ruby và Smalltalk - maglev là một minh chứng cho điều đó. Mặc dù có cú pháp khác thường hơn, Smalltalk có tất cả (nếu không muốn nói là nhiều hơn) vẻ đẹp hướng đối tượng của Ruby.

Từ những gì tôi đã đọc, Smalltalk dường như đã đánh bại Ruby:

• Trưởng thành (phát triển vào những năm 1970)
• Ổn định
• Hỗ trợ thương mại
• Kiểm soát nguồn phân tán (hiểu cấu trúc của mã, không chỉ khác biệt văn bản)
• Một số triển khai của VM
• Hỗ trợ đa nền tảng
• Các khuôn khổ ven biển web như một thay thế mạnh mẽ để Rails

Có vẻ như Ruby chỉ đang phát minh lại bánh xe. Vì vậy, tại sao các nhà phát triển Ruby không sử dụng SmallTalk? Ruby có gì mà Smalltalk không có?

Đối với hồ sơ: Tôi là một chàng trai Ruby có ít hoặc không có kinh nghiệm trong Smalltalk, nhưng tôi bắt đầu tự hỏi tại sao.

Chỉnh sửa: Tôi nghĩ rằng vấn đề dễ tạo tập lệnh đã được GNU Smalltalk giải quyết . Theo tôi hiểu, điều này cho phép bạn viết smalltalk trong các tệp văn bản cũ thông thường và bạn không cần phải ở trong IDE Smalltalk nữa. Sau đó, bạn có thể chạy các tập lệnh của mình với:

gst smalltalk_file

Tôi giống một người Pythonista hơn là một người dùng Ruby, tuy nhiên những điều tương tự lại xảy ra với Ruby vì những lý do giống nhau.

• Kiến trúc của Smalltalk hơi đơn giản trong khi Python và Ruby được xây dựng từ đầu để tạo điều kiện tích hợp. Smalltalk chưa bao giờ thực sự có được sự hỗ trợ ứng dụng lai theo cách mà Python và Ruby có, vì vậy khái niệm 'smalltalk là ngôn ngữ kịch bản nhúng' chưa bao giờ được chú ý.
  
  Ngoài ra, Java không phải là thứ dễ dàng nhất để giao tiếp với các cơ sở mã khác (JNI khá vụng về), nhưng điều đó không ngăn nó đạt được sự quan tâm. IMO đối số giao diện là quan trọng - dễ nhúng không làm tổn hại đến Python - nhưng đối số này chỉ có trọng lượng vừa phải vì không phải tất cả các ứng dụng đều yêu cầu khả năng này. Ngoài ra, các phiên bản sau của Smalltalk đã giải quyết cơ bản vấn đề này.

• Thư viện lớp của hầu hết các triển khai smalltalk chính (VisualWorks, VisualAge, v.v.) rất lớn và nổi tiếng với đường cong học tập khá dốc. Hầu hết các chức năng chính trong Smalltalk đều bị ẩn đi đâu đó trong thư viện lớp, ngay cả những thứ cơ bản như luồng và bộ sưu tập. Mô hình ngôn ngữ cũng là một cú sốc văn hóa đối với những người không quen thuộc với nó và cách nhìn từng phần của chương trình do trình duyệt trình bày hoàn toàn khác với những gì hầu hết mọi người đã từng làm.
  
  Hiệu quả tổng thể là Smalltalk có một danh tiếng (hơi xứng đáng) là khó học; để trở thành một lập trình viên Smalltalk thực sự thành thạo sẽ mất khá nhiều thời gian và công sức. Ruby và Python dễ học hơn nhiều và mang đến cho các lập trình viên mới tốc độ.

• Về mặt lịch sử, việc triển khai Smalltalk chính thống khá tốn kém và cần phần cứng lạ để chạy, như có thể thấy bài đăng trên net.lang.st80 này từ năm 1983 . Windows 3.1, NT và '95 và OS / 2 là hệ điều hành thị trường đại chúng đầu tiên trên phần cứng phổ thông có khả năng hỗ trợ triển khai Smalltalk với tích hợp hệ thống gốc tốt. Trước đây, phần cứng Mac hoặc máy trạm là những nền tảng rẻ nhất có khả năng chạy Smalltalk một cách hiệu quả. Một số triển khai (đặc biệt là Digitalk) đã hỗ trợ hệ điều hành PC khá tốt và đã thành công trong việc đạt được một số lực kéo.
  
  Tuy nhiên, OS / 2 chưa bao giờ thành công và Windows đã không đạt được sự chấp nhận phổ biến cho đến giữa những năm 1990. Thật không may, điều này lại trùng hợp với sự nổi lên của Web như một nền tảng và một lực đẩy tiếp thị lớn đằng sau Java. Java đã nắm bắt được hầu hết các chia sẻ tư duy trong phần cuối của những năm 1990, khiến Smalltalk trở nên giống một chút.

• Ruby và Python hoạt động trong một chuỗi công cụ thông thường hơn và không kết hợp chặt chẽ với một môi trường phát triển cụ thể. Mặc dù các IDE Smalltalk mà tôi đã sử dụng đủ đẹp, nhưng tôi sử dụng PythonWin để phát triển Python phần lớn vì nó có một trình soạn thảo đẹp với đánh dấu cú pháp và không bị lỗi.
  
  Tuy nhiên, Smalltalk được thiết kế để sử dụng với IDE (trên thực tế, Smalltalk là IDE đồ họa ban đầu) và vẫn có một số tính năng tốt không bị sao chép bởi các hệ thống khác. Kiểm tra mã với đánh dấu và 'Hiển thị nó' vẫn là một tính năng rất hay mà tôi chưa bao giờ thấy trong Python IDE, mặc dù tôi không thể nói cho Ruby.

• Smalltalk đã hơi muộn khi đến với bữa tiệc ứng dụng web. Những nỗ lực ban đầu như VisualWave chưa bao giờ thành công rực rỡ và phải đến khi Seaside ra mắt, một web framework tốt mới được chấp nhận trong vòng kết nối Smalltalk. Trong khi đó, Java EE đã có một vòng đời chấp nhận hoàn toàn bắt đầu với những người hâm mộ cuồng nhiệt quảng cáo nó và cuối cùng chán nản và chuyển sang Ruby; -}
  
  Trớ trêu thay, Seaside đang bắt đầu có một chút chia sẻ về tư duy giữa các cognoscenti, vì vậy chúng ta có thể thấy rằng Smalltalk đi theo quay trở lại phổ biến.

Phải nói rằng, Smalltalk là một hệ thống rất tốt khi bạn đã tìm ra cách điều khiển nó.

Khi tôi rời khỏi nhà vào buổi sáng để đi làm, tôi thường gặp khó khăn với quyết định rẽ trái hay rẽ phải theo đường lái xe của mình (tôi sống ở giữa đường). Dù bằng cách nào cũng sẽ đưa tôi đến đích. Một con đường dẫn tôi đến đường cao tốc, tùy thuộc vào giao thông, có thể sẽ đưa tôi đến văn phòng nhanh nhất. Tôi phải lái xe rất nhanh trong ít nhất một đoạn đường và tôi có cơ hội tốt để nhìn thấy một hoặc hai cô gái xinh đẹp trên đường đi làm của họ :-)

Con đường khác cho phép tôi đi xuống một con đường phía sau đầy gió và mê hoặc với toàn cây che phủ. Con đường đó khá thú vị và trong hai cách tiếp cận chắc chắn là vui hơn, mặc dù nó có nghĩa là tôi sẽ đến văn phòng muộn hơn so với khi tôi đi trên đường cao tốc. Mỗi cách đều có giá trị của nó. Vào những ngày tôi rất vội, tôi thường sẽ đi trên đường cao tốc mặc dù tôi có thể gặp phải dòng xe cộ và tôi cũng tăng khả năng bị tai nạn (nếu tôi không cẩn thận trong lúc vội vàng). Những ngày khác, tôi có thể chọn con đường đầy cây cối và lái xe dọc theo, thưởng thức phong cảnh và nhận ra rằng tôi đã đến muộn. Tôi có thể cố gắng tăng tốc, tăng khả năng bị phạt hoặc tự mình gây ra tai nạn.

Không có cách nào tốt hơn cách khác. Mỗi người đều có những lợi ích và rủi ro, và mỗi thứ sẽ giúp tôi đạt được mục tiêu của mình.

Tôi nghĩ rằng câu hỏi của bạn là phần nào thiếu điểm. Bạn không nên chọn, bạn nên học cả hai!

Nếu bạn thực sự ở một vị trí mà bạn có thể chọn khung tiếp theo (vm, cơ sở hạ tầng) thì bạn cần phải quyết định sử dụng cái gì và có thể đặt một câu hỏi cụ thể với ưu và nhược điểm từ góc độ ứng dụng của bạn dự định làm gì.

Tôi đã sử dụng smalltalk (thích nó) và ruby ​​(yêu nó).

Ở nhà hoặc cho dự án nguồn mở, tôi có thể sử dụng mọi ngôn ngữ tôi thích, nhưng khi làm việc, tôi phải chấp nhận.

Tôi bắt đầu sử dụng ruby ​​(tại nơi làm việc) bởi vì chúng tôi cần một số ngôn ngữ kịch bản hoạt động ít nhiều tương đương với solaris, linux và windows (98,2000, xp). Ruby vào thời điểm đó chưa được biết đến với Average-joe và không tồn tại bất kỳ đường ray nào. Nhưng nó rất dễ dàng để bán cho tất cả mọi người tham gia.

(Tại sao không phải là python? Sự thật? Tôi đã từng dành một tuần để tìm kiếm một lỗi đã xảy ra khi một thiết bị đầu cuối chuyển đổi không gian của tôi thành một tab và ý định bị xáo trộn).

Vì vậy, mọi người bắt đầu viết mã ngày càng nhiều bằng ruby ​​vì nó rất thư giãn, thích thú và không phải là một đám mây trên bầu trời.

Paul Graham tổng kết

Chắc chắn là hầu hết mọi người không chọn ngôn ngữ lập trình chỉ đơn giản dựa trên thành tích của họ. Hầu hết các lập trình viên được người khác yêu cầu sử dụng ngôn ngữ nào.

và

Để trở nên hấp dẫn đối với tin tặc, một ngôn ngữ phải tốt để viết các loại chương trình mà họ muốn viết. Và điều đó có nghĩa là, có lẽ đáng ngạc nhiên, nó phải tốt cho việc viết các chương trình bỏ túi.

Và khi ở vùng đất Lisp, hãy cố gắng thay thế LISP bằng smalltalk

Thư viện, cộng đồng và động lực của Ruby rất tốt

Vì vậy, nếu LISP vẫn mạnh hơn Ruby, tại sao không sử dụng LISP? Những phản đối điển hình đối với việc lập trình trong LISP là:

1. Không có đủ thư viện.
2. Chúng tôi không thể thuê lập trình viên LISP.
3. LISP đã không đi đến đâu trong 20 năm qua.

Đây không phải là những phản đối áp đảo, nhưng chúng chắc chắn đáng xem xét.

và

Bây giờ, với sự lựa chọn giữa một ngôn ngữ mạnh mẽ và ngôn ngữ phổ biến, bạn nên chọn ngôn ngữ mạnh mẽ. Nhưng nếu sự khác biệt về sức mạnh là nhỏ, thì việc trở nên phổ biến có rất nhiều lợi thế. Vào năm 2005, tôi đã suy nghĩ rất lâu trước khi chọn LISP thay vì Ruby. Tôi có lẽ chỉ làm điều đó nếu tôi cần mã được tối ưu hóa hoặc macro hoạt động như trình biên dịch chính thức.

Tôi sẽ nói ngược lại: Cú pháp Smalltalk là một trong những cú pháp ngôn ngữ lập trình đơn giản và mạnh mẽ.

Đúng là các ngôn ngữ rất giống nhau. Cách giải thích nông cạn đó là gọi Ruby là một ban nhạc cover Smalltalk. Cách giải thích hợp lý hơn là hệ thống khép kín của Smalltalk đã cô lập nó, trong khi sự tham gia của Ruby vào hệ sinh thái Unix và thói quen sử dụng các tính năng từ mọi ngôn ngữ dưới ánh nắng mặt trời mang lại cho nó một đường cong chấp nhận nhẹ nhàng hơn vô cùng và tích hợp dễ dàng với các công cụ kickass như Git.

Giles Bowkett

Đoán xem ai đã nói điều này? (trích dẫn gần gũi, có thể không chính xác): "Tôi luôn nghĩ Smalltalk sẽ đánh bại Java. Tôi chỉ không biết liệu có được gọi là 'Ruby' hay không khi nó làm như vậy."

Trống cuộn ....

...

Câu trả lời là ... Kent Beck

Stephane Ducasse có một số cuốn sách Smalltalk tuyệt vời có sẵn tại đây:

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

vì vậy, mặc dù cộng đồng Smalltalk không phát triển như cộng đồng Ruby và Rails, nhưng vẫn có một số trợ giúp lớn ở đó.

Ruby có gì mà Smalltalk không có?

• Hỗ trợ rộng rãi, hiện tại bởi các nền tảng chính (IronRuby và jRuby) làm phong phú thêm bộ thư viện
• Những nhà truyền giáo như Dave Thomas, người, trong nhiều năm, đã đi lưu diễn khắp đất nước để rao giảng phúc âm bằng ngôn ngữ của họ. Tôi đã thấy Dave tại các hội nghị Java nói rằng anh ấy không biết Java và anh ấy thích Ruby hơn.
• Bất động sản mạnh mẽ, hiện tại trên giá sách
• Người tạo ra Ruby đã nói rằng anh ấy nghĩ về lập trình viên: Cú pháp của Ruby dường như có sức hấp dẫn Zen này. Thật khó để chốt hạ, nhưng dường như vẫn làm nức lòng người hâm mộ.
• Các bài thuyết trình sáng tạo, năng động như Giles và bài thuyết trình này thu hút được sự chia sẻ tư duy

Tôi nghĩ rằng quan điểm của bạn là đúng đắn. Như một người bạn từng nói, Ruby có thể là "bình mới rượu cũ" đối với Smalltalk. Nhưng đôi khi cái chai mới cũng quan trọng. Rượu phải được đặt đúng nơi, đúng lúc.

Đánh bại tôi. Tôi đã dành một năm để kiểm tra Ruby và thực hiện một số dự án nhỏ để xem tôi thích nó như thế nào. Tôi đoán mình là một người cố chấp Smalltalk vì mỗi khi ngồi xuống làm việc với Ruby, tôi đều thở dài và nghĩ rằng "Tôi thực sự muốn làm điều này ở Smalltalk". Cuối cùng tôi đã nhượng bộ và quay trở lại Smalltalk. Bây giờ tôi hạnh phúc hơn. Hạnh phúc hơn là tốt hơn.

Tất nhiên câu hỏi đặt ra là "Tại sao?". Không theo thứ tự đặc biệt:

1. Bởi vì IDE thổi bay mọi thứ khác mà tôi từng làm việc. Điều này bao gồm một loạt các nền tảng từ ISPF trên máy tính lớn của IBM đến Visual của Microsoft (. *), Bao gồm những thứ như Visual Basic 4-6, Visual C ++ (các hóa thân khác nhau), Borland's Turbo Pascal và các hậu duệ (ví dụ: Delphi), và các thứ trên DEC máy ở cả chế độ ký tự và trong X-Windows.
2. Bởi vì hình ảnh là một nơi tuyệt đẹp để sống. Tôi có thể tìm thấy những gì tôi muốn trong đó. Nếu tôi không thể tìm ra cách làm điều gì đó mà tôi biết ở đâu đó trong hình ảnh là một ví dụ về những gì tôi đang cố gắng làm - tất cả những gì tôi phải làm là săn lùng cho đến khi tôi tìm thấy nó. Và nó tự ghi lại - nếu bạn muốn xem chi tiết về cách hoạt động của một thứ gì đó, bạn chỉ cần mở trình duyệt trên lớp mà bạn quan tâm, xem phương pháp và đó là cách nó hoạt động. (OK, cuối cùng bạn sẽ gặp một thứ gọi là nguyên thủy, và sau đó là "ở đây có rồng", nhưng nó thường có thể hiểu được từ ngữ cảnh). Có thể làm những điều tương tự trong Ruby / C ++ / C, nhưng nó không dễ dàng. Dễ dàng là tốt hơn.
3. Ngôn ngữ là tối thiểu và nhất quán. Ba loại thông điệp - một ngôi, nhị phân và từ khóa. Điều đó cũng mô tả mức độ ưu tiên của việc thực thi - trước tiên là các thông điệp một ngôi, sau đó là các thông điệp nhị phân, sau đó là các thông điệp từ khóa. Sử dụng dấu ngoặc đơn để giúp mọi thứ. Cú pháp nhỏ, thực sự - tất cả đã xong với việc gửi tin nhắn. (Được rồi, phép gán không phải là gửi tin nhắn mà là một toán tử. Vì vậy, là toán tử 'return' (^). Các khối được bao bởi cặp dấu ngoặc vuông ([]). Có thể là một hoặc hai bit 'ma thuật' khác trong đó, but darn little ...).
4. Các khối. Vâng, tôi biết, chúng có trong Ruby (và những người khác), nhưng nếu có, bạn thực sự không thể lập trình trong Smalltalk mà không sử dụng chúng. Bạn là buộc phải học cách sử dụng chúng. Đôi khi bị ép buộc cũng tốt.
5. Lập trình hướng đối tượng không có sự thỏa hiệp - hoặc các lựa chọn thay thế, cho vấn đề đó. Bạn không thể giả vờ rằng bạn đang "làm đồ vật" trong khi vẫn làm điều cũ.
6. Vì nó sẽ làm căng não của bạn. Các cấu trúc thoải mái mà tất cả chúng ta đã quen sử dụng (if-then-else, do-while, for (;;), v.v.) không còn ở đó nữa, vì vậy bạn phải Học một cái gì đó mới. Có những điểm tương đương với tất cả những điều trên (và hơn thế nữa), nhưng bạn sẽ phải học cách nghĩ khác. Khác biệt là tốt.

Mặt khác này chỉ có thể là lời huyên thuyên của một chàng trai của những người được lập trình từ những ngày khi máy tính lớn cai trị trái đất, chúng tôi đã phải đi bộ năm dặm để làm việc thông qua bão tuyết chói mắt, khó khăn cả hai cách, và các máy tính sử dụng bánh rán cho bộ nhớ. Tôi không có gì chống lại Ruby / Java / C / C ++ /, tất cả chúng đều hữu ích trong ngữ cảnh, nhưng hãy cho tôi Smalltalk hoặc cho tôi ... tốt, có lẽ tôi nên học Lisp hoặc Scheme hoặc ... :-)

Smalltalk: mọi người chuyển tiếp ifTrue: [nghĩ] ifFalse: [không nghĩ]

Ruby: mọi người nghĩ về phía trước trừ khi nghĩ ngược lại

1) Luồng kiểm soát giống RPN của Smalltalk bằng các tin nhắn cũng giống như Lisp - nó thường xuyên và tuyệt vời nhưng khiến mọi người ngạc nhiên.

2) Ruby cho phép mọi người viết mã bằng cách sử dụng thành ngữ mà mọi người nói - làm blah trừ khi có lý do để không.

cập nhật đã viết lại mẫu Smalltalk để thực sự là mã hợp pháp hơn ..

Ruby là ngôn ngữ buzz hiện tại. Bây giờ, việc tiếp thị phần mềm được xây dựng bằng nó dễ dàng hơn so với một ngôn ngữ được phát triển vào những năm 70.

Cộng đồng! Ruby và đặc biệt là Rails có một cộng đồng tuyệt vời như vậy. Khi lộn xộn với smalltalk, dường như không có nhiều diễn viên màn hình, bài báo, bài đăng trên blog, v.v. viết về Smalltalk.

Bạn đã trả lời câu hỏi ở dòng đầu tiên: "Ruby đang trở nên phổ biến"

• Có rất nhiều mô-đun, dự án thú vị và những thứ như vậy dựa trên Ruby.
• Nếu bạn gặp khó khăn khi làm điều gì đó trong Ruby, việc tìm kiếm sự trợ giúp ở đâu đó sẽ rất nhỏ.
• Ruby được cài đặt trên rất nhiều máy tính hiện nay (Nó được bao gồm theo mặc định trên OS X, nhiều bản phân phối Linux và có những trình cài đặt tốt cho Windows) - Tôi chưa thấy smalltalk được cài đặt theo mặc định trên bất kỳ máy nào tôi đã sử dụng ..

Tôi có thể nói rằng ngôn ngữ này vượt trội hơn hay không thì một ngôn ngữ vượt trội hơn so với ngôn ngữ khác là không liên quan .. Ví dụ, PHP có thể không phải là ngôn ngữ "tốt nhất" nhưng tôi vẫn sẽ cân nhắc việc sử dụng nó thay vì Ruby on Rails (một công cụ "tốt hơn" để tạo các trang web) vì nó rất phổ biến.

Về cơ bản, những ưu và nhược điểm cụ thể của một ngôn ngữ ít quan trọng hơn nhiều so với mọi thứ xung quanh nó - cụ thể là cộng đồng.

Ruby (hoặc bất kỳ ngôn ngữ nào khác) phổ biến hơn Smalltalk (hoặc bất kỳ ngôn ngữ nào khác) vì chúng ta đang sống trong một vũ trụ hỗn loạn. Nói một cách dí dỏm:

• Từ chính Dave Thomas, "[sau] video về 'Cách xây dựng blog trong 10 phút' ... Ruby đã đi từ một ngôn ngữ thích hợp nhỏ tốt đẹp, trở thành 'ngôn ngữ bạn đã viết ứng dụng Rails'" ( Hội nghị Ruby Bài phát biểu năm 2010 ).
• Các nhà cung cấp Smalltalk ban đầu tính phí nghiêm ngặt
• Smalltalk, bởi vì nó được phát minh (đi trước thời đại) cách đây 30 năm, nên đối với nhiều người như một ngôn ngữ cũ, "đã chết" (như FORTRAN)
• các tập đoàn coi Smalltalk là một lợi thế cạnh tranh nên họ che giấu việc sử dụng nó

Trong khi các ngôn ngữ tương tự nhau về các tính năng OO, lợi thế giết người của Smalltalk là môi trường sống, mở ('hình ảnh' bị hiểu nhầm nhiều). Sau khi bạn xem ví dụ này về lập trình trong Smalltalk , cuộc tranh luận đã kết thúc.

Đối với tôi, nó không phải là trường hợp của những gì Ruby có, nhưng những gì Ruby không có. Và điều mà nó không có là cần một máy ảo và môi trường hoàn chỉnh.

Smalltalk thật tuyệt - đây là nơi tôi học được các khái niệm OO, nhưng để dễ sử dụng, tôi chọn Ruby. Tôi có thể viết mã Ruby trong trình soạn thảo yêu thích của mình và chạy nó dưới dạng dòng lệnh.

Vì vậy, đối với tôi, đó là những gì tôi chọn Ruby thay vì Smalltalk.

Tôi nghĩ rằng tất cả những ai đã làm việc với Ruby một thời gian đều nhận ra món nợ sâu sắc của nó đối với Smalltalk. Là một trong những người này, tôi thích điều gì ở Ruby hơn Smalltalk? Tôi nghĩ từ góc độ ngôn ngữ chặt chẽ, đó là đường. Ruby cố tình là một ngôn ngữ rất có cú pháp, trong khi Smalltalk là một ngôn ngữ rất tối giản về cú pháp. Về cơ bản, Ruby là mô hình đối tượng Smalltalk với đường cú pháp Perlish. Tôi tình cờ thích đường và thấy nó làm cho việc lập trình trở nên thú vị hơn.

Bạn có thể tìm một công việc khá dễ dàng khi làm Ruby.Mặc dù tôi thực sự yêu thích Smalltalk, nhưng hầu như không thể tham gia vào thị trường ngách của Smalltalk. Có rất nhiều công việc xung quanh nó, nhưng nếu bạn không tham gia khi nó phổ biến thì bây giờ hầu như không thể.

Tất cả những lý do khác đều trở nên vô nghĩa vì bạn cần dành nhiều thời gian, tập trung vào công việc thực tế để học ngoại ngữ đúng cách. Nếu bạn không giàu có một cách độc lập, cách tốt nhất để làm điều đó là tiếp xúc với nó tại nơi làm việc.

Bởi vì các bản phân phối Smalltalk được định giá bằng bội số $ 1000USD trong khi Ruby miễn phí.

Ruby là Smalltalk vì chữ số Ả Rập là chữ số La Mã. Cùng một phép toán, cú pháp dễ dàng hơn.

Tôi đã làm một chút Smalltalk - IDE là một điều tôi nhớ - Ruby có hỗ trợ IDE tốt không?

Sử dụng Ruby vì nó có thể có chân kinh doanh, Smalltalk thì không.

Tôi có thể cho bạn biết từ kinh nghiệm cá nhân. Vẫn đang sử dụng Smalltalk, yêu thích nó và đã sử dụng một vài hương vị. Mặc dù Smalltalk là một ngôn ngữ tuyệt vời và là tất cả những gì bạn đã đề cập, nhưng bạn sẽ không thuyết phục được CIO / CTO trung bình sử dụng Smalltalk trong một dự án mới. Tất nhiên, bạn thậm chí có thể gặp khó khăn khi thuyết phục một CIO / CTO bảo thủ sử dụng Ruby. Cuối cùng, bạn phải rất cẩn thận nếu bạn muốn được hỗ trợ thương mại lâu dài và khả năng tìm kiếm những nhân viên không chuyên có thể hỗ trợ hệ thống của bạn trong tương lai. Ví dụ, Smalltalk là một công ty thực sự lớn vào đầu những năm 90 và IBM đã đầu tư rất nhiều vào nó vào cuối những năm 90. Đối với IBM, Smalltalk sẽ là ngôn ngữ tiếp theo cho tất cả các ứng dụng kinh doanh. IBM đưa Smalltalk vào mọi thứ bao gồm cả hệ thống máy tính lớn của họ. Java trở nên phổ biến, chiếm lĩnh thị trường, và Smalltalk trở thành một người chơi thích hợp. Hơn một năm trước IBM đã loại bỏ ngôn ngữ này (thuật ngữ của họ là hoàng hôn). Ngoài ra, hãy xem Lịch sử. ParkPlace và Digitalk, nơi những người chơi thương mại lớn đầu tiên trong đấu trường Smalltalk, họ hợp nhất và sau đó ngừng kinh doanh.

Tôi yêu cả Smalltalk và Ruby - nhưng tôi nhận thấy rằng Ruby có thể áp dụng nhiều hơn cho những gì tôi làm hàng ngày và gần gũi với trái tim tôi hơn (thực tế mà nói). Ruby cung cấp những gì mà Smalltalk không cung cấp?

• Tập lệnh dựa trên văn bản
• Yêu cầu triển khai thấp (chạy ở nhiều nơi hơn)
• Dễ dàng học và chứng minh hơn (các lập trình viên Perl và Python sẽ có không gặp khó khăn gì
• Dễ dàng di chuyển các chương trình hơn - các tệp văn bản!
• Giao diện tốt với môi trường bản địa
• Java chạy ở bất kỳ đâu, jRuby chạy ...
• Cộng đồng lớn hơn và tích cực hơn nhiều

Một số đã đề cập đến gst (GNU Smalltalk); những vấn đề vẫn còn tồn tại.

Sử dụng bất cứ điều gì khiến bạn mạnh mẽ hơn và nhanh hơn để vượt qua thử thách của bạn.

Đối với chúng tôi , một chút trong khuôn khổ ngôi nhà, chúng tôi xây dựng trên đỉnh bờ biển thực sự là siêu năng lực của chúng tôi.

Tôi yêu cộng đồng RoR, nó có thái độ đúng đắn. Điều đó rất có giá trị. Nhưng đồng thời, về mặt công nghệ, bên bờ biển khiến bạn mạnh mẽ hơn trước những vấn đề phức tạp hơn.

Bạn có thể tạo các ứng dụng web tuyệt vời bên bờ biển bằng cách sử dụng công cụ nguồn mở.

dabbledb là một sartup dựa trên bờ biển và, hey! Avi đã bán nó cho twitter vào tháng 6 năm nay!

Tôi nói rằng bạn không cần phải đợi người khác chấp thuận sáng kiến ​​của bạn.

Chỉ cần đi cho nó. Làm cho nó hoàn thành. Cho chúng tôi thấy rằng nó hoạt động.

Bạn không cô đơn. Chúng ta đang ở trên cùng một con thuyền.

Góc nhìn thú vị từ Robert Martin (từ RailsConf 2009): "What Killed Smalltalk cũng có thể giết Ruby"

Tôi nghĩ một phần của vấn đề là môi trường phát triển-là-thời gian chạy. Điều này mang lại rất nhiều sức mạnh, nhưng nó cũng thể hiện một đường cong học tập lớn hơn.

Đây là một hướng dẫn chào thế giới.

Điều này rất khác so với các ngôn ngữ khác, nơi tôi chỉ cần biết cách mở trình soạn thảo văn bản và sao chép và dán văn bản, nhấn lưu và chạy trình biên dịch. Tôi phải biết cách sử dụng môi trường. Hướng dẫn đó thậm chí không chỉ cho tôi cách tạo một chương trình cơ bản (nhiều khả năng là lỗi của hướng dẫn đó) mà tôi có thể chạy.

Chắc chắn sẽ có chi phí cao hơn để mọi thứ diễn ra suôn sẻ hơn hầu hết các ngôn ngữ khác.

Hầu hết các ngôn ngữ đều có một số mã đẹp bắt mắt mà chúng có thể thể hiện. Tôi chưa thấy điều đó với Smalltalk. Tôi cũng nghĩ rằng có một số kỳ thị đối với Smalltalk bởi vì nó đã tồn tại quá lâu và nó vẫn còn tương đối mù mờ.

Tôi nghĩ sự khác biệt LỚN NHẤT là Ruby giống hơn nhiều với perl về CÁCH SỬ DỤNG. Smalltalk không bao giờ có chỗ đứng trong các ngôn ngữ "kịch bản".

VM thực sự rất tuyệt và tôi hy vọng ruby ​​sẽ có thứ gì đó tương tự như nó để chúng tôi có thể coi mọi thứ trên hệ điều hành của mình được viết bằng ruby ​​như một đối tượng trong không gian bộ nhớ, tuy nhiên cho đến lúc đó tôi chỉ đơn giản là thích thú với cú pháp ngắn gọn của Ruby, khả năng viết một script nhỏ và sử dụng lại sau đó. Ruby có tất cả những ưu điểm của perl và OOP giống với smalltalk hơn là hack OOP của perl.

Tôi sẽ đi xa hơn câu trả lời của Jonke và nói rằng hiện nay có một số lượng lớn các ngôn ngữ có một cộng đồng rất mạnh, gần như đủ để phù hợp với mọi sở thích và một tập hợp con trong số này được công nhận chính thống (tức là người quản lý của bạn sẽ cho phép bạn sử dụng chúng tại hoạt động tốt).

Thật dễ dàng để học những điều cơ bản của một ngôn ngữ, nhưng để thực sự sử dụng nó một cách hiệu quả, bạn cần đầu tư đủ thời gian để tìm hiểu nền tảng và các công cụ, cũng như cú pháp và thành ngữ. IIRC, McConnell tuyên bố rằng phải mất khoảng ba năm để trở nên thực sự thành thạo.

Với những điều đó, thật khó để biện minh cho việc dành nhiều thời gian cho các ngôn ngữ như LISP và Smalltalk, mặc dù chúng rất thú vị và có lẽ mang tính giáo dục.

Là người đến sau trong cuộc thảo luận, vấn đề chính với Smalltalk và Lisp là bạn không thể chạy chúng với CGI hoặc FastCGI trên chia sẻ lưu trữ.

Khối lượng lớn chưa được rửa sẽ không bao giờ sử dụng chúng nếu họ cần VPS hoặc máy chủ chuyên dụng để sử dụng chúng. IMHO Seaside vượt trội hơn hầu hết mọi thứ, nhưng liệu nó có chạy trên Dreamhost hay Web thỏa mãn không?