Friday, November 23, 2007

Linguaggi di scripting e linguaggi compilati

Il rilascio di un programma non può mai essere considerato completamente a prova di bugs. Come si sa errori possono comparire anche dopo molto tempo e possono essere difficili da individuare nei cicli di test. In effetti molti errori possono non dipendere direttamente dal programma scritto in maniera non corretta, ma possono essere causati da dati non conformi alle aspettative.
Succede così che programmi che sono in esecuzione da anni, si blocchino improvvisamente su certi input.
Un ulteriore elemento di aleatorietà è rappresentato dalle interconnessioni che un certo programma deve avere con l'esterno (altri programmi, altri database). In questo caso può essere utile modificare la condotta del programma in base alla variazione del contorno.

Tutto quanto ho scritto sopra evidenzia come la possibilità di entrare in debug non appena si verifica un errore (difficilmente riproducibile) e di risolverlo all'istante per non bloccare un certo processo sia presupposto essenziale.

Gli approcci sono diversi a seconda che si adotti una soluzione compilata o una soluzione interpretata.
Nel primo caso, la correzione dell'errore comporta la disponibilità dei sorgenti, la disponibilità delle configurazioni per il compilatore e la possibilità di usare un ambiente conforme a quando il programma era stato sviluppato. Nel secondo caso ciò che è sufficiente è disporre dei diritti di aprire il file dei sorgenti (che deve essere presente perchè interpretato); se inoltre si dispone di un ambiente in cui il programma è in esecuzione allora le attività di debug sono veramente semplici.
Non voglio dire che l'approccio compilato sia sbagliato: per certi programmi è l'unica soluzione possibile e per programmi da pacchettizzare forse l'unica; voglio solo mettere in evidenza che nel caso in cui si sviluppi all'interno di un'azienda la soluzione da preferire (soprattutto per programmi che accedono a DBMS) è la seconda.
Ho già scritto in passato sulla differenza tra Delphi e MS Access e questo post vuole fornire ulteriori spunti alla discussione.

Saturday, November 10, 2007

Tutti contro tutti

Leggendo questo articolo mi sono reso conto che le sensazioni da me provate al pensiero di usare una piattaforma al termine del suo ciclo di vita come Delphi, siano in realtà condivise da chi usa Java per sviluppare.
Nei commenti all'articolo sopra risulta interessante carpire i seguenti segnali:
Java sta diventando sempre più complesso
Java ha necessità di troppi pezzi software che devono essere messi assieme e configurati
Java richiede troppe risorse sulla macchina
Jave deve essere studiato a fondo per diventare produttivo.

I nuovi linguaggi di scripting come Ruby, PHP, Perl, hanno necessità di Apache e di un editor.
Un ragazzo che inizia ora a programmare, non può imparare una "valanga" di aspetti legati al framework e al contorno per poter essere produttivo e cominciare a vedere i risultati del suo lavoro.

Da questo punto di vista sicuramente Delphi è più avvantaggiato di Java: un ambiente unico, un solo produttore, componenti divisi per funzionalità, grande quantità di librerie e documentazione e soprattutto, come risultato, un programma compilato da trasferire semplicemente sul computer del cliente.