Po co używać Rubiego zamiast Smalltalk? [Zamknięte]

121

Ruby staje się popularny , głównie dzięki wpływowi Ruby on Rails, ale wydaje się, że obecnie boryka się z okresem dojrzewania. Istnieje wiele podobieństw między Rubim i Smalltalk - maglev jest tego świadectwem. Pomimo bardziej niezwykłej składni Smalltalk ma wszystko (jeśli nie więcej) zorientowanego obiektowo piękna Rubiego.

Z tego, co przeczytałem, wydaje się, że Smalltalk radzi sobie z Ruby:

Wygląda na to, że Ruby po prostu wymyśla koło na nowo. Dlaczego więc programiści Ruby nie używają SmallTalk? Co ma Ruby, a Smalltalk nie?

Dla przypomnienia: jestem Rubinem z niewielkim lub żadnym doświadczeniem w Smalltalk, ale zaczynam się zastanawiać, dlaczego.


Edycja: Myślę, że problem łatwości pisania skryptów został rozwiązany przez GNU Smalltalk . Jak rozumiem, pozwala to na pisanie smalltalk w zwykłych starych plikach tekstowych i nie musisz już być w środowisku Smalltalk IDE. Następnie możesz uruchamiać swoje skrypty za pomocą:

gst smalltalk_file
dwubitowych głupców
źródło
47
Bo wszyscy wciąż czekają na „Smalltalk on Snails”?
Mark Rushakoff
10
Technicznie nazywa się „Seaside” (www.seaside.st) i działa dość szybko na maszynie wirtualnej Gemstone, która ma kompilator JIT. Jest też port Ruby do maszyny wirtualnej Gemstone o nazwie Maglev.
ConcernedOfTunbridgeWells
3
Po przejrzeniu wszystkich tych komentarzy poniżej, będąc fanem rubinów przez ostatnie 5 lat, teraz kusi mnie, aby nauczyć się smalltalk jak najszybciej
Amol Pujari
1
GNU Smalltalk jest prawie jedyną bezpłatną implementacją, która nie jest sztywno połączona z GUI. Myślę, że to nadal jest krytyczne.
eonil
Łącze „rozproszona kontrola źródła” jest uszkodzone.
Piovezan

Odpowiedzi:

88

Jestem bardziej Pythonistą niż użytkownikiem Rubiego, jednak to samo dotyczy Rubiego z tych samych powodów.

  • Architektura Smalltalk jest nieco izolowana, podczas gdy Python i Ruby zostały zbudowane od podstaw, aby ułatwić integrację. Smalltalk nigdy tak naprawdę nie uzyskał wsparcia dla aplikacji hybrydowych w taki sposób, jak Python i Ruby, więc koncepcja „smalltalk jako wbudowanego języka skryptowego” nigdy się nie przyjęła.

    Nawiasem mówiąc, Java nie była najłatwiejszą rzeczą do połączenia z innymi bazami kodu (JNI jest dość niezdarna), ale to nie powstrzymało go przed zdobyciem wiedzy. IMO argument dotyczący interfejsu jest znaczący - łatwość osadzania nie zaszkodziła Pythonowi - ale ten argument ma tylko umiarkowaną wagę, ponieważ nie wszystkie aplikacje wymagają takiej możliwości. Ponadto późniejsze wersje Smalltalk w znacznym stopniu rozwiązały problem zaściankowości.

  • Biblioteka klas większości głównych implementacji smalltalk (VisualWorks, VisualAge itp.) Była duża i miała reputację dość stromej krzywej uczenia się. Większość kluczowych funkcji Smalltalk jest ukryta gdzieś w bibliotece klas, nawet podstawowe rzeczy, takie jak strumienie i kolekcje. Paradygmat językowy jest również czymś w rodzaju szoku kulturowego dla kogoś, kto go nie zna, a fragmentaryczny obraz programu prezentowany przez przeglądarkę jest zupełnie inny niż to, do czego przywykła większość ludzi.

    Ogólny efekt jest taki, że Smalltalk zyskał (nieco zasłużoną) reputację jako trudny do nauczenia; potrzeba sporo czasu i wysiłku, aby stać się naprawdę biegłym programistą Smalltalk. Ruby i Python są znacznie łatwiejsze do nauczenia i przyspieszają pracę nowych programistów.

  • Historycznie rzecz biorąc, główne implementacje Smalltalk były dość drogie i wymagały egzotycznego sprzętu do uruchomienia, jak widać w tym wpisie net.lang.st80 z 1983 roku . Windows 3.1, NT oraz '95 i OS / 2 były pierwszymi systemami operacyjnymi na rynku masowym na głównym sprzęcie, zdolnymi do obsługi implementacji Smalltalk z przyzwoitą natywną integracją systemu. Wcześniej komputery Mac lub stacje robocze były najtańszymi platformami umożliwiającymi efektywne działanie Smalltalk. Niektóre implementacje (szczególnie Digitalk) całkiem dobrze wspierały systemy operacyjne komputerów osobistych i odniosły sukces.

    Jednak OS / 2 nigdy nie odniósł takiego sukcesu, a Windows nie osiągnął akceptacji głównego nurtu aż do połowy lat 90-tych. Niestety zbiegło się to w czasie z pojawieniem się Internetu jako platformy i dużym naciskiem marketingowym za Javą. Java przejęła większość zainteresowania w drugiej połowie lat 90-tych, co sprawiło, że Smalltalk stał się nieco inny.

  • Ruby i Python działają w bardziej konwencjonalnym łańcuchu narzędzi i nie są ściśle powiązane z określonym środowiskiem programistycznym. Chociaż IDE Smalltalk, których użyłem, są wystarczająco ładne, używam PythonWin do programowania w Pythonie głównie dlatego, że ma ładny edytor z podświetlaniem składni i nie jest pod stopami.

    Jednak Smalltalk został zaprojektowany do użytku z IDE (w rzeczywistości Smalltalk był oryginalnym graficznym IDE) i nadal ma kilka fajnych funkcji, które nie są replikowane przez inne systemy. Testowanie kodu za pomocą funkcji podświetlania i „Pokaż to” jest nadal bardzo fajną funkcją, której nigdy nie widziałem w środowisku Python IDE, chociaż nie mogę mówić w imieniu Rubiego.

  • Smalltalk nieco spóźnił się na imprezę poświęconą aplikacjom internetowym. Wczesne wysiłki, takie jak VisualWave, nigdy nie odniosły wielkiego sukcesu i dopiero po pojawieniu się Seaside przyzwoity framework sieciowy zyskał akceptację w kręgach Smalltalk. W międzyczasie Java EE przeszła pełny cykl akceptacji, począwszy od szalejących fanboyów, którzy ją promowali, a na końcu znudzili się i przeniosli na Ruby; -}

    Jak na ironię, Seaside zaczyna mieć trochę wspólnego myślenia wśród znawców, więc może się okazać, że Smalltalk jeździ, wrócić do popularności.

Powiedziawszy to, Smalltalk to bardzo fajny system, gdy już się nauczysz, jak nim sterować.

ConcernedOfTunbridgeWells
źródło
1
Myślę, że punkt biblioteki klas jest poza bazą. Wiem, że zarówno Smalltalk, jak i Ruby, a biblioteki klas są bardzo podobne. Jakiekolwiek problemy, jakie miałem przy nauce jednego, bym się nauczył drugiego. Zrobiwszy najpierw więcej ruby, znacznie ułatwiło to naukę bibliotek Smalltalk. W większości miejsc są zadziwiająco podobne. Nie sądzę, żeby biblioteka klas lub sam język utrudniał Smalltalk niż Ruby.
Sean T Allen
2
Zarówno VW, jak i VA Smalltalk cieszyły się reputacją trudnego uczenia się ze względu na rozmiar bibliotek klas. W tamtym czasie było to dość powszechnie znane. Nauczyłem się Smalltalk ze starej wersji DOS Digitalk Smalltalk / V, która miała znacznie mniejszą bibliotekę klas. Podręcznik do tego był mniej więcej tego samego rozmiaru co książka PP Ruby i podobnie jak w tej książce, odniesienie do biblioteki klas stanowiło około połowy całkowitej liczby stron. Jednak biblioteki klas dla VW i VA są znacznie, dużo większe.
ConcernedOfTunbridgeWells
79

Kiedy wychodzę rano z domu do pracy, często borykam się z decyzją o skręceniu w lewo lub w prawo z drogi dojazdowej (mieszkam na środku ulicy). Tak czy inaczej, dotrzesz do celu. Jedna droga prowadzi mnie na autostradę, która w zależności od natężenia ruchu prawdopodobnie najszybciej doprowadzi mnie do biura. Przez przynajmniej część drogi jeżdżę bardzo szybko i mam duże szanse na zobaczenie jednej lub dwóch ładnych dziewczyn w drodze do pracy :-)

Drugi sposób pozwala mi podróżować po bardzo urokliwej, wietrznej bocznej drodze z całkowitym zadrzewieniem. Ta ścieżka jest całkiem przyjemna iz tych dwóch podejść jest zdecydowanie przyjemniejsza, chociaż oznacza to, że do biura dotrę później niż autostradą. Każdy sposób ma swoje zalety. W dni, w których bardzo się śpieszę, zazwyczaj jeżdżę autostradą, chociaż mogę natknąć się na korki, a także zwiększam swoje szanse na wypadek (jeśli nie będę ostrożny w pośpiechu). W inne dni mogę wybrać leśną ścieżkę i jechać dalej, podziwiając krajobrazy i zdając sobie sprawę, że spóźniam się. Mogę spróbować przyspieszyć, zwiększając swoje szanse na zdobycie mandatu lub spowodowanie wypadku.

Żaden sposób nie jest lepszy od drugiego. Każdy z nich ma swoje korzyści i ryzyko, i każdy doprowadzi mnie do celu.

Mario Aquino
źródło
5
Która z nich to międzystanowa, a która to wietrzna droga z tyłu porośnięta drzewami? lol
Charlie Flowers
9
Charlie: to sprawia, że ​​jest zen :)
xofz
32
A w jakim języku są ładniejsze dziewczyny?
Tin Man,
25

Myślę, że twoje pytanie trochę mija się z celem. Nie powinieneś wybierać, powinieneś nauczyć się ich obu!

Jeśli naprawdę jesteś w stanie wybrać następny framework (vm, infrastrukturę), musisz zdecydować, czego użyć i możesz zadać konkretne pytanie z zaletami i wadami z perspektywy tego, co ma zrobić Twoja aplikacja.

Użyłem smalltalk (uwielbiam to) i ruby ​​(uwielbiam).

W domu lub w projekcie open source mogę używać każdego języka, który lubię, ale wykonując pracę muszę się dostosować.

Zacząłem używać ruby ​​(w pracy), ponieważ potrzebowaliśmy języka skryptowego, który zachowywałby się mniej więcej tak samo pod systemami solaris, linux i windows (98,2000, xp). Ruby był w tym czasie nieznany przeciętnemu joe i nie było tam żadnych szyn. Ale sprzedaż była łatwa dla wszystkich zaangażowanych.

(Dlaczego nie Python? Prawda? Spędziłem raz tydzień na poszukiwaniu błędu, który wydarzył się, gdy terminal zamienił moje miejsce na kartę i zamiar się popsuł).

Więc ludzie zaczęli kodować coraz więcej w języku Ruby, ponieważ był on tak relaksujący, przyjemny i nie był chmurą na niebie.

Paul Graham podsumowuje to

To prawda, z pewnością, że większość ludzi nie wybiera języków programowania po prostu na podstawie ich zalet. Większości programistów mówi się, jakiego języka ma używać ktoś inny.

i

Aby być atrakcyjnym dla hakerów, język musi być dobry do pisania programów, które chcą napisać. A to oznacza, być może zaskakujące, że musi być dobry do pisania programów jednorazowych.

A kiedy byłeś na ziemi Lispa, spróbuj zamienić LISP na smalltalk

Biblioteki, społeczność i rozmach Rubiego są dobre

Więc jeśli LISP jest nadal potężniejszy niż Ruby, dlaczego nie użyć LISP-a? Typowe zastrzeżenia do programowania w LISP to:

  1. Brakuje bibliotek.
  2. Nie możemy zatrudniać programistów LISP.
  3. LISP nie poszedł donikąd w ciągu ostatnich 20 lat.

Nie są to przytłaczające zastrzeżenia, ale z pewnością warto je rozważyć.

i

Mając wybór między językiem potężnym a popularnym, wybór tego potężnego może mieć sens. Ale jeśli różnica w mocy jest niewielka, bycie popularnym ma wiele zalet. W 2005 roku zastanawiałbym się długo i intensywnie przed wyborem LISP-a zamiast Rubiego. Prawdopodobnie zrobiłbym to tylko wtedy, gdybym potrzebował zoptymalizowanego kodu lub makr, które działały jako pełnoprawne kompilatory.

Jonke
źródło
4
Ahem, „ostatnie 20 lat”?!?! Myślę, że miałeś na myśli „ostatnie 51 lat”. :-)
DigitalRoss
1
@DigitalRoss - wybrałbym 20; W pewnym momencie LISP był dość popularny w pewnych kręgach, ale (niezależnie od ViaWeb) od lat 80. nie widziano żadnych nowych „zabójczych aplikacji”. Jednak technologie oparte na LISP w rzeczywistości uzyskały całkiem spore finansowanie w latach 60., 70. i 80. XX wieku; ludzie naprawdę myśleli, że LISP od dłuższego czasu jeździ w różne miejsca.
ConcernedOfTunbridgeWells
2
@DigitalRoss tak, jeśli zignorujesz takie rzeczy, jak kontynuacje, multimetody, makra, optymalizacja wywołań ogonowych, z góry mojej głowy.
Frank Shearar
Zawsze uważam, że tego rodzaju argumenty są mniej przyjemne. Nie ma najlepszego języka i każdy inżynier oprogramowania może zrobić lisp, schemat, ruby, php lub c lub cokolwiek. A jeśli nie może, może się tego nauczyć w 2 tygodnie. Język to tylko narzędzie. Nie musisz z tym spać.
Edgar Klerks
22

Powiedziałbym odwrotnie: składnia Smalltalk jest jedną z najprostszych i najmocniejszych składni języka programowania.

Igor Stasenko
źródło
7
Chcę tylko powiedzieć amen!
Schpaencoder
19

To prawda, że ​​języki są do siebie bardzo podobne. Płytkim sposobem zinterpretowania tego jest nazwanie Ruby zespołem coverowym Smalltalk. Bardziej rozsądną interpretacją jest to, że zamknięty system Smalltalk wyodrębnił go, podczas gdy udział Rubiego w ekologii Uniksa i nawyk przywłaszczania funkcji z każdego języka pod słońcem daje mu nieskończenie łagodniejszą krzywą adaptacji i łatwą integrację z niesamowitymi narzędziami, takimi jak Git.

Giles Bowkett

Vesan
źródło
17

Zgadnij, kto to powiedział? (cytat jest bliski, może nie dokładny): „Zawsze myślałem, że Smalltalk pokona Javę. Po prostu nie wiedziałem, czy zostanie nazwany„ Ruby ”, kiedy to zrobił.”

Werble ....

...

Odpowiedź brzmi ... Kent Beck

Charlie Flowers
źródło
15

Stephane Ducasse ma kilka świetnych książek Smalltalk dostępnych tutaj:

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

więc chociaż społeczność Smalltalk nie jest tak płodna jak społeczności Ruby i Rails, wciąż istnieje duża pomoc.

Simon Knights
źródło
1
To zasługuje na więcej głosów!
froginvasion
15

co ma Ruby, czego nie ma Smalltalk?

  • Ogromne, aktualne wsparcie głównych platform (IronRuby i jRuby), które wzbogacają zestaw bibliotek
  • Ewangeliści tacy jak Dave Thomas, którzy od lat podróżują po całym kraju, głosząc ewangelię swojego języka. Widziałem Dave'a na konferencjach poświęconych Javie , który twierdził, że nie zna Javy i woli Rubiego.
  • Mocna, aktualna nieruchomość na półkach
  • Twórca Rubiego powiedział, że myśli o programatorze: składnia Rubiego wydaje się mieć ten urok Zen. Trudno to określić, ale wydaje się, że pobudza fanów.
  • Kreatywne, dynamiczne prezentacje, takie jak Giles i ta, która przykuwa uwagę

Myślę, że twój punkt widzenia jest słuszny. Jak kiedyś ujął to przyjaciel, Ruby mogłaby być „starym winem w nowej butelce” w porównaniu z Smalltalk. Ale czasami nowa butelka ma znaczenie. Wino musi znajdować się we właściwym miejscu we właściwym czasie.

Michael Wielkanoc
źródło
Twój pierwszy punktor jest wyłączony. Obsługa JVM i .NET VM to bzdury dla Smalltalk, ponieważ każda implementacja działa już na maszynie wirtualnej (jak inaczej mogą działać tak dobrze na wielu systemach operacyjnych, prawda?) Składnia Rubiego jest bardziej skomplikowana niż Smalltalk. Trudno określić, co jest częścią problemu;)
1
Tak, jednym z powodów, dla których niektórzy ludzie mogą używać jruny / ironruby, jest względna niedojrzałość vm ruby, ale jest kilka naprawdę fajnych bibliotek dostępnych dla .net / jvm, których mogą chcieć użyć, które nie mają odpowiedników w innych miejscach, a także niektórym firmom o wiele łatwiej jest zazębiać się z bazami kodu Java / C #.
Roman A. Taycher
2
Oczywiście uważam, że cenienie „silnej, aktualnej nieruchomości na półkach z książkami” jest jedną z kar za skomplikowany język bez żywego, dynamicznego środowiska. Kiedy pisałem w C ++, miałem półki pełne książek gotcha. Po przejściu do Smalltalk (przez Ruby) nie brakuje mi ich ani trochę. Polegając na samym IDE, aby uzyskać większość wskazówek, rzadko zostawiam obraz na więcej niż szybkie wyszukiwanie w Google i gentryfikowałem część tej półki z serią Game of Thrones;)
Sean DeNigris
14

Bije mnie. Spędziłem rok sprawdzając Rubiego i robiąc drobne projekty, aby zobaczyć, jak mi się podoba. Myślę, że jestem fanatykiem Smalltalk, ponieważ za każdym razem, gdy siadałem do pracy z Ruby, wzdychałem i pomyślałem: „Naprawdę wolałbym robić to w Smalltalk”. W końcu poddałem się i wróciłem do Smalltalk. Teraz jestem szczęśliwszy. Szczęśliwsze jest lepsze.

Co oczywiście nasuwa pytanie: „Dlaczego?”. W przypadkowej kolejności:

  1. Ponieważ IDE niszczy wszystko, z czym kiedykolwiek pracowałem. Obejmuje to kilka platform od ISPF na komputerach mainframe IBM do Visual Basic (. *) Microsoftu, w tym takie rzeczy, jak Visual Basic 4-6, Visual C ++ (różne wcielenia), Turbo Pascal firmy Borland i jego potomkowie (np. Delphi) oraz rzeczy na DEC maszyny w trybie znakowym i pod X-Windows.
  2. Ponieważ obraz to piękne miejsce do życia. Mogę tam znaleźć to, czego chcę. Jeśli nie mogę dowiedzieć się, jak coś zrobić, wiem, że gdzieś na obrazku jest przykład tego, co próbuję zrobić - wszystko, co muszę zrobić, to polować, aż go znajdę. I to jest samodokumentacja - jeśli chcesz zobaczyć szczegóły, jak coś działa, po prostu otwórz przeglądarkę klasy, która Cię interesuje, spójrz na metodę i tak to działa. (OK, w końcu trafisz na coś, co nazywa się prymitywem, a potem jest to „tu są smoki”, ale zwykle jest to zrozumiałe z kontekstu). W Rubim / C ++ / C można zrobić podobne rzeczy, ale nie jest to takie proste. Łatwiej jest lepiej.
  3. Język jest minimalny i spójny. Trzy rodzaje wiadomości - jednoargumentowe, binarne i słowo kluczowe. To również określa priorytet wykonania - najpierw komunikaty jednoargumentowe, potem komunikaty binarne, a potem komunikaty ze słowami kluczowymi. Użyj nawiasów, aby pomóc. Cholernie mała składnia, naprawdę - wszystko odbywa się za pomocą wysyłania wiadomości. (OK, przypisanie nie jest wysłaniem wiadomości, to operator. Tak samo jest z operatorem „powrotu” (^). Bloki są ujęte w pary nawiasów kwadratowych ([]). Może tam być jeden lub dwa inne „magiczne” bity, ale cholernie mało ...).
  4. Bloki. Tak, wiem, są tam w Ruby (i innych), ale do cholery, dosłownie nie możesz programować w Smalltalk bez ich używania. Jesteś zmuszony nauczyć się ich używać. Czasami bycie zmuszonym jest dobre.
  5. Programowanie zorientowane obiektowo bez kompromisów - lub alternatyw, jeśli o to chodzi. Nie możesz udawać, że „robisz przedmioty”, jednocześnie robiąc to samo.
  6. Ponieważ rozciągnie twój mózg. Wygodne konstrukcje, do których wszyscy przyzwyczailiśmy się (if-then-else, do-while, for (;;) itp.) Już nie istnieją, więc musisz nauczyć się czegoś nowego. Istnieją odpowiedniki wszystkich powyższych (i nie tylko), ale będziesz musiał nauczyć się myśleć inaczej. Inaczej jest dobrze.

Z drugiej strony może to być po prostu włóczęga faceta, który programuje od czasów, gdy na Ziemi rządziły komputery typu mainframe, musieliśmy przejść pięć mil, aby przejść przez oślepiające burze śnieżne, pod górę w obie strony, a komputery używały pączków jako pamięci. Nie mam nic przeciwko Ruby / Java / C / C ++ /, wszystkie są przydatne w kontekście, ale daj mi Smalltalk lub daj mi ... cóż, może powinienem nauczyć się Lisp lub Scheme lub ... :-)

Bob Jarvis - Przywróć Monikę
źródło
1
Pomyślałem, że pytanie brzmi: „Czego Ruby ma, a Smalltalk nie?”
Mauricio
1
@Mauricio, a @Bob odpowiedział: „Beats me”.
systemovich
1
Świetnie mówiąc, uwielbiam to! Dlaczego coś nie może być lepsze mimo że jest mniej popularne? Jeśli się nie zgadzasz, śmiem twierdzić, że nie dostaniesz Smalltalk ;-)
Amos M. Carpenter
@aaamos - dziękuję. Podejrzewam, że powodem, dla którego Smalltalk nie jest popularny, jest # 6, aw mniejszym stopniu # 5. Smalltalk nie jest miejscem „tej samej starej składni” twojej mamy - jest inne. Na przykład, jeśli znasz C, to C ++, Java i C # są całkiem wygodne. A „jak” i „dlaczego” w zachowaniu Smalltalk może być nieco zniekształcające. (Zaryzykuję, że jeśli nowy Smalltalker nie czuje, że jego głowa się odkręca, albo jest tak genialny, że od razu to oszukał, albo po prostu go nie rozumie. Tak, zastanawiam się, jak to „genialne "coś by się czuł :-).
Bob Jarvis - Przywróć Monikę
Czy próbowałeś debugować za pomocą podważenia (i wtyczek) oraz kodowania na żywo z ponownym ładowaniem zapisanych plików na gorąco? To było najlepsze programowanie, jakie miałem.
Rivenfall,
11

Smalltalk: ludzie do przodu ifTrue: [myślę] ifFałsz: [nie myślę]

Ruby: ludzie myślą naprzód, chyba że myślą wstecz

1) Przepływ sterowania przez wiadomości podobny do RPN w Smalltalk jest podobny do Lispa - jest regularny i fajny, ale dziwnie ludzi.

2) Ruby pozwala ludziom pisać kod używając idiomatycznego sposobu, w jaki ludzie mówią - rób bla, chyba że jest ku temu powód.

aktualizacja przepisała przykład Smalltalk, aby był bardziej legalnym kodem.

Andy Dent
źródło
4
Angielski jest prawdopodobnie jednym z najgorszych sposobów wyrażania instrukcji programistycznych. Mam na myśli to, że powoduje dość zamieszania wśród ludzi, nie mówiąc już o komputerach. Czy bla? Kto powinien robić bla? na co? Również twój kod ruby ​​nie ma sensu i jest nieprawidłowy. Powinien być: Ruby: people.think_forwards, chyba że people.think_backwards? a SmallTalk powinno wyglądać następująco: Smalltalk: (people think_forwards?) ifTrue: [people think_forwards])
donalbain
2
Można również dodać metodę o nazwie else: aBlock do klasy BlockClosure z kategorii metod jądra, która oceniałaby aBlock i ifTrue: oceniałby blok wywołujący.
Ricardo de Cillo
3
@donalbain, nie sugerowałem, że są to dosłowne instrukcje programowania, ale wskazujące na kolejność instrukcji. Kiedy pisałem odpowiedź, pomyślałem, że to dość oczywiste.
Andy Dent
1
@donalbain Bardzo prawdziwe, w rzeczywistości istnieje. Więcej przepływu sterowania podobnego do Rubiego znajduje się na github.com/randycoulman/SuffixConditionals . Andy, w twoim kodzie jest błąd - ludzie nie myślą wstecz, więc powinieneś był wysłać #ifFalse: ;-P
Sean DeNigris
Smalltalk ma zły marketing: dziwną składnię i obraz oparty na obrazie. Ruby jest bardziej normalny, ale ma również dobrą składnię. Java jest wpisywana i kompilowana, co uspokaja klientów. Nie miałbym nic przeciwko nauce i używaniu dziwnej składni, gdyby nie wpłynęło to na mój własny „marketing” jako programisty.
Rivenfall,
8

Ruby to aktualny język buzzów. Łatwiej jest teraz sprzedawać oprogramowanie zbudowane za jego pomocą niż język opracowany w latach 70.

koder1
źródło
Fakt, że został „opracowany w latach 70.” nie ma nic wspólnego z tym, jak trudno jest się z nim rozwijać.
gracchus
3
a mój komentarz nie ma nic wspólnego z rozwojem.
coder1
3
Przepraszam, mam tendencję do błędnego czytania, kiedy jestem zmęczony, więc muszę spędzać wakacje na przepraszaniu ludzi, których dręczyłem.
gracchus
8

Społeczność! Ruby, a zwłaszcza Railsy, ​​mają świetną społeczność. Kiedy bawić się smalltalk, wydawało się, że o Smalltalk nie napisano aż tylu zrzutów ekranu, artykułów, postów na blogu itp.

Kevin Kaske
źródło
7

Odpowiedziałeś na pytanie w swojej pierwszej linii: „Ruby staje się popularny”

  • Jest ich dużo interesujących modułów, projektów itp. Opartych na Rubim.
  • Jeśli masz problem z zrobieniem czegoś w Rubim, znalezienie pomocy gdzieś będzie trywialne.
  • Ruby jest teraz instalowany na wielu komputerach (jest domyślnie dołączony do OS X, wielu dystrybucji Linuksa i są dobre instalatory dla Windows) - nie widziałem domyślnie instalowanego smalltalk na żadnym komputerze, z którego korzystałem.

Powiedziałbym, że to, czy jeden język jest lepszy od drugiego, czy nie, jest nieistotne. Na przykład PHP może nie być "najlepszym" językiem w historii, ale nadal rozważałbym jego użycie zamiast Ruby on Rails ("lepsze" narzędzie do tworzenia witryn internetowych), ponieważ jest tak rozpowszechniony.

Zasadniczo konkretne wady i zalety języka są znacznie mniej ważne niż wszystko, co go otacza - a mianowicie społeczność.

dbr
źródło
7

Ruby (lub jakikolwiek inny język) jest bardziej popularny niż Smalltalk (lub jakikolwiek inny język), ponieważ żyjemy w chaotycznym wszechświecie. Dowcip:

  • Od samego Dave'a Thomasa, "[po] wideo na temat 'Jak zbudować blog w dziesięć minut' ... Ruby przeszedł od bycia miłym, niszowym językiem do bycia 'językiem, w którym pisałeś aplikacje Railsowe'" ( Ruby Conference Myśl przewodnia 2010 ).
  • Pierwsi sprzedawcy Smalltalk pobierali opłaty zaporowe
  • Smalltalk, ponieważ został wynaleziony (wyprzedzając swój czas) 30 lat temu, wielu osobom jawi się jako stary, „martwy” język (jak FORTRAN)
  • korporacje uważają Smalltalk za taką przewagę konkurencyjną, że ukrywają jego wykorzystanie

Podczas gdy języki są podobne w funkcjach OO, zabójczą przewagą Smalltalka jest żywe, otwarte środowisko (bardzo źle rozumiany „obraz”). Gdy obejrzysz ten przykład programowania w Smalltalk , debata dobiegnie końca.

Sean DeNigris
źródło
5

Dla mnie to nie tyle kwestia tego, co ma Ruby, ale tego, czego nie ma. A to, czego nie ma, to potrzeba maszyny wirtualnej i kompletnego środowiska.

Smalltalk jest świetny - to tam nauczyłem się koncepcji OO, ale ze względu na łatwość użytkowania stawiam na Ruby. Potrafię pisać kod Ruby w moim ulubionym edytorze i uruchamiać go z linii poleceń.

Więc dla mnie to właśnie wybrałem Ruby zamiast Smalltalk.

Simon Knights
źródło
Ale śmiało i naucz się też Smalltalk.
Simon Knights
Zgodnie z moją edycją: GNU Smalltalk umożliwia korzystanie z ulubionego edytora i uruchamianie z wiersza poleceń.
two-bit-fool
Tak - dzięki - właśnie obejrzałem i pobrałem kopię!
Simon Knights
2
Cóż, nie ma też świetnego frameworka internetowego. Rails są w porządku, ale to nie Seaside
Stephan Eggermont
3
Każda platforma smalltalk umożliwia pisanie kodu smalltalk w Twoim ulubionym edytorze. Ale jeśli lubisz odłączać się od żywego świata, to Twój wybór. Po prostu wiedz, że robiąc to, tracisz około 90% produktywności.
Igor Stasenko
5

Myślę, że każdy, kto przez jakiś czas pracował z Ruby, zdaje sobie sprawę z jej głębokiego długu wobec Smalltalk. Jako jedna z tych osób, co mi się podoba w Ruby zamiast Smalltalk? Myślę, że ze stricte językowego punktu widzenia to cukier. Ruby celowo jest językiem o bardzo ograniczonej składni, podczas gdy Smalltalk jest językiem o bardzo minimalnej składni. Ruby jest zasadniczo modelem obiektowym Smalltalk z perlish składniowym cukrem. Tak się składa, że ​​lubię cukier i uważam, że programowanie jest przyjemniejsze.

Avdi
źródło
1
Ruby ma jednak inny model obiektowy niż Smalltalk. Powiedziałbym „pod wpływem”, ale nie to samo. Możesz pisać programy w języku ruby ​​w oparciu o prototypy, unikając konieczności tworzenia nowych klas. Chociaż jest to niezwykłe, Smalltalk po prostu tego nie obsługuje.
Dafydd Rees
2
Lubię smalltalk, ponieważ mogę wymyślać i używać własnego cukru składniowego, kiedy tylko tego potrzebuję. Nie ma potrzeby używania cukru, jeśli już możesz zrobić wszystko przy minimalnej składni.
Igor Stasenko
5

W Rubim można łatwo znaleźć pracę.Chociaż naprawdę kocham Smalltalk, to praktycznie niemożliwe jest wejście do niszy Smalltalk. Jest w tym trochę pracy, ale jeśli nie dostałeś się, gdy był popularny, teraz jest praktycznie niemożliwy.

Wszystkie inne powody bledną, ponieważ musisz spędzać dużo czasu, skupiając się na prawdziwej pracy, aby właściwie nauczyć się języka. Jeśli nie jesteś bogaty samodzielnie, najlepszym sposobem na to jest kontakt z nim w pracy.

daf
źródło
4

Ponieważ dystrybucje Smalltalk zostały wycenione jako wielokrotności 1000 USD, podczas gdy Ruby jest bezpłatny.

grettke
źródło
4

Ruby to Smalltalk jak cyfry arabskie do rzymskich. Ta sama matematyka, łatwiejsza składnia.

sal
źródło
3
To jest zły sposób. Smalltalk ma znacznie prostszą składnię.
Stephan Eggermont
1
Tylko jeśli myślisz w rpn. Większość ludzi tego nie robi. Właściwie to jestem dumny z tego, że ten post wciąż zyskuje na głosach.
Sal
12
RPN? Java: foo.bar () Perl: foo-> bar () Python: foo.bar () Smalltalk: foo bar Więc poza prostszą składnią, jeśli twierdzisz, że Smalltalk to RPN, musisz powiedzieć, że wszystkie główne języki OO są „RPN”.
Randal Schwartz
2
Wystarczy porównać liczbę słów kluczowych Ruby z liczbą słów kluczowych Smalltalk. A to dopiero początek! Składnia Smalltalka mieści się na serwetce, spróbuj zrobić to z Rubim, a będzie ci ciężko.
froginvasion
3

Zrobiłem trochę Smalltalk - IDE to jedna rzecz, którą pamiętam - czy Ruby ma dobre wsparcie dla IDE?

Chris Kimpton
źródło
Tak. TextMate jest świetny, obsługa Eclipse jest dobra, a Emacs ma przyzwoity tryb.
Pete
6
Jeśli myślisz, że "TextMate / Eclipse / Emacs" jest porównywalne z wbudowanym IDE Smalltalk, to nie widziałeś prawdziwego Smalltalk!
Randal Schwartz
Nadal tęsknię za wyborem -> 'Pokaż to' z IDE w systemach, z którymi obecnie buduję - z jednym wyjątkiem: narzędzia programistyczne SQL Servera pozwolą Ci zaznaczyć wybór i wykonać go jako zapytanie. Smalltalk ma wpływ, jeśli nic innego!
ConcernedOfTunbridgeWells
IDE zbliża się do Smalltalk it IMHO ArachnoRuby. Jest lepiej zintegrowany niż jakikolwiek Emacs / TextMate itp. Jednak wydaje się, że ludzie są całkiem zadowoleni z kilku otwartych okien z różnymi narzędziami Pozdrawiam
Friedrich
@Friedrich Re "Ludzie są całkiem zadowoleni z kilku otwartych okien z różnymi narzędziami" ... "Języki programowania uczą, że nie chcesz tego, czego nie mogą zapewnić. Musisz myśleć w języku ..." - Paul Graham
Sean DeNigris
3

Użyj Rubiego, ponieważ może mieć nogi biznesowe, Smalltalk nie.

Mogę powiedzieć z własnego doświadczenia. Nadal używam Smalltalk, uwielbiam to i używam kilku smaków. Chociaż Smalltalk to świetny język i jest wszystkim, o czym wspomniałeś, prawdopodobnie nie przekonasz przeciętnego CIO / CTO do używania Smalltalk w nowym projekcie. Oczywiście możesz nawet mieć trudności z przekonaniem konserwatywnego CIO / CTO do używania Rubiego. Ostatecznie musisz być bardzo ostrożny, jeśli chcesz mieć trwałe, długoterminowe wsparcie komercyjne i mieć możliwość znalezienia pracowników spoza ulicy, którzy mogą wspierać Twoje systemy w przyszłości. Na przykład Smalltalk był naprawdę wielkim wydarzeniem na początku lat 90-tych, a IBM dużo w niego zainwestował pod koniec lat 90-tych. Dla IBM Smalltalk miał być następnym językiem dla wszystkich aplikacji biznesowych. IBM umieścił Smalltalk we wszystkim, łącznie z systemami mainframe. Java stała się popularna, przejęła rynek, a Smalltalk stał się graczem niszowym. Ponad rok temu IBM porzucił ten język (ich termin to wygaśnięcie). Spójrz także na historię. ParkPlace i Digitalk, gdzie pierwsi główni gracze komercyjni na arenie Smalltalk, połączyli się, a następnie wypadli z biznesu.

tatuś
źródło
Smalltalk "ma nogi biznesowe" - jeśli masz już odpowiednie doświadczenie i możesz znaleźć odpowiednie możliwości ...
Dafydd Rees
Twój tytuł jest mocno zawyżony. Nie każdy biznes jest ograniczony przez krótkowzrocznych CTO. Jak powiedział Paul Graham, kiedy dokładnie obalił mit, że mainstreamowy język jest bezpieczniejszy: „Będziesz miał trudności z przekonaniem spiczastego szefa, by pozwolił ci budować rzeczy w Lispie ... Ale jeśli pracujesz dla startupu, który tego nie robi” Nie masz jeszcze spiczastych szefów, możesz ... używać technologii, której twoi konkurenci, przyklejeni nieruchomo do języka mediany, nigdy nie będą w stanie dopasować. "
Sean DeNigris
2

Uwielbiam zarówno Smalltalk, jak i Ruby - ale odkryłem, że Ruby jest bardziej odpowiedni do tego, co robię na co dzień i jest bliżej mojego serca (praktycznie mówiąc). Co oferuje Ruby, czego nie ma Smalltalk?

  • Skrypty tekstowe
  • Niskie wymagania wdrożeniowe (działa w większej liczbie miejsc)
  • Łatwiejsze do nauczenia i uzasadnić (Perl i Python programiści będą musieli nie kłopotów
  • Łatwiejsze przenoszenie programów - pliki tekstowe!
  • Dobrze współpracuje ze środowiskiem natywnym
  • Wszędzie, gdzie działa Java, jRuby działa ...
  • Większa i dużo bardziej aktywna społeczność

Niektórzy wspominali o gst (GNU Smalltalk); problemy nadal istnieją.

Mei
źródło
Które „miejsca” obsługuje Ruby, a których nie obsługuje Smalltalk? Na przykład Pharo Smalltalk działa na komputerach Mac, Windows, Unix, w ogóle bez systemu operacyjnego (czy Ruby to potrafi?) I jest przenoszony na różne platformy mobilne (Android, iOS).
Sean DeNigris
A co z FreeBSD i OpenBSD? (nie, nie znam odpowiedzi ...) A co z Solarisem, HP-UX i OpenVMS? Nie chciałbym też używać Rubiego ani Smalltalk na Androida lub iOS. Największym problemem nie jest system operacyjny, ale pamięć: Ruby będzie działał w znacznie mniejszej ilości pamięci niż Smalltalk.
Mei
Najwyraźniej istnieje maszyna wirtualna FreeBSD (zobacz ostatni punkt OP na forum.world.st/SOB-minutes-3-6-12-td4453817.html ). Nie jestem pewien co do pozostałych. Jeśli chodzi o Androida i iOS, to czy chciałbyś używać Smalltalk, to jest inne pytanie niż to, czy jest on dostępny ;-) Ludzie piszą o udanych eksperymentach na tych platformach, z których widziałem kilka obiecujących screencastów.
Sean DeNigris
To też mi przypomina - przypominam sobie Smalltalk for the Palm.
Mei
2

Użyj tego, co sprawia, że ​​jesteś potężniejszy i szybszy, aby pokonać wyzwanie.

Dla nas , trochę w ramach domu, który zbudowaliśmy na wybrzeżu, jest naprawdę naszą supermocarstwem.

Uwielbiam społeczność RoR, ma właściwe podejście. To bardzo cenne. Ale jednocześnie, technologicznie, morze wzmacnia Cię przed bardziej skomplikowanymi problemami.

Możesz tworzyć wspaniałe nadmorskie aplikacje internetowe, korzystając z oprogramowania open source.

dabbledb to projekt oparty na morzu i hej! Avi sprzedał go twitterowi w czerwcu tego roku!

Mówię, że nie musisz czekać, aż inni zaakceptują twoją inicjatywę.

Po prostu to zrób. Zrób to. Pokaż nam, że to działa.

Nie jesteś sam. Jesteśmy na tej samej łodzi.

Sebastian Sastre
źródło
2

Ciekawa perspektywa z perspektywy Roberta Martina (z RailsConf 2009): „Co zabiło Smalltalk może zabić Rubiego, też”

jmoże
źródło
2
Ta mowa zakłada, że ​​smalltalk jest martwy (nie jest) i że rubin jest na tyle podobny do smalltalk w czasie i przestrzeni, że może spotkać go ten sam (nie) los. Tak nie jest.
Randal Schwartz
0

Myślę, że częścią problemu jest środowisko-programistyczne-to-runtime. Daje to dużą moc, ale daje też większą krzywą uczenia się.

Oto samouczek Hello World.

To bardzo różni się od innych języków, w których po prostu muszę wiedzieć, jak otworzyć edytor tekstu i skopiować i wkleić tekst, nacisnąć przycisk Zapisz i uruchomić kompilator. MUSZĘ wiedzieć, jak korzystać ze środowiska. Ten samouczek nawet nie pokazuje mi, jak stworzyć podstawowy program (co jest prawdopodobnie bardziej błędem tego samouczka), który mogę uruchomić.

Koszt samego rozpoczęcia pracy jest zdecydowanie wyższy niż w przypadku większości innych języków.

Większość języków ma ładny, przyciągający wzrok kod, którym mogą się pochwalić. Nie widziałem tego w Smalltalk. Myślę też, że Smalltalk ma pewne piętno, ponieważ istnieje od tak dawna i nadal jest stosunkowo mało znany.

Steve g
źródło
U dołu strony: self inform: „Hello, World!”. Zgadzam się, że krzywa uczenia się jest bardziej stroma, ale używanie słowa „witaj, świecie” jako dowodu, wydaje mi się, że to za dużo. :)
jop
Chodziło mi o to, aby zobaczyć, jak napisać coś prostego, na przykład hello workld, samouczek musi powiedzieć, które okna należy otworzyć. Nazwy i zastosowania okien nie są czymś, czego mogę się domyślić. Zajęło mi trochę klikania, aby znaleźć okna, o których mówił.
Steve g
1
Zgodnie z moją edycją: GNU Smalltalk umożliwia korzystanie z ulubionego edytora i uruchamianie z wiersza poleceń.
two-bit-fool
ruby -e 'stawia "hello world"'
Marcel Valdez Orozco
1
pharo [nazwa pliku obrazka] -e "self inform: 'hello world'"
Sean DeNigris
0

Myślę, że NAJWIĘKSZA różnica polega na tym, że Ruby jest znacznie bardziej podobny do Perla pod względem UŻYCIA. Smalltalk nigdy nie zdobył przyczółka w językach „skryptowych”.

Maszyna wirtualna jest naprawdę fajna i mam nadzieję, że Ruby będzie miał coś podobnego, dzięki czemu będziemy mogli traktować wszystko w naszym systemie operacyjnym, które jest napisane w ruby ​​jako obiekt w przestrzeni pamięci, jednak do tego czasu po prostu lubię zwięzłą, krótką składnię Rubiego, możliwość po prostu napisz mały skrypt i użyj go później. Ruby ma wszystkie zalety perla, a OOP jest znacznie bardziej podobny do smalltalk niż hack OOP perla.

Ona
źródło
0

Poszedłbym dalej niż odpowiedź Jonkego i powiedziałbym, że obecnie istnieje duża liczba języków, które mają bardzo silną społeczność, prawie wystarczającą na każdy gust, a część z nich ma uznanie głównego nurtu (tj. Twój menedżer pozwoli Ci ich używać w działają).

Podstawy języka są łatwe do nauczenia, ale aby go efektywnie używać, trzeba poświęcić wystarczająco dużo czasu na naukę platformy i narzędzi, a także składni i idiomów. IIRC, McConnell twierdzi, że osiągnięcie prawdziwej biegłości zajmuje około trzech lat.

Biorąc to pod uwagę, trudno jest uzasadnić spędzanie dużej ilości czasu na językach takich jak LISP i Smalltalk, chociaż są one interesujące i być może pouczające.

Stuart Ellis
źródło
0

Jeśli spóźniasz się do dyskusji, głównym problemem z Smalltalk i Lisp jest to, że nie możesz ich uruchomić z CGI lub FastCGI na współdzielonym hostingu.

Niemyte masy nigdy nie będą ich używać, jeśli potrzebują VPS lub serwerów dedykowanych, aby z nich korzystać. IMHO Seaside jest lepsze od prawie wszystkiego innego, ale czy będzie działać na Dreamhost czy Webfaction?

vfclists
źródło
Zastanawiam się, czy to nadal duża bariera teraz, gdy np. Digital Ocean oferuje VPS za 0,007 USD / godz.
Sean DeNigris