Perché usare Ruby invece di Smalltalk? [chiuso]

Ruby sta diventando popolare , in gran parte per l'influenza di Ruby on Rails, ma sembra che stia attualmente lottando per la sua adolescenza. Ci sono molte somiglianze tra Ruby e Smalltalk - maglev ne è una testimonianza. Nonostante abbia una sintassi più insolita, Smalltalk ha tutta (se non di più) la bellezza orientata agli oggetti di Ruby.

Da quello che ho letto, Smalltalk sembra aver battuto Ruby su:

• Maturità (sviluppata negli anni '70)
• Stabilità
• Supporto commerciale
• Controllo del codice sorgente distribuito (comprende la struttura del codice, non solo la differenza di testo)
• Diverse implementazioni della VM
• Supporto multipiattaforma
• Il framework web sul mare come forte alternativa a Rails

Sembra che Ruby stia reinventando la ruota. Quindi, perché gli sviluppatori Ruby non usano SmallTalk? Cosa ha Ruby che Smalltalk non ha?

Per la cronaca: sono un ragazzo di Ruby con poca o nessuna esperienza in Smalltalk, ma comincio a chiedermi perché.

Modifica: penso che il problema della facilità di scripting sia stato risolto da GNU Smalltalk . A quanto ho capito, questo ti consente di scrivere smalltalk in normali vecchi file di testo e non è più necessario essere nell'IDE Smalltalk. Puoi quindi eseguire i tuoi script con:

gst smalltalk_file

Sono più un Pythonista che un utente Ruby, tuttavia le stesse cose valgono per Ruby per le stesse ragioni.

• L'architettura di Smalltalk è in qualche modo isolata, mentre Python e Ruby sono stati costruiti da zero per facilitare l'integrazione. Smalltalk non ha mai realmente ottenuto un corpo di supporto per applicazioni ibride come Python e Ruby, quindi il concetto di "smalltalk come linguaggio di scripting incorporato" non ha mai preso piede.
  
  Per inciso, Java non era la cosa più facile da interfacciare con altre basi di codice (JNI è abbastanza goffo), ma ciò non gli ha impedito di ottenere mindshare. IMO l'argomento di interfacciamento è significativo - la facilità di incorporamento non ha danneggiato Python - ma questo argomento ha solo un peso moderato poiché non tutte le applicazioni richiedono questa capacità. Inoltre, le versioni successive di Smalltalk affrontarono sostanzialmente l'insularità.

• La libreria di classi della maggior parte delle principali implementazioni smalltalk (VisualWorks, VisualAge ecc.) Era ampia e aveva la reputazione di una curva di apprendimento piuttosto ripida. La maggior parte delle funzionalità chiave in Smalltalk è nascosta da qualche parte nella libreria di classi, anche cose di base come stream e raccolte. Il paradigma del linguaggio è anche una sorta di shock culturale per qualcuno che non lo conosce, e la visione frammentaria del programma presentata dal browser è molto diversa da quella a cui la maggior parte delle persone era abituata.
  
  L'effetto complessivo è che Smalltalk ha ottenuto una (in qualche modo meritata) reputazione di difficile apprendimento; ci vuole un bel po 'di tempo e fatica per diventare un programmatore Smalltalk veramente esperto. Ruby e Python sono molto più facili da imparare e per portare i nuovi programmatori al passo con i tempi.

• Storicamente, le implementazioni Smalltalk tradizionali erano piuttosto costose e necessitavano di hardware esotico per funzionare, come si può vedere in questo post di net.lang.st80 del 1983 . Windows 3.1, NT e '95 e OS / 2 furono i primi sistemi operativi di mercato di massa su hardware mainstream in grado di supportare un'implementazione Smalltalk con una discreta integrazione del sistema nativo. In precedenza, l'hardware Mac o workstation erano le piattaforme più economiche in grado di eseguire Smalltalk in modo efficace. Alcune implementazioni (in particolare Digitalk) supportavano abbastanza bene i sistemi operativi per PC e sono riuscite a ottenere una certa trazione.
  
  Tuttavia, OS / 2 non ha mai avuto tanto successo e Windows non ha ottenuto l'accettazione principale fino alla metà degli anni '90. Sfortunatamente questo ha coinciso con l'ascesa del Web come piattaforma e una grande spinta di marketing dietro Java. Java ha conquistato la maggior parte della condivisione mentale nell'ultima parte degli anni '90, rendendo Smalltalk un po 'un gioco da ragazzi.

• Ruby e Python funzionano in una toolchain più convenzionale e non sono strettamente collegati a uno specifico ambiente di sviluppo. Anche se gli IDE Smalltalk che ho usato sono abbastanza carini, uso PythonWin per lo sviluppo di Python in gran parte perché ha un bel editor con evidenziazione della sintassi e non viene messo sotto i piedi.
  
  Tuttavia, Smalltalk è stato progettato per essere utilizzato con un IDE (in effetti, Smalltalk era l'IDE grafico originale) e ha ancora alcune caratteristiche interessanti non replicate da altri sistemi. Testare il codice con l'evidenziazione e "Mostra" è ancora una caratteristica molto bella che non ho mai visto in un IDE Python, anche se non posso parlare per Ruby.

• Smalltalk era arrivato in ritardo alla festa dell'applicazione web. I primi sforzi come VisualWave non hanno mai avuto un grande successo e solo quando Seaside è uscito un framework Web decente ha ottenuto l'accettazione nei circoli Smalltalk. Nel frattempo Java EE ha avuto un ciclo di vita completo di accettazione, a partire dai fan deliranti che lo promuovono e alla fine si annoiano e si spostano su Ruby; -}
  
  Ironia della sorte, Seaside sta iniziando a ottenere un po 'di condivisione mentale tra i cognoscenti, quindi potremmo scoprire che Smalltalk lo cavalca tornare alla popolarità.

Detto questo, Smalltalk è un sistema molto carino una volta che hai capito come guidarlo.

Quando esco di casa la mattina per andare al lavoro, spesso lotto con la decisione di svoltare a sinistra oa destra fuori dal mio percorso (vivo in mezzo a una strada). In ogni caso mi porterà a destinazione. Un modo mi porta all'autostrada che, a seconda del traffico, probabilmente mi porterà in ufficio più velocemente. Riesco a guidare molto veloce per almeno una parte del percorso e ho buone possibilità di vedere una o due belle ragazze mentre vanno al lavoro :-)

L'altro modo mi permette di percorrere una strada molto suggestiva e ventosa con copertura completa degli alberi. Quel percorso è abbastanza piacevole e dei due approcci è sicuramente il più divertente, anche se significa che arriverò in ufficio più tardi di quanto avrei fatto se avessi preso l'autostrada. Ogni modo ha i suoi meriti. Nei giorni in cui ho molta fretta, di solito prendo l'autostrada anche se posso incappare nel traffico e aumentare anche le mie possibilità di incorrere in un incidente (se non sto attento nella fretta). Altri giorni posso scegliere il sentiero boscoso e proseguire, godendomi il paesaggio e rendendomi conto che sono in ritardo. Potrei provare ad accelerare, aumentando le mie possibilità di ottenere un biglietto o causare un incidente io stesso.

Nessuno dei due è migliore dell'altro. Ognuno di loro ha i suoi vantaggi e rischi e ognuno mi porterà al mio obiettivo.

Penso che la tua domanda in qualche modo sfugga al punto. Non dovresti scegliere, dovresti impararli entrambi!

Se sei veramente nella posizione di poter scegliere il framework successivo (VM, infrastruttura), devi decidere cosa usare e puoi porre una domanda specifica con pro e contro dal punto di vista di ciò che la tua applicazione è intesa a fare.

Ho usato smalltalk (love it) e ruby ​​(love it).

A casa o per progetti open source posso usare ogni lingua che mi piace, ma quando faccio il lavoro devo adottarla.

Ho iniziato a usare ruby ​​(al lavoro) perché avevamo bisogno di un linguaggio di scripting che si comportasse più o meno allo stesso modo sotto solaris, linux e windows (98,2000, xp). A quel tempo Ruby era sconosciuta alla media Joe e non esistevano binari. Ma è stato facile vendere a tutte le persone coinvolte.

(Perché non Python? La verità? Ho passato una settimana a cercare un bug che si è verificato quando un terminale ha convertito il mio spazio in una scheda e l'intenzione è stata incasinata).

Così le persone hanno iniziato a programmare sempre di più in ruby ​​perché era così rilassante, divertente e non una nuvola nel cielo.

Paul Graham lo riassume

È vero, certamente, che la maggior parte delle persone non sceglie i linguaggi di programmazione semplicemente in base ai propri meriti. Alla maggior parte dei programmatori viene detto quale linguaggio usare da qualcun altro.

e

Per essere attraente per gli hacker, un linguaggio deve essere buono per scrivere i tipi di programmi che vogliono scrivere. E questo significa, forse sorprendentemente, che deve essere utile per scrivere programmi usa e getta.

E quando eravamo al Lisp, prova a sostituire LISP con Smalltalk

Le biblioteche, la community e lo slancio di Ruby sono buoni

Quindi se LISP è ancora più potente di Ruby, perché non usare LISP? Le obiezioni tipiche alla programmazione in LISP sono:

1. Non ci sono abbastanza biblioteche.
2. Non possiamo assumere programmatori LISP.
3. LISP non è andata da nessuna parte negli ultimi 20 anni.

Queste non sono obiezioni schiaccianti, ma meritano sicuramente di essere prese in considerazione.

e

Ora, data la possibilità di scegliere tra una lingua potente e una lingua popolare, può avere un senso eccellente scegliere quella potente. Ma se la differenza di potere è minore, essere popolare ha tutti i tipi di vantaggi. Nel 2005, pensavo a lungo prima di scegliere LISP invece di Ruby. Probabilmente lo farei solo se avessi bisogno di codice ottimizzato o macro che funzionassero come compilatori a tutti gli effetti.

Direi il contrario: la sintassi Smalltalk è una delle sintassi del linguaggio di programmazione più semplici e potenti.

È vero che le lingue sono molto simili. Il modo superficiale di interpretarlo è chiamare Ruby una cover band Smalltalk. L'interpretazione più ragionevole è che il sistema chiuso di Smalltalk lo ha isolato, mentre la partecipazione di Ruby all'ecologia di Unix e l'abitudine di appropriarsi delle funzionalità di ogni linguaggio sotto il sole gli conferiscono una curva di adozione infinitamente più delicata e un'integrazione senza sforzo con strumenti kickass come Git.

Giles Bowkett

Indovina chi l'ha detto? (la citazione è vicina, forse non esatta): "Ho sempre pensato che Smalltalk avrebbe battuto Java. Solo non sapevo se si sarebbe chiamato 'Ruby' quando lo faceva."

Rullo di tamburi ....

...

La risposta è ... Kent Beck

Stephane Ducasse ha alcuni fantastici libri Smalltalk disponibili qui:

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

quindi, sebbene la comunità Smalltalk non sia così prolifica come le comunità Ruby e Rails, c'è ancora un grande aiuto là fuori.

cosa ha Ruby che Smalltalk non ha?

• Supporto massiccio e attuale dalle principali piattaforme (IronRuby e jRuby) che arricchiscono il set di librerie
• Evangelisti come Dave Thomas che, da anni, girano per il paese predicando il vangelo della loro lingua. Ho visto Dave alle conferenze Java affermare di non conoscere Java e di preferire Ruby.
• Immobili forti e attuali sugli scaffali
• Il creatore di Ruby ha detto di pensare al programmatore: la sintassi di Ruby sembra avere questo fascino Zen. È difficile da definire, ma sembra galvanizzare i fan.
• Presentazioni creative e dinamiche come Giles e questa che guadagnano mindshare

Penso che il tuo punto di vista sia ben accolto. Come disse una volta un amico, Ruby potrebbe essere "vino vecchio in una nuova bottiglia" nei confronti di Smalltalk. Ma a volte la nuova bottiglia è importante. Un vino deve essere al posto giusto al momento giusto.

Mi batte. Ho passato un anno a controllare Ruby ea fare alcuni piccoli progetti per vedere come mi piaceva. Immagino di essere un bigotto di Smalltalk perché ogni volta che mi siedo a lavorare con Ruby sospiro e penso "Preferirei davvero farlo in Smalltalk". Alla fine ho ceduto e sono tornato a Smalltalk. Adesso sono più felice. Più felice è più buono.

Il che ovviamente fa sorgere la domanda: "Perché?". Senza un ordine particolare:

1. Perché l'IDE spazza via qualsiasi altra cosa con cui abbia mai lavorato. Ciò include un sacco di piattaforme da ISPF su mainframe IBM a Microsoft Visual (. *), Include cose come Visual Basic 4-6, Visual C ++ (varie incarnazioni), Turbo Pascal di Borland e discendenti (ad esempio Delphi) e cose su DEC macchine sia in modalità carattere che sotto X-Windows.
2. Perché l'immagine è un bel posto in cui vivere. Posso trovare quello che voglio lì dentro. Se non riesco a capire come fare qualcosa, so che da qualche parte nell'immagine è un esempio di ciò che sto cercando di fare - tutto quello che devo fare è cacciare finché non lo trovo. Ed è auto-documentante: se vuoi vedere i dettagli di come funziona qualcosa, apri un browser sulla classe che ti interessa, guarda il metodo ed è così che funziona. (OK, alla fine troverai qualcosa che chiama primitivo, e quindi è "qui ci sono draghi", ma di solito è comprensibile dal contesto). È possibile fare cose simili in Ruby / C ++ / C, ma non è così facile. Facile è meglio.
3. Il linguaggio è minimale e coerente. Tre tipi di messaggi: unario, binario e parola chiave. Questo descrive anche la priorità di esecuzione: prima i messaggi unari, poi i messaggi binari, poi i messaggi con parole chiave. Usa le parentesi per aiutare le cose. Dang poca sintassi, davvero - è tutto fatto con i messaggi inviati. (OK, l'assegnazione non è un messaggio inviato, è un operatore. Così è l'operatore "return" (^). I blocchi sono racchiusi da coppie di parentesi quadre ([]). Potrebbero esserci uno o due altri bit "magici", ma maledettamente poco ...).
4. Blocchi. Sì, lo so, sono lì in Ruby (e altri), ma dannazione, non puoi letteralmente programmare in Smalltalk senza usarli. Sei costretto a imparare a usarli. A volte essere costretti fa bene.
5. Programmazione orientata agli oggetti senza compromessi o alternative, se è per questo. Non puoi fingere di "fare oggetti" mentre fai ancora la stessa vecchia cosa.
6. Perché allungherà il tuo cervello. I costrutti comodi a cui tutti ci siamo abituati (if-then-else, do-while, for (;;), ecc) non sono più lì, quindi devi imparare qualcosa di nuovo. Ci sono equivalenti a tutto quanto sopra (e altro), ma dovrai imparare a pensare in modo diverso. Diversamente va bene.

D'altra parte potrebbero essere solo le divagazioni di un ragazzo che ha programmato dai tempi in cui i mainframe dominavano la terra, dovevamo camminare per cinque miglia per lavorare attraverso tempeste di neve accecanti, in salita in entrambe le direzioni, ei computer usavano ciambelle per la memoria. Non ho niente contro Ruby / Java / C / C ++ /, sono tutti utili nel contesto, ma dammi Smalltalk o dammi ... beh, forse dovrei imparare Lisp o Scheme o ... :-)

Smalltalk: la gente inoltra ifTrue: [pensa] ifFalse: [non pensa]

Ruby: le persone pensano in avanti a meno che non pensino al contrario

1) Il flusso di controllo dei messaggi simile a RPN di Smalltalk è come Lisp: è normale e interessante ma fa strane le persone.

2) Ruby permette alle persone di scrivere codice usando il modo idiomatico di parlare delle persone - fare bla a meno che non ci sia un motivo per non farlo.

update ha riscritto l'esempio Smalltalk per essere effettivamente un codice più legale ..

Ruby è l'attuale linguaggio dei buzz. È più facile commercializzare software costruito con esso in questo momento rispetto a un linguaggio sviluppato negli anni '70.

Comunità! Ruby e soprattutto Rails hanno una community così grande. Quando si scherzava con Smalltalk sembrava che non ci fossero tanti screen cast, articoli, post di blog, ecc. Scritti su Smalltalk.

Hai risposto alla domanda nella prima riga: "Ruby sta diventando popolare"

• Ci sono molti moduli, progetti interessanti e simili basati su Ruby.
• Se hai problemi a fare qualcosa in Ruby, sarà banale trovare aiuto da qualche parte.
• Ruby è installato su molti computer ora (è incluso di default su OS X, molte distribuzioni Linux e ci sono buoni programmi di installazione per Windows) - Non ho visto Smalltalk installato di default su nessuna macchina che ho usato ..

Direi che una lingua sia superiore o meno a un'altra è irrilevante .. Ad esempio, PHP potrebbe non essere il linguaggio "migliore" in assoluto, ma prenderei comunque in considerazione di usarlo su Ruby on Rails (uno strumento "migliore" per creare siti web) perché è così diffuso.

Fondamentalmente, i pro e i contro specifici di una lingua sono molto meno importanti di tutto ciò che la circonda, vale a dire la comunità.

Ruby (o qualsiasi altra lingua) è più popolare di Smalltalk (o qualsiasi altra lingua) perché viviamo in un universo caotico. Vale a dire:

• Dallo stesso Dave Thomas, "[dopo il] video su 'How to Build a Blog in Ten Minutes' ... Ruby è passato dall'essere un bel linguaggio di nicchia, a essere 'una lingua in cui hai scritto le app Rails'" ( Ruby Conference Keynote 2010 ).
• I primi fornitori di Smalltalk addebitavano prezzi proibitivi
• Smalltalk, poiché è stato inventato (in anticipo sui tempi) 30 anni fa, viene considerato a molti come un vecchio linguaggio "morto" (come FORTRAN)
• le multinazionali considerano Smalltalk un vantaggio competitivo tale da nasconderne l'uso

Sebbene le lingue siano simili nelle funzionalità OO, il vantaggio killer di Smalltalk è l'ambiente live e aperto (la tanto fraintesa "immagine"). Dopo aver controllato questo esempio di programmazione in Smalltalk , il dibattito è finito.

Per me non è tanto un caso di quello che ha Ruby, ma di quello che Ruby non ha. E la cosa che non ha è la necessità di una VM e di un ambiente completo.

Smalltalk è fantastico: è qui che ho imparato i concetti di OO, ma per facilità d'uso scelgo Ruby. Posso scrivere codice Ruby nel mio editor preferito ed eseguirlo dalla riga di comando.

Quindi, per me, questo è quello che scelgo Ruby su Smalltalk.

Penso che tutti coloro che hanno lavorato con Ruby per un po 'riconoscano il suo profondo debito con Smalltalk. Come una di queste persone, cosa mi piace di Ruby su Smalltalk? Penso che da una prospettiva strettamente linguistica, sia lo zucchero. Ruby è deliberatamente un linguaggio molto sintattico-zuccherino, mentre Smalltalk è un linguaggio molto sintattico. Ruby è essenzialmente il modello a oggetti Smalltalk con sintassi Perlish zucchero. Mi piace lo zucchero e trovo che renda la programmazione più divertente.

Puoi trovare un lavoro abbastanza facilmente facendo Ruby. Anche se adoro Smalltalk, è praticamente impossibile entrare nella nicchia di Smalltalk. C'è del lavoro da fare, ma se non sei entrato quando era popolare è praticamente impossibile ora.

Tutti gli altri motivi diventano insignificanti perché devi dedicare molto tempo, concentrato sul lavoro reale per imparare una lingua correttamente. Se non sei ricco in modo indipendente, il modo migliore per farlo è esporlo al lavoro.

Perché le distribuzioni Smalltalk avevano un prezzo in multipli di $ 1000USD mentre Ruby è gratuito.

Ruby sta a Smalltalk come i numeri arabi stanno ai numeri romani. Stessa matematica, sintassi più semplice.

Ho fatto un po 'di Smalltalk - l'IDE è una cosa che ricordo - Ruby ha un buon supporto IDE?

Usa Ruby perché potrebbe avere gambe d'affari, Smalltalk no.

Te lo posso dire per esperienza personale. Usando ancora Smalltalk, lo adoro e ho usato un paio di gusti. Sebbene Smalltalk sia un ottimo linguaggio ed è tutto ciò che hai menzionato, probabilmente non convincerai il CIO / CTO medio a utilizzare Smalltalk su un nuovo progetto. Naturalmente, potresti anche avere difficoltà a convincere un CIO / CTO conservatore a usare Ruby. Alla fine devi stare molto attento se desideri un supporto commerciale duraturo a lungo termine e la capacità di trovare dipendenti fuori strada che possano supportare i tuoi sistemi in futuro. Ad esempio, Smalltalk era davvero una cosa importante nei primi anni '90 e IBM ha investito molto in esso alla fine degli anni '90. Per IBM Smalltalk sarebbe stata la lingua successiva per tutte le applicazioni aziendali. IBM ha messo Smalltalk su tutto, compresi i sistemi mainframe. Java è diventato popolare, ha conquistato il mercato, e Smalltalk è diventato un attore di nicchia. Oltre un anno fa IBM ha scaricato la lingua (il loro termine è tramonto). Inoltre, dai un'occhiata alla storia. ParkPlace e Digitalk, dove i primi grandi attori commerciali nell'arena Smalltalk, si sono fusi e poi hanno cessato l'attività.

Amo sia Smalltalk che Ruby, ma ho scoperto che Ruby è più applicabile a ciò che faccio quotidianamente ed è più vicino al mio cuore (praticamente parlando). Cosa offre Ruby che Smalltalk non offre?

• Scripting basato su testo
• Requisiti di implementazione bassi (viene eseguito in più luoghi)
• Più facile da imparare e giustificare (Perl e Python programmatori avranno alcuna difficoltà
• Più facile spostare i programmi: file di testo!
• Si interfaccia bene con l'ambiente nativo
• Ovunque venga eseguito Java, jRuby viene eseguito ...
• Comunità più grande e molto più attiva

Alcuni hanno menzionato gst (GNU Smalltalk); i problemi continuano ancora.

Usa tutto ciò che ti rende più potente e veloce per vincere la tua sfida.

Per noi , un po 'in casa, abbiamo costruito in cima al mare è davvero il nostro superpotere.

Amo la comunità RoR, ha l'atteggiamento giusto. È molto molto prezioso. Ma allo stesso tempo, tecnologicamente, il mare ti rende più forte contro problemi più complicati.

Puoi creare fantastiche app web sul mare utilizzando materiale open source.

dabbledb era un sartup basato sul mare e, ehi! Avi lo ha venduto a Twitter nel giugno di quest'anno!

Dico che non devi aspettare che gli altri approvino la tua iniziativa.

Provaci. Fallo fatto. Mostraci che funziona.

Non sei solo. Siamo sulla stessa barca.

Prospettiva interessante di Robert Martin (da RailsConf 2009): "What Killed Smalltalk Could Kill Ruby, Too"

Penso che parte del problema sia l'ambiente di sviluppo è il runtime. Questo dà molta potenza, ma presenta anche una curva di apprendimento più ampia.

Ecco un tutorial Hello World.

Questo è molto diverso dalle altre lingue in cui ho solo bisogno di sapere come aprire un editor di testo e copiare e incollare testo, premere Salva ed eseguire un compilatore. DEVO sapere come usare l'ambiente. Quel tutorial non mi mostra nemmeno come creare un programma di base (che è probabilmente più un difetto di quel tutorial) che posso eseguire.

C'è sicuramente un costo maggiore per far funzionare le cose rispetto alla maggior parte delle altre lingue.

La maggior parte delle lingue ha un codice accattivante che possono mostrare. Non l'ho visto con Smalltalk. Penso anche che ci sia qualche stigma su Smalltalk perché esiste da così tanto tempo ed è ancora relativamente oscuro.

Penso che la differenza PIÙ GRANDE sia che Ruby è molto più simile a perl in termini di UTILIZZO. Smalltalk non ha mai preso piede nei linguaggi di "scripting".

La VM è davvero fantastica e spero che ruby ​​abbia qualcosa di simile in modo che possiamo trattare tutto sul nostro sistema operativo che è scritto in ruby ​​come oggetto nello spazio di memoria, tuttavia fino ad allora mi piace semplicemente la sintassi breve e concisa di Ruby, la capacità di scrivi un minuscolo script e riutilizzalo in seguito. Ruby ha tutti i vantaggi di perl e l'OOP è molto più simile a smalltalk rispetto all'hack OOP di perl.

Vorrei andare oltre la risposta di Jonke e dire che ora ci sono un gran numero di lingue che hanno una comunità molto forte, quasi sufficiente per tutti i gusti, e un sottoinsieme di queste ha un riconoscimento tradizionale (cioè il tuo manager ti permetterà di usarle a funziona pure).

È facile apprendere le basi di una lingua, ma per usarla effettivamente in modo efficace è necessario investire abbastanza tempo per apprendere la piattaforma e gli strumenti, nonché la sintassi e gli idiomi. IIRC, McConnell afferma che ci vogliono circa tre anni per diventare veramente competenti.

Date queste cose, è difficile giustificare il fatto di dedicare molto tempo a lingue come LISP e Smalltalk, sebbene siano interessanti e forse educative da guardare.

Essendo un ritardatario nella discussione, il problema principale con Smalltalk e Lisp è che non puoi eseguirli con CGI o FastCGI su hosting condiviso.

Le masse non lavate non li useranno mai se hanno bisogno di VPS o server dedicati per usarli. IMHO Seaside è superiore a quasi tutto il resto, ma funzionerà su Dreamhost o Webfaction?