Programmation MultiParadigme...

...o PMP è il nome di un progetto di studio che ha origine ai “Leibnitz Laboratory” a Grenoble in Francia e che ha come obiettivo lo sviluppo di una piattaforma unica per lo studio dei fondamenti della computer science. Infatti, come si può leggere nel sito ufficiale del progetto (http://www-leibniz.imag.fr/PMP/ che consiglio vivamente di guardare):

L'objectif de l'équipe Programmation Multiparadigme (PMP) est l'étude des fondements théoriques et la mise en oeuvre pratique d'une plate-forme expérimentale dédiée à la programmation multiparadigme. Nous considérons particulièrement l'intégration des paradigmes de programmation logique, fonctionnelle, impérative et concurrente.

Come più volte ho ribadito in questo blog, nessun paradigma da solo dà la soluzione a quella che ormai è stata definita (fino alla nausea) la crisi del software. L'OOP risolve molti problemi ma non tutti. D'altro canto se si vogliono ottenere altissime prestazioni, difficilmente si può rinunciare alla programmazione procedurale. Linguaggi “evoluti” come Java o C# sono definiti puri, nel senso che supportano esclusivamente l'OOP (sono detti puri anche se poi effettivamente danno il supporto anche per la programmazione concorrenziale).
Contrariamente ai linguaggi puri, esistono i linguaggi “ibridi”, che supportano più paradigmi di programmazione. Esempi di questi linguaggi sono il C++ ed il Python. Il C++ supporta l'OOP, la programmazione procedurale, la programmazione template e la programmazione concorrenziale. I primi tre paradigmi sono nativi del linguaggio, mentre la programmazione concorrenziale si appoggia a librerie esterne (POSIX per sistemi UNIX-like o Win32 e .NET per sistemi Windows). Nella prossima versione della standardizzazione del C++ il cui nome in codice è C++0x (che probabilmente prenderà il nome definitivo di C++09 visto che verrà rilasciata nel 2009), si pensa che anche la programmazione concorrenziale diventerà nativa nel linguaggio. La computer science è una scienza ancora relativamente giovane ed i campi di studio aperti sono ancora molti. Una delle frontiere è rappresentata proprio dallo studio della programmazione concorrenziale (concurrency programming). In questo blog ritornerò spesso sulla concurrency programming e sulla sua modellizzazione (Petri net e net theory in generale). Lo studio della programmazione concorrenziale è un campo ancora del tutto aperto e multi-disciplinare (fisica, matematica, logica, teoria dell'informazione, scienze cognitive, ecc) ed è affascinante come lo è ogni studio di frontiera. Dalla fisica, la programmazione concorrenziale eredita l'impredicibilità dei sistemi dinamici e della teoria del caos, spingendoci ad abbandonare l'idea che in ogni istante si possa sempre conoscere lo stato di un processo di elaborazione. Anche i programmatori più esperti e con più esperienza temono la programmazione concorrenziale. A volte ci vogliono letteralmente dei mesi per capire alcuni comportamenti dei propri programmi multithreding, ed a volte, non li si capirà mai. Un programma, se non attentamente studiato e programmato, può andare in errore in maniera imprevedibile anche dopo diversi anni dal suo rilascio. Nessun tipo di test può evidenziare tutte le insidie nascoste in un programma che fa uso di tecniche concorrenziali.

Bene. Per ora mi fermo qui ripromettendomi (se troverò il coraggio) di analizzare in qualche prossimo post alcune delle basi teoriche della programmazione concorrenziale.

Luca Ciciriello

Transizioni

Ultimamente mi è successa una cosa che mi ha fatto riflettere. Come mi pare di aver già accennato in un post precedente, mia moglie ed io, a casa, utilizziamo solo sistemi Macintosh. Io come piattaforma di programmazione, e lei come la maggior parte di qualsiasi utente, quindi per la navigazione in internet, per l’home-banking, la mail, le chat, fotoritocco, attività ludiche in generale, ecc. Per la mia attività di programmazione io uso un portatile Apple, mentre mia moglie utilizza una postazione Apple fissa. Più o meno recentemente la Apple ha aggiornato il suo sistema operativo MacOS X dalla versione 10.4 (Tiger) alla versione 10.5 (Leopard). Apple è stata da sempre una ditta che ha fatto dell’innovazione la sua vision aziendale. Molte volte, questa innovazione è andata a discapito della retro compatibilità fra i vari sistemi. Anche io, a casa, ho aggiornato il parco macchine con la nuova versione del sistema operativo Apple. Per me programmatore, le innovazioni apportate dalla nuova versione del sistema sono state notevoli. Tanto per dirne una (che da sola vale i 129 Euro per macchina spesi per l’aggiornamento), ho la possibilità di utilizzare il nuovo ambiente di sviluppo Xcode 3.1.1 fornito gratuitamente dalla Apple. Questo ambiente mi consente di utilizzare la versione 4.2 del compilatore gcc e l’innovativa tecnologia di linking LLVM. L’IDE di Xcode 3.1.1 è notevolmente maturata rispetto alla versione 2.5 che veniva utilizzata sul vecchio sistema. E per chi utilizza Xcode come applicazione principale e come motivo quasi esclusivo per utilizzare il computer, vi assicuro che questa è una ragione più che sufficiente per vedere di buon grado l’aggiornamento di sistema. Ora veniamo alla cosa che mi ha fatto riflettere. Per un’utenza ordinaria, quali sono le motivazioni che dovrebbero spingere a fare questo aggiornamento? Mia moglie mi ha detto che il 90% dei giochi che giravano benissimo su Tiger, su Leopard non girano più. Molti altri programmi hanno richiesto il download della versione aggiornata per Leopard. È vero che la versione 10.5 ha aggiunto qualche utile applicazione utente rispetto alla versione 10.4, come “Spaces” o “Front Row”, e qualche altro abbellimento estetico, ma quello che mi chiedo io è: “queste piccole aggiunte da sole sono sufficienti per convincere un utente ordinario a passare alla versione successiva del sistema operativo?”. Sinceramente, a mia moglie, non importa niente se ora il kernel di MacOS X utilizza un nuovo sistema di gestione della memoria, o se tutto il supporto OpenGL è stato ricompilato e linkato con la tecnologia LLVM. A lei non importa se Leopard, rispetto a Tiger, è stato certificato per usi governativi o se sul nuovo sistema si può utilizzare il compilatore gcc-4.2 mentre su Tiger si utilizza il gcc-4.0. Quello che interessa a lei è che i giochi che prima giravano, ora non girano più e che ha dovuto passare un sacco di tempo per andarsi a cercare i vari aggiornamenti dei programmi che utilizzava di più per far girare questi anche sul nuovo sistema. A me questo ha fatto riflettere…

Luca Ciciriello