Newsgroup: it.comp.programmare
Titolo: Ma la portabilità esiste davvero?

Vale a dire: serve a qualcosa darsi la pena di rendere il proprio codice 
"portabile", quando poi nei fatti non lo è mai?
Sto facendo queste considerazioni da un paio di giorni alla luce di 
precedenti esperienze: uso C++ per programmare sotto Windows, ho sempre 
cercato di usare strumenti e librerie multipiattaforma per quanto ho 
potuto, ma alla fine il codice che ho scritto era sempre dipendente da 
qualcosa di specifico per Windows, o perchè mi serviva una DLL di 
sistema, o perchè usavo una libreria che esisteva solo per Windows. 
Senza fare così, avrei dovuto scrivere molto più codice, mi sarebbe 
servito molto più tempo e avrei introdotto sicuramente molti più errori.
Per cui, che senso ha (in programmi un pò complessi, non in piccole 
utility) badare alla portabilità del codice? Lasciamo perdere le varie 
differenze fra compilatori C++, versioni di Make e strumenti vari, che 
pure hanno il loro peso. Perfino in Java la portabilità non è 
assicurata, per via delle differenze delle varie versioni e dei bug 
delle macchine virtuali su piattaforme diverse :-(
Mi chiedo se non sia il caso di rivedere il mio approccio, fregandomene 
altamente della portabilità del codice. Magari fare in modo da poter 
riusare la struttura generale del programma, e in caso di porting 
riscrivere da zero il codice "spicciolo" per così dire.
Non so... voi vi siete mai posti il problema di eventuali porting? Ne 
avete mai fatto uno? Cosa ne pensate??

 avete mai fatto uno? Cosa ne pensate??
Il problema del porting me lo pongo sempre, ma basta rispettare lo 
standard Posix e si porta tutto ovunque.

 nelle interfacce.
Infatti è lì il grosso del problema. Quando devi accedere al S.O. non 
puoi farlo in modo portabile, bisogna per forza scrivere codice non 
portabile. Se il tuo programma prevede grosse elaborazioni il bisogno di 
interfaccia è limitato, ma se lavori con ADO per i DB e/o devi gestire 
le stampe e le reti l'interfacciamento con il SO comincia a diventare un 
bel pezzo del programma. In queste condizioni non so fino a che punto 
renda, preoccuparsi della portabilità... o meglio, come dicevo, forse 
sarebbe il caso di preoccuparsene in modo diverso, visto che molto 
codice andrà comunque riscritto da capo, nell'eventualità che...

 utility) badare alla portabilità del codice? Lasciamo perdere le varie 
Lo fai per lavoro e con rilascio a tempi ristretti ?
Se si e la portabilità non porta un valore aggiunto al prodotto
puoi (a tua discrezione) fregartene.

riscrivere da zero il codice "spicciolo" per così dire.
E' questo che io intendo per "portabile".

 "portabile", quando poi nei fatti non lo è mai?
Secondo me è un approccio vecchio di almeno 10 anni, i tempi in cui il 
programmatore ragionava in termini di "programma" inteso come software 
da installare sul proprio PC.
Forse sarebbe ora di convertirsi ad una programmazione Web, magari 
utilizzando web service (XML & Co.) eliminando il problema alla radice 
(per lo meno nel 95% dei casi)

(per lo meno nel 95% dei casi)
Ma per favore!

standard Posix e si porta tutto ovunque.
Falso. Porti il codice ovunque sia supportato POSIX, che non è ovunque
e solo per le funzionalità esposta da questo standard, peraltro.

 programmi portabili? :-)
E' vero che non ho mai fatto un porting di miei programmi altrove (se si 
esclude da winXP a win98: conta??? :-) però è anche vero che ho sempre 
tenuto presente la possibilità di doverlo fare, perdendo tempo e fatica 
per non usare costrutti e funzioni specifici del compilatore/ambiente, 
anche se magari mi avrebbero fatto comodo, e scegliere solo alternative 
standard. Solo che mi rendo conto che non basta, e che la parte di 
interfaccia va comunque riscritta e non ci sono santi.
Probabilmente hai ragione dicendo che il meglio che si può fare è 
isolare le parti di interfaccia con il SO e scrivere meno interfaccia 
possibile, rassegnandosi a doverle rifare in caso di porting.

interfaccia va comunque riscritta e non ci sono santi.
Intendi la GUI? Non è vero in generale che una GUI vada riscritta da
zero. Ci sono librerie x-platform ed è anche possibile costruire
librerie wrapper attorno alle funzionalità dei singoli sistemi. Tempo
fa Borland lo fece con Delphi/Kylix.

 standard.
Allora fermiamoci un attimo. La portabilità la ottieni (o puoi cercarla)
dal di sopra al di sotto. Ovvero *tagliando* features che sai essere non
portabili oppure usando *esclusivamente* features che sai essere
portabili. Sembra essere la stessa cosa, ma ovviamente il primo
approccio non funziona, il secondo si. Sembra anche essere un discorso
piuttosto accademico, ma di fatto è una distinzione importante.
Inoltre la 'portabilità' dipende anche dall'ambiente e dal livello a cui
lavori. Ci sono contesti per esempio in cui devi mettere in fortissima
considerazione endianness e dimensione dei tipi di dato (che so, a
livello cretino se devi scrivere qualcosa che serializzi degli oggetti).
Questi sono problemi che potrebbero essere invisibili fra Windows e
Linux x86 (32 bit) ma che si sfasciano brutalmente restando sulla stessa
distribuzione su una piattaforma hw diversa. Sono anche problemi che
lavorando in Java o in Python non esistono.
Ci sono problemi di portabilità legati alle interfacce (WinAPI non gira
su OS X, per dire). Ma anche cose più semplici: i font. Prendi
un'applicazione Java teoricamente portabile, fai due customizzazioni su
font e dimensione di controlli e tutto sballa quando porti su una
diversa piattaforma. Ma anche cambiando lingua, per dire. [ chiaro,
questa non è portabilità in senso stretto ].
Ha senso scrivere codice portabile? Io direi che per determinate cose
*non ha senso* scriverlo non portabile, poichè l'attenzione per farlo è
relativamente contenuta e probabilmente taglia a monte anche alcune
classi di bachi fastidiosi o che si potrebbero presentare domani (quando
per dire sei su Win a 64 bit).
Per altre cose il costo è invece grosso. Pensa per esempio alle GUI,
appunto. Usare i tools Microsoft è probabilmente ordini di grandezza più
comodo che usare wx (che a me sta pure sulle palle). Usare Qt è una gran
bella cosa (adoro Qt), purtroppo o rilasci in GPL o paghi una licenza di
un certo peso, che potresti non volere affrontare. Tra l'altro Qt
scherma anche da diversi problemi di portabilità aggiuntiva (isola lei
db, thread e un sacco di roba, insomma, dove porti Qt, porti anche il
tuo applicativo, entro certi limiti).
Parlo di Qt perchè sono le librerie cross-platform di mia conoscenza che
si comportano globalmente meglio sulle piattaforme su cui le ho usate.
Tipicamente wx su OS X fa veramente cagare e GTK non ci gira. Poi GTK
non l'ho vista sempre splendidamente su Windows (e non so come se la
cavi con Vista, mentre Qt te la garantiscono loro, IIRC). 
Certo, Qt ha un costo.  Ma anche Visual Studio completo lo ha, per dire.
Oppure c'è il cambio di linguaggio. Ma ancora una volta resta il
problema delle GUI. Certo... passando a GUI web based (quando e se
possibile) con un linguaggio come Python nel backend hai risolto d'un
colpo quasi tutti i problemi. Entro certi limiti puoi anche fregartene
dei problemi di cross-browser: se puoi permetterti di fare installare al
cliente un'applicazione 'stand-alone', probabilmente puoi anche
permetterti di fare installare Firefox per interfacciarsi al tuo
backend.
<spam & eggs>
Per maggiori dettagli, ovviamente vieni al Pycon! :P
</spam & eggs>
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc