I programmatori di LiberoPOPs hanno scelto di rendere il codice portabile su un gran numero di piattaforme; l'autore di HTML2POP3 ha invece preferito concentrarsi sullo sviluppo per un'unica piattaforma, privilegiando la semplicità. Due visioni contrapposte, ciascuna con le proprie motivazioni. Vorremmo coinvolgere anche i lettori di Zeus News nella discussione, in particolar modo gli sviluppatori. Cosa ne pensate? La parola a Matteo Baccan, ideatore di HTML2POP3.

Nei giorni scorsi leggevo con rammarico la nota rilasciata da LiberoPOPs sulla portabilita' del codice. Com'e' vero che ognuno puo' esprimere una propria opinione, e' anche vero che chiunque puo' dissentire.

Ho letto con attenzione il documento che hanno scritto e devo dire che, per alcuni aspetti lo condivido.

Condivido che, negli anni 60-70, al posto di scrivere tutto un sistema operativo in ASM, si decise per l'utilizzo di un linguaggio di piu' alto livello che potesse dare una maggiore portabilita', e da questo l'utilizzo di C.

Concordo il fatto che questo linguaggio sia, probabilmente, il linguaggio piu' diffuso al mondo come supporto in piattaforme diverse.

Dissento pero' su alcuni passaggi e, a favore di queste mie osservazioni, riporto una vecchia intervista a Bjarne Stroustrup, autore di C++, che ho potuto fare nel lontano dicembre 2000, pubblicata a marzo 2001 su DEV.

C e' sicuramente un linguaggio con un libreria di base povera, dato che le librerie standardizzate si possono veramente contare sulla punta delle dita, mentre C++ diverge da questo fatto, dato che integra un maggior numero di librerie standardizzate di base. Entrambi pero', se guardiamo allo standard, sono inferiori a Java. Per voler fare degli esempi semplici, possiamo parlare di Thread e Socket, due aspetti importanti per lo sviluppo di un prodotto come HTML2POP3 o LiberoPOPs.

Stroustrup stesso lamentava questa carenza, dicendo pero' che, grazie alle librerie di terze parti, queste lacune erano colmate. Criticava inoltre il fatto che, implementazioni come Java o Ada, che hanno questo tipo di supporto, possono non sfruttare al massimo un sistema per il fatto che non supportano i Thread in maniera nativa, ma astratta.

Inoltre affermava che, le librerie per C++, erano sicuramente superiori in numero e funzionalita', rispetto a quelle Java. Questo almeno 3 anni fa. Quindi, per non trasformare questo discorso in pura accademia, vediamo di fissare dei punti sulla carta e capire a quale conclusione arrivare.

C e C++ sono sicuramente linguaggi piu' diffusi di Java, ma necessitano di ricompilazione obbligatoria sulle piattaforme dove devono essere utilizzati.

C e C++ soffrono di problemi di buffer overflow, problemi sconosciuti a Java, soprattutto per la mancanza di puntatori, per tale ragione si ricorre all'utilizzo di libreria di terze parti per evitare di incorrere in questi problemi.

Java ha una libreria di base sicuramente piu' ricca di C e C++, che suppliscono a queste carenze con librerie di terze parti.

Alla luce di questo, si puo' tranquillamente parlare di linguaggi, tutto sommato, paritetici, se parliamo di funzionalita' date, sia dalle librerie standard che dalle librerie di terze parti.

Inoltre e' importante pensare che Java, in realta', si basa su un kernel C, e quindi, quando usiamo Java, stiamo usando un motore C che fa girare del bytecode Java, anche se, grazie ai nuovi compilatori JIT, quello che viene eseguito e' molto piu' vicino a del codice nativo che a un mero interpretato.

Tutto questo discorso per arrivare a una conclusione o meglio, a una non conclusione. Possiamo scrivere tutti i programmi che vogliamo in tutti i linguaggi che vogliamo, questo non e' importante. I linguaggi moderni sono in grado di avere, nativamente, o grazie a librerie esterne, tutte le funzionalita' che ci servono.

E' vero pero' che alcuni linguaggi siano piu' "facilmente" portabili di altri, questo pero' non significa che siano piu' "portabili" di altri.

C e' piu' portabile di Java, Java e' piu' facilmente portabile di C. Questo lo si deduce anche dal numero di righe di codice personalizzato che occorre scrivere in un programma C per poterlo portare, ad esempio, da Unix a Windows o viceversa, oltre agli errori che vengono dati da una gestione diversa delle librerie standard, dato che sono sviluppate da aziende diverse e non concentrate sotto una sola azienda, problema notato anche da Stroustrup.

Quindi, non focalizziamo i problemi sul linguaggio utilizzato, vanno bene tutti. Mi ricordo quando ho iniziato a pensare a HTML2POP3, la prima implementazione che ho trovato, dei suoi concetti di base, era un pezzo di codice scritto in PERL da un altro programmatore.

Per quanto riguarda la moda, questo e' un altro discorso. Ho lavorato per anni in ASM, Clipper, C e C++, passando giornalmente da un linguaggio all'altro. Poi ho studiato Delphi, Java e C#. Ognuno di questi linguaggi ha pregi e difetti, ma con ognuno di questi si sarebbe potuto scrivere un prodotto come HTML2POP3, bastava pazienza e applicazione.

Lavorando in ASM si poteva provare a usare un metacompilatore, o per assurdo si poteva scrivere un codice e poi eseguirlo in emulazione su altre piattaforme, partendo da un prodotto come bochs, ed adattandolo, anche se entrambe le soluzioni sarebbero state un bagno di sangue.

Con Clipper si sarebbe usato Harbour, la sua versione cross-platform, C-based. Con C e C++ si sarebbero usati i compilatori nativi Unix o le versioni portabili Windows, OS/2 etc, come Cygwin. Con Delphi occorreva usare FreePascal, supportato per Amiga, QNX, SunOS, Win32, Linux, FreeBSD e altri. Java viene fotunatamente supportato da casa Sun su piattaforme diverse. C# poteva girare in ambiente Windows, con .NET SDK, e in Linux/Unix grazie a Mono. Quindi, non importa quale compilatore usare, ma quali sono gli obiettivi del progetto.

Personalmente non volevo spendere notti su notti su questo programma. Due giorni per la prima implementazione e un po' di lavoro per l'ottimizzazione sono stati abbastanza per ottenere un prodotto utilizzabile su un numero decente di piattaforme, non tutte, lo riconosco, ma almeno senza aver speso un solo secondo a pensare a file di make, switch di compilazione, parametri gestiti in maniera non standard da un compilatore piuttosto che un altro, codice condizionale e cosi via.

Sono contento del risultato raggiunto, soprattutto in relazione allo sforzo fatto. Potessi ripartire potrei anche riscrivere tutto in un altro linguaggio, in C++, ad esempio, ma per pura sfida personale, anche se pensandoci tutto questo non avrebbe minimamente senso.