Or was Smalltalk software only ever sold to sophisticated users who were programmers too?
No. È il contrario: Smalltalk è stato progettato in modo che ogni utente possa essere un programmatore, senza che che richiede sia sofisticato. In effetti, Smalltalk è stato progettato per bambini .
L'idea di base è che un utente legga un manuale sulla lunghezza di un libro di testo universitario di livello medio per poter utilizzare macchinari sofisticati. Dimmi, sei un falegname e comprati una macchina CNC, non ti aspetteresti di poterlo usare subito, ma non ti aspetteresti nemmeno di aver bisogno di anni per imparare a usarlo. Probabilmente ti aspetteresti di leggere da 10000 a 100000 righe di manuali e di imparare un paio di giorni per un paio di settimane.
Per un sistema software, il manuale definitivo è il codice sorgente. Quindi, per essere utilizzabile, il sistema software non dovrebbe contenere più di 100000 righe di codice, in modo che l'utente possa leggerle tutte. (E dovrebbe essere scritto in un modo e in un linguaggio del genere che lei possa capirlo.) Questo è l'obiettivo di Smalltalk: il sistema originale Smalltalk era di circa 60000 righe di codice per tutto , il "SO ", i driver hardware, la VM, il compilatore, l'interprete, l'IDE, il debugger, l'editor, una suite per ufficio, un sistema di gestione documentale distribuito, ecc. Negli anni '70 era il meglio che potevano fare oggi 40 anni dopo, abbiamo a disposizione linguaggi molto migliori, e il sistema di sostituzione e le lingue in cui al momento sta lavorando il team di Alan Kay, dovrebbero avere meno di 20000 linee per lo stesso set di funzionalità. (Confrontalo ad esempio con Windows, che ha 50 milioni linee.)
Questa era l'idea. Quanto bene ha funzionato quell'idea, beh ... giudica tu stesso: -)
I moderni Smalltalks cercano di fare una distinzione tra sviluppo e distribuzione. Fondamentalmente, si definisce un oggetto radice dell'applicazione, il sistema traccia le connessioni tra tutti gli oggetti nel sistema e copia solo quegli oggetti che sono collegati direttamente o indirettamente all'oggetto dell'applicazione radice, lasciandovi un'immagine semplificata che contiene solo l'applicazione e le librerie e i framework necessari.
In genere non modifichi direttamente il sistema in esecuzione, ma usa un qualche tipo di sistema di controllo della versione (ad esempio Monticello) che memorizza le tue modifiche come una serie di modifiche semantiche al sistema e quindi può essere riprodotto su un sistema diverso. C'è anche una ricerca sui sistemi di moduli e sui sistemi di gestione dei pacchetti, e la maggior parte dei Smalltalks moderni ha almeno uno dei due.
Quindi, il modo in cui i sistemi Smalltalk sono implementati oggi è che c'è una minima immagine "pulita", e si applicano i changeset CVS o si installano pacchetti o moduli di collegamento sopra a quello, che produce un immagine che è specializzata solo per quella applicazione. Se si vuole fare sviluppo, si inizia con un'immagine di sviluppo che include l'editor, il compilatore, l'IDE, ecc. E si applicano le stesse modifiche.
I linguaggi successivi a Smalltalk (ad es. Self, Newspeak) spesso includevano un formato di serializzazione testuale per il codice (Smalltalk stesso non ha sintassi per classi o metodi, perché sono creati a livello di programmazione dall'IDE (ad esempio la creazione di una classe è in realtà solo chiamando il metodo subclass su qualche classe che restituirà una classe che è una sottoclasse della classe su cui è stato chiamato il metodo), ha solo sintassi per espressioni e istruzioni.), che potrebbe essere usata per "file in" classi e metodi nel sistema, e le moderne Smalltalks hanno anche questa capacità.