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:
- Dojrzałość (opracowana w latach siedemdziesiątych)
- Stabilność
- Wsparcie komercyjne
- Rozproszona kontrola źródła (rozumie strukturę kodu, a nie tylko różnicowanie tekstu)
- Kilka implementacji maszyny wirtualnej
- Obsługa wielu platform
- Ramy nadmorski internetowej jako silną alternatywę dla Rails
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
źródło
Odpowiedzi:
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ć.
źródło
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.
źródło
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
i
A kiedy byłeś na ziemi Lispa, spróbuj zamienić LISP na smalltalk
i
źródło
Powiedziałbym odwrotnie: składnia Smalltalk jest jedną z najprostszych i najmocniejszych składni języka programowania.
źródło
Giles Bowkett
źródło
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
źródło
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.
źródło
co ma Ruby, czego nie ma Smalltalk?
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.
źródło
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:
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 ... :-)
źródło
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.
źródło
Ruby to aktualny język buzzów. Łatwiej jest teraz sprzedawać oprogramowanie zbudowane za jego pomocą niż język opracowany w latach 70.
źródło
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.
źródło
Odpowiedziałeś na pytanie w swojej pierwszej linii: „Ruby staje się popularny”
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ść.
źródło
Ruby (lub jakikolwiek inny język) jest bardziej popularny niż Smalltalk (lub jakikolwiek inny język), ponieważ żyjemy w chaotycznym wszechświecie. Dowcip:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
Ponieważ dystrybucje Smalltalk zostały wycenione jako wielokrotności 1000 USD, podczas gdy Ruby jest bezpłatny.
źródło
Ruby to Smalltalk jak cyfry arabskie do rzymskich. Ta sama matematyka, łatwiejsza składnia.
źródło
Zrobiłem trochę Smalltalk - IDE to jedna rzecz, którą pamiętam - czy Ruby ma dobre wsparcie dla IDE?
źródło
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.
źródło
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?
Niektórzy wspominali o gst (GNU Smalltalk); problemy nadal istnieją.
źródło
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.
źródło
Ciekawa perspektywa z perspektywy Roberta Martina (z RailsConf 2009): „Co zabiło Smalltalk może zabić Rubiego, też”
źródło
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.
źródło
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.
źródło
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.
źródło
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?
źródło