|
In queste poche righe non ho
certo la velleitΰ di affrontare e risolvere il complesso problema dei
linguaggi di programmazione e del loro utilizzo migliore, ma il
contenuto puς servire ai profani per comprendere e sensibilizzarsi sulla
grandezza del problema, rimandando gli interessati ad altre fonti di
approfondimento piω qualificate.
Ci sono due strade
altrettanto importanti per valutare un linguaggio di programmazione:
- capire "cosa" sa fare il
linguaggio, ovvero le motivazioni che ne hanno spinto la realizzazione,
ma non alle sue origini, che magari si perdono nella notte dei tempi,
bensμ nel suo stato piω recente di disponibilitΰ
- capire "come" lo sa fare,
nel senso che molti linguaggi presentano strumenti di sviluppo analoghi
tra loro, ma possono presentarsi con regole grammaticali o sintattiche
anche molto diverse, oppure avere altri limiti, anche gravi, se valutati
nel contesto delle nostre esigenze.
Oggi la scelta di un
linguaggio da adottare per una certa applicazione si presenta assai
vasta e complessa.
Sono finiti i tempi in cui un
programmatore studiava e imparava un solo linguaggio e campava con
quello per tutta la sua carriera. La conoscenza di differenti linguaggi
θ indispensabile perchθ il mondo informatico tende ad ampliarsi sempre
di piω, integrando in una stessa applicazione problemi che possono
essere di gestione dei dati di un database, di comunicazioni remote, di
accesso a Internet, di gestione della sicurezza, di controllo dei
processi, di collaborazione e scambio informazioni tra varie piattaforme
o tra vari sistemi operativi e via dicendo.
Un conto θ dovere scegliere
un linguaggio per sviluppare dei giochi al computer, ben diversa la
scelta per l'insegnamento universitario ed ancora diversa quella per
realizzare, invece, applicazioni in ambienti aziendali. Solo per citare
tre differenti approcci al problema.
Il piω elevato numero di
programmi e di righe di codice oggi θ sicuramente legato al mondo
aziendale, o commerciale o del business o del gestionale, che dir si
voglia.
E' per questo motivo che
anche molti linguaggi "puri", nati semplicemente per lo studio o con
scopi ben piω teorici e nobili, hanno finito, prima o poi, per essere
implementati e presentati anche sul mercato del "grande business".
La domanda di sviluppatori
competenti θ quindi sempre piω orientata a questa area di interesse, che
non a tutte le altre.
Allora nella marea di
linguaggi proponibili per lo sviluppo di applicazioni aziendali dobbiamo
essere in grado di fare scelte precise e vincenti.
Chiariamo un altro concetto:
imparare un nuovo linguaggio richiede tempo e fatica e soprattutto un
buon periodo di esercitazione pratica, senza la quale non s'θ imparato
un bel niente!
Sbagliare scelta, sia in
termini di cultura personale che -a maggior ragione- in termini di
scelta aziendale, puς costare molto caro e condannarci a proseguire per
quella strada nel nostro sviluppo di programmi, non potendo buttare via
tutto il lavoro giΰ fatto per ricominciare daccapo.
Gli elementi piω critici da
valutare possono quindi riguardare:
- la standardizzazione e
diffusione del linguaggio e relativa tranquillitΰ e fiducia nel
fornitore, che deve offrire tutte le garanzie di proseguire nella sua
evoluzione, adeguando di volta in volta il suo prodotto al rinnovarsi
delle tecnologie, senza piantarci in asso, magari alla versione
0.1/beta, del suo prodotto
- le caratteristiche
strutturali del linguaggio, gli strumenti che mette a disposizione e le
sue doti fondamentali, ovvero: elasticitΰ, flessibilitΰ, completezza,
affidabilitΰ, autodocumentabilitΰ, semplicitΰ e chiarezza,
manutenibilitΰ, sicurezza, economicitΰ (rendimento in termini di tempi
di scrittura e debug), e via dicendo
- la portabilitΰ del codice
su varie piattaforme hardware e sistemi operativi diversi.
Ognuno dei suddetti punti θ
piω o meno importante e siccome non esiste il linguaggio ideale, come
non esistono tante altre cose ideali, bisogna dare pesi diversi ai vari
attributi, in base alle nostre specifiche esigenze.
Per esempio, in alcune
circostanze la portabilitΰ di un applicativo θ fondamentale, mentre in
altre situazioni puς non essere un grave problema. Teniamo anche
presente che molto spesso esistono tools che alla piω disperata ci
potrebbero aiutare molto a migrare da una soluzione ad un'altra.
Cosμ pure la manutenibilitΰ
non θ sempre un requisito primario. Tutti i programmi si possono
manutere, ma chiaramente in un' applicazione rivolta a paghe e stipendi
o a gestire una produzione assai variabile nel tempo, questo problema
puς essere cruciale, mentre in altri processi potrebbe passare in
secondo ordine di importanza.
Al di lΰ, poi, delle
caratteristiche intrinseche di ogni linguaggio di programmazione c'θ una
valutazione altrettanto importante che deve essere fatta: la conoscenza
giΰ acquisita. Se un linguaggio θ giΰ in uso da un certo team di lavoro,
anche se non θ il linguaggio migliore, probabilmente i risultati che
loro riescono ad ottenere saranno ancora piω validi di quelli
conseguibili se passassero ad un nuovo linguaggio.
Bisogna anche pensare che
l'approccio al problema della scelta θ radicalmente diverso se visto dal
lato degli interessi aziendali piuttosto che da quello del giovane che
vuole affrontare la sua carriera.
L'azienda ha il dovere di
scegliere strade sicure e soluzioni basate su linguaggi ben diffusi, in
modo da non correre rischi di trovarsi in un vicolo cieco con
l'investimento o di essere posta sotto ricatto dal fornitore di software
esclusivo. Il tecnico, invece, puς anche seguire i suoi gusti personali
e fare scelte di specializzazioni di nicchia, rischiando qualcosa in
piω, ma giocando la carta della richiesta sul mercato. Oggi, per
esempio, quanta gente al mondo sa programmare (o comunque dice di saper
programmare) in codice HTML? Sicuramente in tantissimi. Mentre quanti
tecnici si sono specializzati in Postscript? O conoscono bene l'ASP o
XML o Perl o Delphi o Visual RPG? Sicuramente molti di meno. Ma ciς non
significa che non ci sia una domanda anche per quelle conoscenze.
Un punto che secondo me θ
fondamentale nell'area delle applicazioni aziendali θ la scelta di un
linguaggio che sia il piω possibile "problem oriented", ovvero che non
richieda grandi sforzi di stesura del codice, ma che lasci al
programmatore il tempo e la mente libera per potersi concentrare molto
di piω sulle reali esigenze aziendali e la loro traduzione in programmi
gestionali, piuttosto che arrovellarsi il cervello sul perchθ una certa
attivitΰ del programma non funzioni.
Le applicazioni aziendali
muovono un'infinitΰ di dati e oggi sono tutte imperniate su database
relazionali.
Il programmatore in questo
campo deve dunque essere piω un fedele e sensibile interprete ed
esecutore della volontΰ direzionale o della sua societΰ di servizi, che
non un tecnico che si diverta a fare cose sofisticate al computer.
"Piω θ facile, meglio θ",
dovrebbe essere il motto. Mentre purtroppo per la maggior parte degli
hackers, (intesi come smanettoni), vale sempre il pensiero che "piω θ
difficile e piω mi diverto".
Ricky Spelta
|
