Programmazione imperativa e funzionale

L’avvento di .NET 3.5 porterà ai linguaggi che usiamo di più (C# e VB) una serie di novità che sono principalmente destinate a supportare LINQ. Gli interventi sui linguaggi, però, hanno una portata più vasta di quello che sembra destinato a soddisfare le esigenze sintattiche di una particolare estensione “verticale” (come potrebbe essere l’integrazione delle query sui dati in un linguaggio – in realtà LINQ è qualcosa di più ma questo sarebbe argomento per un altro post).

Un tema che emerge è l’introduzione di elementi di programmazione funzionale nei linguaggi. Quando dovetti imparare il Lisp, pensavo che i linguaggi più funzionali avessero un ruolo marginale e irrilevante, credendo che fossero desitnati a estinguersi. Molti di noi sono probabilmente più abituati alla programmazione imperativa: io sono cresciuto con Pascal e C, poi C++, Delphi (quindi programmazione a oggetti), fino ad arrivare a C#. Chi è passato da VB o Clipper ha comunque una formazione analoga.

Si sa, l’esperienza porta fa acquisire nuovi punti di vista e le novità introdotte in C# 3.0 porteranno a un’evoluzione che va verso i linguaggi funzionali più che ai linguaggi dinamici, come erroneamente anche io ho avuto modo di pensare.

Perché questi aspetti sono rilevanti? Uno dei motivi è che i linguaggi funzionali consentono più facilmente di delegare al compilatore attività di parallelizzazione delle operazioni, in particolare quando si opera su dei valori (tipi value) piuttosto che su degli oggetti (tipi reference). Un altro è che la programmazione funzionale consente un approccio top-down piuttosto che bottom-up, il che ha i suoi pro (vedi Expression-based programming) e contro.

Se volete saperne di più e sentire cosa ne pensano i principali progettisti in Microsoft, non perdete questa tavola rotonda in cui potete sentire Anders Hejlsberg, Herb Sutter, Erik Meijer e Brian Beckman discutere di questi temi in maniera estremamente più competente di quanto potrebbe fare il sottoscritto.

Specifiche interne di Orcas

A questo link sono disponibili dei documenti che descrivono le specifiche di alcune delle nuove funzionalità di Orcas (la prossima versione di Visual Studio).


Oggi ho aperto per la prima volta alcuni di questi documenti, per capire se nella nuova CTP Jan 07 sono disponibili alcune nuove funzionalità che attendevo da tempo. La curiosità ha preso il sopravvento e uno dei primi documenti che ho aperto è quello relativo allo Splash Screen. Vi invito a dargli un’occhiata perché qui si capisce chiaramente che chi ha scritto il documento non pensava che sarebbe mai stato disponibile al pubblico. Curioso anche l’uso di Elvis come nome dello sviluppatore medio, e mi piacerebbe anche capire cosa si intenda per “frugal developer”. Come lo tradurreste? 🙂

Windows Server Home in arrivo

Date un’occhiata a questa recensione di Windows Server Home fatta da Paul Thurrot. Se avete un paio di PC a casa in qualsiasi forma (bastano un laptop e un desktop…) questo prodotto promette miracoli. La sola funzione di Expandable Storage (vedere recensione) vale da sola tutto il prodotto, ammesso che funzioni e che sia affidabile, ovviamente.


Un’idea per Natale (peccato che sia appena passato). Buon anno 2007 a tutti.

Visual Basic 6: una pietra sopra (e uno sguardo al futuro)

Strano modo di cominciare l’anno: invece di parlare di cosa ci attende di nuovo, ho l’occasione di guardare lo specchietto retrovisore e tornare su un argomento che avevo toccato quasi due anni fa.


Una mail di commento a questo post sulla famosa “petizione” a Microsoft per il mantenimento di VB6 (per chi non ha voglia di leggere, ero e sono contrario alla petizione) mi ha dato lo stimolo per fare alcune ricerche e dare una risposta. Nella mail che ho ricevuto mi si chiedeva se avessi cambiato idea, citando a supporto anche il commento di Dan Appleman, che era d’accordo con gli obiettivi della petizione ma non sul modo per raggiungerli reclamato nella petizione stessa.


Microsoft non ha mai supportato la richiesta di cui parlavo nel post, che alcuni degli stessi firmatari hanno ritenuto una goliardata (vedere i commenti al mio post). In questi due anni nulla è stato fatto per estendere la vita di VB6, non sono uscite patch né service pack.


Visual Basic 6 è stato rilasciato nell’ottobre del 1998. A parte qualche service pack uscito nel frattempo (l’ultimo, SP6, nel marzo 2004), non è stato rilasciato alcun aggiornamento. Il supporto a VB6 scadrà l’8 aprile 2008 (per i clienti che hanno l’extended support, cioè clienti che pagano Microsoft per richieste su problemi relativi a tale prodotto – il supporto gratuito è già terminato da tempo).


Nonostante questo, esiste ancora una pagina che riassume il materiale di knowledge base per VB6.


A distanza di quasi due anni, quindi, non ho cambiato idea e pare che anche il mercato non abbia avuto la forza per far cambiare idea anche a Microsoft. VB6 è stato supportato anche oltre i termini contrattuali disponibili, senza però offrire nuove versioni che avrebbero indotto qualcuno a realizzare nuovi progetti su tale ambiente. VB6 credo sia usato per mantenere e supportare applicazioni esistenti, ma tutte le aziende con cui sono entrato in contatto negli ultimi 5 anni si sono mosse per definire un percorso di migrazione a nuovi ambienti: in un arco di tempo lungo, le applicazioni evolvono e spesso hanno bisogno di un momento di “restyiling”, che il più delle volte è l’occasione giusta per un contestuale intervento di migrazione a una nuova piattaforma (che non è detto sia VB.NET e non è detto neppure che sia Microsoft!).


Comunque, il mercato ha sempre una risposta. KBasic (http://www.kbasic.com/) offre la possibilità di migrare il proprio programma VB6 in un ambiente attualmente supportato e addirittura multipiattaforma. Evidentemente questo mercato non è grande a sufficienza per Microsoft, ma lo è per qualche azienda più piccola e non ci vedo nulla di male.


Forse sull’argomento è bene metterci una pietra sopra. Probabilmente vedremo software VB6 girare ancora per 10 anni, ma difficilmente vedremo nuovi progetti creati espressamente per questo ambiente.


Il futuro dell’interfaccia utente è vettoriale, 3D, dinamico, sofisticato ma semplice e immediato da usare. VB6 è bitmap-oriented. Windows Forms, molto più giovane, farà la stessa fine nel giro di qualche anno. Chiunque è libero di fare scelte diverse e mantenersi arroccato sulle proprie posizioni, ma l’unica cosa che può cambiare, credo, è solo quanto tempo ci vorrà per vedere questo cambiamento in atto. Quest’anno ho consigliato (e continuerò a farlo ancora per un po’) alcune aziende a iniziare nuovi progetti in Windows Forms, ma facendo estrema attenzione a mantenere un’architettura che consentisse il passaggio a un’altra interfaccia utente (per esempio WPF) con costi minimi.


In casa Microsoft il futuro è questo. Office 2007 sembrerebbe lì a dimostrare il contrario, ma non confondete l’implementazione con gli obiettivi. Quasi tutto Office 2007 si adatta a risoluzioni diverse usando tecniche “tradizionali”, il Ribbon non è scritto in .NET ma in C++, ma ricordatevi che Office 2007 non ha bisogno di .NET per girare. Forse la prossima versione. Ma i costi di sviluppo di Office 2007 sono stellari, provate a fare le stesse cose usando ATL e C++ e fate due conti, non è qualcosa alla portata di tutte le tasche. Infine, cercate di pensare a quale è il costo maggiore: disegnare un Ribbon o decidere cosa metterci dentro? La risposta è semplice. Il Ribbon è un componente, chiunque lo può usare, magari comprando una libreria. Decidere come riempirlo è invece il problema più costoso da risolvere e oggi non c’è quasi nessuno in grado di farlo.


Buon 2007 a tutti!