Ho guardato alcuni discorsi di MountainWest RubyConf 2014 e ho notato un tema interessante. Molti ambienti di programmazione dinamici ai vecchi tempi erano solitamente delle immagini VM autonome, ad es. SmallTalk, GemStone / S.
Si potrebbe controllare, modificare e spedire all'ingrosso queste immagini e farlo funzionare con pochissimo sforzo. Avanzamento veloce fino ad ora e sto ancora utilizzando Crea file per configurare e installare i binari. Che cosa è successo?
Si scopre che fornire una VM che modula tutte le comunicazioni verso il sistema operativo è davvero difficile. Nel migliore dei casi, ti ritroverai con un'interfaccia con le ginocchia che migliora man mano che le persone si lamentano di non essere in grado di fare certe cose.
Ricorda che un sacco di questi linguaggi dinamici si sono evoluti come colla, nessuno ha mai pensato che Perl avrebbe dovuto girare su Windows quando Larry Wall lo ha creato per la prima volta. Era molto più importante per lui essere in grado di interagire in modo apparentemente con Unix poiché era quello che tutti volevano fare con esso.
Anche le cose in smalltalk VM land non sono tutte hunkydory, è quasi impossibile fare il genere di cose a cui sei abituato ad essere 5 righe di perl poiché smalltalk gioca terribilmente con il mondo esterno.
Al massimo oggigiorno, se vuoi macchine virtuali multipiattaforma, devi investire un po 'di tempo in Groovy o JRuby che funzionano su una VM che si è dolorosamente evoluta per essere un'interfaccia utile crossplatform.
Il numero di persone che avevano effettivamente utilizzato uno di questi ambienti di produttività estremi era piuttosto basso. È iniziato nel mondo delle workstation, penso a $ 100.000 / sviluppatore. La maggior parte degli sviluppatori non poteva permettersi la licenza e l'hardware necessari. Poi è scoppiata la guerra dei prezzi in cui Microsoft ha cercato di uccidere Borland e Sun ha dato via Java. Non abbastanza sviluppatori avevano effettivamente usato smalltalk abbastanza per fermare la gestione che faceva errori a lungo termine. Quindi ora i vms tornano dal lato devope, con docker
Sì, ce n'erano parecchi. Mi riferisco a un singolo pacchetto che contiene codice scritto per una VM, la VM stessa e un set di file di dati, spesso utilizzando un formato di database proprietario. Se scrivi e salvi il codice, viene salvato anche nell'ambiente.
Il vantaggio che è un singolo oggetto da spedire, e funziona senza installazione poiché non ha dipendenze (eccetto il SO di destinazione). Ricordo vari gusti di Smalltalk, Logo, Mumps / MIIS, Pick / Information / Ultimate.
Condividono gran parte della stessa storia con 4GL e insieme costituiscono qualcosa del [walled garden] ( collegamento di un programmatore ). Penso che quello che è successo, sorprendentemente, fosse Internet.
Gli sviluppatori desideravano da tempo un database migliore, IDE migliori, librerie migliori, ecc. Prima di Internet erano bloccati, ma improvvisamente potevano trovare tutti i tipi di strumenti migliori ei venditori di pacchetti non potevano muoversi abbastanza velocemente da portarli all'interno del giardino murato o competere direttamente. Questi pacchetti ti hanno dato tutto ciò di cui avevi bisogno finché non avevi bisogno di molto, ma Internet ti dava una scelta infinita, ad un prezzo.
Personalmente penso che il giardino recintato abbia molto da offrire, soprattutto per i programmatori con competenze limitate. Tuttavia, non puoi più ricavarne guadagni e le persone intelligenti che creano strumenti non vedono il punto, quindi non credo che vedremo un ritorno.
Ho usato questo approccio parecchio per copiare e condividere gli ambienti di sviluppo.
Funziona abbastanza bene - tranne l'ossessione di Linux per "cercare di essere carina come Apple" significa che le VM vengono visualizzate e il desktop viene regolarmente eliminato nel cestino se si autorizzano gli aggiornamenti automatici.
L'alternativa alla rotazione degli aggiornamenti consente di avere una ragionevole possibilità che il desktop funzioni quando si attiva la VM, ma se si richiedono le ultime librerie per lo sviluppo, è doloroso aggiornarle manualmente.
Probabilmente a causa delle prestazioni. Ho usato un'immagine VM da sviluppare con - sulla piattaforma Microsoft sono stato esposto a un prodotto legacy che ha funzionato su XP ma non su Windows 7, quindi mi è stata data una copia di una VM da eseguire sulla mia workstation che conteneva tutti gli strumenti di sviluppo impostati andare. Le prestazioni non erano quelle che avrei voluto.
Penso che molto di ciò sia dovuto alle prestazioni della GUI, ma questa è la parte più importante per uno sviluppatore. In passato, con gli ambienti mainframe in parte la macchina virtuale è stata integrata meglio, ma anche le interfacce grafiche erano meno intensive.
Oggi tendiamo ad avere ambienti di sviluppo che richiedono tutta la potenza disponibile, ma c'è un passaggio alla distribuzione delle applicazioni in una singola immagine - abbiamo visto VM per l'implementazione, ma queste erano tendenzialmente troppo pesanti per un singola applicazione (ovvero si doveva avere un sistema operativo completo in esecuzione solo per ospitare una piccola applicazione server), quindi ci stiamo muovendo verso VM a livello di applicazione sotto forma di framework come Docker o Contenitori di Windows .
Leggi altre domande sui tag programming-languages deployment virtual-machine ruby smalltalk