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

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

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ć.

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.

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.

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

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

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

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.

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.

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 ... :-)

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.

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

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.

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ść.

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.

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.

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.

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.

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

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

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

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.

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ą.

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.

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

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.

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.

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.

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?