Il nostro viaggio all’interno dell’ecosistema DEV di Microsoft arriva agli anni ’90, periodo caratterizzato dall’esplosione di Windows e dal “mondo a finestre”. L’ottica MS cambia con una visione a più lungo respiro e arrivano i primi e veri IDE (Integrated Development Environment), ovvero i primi ambienti integrati di sviluppo.
Ambienti di sviluppo MS nei primi anni ‘90
Si inaugura così l’era “VISUAL” e il portabandiera non poteva non essere che Visual Basic. Il “papà” di VB è Alan Cooper, che, il 6 marzo del 1988, si presenta da Bill Gates per mostrargli un prototipo di shell drag-and-drop chiamata Tripod (scritto interamente in C), in grado di trascinare dei widget su un’area applicativa e gestirli attraverso un modesto linguaggio di sviluppo. Gates ne intuisce subito le potenzialità e Microsoft acquista il concept, rinominandolo in Ruby.
Il team di “Ruby” al completo nella primavera del 1989: (da sinistra) Frank Raab, Mike Geary, Alan Cooper, Gary Kratkin e Mark Merker
Cooper racconta così l’incontro con Gates:
Because I was in the business of inventing programs and selling them to publishers, I began to show Tripod around the industry. Many companies in Silicon Valley saw it, but few expressed serious interest. However, in March of 1988, I showed this prototype to Bill Gates, and he immediately saw its potential. He declared that it was “cool” and that it would have significant impact across their entire product line. Bill said he wanted to buy it, and over the next few months we hammered out a deal. Because the name Tripod had had so much exposure, we promptly changed it to “Ruby.” Meanwhile, I put together a team of skilled programmers to build a release-quality program.
[Poiché ero nel business di chi creava programmi per poi cercare una software house che lo vendesse, cominciai a far visionare Tripod alle industrie di settore. Molte compagnie della Silicon Valley videro il sistema, ma poche espressero un reale interesse. Nel marzo del 1988 mostrai il prototipo a Bill Gates che immediatamente ne vide le potenzialità. Da subito dichiarò che Tripod era “cool” e che poteva avere un impatto significativo su tutta la loro linea di prodotti. Bill disse di volerlo acquistare, e nei mesi successivi raggiungemmo un accordo. Poiché il nome Tripod era stato molto esposto, rinominammo il sistema in “Ruby”. Nel frattempo misi insieme un team esperto per realizzare una build di qualità del programma]
Tre anni dopo (20 Marzo 1991), dal matrimonio tra Quick Basic (che sostituì l’iniziale linguaggio di scripting) e Ruby, nasce Thunder, rilasciato ufficialmente come Visual Basic 1.0 a Maggio del 1991, durante il Comdex/Windows World Trade Show in Atlanta, Georgia. Si tratta di un linguaggio di terza generazione di tipo event-driven, dotato di un ambiente che permette lo sviluppo rapido e semplificato di applicazioni Windows, con tanto di accesso al DB point-and-click, sulla falsa riga di PowerSoft Powerbuilder.
Una curiosità che ricorda le origini di VB: i controlli creati dal runtime di VB hanno avuto per molto tempo il nome interno che iniziava con il prefisso Thunder (ad esempio i bottoni, internamente, erano conosciuti come ThunderCommandButton).
Visual Basic 1.0
Nella seconda metà del 1992 (settembre) viene rilasciato Visual Basic per DOS. Al di la del nome, questa versione non ha nulla a che fare con quella Windows, essendo più che altro un’evoluzione del QuickBasic. Inoltre il linguaggio stesso è incompatibile con quello di VB per Windows.
Visual Basic per DOS
A Visual Basic bastano un paio d’anni per raggiungere la prima versione matura di VB, ovvero la 3.0, rilasciata a giugno del 1993. Passando per la versione 2, VB si arricchisce di alcuni tool prodotti da terzi (come lo Sheridan Software’s VBAssist Debuts), nonché della prima implementazione di ODBC, delle FORM MDI e diverse migliorie al linguaggio in se. Sicuramente, però, il grande valore aggiunto è l’integrazione del motore JET 1.1 di Access e la capacità di supportare pienamente OLE (Object Linking and Embedding) 2.0.
L’IDE di VB 3.0
Nella scala temporale, il secondo ambiente con cui veniamo a contatto è FoxPro (1993, ancora non “visual”). Originariamente pubblicato dalla Fox Software (1984) per DOS, Windows, Macintosh e UNIX, entra nella sfera Microsoft nel 1992, quando il big di Redmond decide di acquistare l’intera società.
Si tratta di un linguaggio di programmazione procedurale orientato alla gestione dei dati relazionali e basato su un potente engine DBMS (Database Management System) senza funzionalità transazionali e quindi non adatto ad ambienti Enterprise.
Microsoft ne decide l’acquisizione per entrare in modo deciso nel mondo xBase, considerando il proprio “Ciruss” (al secolo: Access) una soluzione da integrare nella suite Office, ideale per lo sviluppo di applicazioni DESK, sulla falsa riga di Borland Paradox, ma non sufficiente per il mondo professional. In particolare l’acquisto di Fox porta a Redmond la tecnologia “Rushmore”, un sistema di ottimizzazione delle interrogazioni SQL di cui beneficerà anche lo stesso motore Jet di Access. A differenza dei pasticci combinati da Borland nella gestione parallela di Paradox e dBase (divenuto di Borland in seguito all’acquisizione di Ashton-Tate), Microsoft riesce a gestire brillantemente i due sistemi, anche se le attività di marketing e promozione sono tutte concentrate su Access.
FoxPro diventa “Microsoft”
A febbraio del 1993 arriva anche Visual C++, successore della serie dei compilatori C/C++, QuickC. Inizialmente rilasciato solo nell’edizione a 16bit, viene subito affiancato da quella a 32bit,e riunito in un unico package “16/32 bit”, anche se le versioni sono differenti: 1.5 (rilasciata a dicembre del 1993) per quella a 16bit, 1.0 per quella a 32bit. C’è da precisare che la prima versione a 32bit non ha il supporto a OLE 2.0 e ODBC, cosa che favorisce, ancora per un po’, l’utilizzo di quella a 16bit.
Visual C++ 1.5
La versione 1.5 è l’ultima release a 16-bit, anche se non mancheranno dei fix update che porteranno la 1.5 alla 1.52c, incluse in Visual C++ 2.x, disponibile solo nella versione a 32bit e dotato delle MFC 3.0.
Si chiude qui il terzo appuntamento con l’evoluzione degli ambienti di sviluppo targati Microsoft. Nel prossimo post affronteremo la progressiva convergenza degli IDE e il tramonto delle soluzioni pre dotNet.
Il pefisso Thunder si trova ancora oggi nell’ormai obsoleto Visual Basic 6. E’ usato nel nome delle calssi della finestra nascosta che crea il runtime di VB.
Due osservazioni. Relativamente a VB 3 viene detto che include il motore JIT 1.1, forse si intendeva il motore JET per Access. Riguardo al DB di FoxPro viene detto che non essendo transaziale non è un DB relazionale (RDBMS), ma non è corretto, sono due corse diverse, un transazione è la capacità di validare o annulare più operazioni in maniera atomica (ho semplificato molto), mentre le relazioni sono le tabelle stesse e il modo di gestirle (poi c’è chi intende per relazioni i collegamenti e vincoli fra i dati delle tabelle, su questa sfumatura ci sarà eterna discussione…).
@Cla,
vero entrambe le tue osservazioni… il motore è JET (JIT è un compilatore Just in time :-)), mentre la frase corretta è “non adatto ad ambiente Enterprise”.
Grazie
articolo come sempre interessantissimo come sempre ma qualche piccolo errore grammaticale causato da una traduzione frettolosa.
cominciaI a faR visionare
espressERo un reale
marzo del 1988 (non 1998)
@luk… sorry… ho inserito la traduzione all’ultimo secondo per accogliere la richiesta di un nostro lettore… ma qualcosa è sfuggito :-)
Bell’articolo.
Mi sembra giusto ricordare in questa sezione di quanto questi IDE abbiano giovato del “nome” e delle possibilità di marketing di microsoft, rispetto agli IDE concorrenti.
Per esempio, il primo VB “usabile” è stato il 3.0, dopo circa 2 anni la borland sfornava Delphi 1.0 nettamente superiore su tutto (ne possiamo parlare se interessa a qualcuno), ma che non si è mai neanche avvicinato ai numeri e diffusione di VB. Situazione che non è cambiata negli anni successivi, quando la superiorità di delphi/c++builder su vb si amplificava sempre più, ma la gente continuava ad imparare e usare vb – rilasciando alla fine il più delle volte prodotti scadenti.
Addirittura in un istituto tecnico della mia zona nelle lezioni di sistemi insegnavano il vb6 (tra l’altro con un libro scritto da uno che il vb6 secondo me non l’aveva neanche mai avviato)… sì, sì, proprio adatto come “linguaggio didattico”!!! ROTFL!
I linguaggi della serie Visual di MS hanno mantenuto la buona qualità e l’uniformità dell’IDE già portata avanti con quelli delle versioni per DOS della serie Quick. Almeno, secondo me, questo aspetto ha costituito un secondo momento d’oro per MS insieme all’innegabile vantaggio della maggiore visibilità commerciale.
Comunque i prodotti erano sostanzialmente buoni e dal punto di vista della praticità dell’interfaccia bisogna considerare anche una questione di abitudine. Io non mi sono mai trovato altrettanto bene con i Builder Delphi e sinceramente, nemmeno benissimo con i vari Turbo… ma si tratta di dettagli che ritengo non sufficienti per denigrare completamente un prodotto fino al punto di farne un’accusa.
@the_m
che il VB possa essere stato usato a scopo didattico non capisco perché debba sorprendere. In ambito lavorativo ricordo che ho avuto modo di sfruttare con estrema utilità e con enorme vantaggio la presenza di VBA e soprattutto, di poterlo fare anche non solo con prodotti MS.
Oggi le cose sono anche un po’ cambiate, ma intendere VB come una sorta di “scripting molto evoluto” era una prerogativa nota e perlomeno invidiabile. Tutto dipende dall’uso e dalle necessità specifiche (ma questo argomento è una questione ben nota e risolta per ognuno che abbia un po’ di esperienza di programmazione e quindi che anche tu saprai).
buon RC con http://www.jurassicnews.com
Ciao, in VB 3.0 è necessario installare un layer di compatibilità per farlo interagire con Access 2.0.
L’ho installato giusto l’altro giorno su un pc con Windows 7 x86 (!)
@Giovanni
il VB è pessimo come linguaggio didattico per tanti motivi, tra cui:
– consente (anzi, utilizza per default) tipi di dati Variant tolgono il compito “naturale” dello sviluppatore di pensare al tipo di dato che dovrà contenere una variabile
– consente (anzi, utilizza per default se manca “Option Explicit”) una dichiarazione automatica delle variabili, cosa che in nessun altro linguaggio è prevista e che è pessima, non dovrebbe esistere neanche in vb
– è un mix tra un linguaggio procedurale, a eventi e uno object-oriented “monco” (mancano tanti aspetti nell’ereditarietà, polimorfismo, ecc.)
– è molto ad alto livello, quindi “nasconde” la maggior parte del lavoro che il sistema svolge ma di cui si prende carico il runtime di vb
– ha i tipi di dati “sfalsati” per motivi di retro-compatiblità, es. non troverai alcun altro compilatore a 32 bit che compila il tipo di dati “Integer” come intero a 16 bit come fa VB
ecc.
Per quanto riguarda VBA, che è un’altra cosa rispetto a VB, mi chiedo come tu possa averlo usato al di fuori di prodotti MS visto che è utilizzato e utilizzabile solo in microsoft office.
@the_m:
Ottimo, si fa lo stesso in Python da quando è nato.
Ottimo, Python permette esclusivamente la dichiarazione automatica della variabili.
Le mancanze sono state colmate da tempo con le versioni .NET. Per il resto il fatto di permettere l’uso di paradigmi diversi non depone pregiudizialmente a sfavore di un linguaggio.
Sempre Python consente di modellare il codice col paradigma procedurale/strutturato, a oggetti, funzionale, in parte ad aspetti, consente la modularizzazione del codice, e infine mette a disposizione la metaprogrammazione.
Eccellente, come in Python (che consente di astrarre ancora più, comunque).
Prima che ti affretti a replicare, Python ha riscosso enormi consenti e difficilmente troverai un linguaggio migliore per imparare a programmare (un’etichetta che è stata coniata per lui è quella di “pseudocodice eseguibile”, che parla già da sé).
Il MIT (quindi non l’ultimo arrivato) dopo decenni di Scheme (un dialetto del LISP) negli ultimi anni l’ha sostituito con Python nei corsi d’introduzione alla programmazione.
Lo stesso capita con altri linguaggi, come il C, ad esempio: la dimensione esatta di int non è definita. Potrebbe essere a 32 o 64 bit, ma… anche a 16 bit, a seconda del compilatore.
Comunque io mi sono trovato meglio coi prodotti Borland anziché con quelli Microsoft, anche se negli ultimi anni le suite Microsoft (VisualStudio *) sono diventate di ottima fattura.
Mica vero, VBA c’è anche in CorelDraw.
Infatti c’erano anche altri prodotti che avevano adottato VB praicamente come scripting… molto molto comodo. Inoltre la forte diffusione di VB (e prima anche di QB) hanno spinto ad implementare molte regole sintattiche e strutture di altri linguaggi.
@the_m
La questione da te sollevata riguardo alla bontà di un linguaggio per finalità didattiche è una cosa ormai sorpassata e che anch’io ricordo benissimo come fosse un’accesa diatriba dopo la metà degli anni ottanta dopo l’ampia diffusione del Pascal (e dell’economico Turbo di Borland) specialmente in ambienti informatici.
Già allora però questo aspetto di “qualità legata ai vincoli formali” piuttosto che ad una chiara appartenenza a certe categorie teoriche (vedi la rigida strutturazione del Pascal, appunto) venivano poco considerate da chi doveva lavorare, a fronte di una reale efficienza del linguaggio per gli scopi a che si vogliono raggiungere.
Personalmente, dal puno di vista didattico, ritengo ben più importante rispettare delle regole generali di chiarezza, scrivere del codice che faciliti il lavoro di gruppo e, attenzione, per esperienza questo non significa necessariamente inserire tanti commenti che a volte possono essere in eccesso (non si scrive un romanzo ma un programma): bisogna essere “eleganti”… come in matematica!
@Cesare
a prescindere dai gusti personali borland-Vs-MS, mi pare che tu convenga sulla mia opinione. Certo anch’io apprezzo moltissimo l’estrema libertà che Phyton concede… devo dire che negli ultimi anni (specie in internet con javascript e php) ci si può scontrare con delle porcherie di codice allucinanti: ma questo non riguarda certo la libertà formali dei linguaggi, ma la testa di chi scrive!
ciao ciao
Sì, sono d’accordo con quanto scrivi, ma aggiungo che certi linguaggi possono comunque contribuire alla scrittura di codice poco leggibile / manutenibile.
Infatti non è un caso che, in maniera diametralmente opposta a Python, per Perl sia stato coniato il termine “executable line noise”, oppure venga definito come linguaggio “write-only”.
Da incorniciare la parte relativa ai commenti (soprattutto) e alla “eleganza”.
Mi spiace cesare di mauro ma quando cerchi di difendere il vb e paragonarlo al pyton mi perdi tutti i punti di stima che ti avevo accreditato..
Molto meglio usare il pascal come linguaggio didattico almeno ti apre la mente e ti insegna a diventare sviluppatore.
Non scimmia programmatore!
Non sai la fatica che faccio a togliere dalla mente le brutte abitudini del vb. e c’è chi pure lo difende.
mah..
A me spiace che tu abbia letto questo.
Se guardi bene il mio commento, erano state fatte delle critiche a VB a causa di precisi punti; punti sui quali, da pythonista, mi sono sentito direttamente coinvolto, perché hanno fatto la fortuna di questo linguaggio e, manco a dirlo, di chi lo apprezza.
Ma da qui a paragonare VB a Python il passo mi sembra più lungo della gamba, mi pare. D’altra parte se oggi sviluppo in Python e non in VB (col quale ho lavorato diversi anni, peraltro), un motivo ci sarà.
Con ciò, e non m’interessa se subirò delle critiche, voglio comunque spezzare una lancia a favore di VB, perché non è certo un linguaggio senza pregi. Se si è diffuso parecchio è perché quella B non è certo messa lì a caso: Beginner All-Purpose Symbolic Instruction Code.
Il BASIC ha facilitato molto l’avvio alla programmazione, pur con tutti i limiti del caso (penso sempre che tanta gente è passa troppo velocemente dalla zappa alla tastiera).
D’altra parte, se son rose fioriranno: si diventa buoni programmatori anche partendo dal BASIC, che fu il mio primo linguaggio (sebbene seguito a ruota dal linguaggio macchina; MOS 6510).
Difatti sono poi approdato al (Turbo) Pascal, Modula-2, infine a Delphi (con una puntatina a FreePascal), perché ho preferito i linguaggi di casa Wirth o fortemente ispirati, che tuttora gradisco se dovessi essere costretto a sceglierne uno staticamente tipizzato (lavoro in C#, ma bramo Delphi).
Negli ultimi anni sono approdato a Python che è completamente diverso (anche da tanti altri linguaggi), col quale riesco a esprimere meglio le capacità di problem-solving… divertendomi pure. 8-)
Non voglio certo istigare la polemica ma mi limito a constatare che certi “luoghi comuni” sono davvero difficili da estirpare e probabilmente sempre alimentati! Un buon sviluppatore, secondo me, si capisce dalla testa indipendentemente dal linguaggio… il linguaggio l limite, lo sceglie in base a ciò che deve fare.
Parlo così perché penso di avere un’esperienza simile a quella di @Cesare, forse addirittura maturata qualche anno prima, ma originariamente quasi da autodidatta su “macchinine” che non permettevano tante possibilità di scelta in quanto a linguaggi da utilizzare: quando (spessissimo) qualche dialetto del basic non arrivava a fare il suo dovere non c’era alternativa che usare un assembler (se non proprio “assemblare” direttamente in memoria!).
Come dicevo prima, negli ambienti accademici (ai miei tempi) avveniva l’esaltazione del Pascal per ogni suo minimo aspetto (oggi mi pare che promuovano ancora Java, ma non ne sono sicuro). Ovviamente, un po’ per il fatto che ci lavoravo (sul serio) al di fuori dell’università e per contrarietà ai tanti saputelli con “la puzza sotto il naso” preferivo di gran lunga il C, prima, il C++ poi.
Per lavoro mi è capitato di realizzare da solo o collaborare con altri a delle ottime applicazioni (alcune ancora in commercio) sia in QuickBasic sia in VB e soprattutto, qualità spesso dimenticata, messe a punto in tempi estremamente brevi.
Da diversi anni, in cui la necessità di programmare non ha più finalità professionali, mi diverto un sacco con Phyton, ma anche con php sul web con mysql e qualche capatina nel passato con C su linux, su Amiga o sui vecchi PC… e assembly su Z80, 6502, 68000…
@Cesare
Ed è una cosa sbagliata ed inutile quando uno sta imparando a programmare a scuola
Ed è una cosa sbagliata ed inutile quando uno sta imparando a programmare a scuola.
Non conosco Python, ma è una bella porcheria se dichiara automaticamente le variabili quando le usi.. Quindi se uso una variabile CesareDiMuro dimenticando una lettera, a lui va bene, non segnala nulla e va avanti inizializzandola a zero (come fa VB senza option explicit)?
Stento a crederci… in quel modo è impossibile gestire programmi di più di qualche decina di righe senza infilarci dentro errori molto difficili da scovare.
Ma chi sta parlando di .NET o di Python? -.-
Eccellente quando lavorando e producendo, meno eccellente quando stai imparando a programmare a scuola.
Si vede che non hai mai insegnato :)
(ok, io solo un semestre a un corso post-diploma e ad un paio di studentesse a cui non potevo dire di no :P ma qualche esperienza l’ho avuta)
Comportamento del VB (32-bit) alquanto strano, visto che come ben sai le operazioni internamente vengono eseguite tra registri a 32 bit.
Qualsiasi altro compilatore che abbia mai usato in C, C++, Java, Delphi e simili, compila di default un “integer” a 16 bit se sto compilando a 16 bit come target, o a 32 bit se ho un target a 32 bit… non ho usato tutti i compilatori esistenti, se ne conosci che si comportano diversamente puoi dirmeli
Se se.. trovato meglio con i borland, come no… lo sappiamo che fai la fila davanti al MS Store per accaparrarti il nuovo Zune come i macachi davanti all’apple store per ai’fon :D :D eheh ;)
@schwalbe
Hai ragione a quanto pare anche AutoCad.. questa non la sapevo.. Anche se secondo wikipedia il supporto pieno a VBA c’è solo nei software MS (bella forza, allora anche OpenOffice supporta il suo.. “vba personalizzato” ;) )
@the_m:
Ma quando mai. Caso mai è l’esatto opposto.
La tendenza negli ultimi anni è, infatti, quella di evitare di dover specificare il tipo di una variabile, come avviene anche in linguaggi come il C++ nella sua ultima incarnazione, facendo ricorso al concetto di type inference.
In C#, ad esempio, si usa la keyword var per sfruttare la type inference:
var Lista = new List();Al posto del più verboso (e la ridondante ripetizione del tipo):
List Lista = new List();In python:
Lista = list()o, meglio ancora:
Lista = []Direi che non c’è storia quanto a semplicità e, soprattutto, a livello didattico.
Ancora una volta: ma quando mai?
Non esattamente (avevo detto che non erano uguali).
Python crea una nuova variabile quando viene eseguita un’assegnazione. Altrimenti se deve leggerne il valore e non la trova nello scope corrente, la va a cercare negli altri scope (variabili non locali, globali, o built-in).
Quindi se tu scrivi:
x = a + bviene creata la variabile x se precedentemente non lo era. Mentre per le variabili a e b, se non sono definite nello scope attuale (ad esempio perché prima c’erano delle assegnazioni che le vedevano direttamente coinvolte, oppure perché erano parametri della funziona), vengono ricercati nei vari scope di cui sopra.
Innanzitutto Python è ormai molto diffuso anche con progetti molto grossi. Google, ad esempio, fa un uso estensivo di Python. YouTube è quasi interamente scritto in Python.
Ma a parte questo, ci sono metodologie di sviluppo che consentono di eliminare alla radice problemi questi. Mai sentito parlare di Unit Testing, TDD, BDD, ecc.?
Infine gli IDE moderni già da anni aiutano moltissimo a risolvere questi casi, grazie a potenti strumenti di code analysis che integrano e che consentono di visualizzarli subito.
Certo, se si continuano a utilizzare editor testuali “di base” a 2011 inoltrato, il discorso cambia. Ma quest’articolo parla di IDE, e non a caso, visto che ci siamo LEGGERMENTE evoluti dall’età della pietra informatica.
Hai parlato del supporto a diversi paradigmi di programmazione quale “origine del male”, e ho semplicemente fatto notare che la versione .NET ne supporta diversi e Python pure. Ovviamente ciò NON implica che siano dei cattivi linguaggi di programmazione.
Veramente, e ancora una volta, è l’esatto contrario: proprio chi sta imparando non ha bisogno di conoscere dettagli di basso livello, ma concentrarsi sulla risoluzione dei problemi.
Al più potrebbe interessare proprio in ambito lavorativo, dove magari l’uso di un double ti permette di risolvere ugualmente un problema, ma usando un intero avresti fatto lo stesso, solo molto più velocemente e occupando meno spazio.
Ho insegnato anch’io (lezioni private) per diversi anni fino a un po’ tempo fa. Però una cosa la ricordo bene: quando si inizia generalmente si fa uso di pseudocodice e/o diagrammi di flusso.
Adesso trovami in almeno uno di questi modelli:
– la dichiarazione obbligatoria delle variabili;
– la dichiarazione obbligatoria del tipo di una variabile;
– l’esposizione di dettagli di basso livello.
Forse abbiamo usato modelli diversi, e ciò potrebbe spiegare il perché della totale divergenze fra le tue e le mie affermazioni.
Ed è un problema questo? Da parecchi anni esistono le istruzioni movz e movs nell’ISA 80386+, che anzi consentono di ottimizzare lo spazio in memoria e l’uso della banda di memoria & cache L1/L2/L3.
E quindi, come vedi, gli interi hanno dimensione variabile a seconda delle implementazioni.
Adesso mettiti nei panni di uno che vuole sviluppare un codice portabile. VisualBasic gli garantisce che gli interi sono sempre a 16 bit, per cui può dormire sonni tranquilli. Il C no, e devi far ricorso al preprocessore se vuoi avere qualche speranza.
Brutta cosa il fanatismo.