Newsgroup: it.comp.retrocomputing
Titolo: Legacy system: the one that works

Tempo fa in questo NG si parlò a più riprese di migrazione dati in ambito
gestionale e ne scaturì un'accesa discussione sul valore dei cosiddetti
sistemi legacy e di tutto quel che gli ruota(va) intorno, dell'eredità che
lasciano alle aziende, e del retaggio che lasciano nella storia del calcolo e
anche nel modo di lavorare e di concepire il lavoro del programmatore.
Il seguente articolo potrebbe essere uno spunto interessante, soprattutto per
scambiare opinioni con i tanti lettori di questo NG che lavorano a qualche
titolo nel mondo dell'Information Technology (come dev'essere chiamata ora per
essere à la page), ma anche gli altri sono ovviamente i benvenuti.
Oltre all'articolo in sé, leggete anche i relativi commenti: penso che ce ne
siano di molto interessanti e molto utili come argomenti di discussione.
Eccolo: 
http://thedailywtf.com/Articles/Jurassic-Programmers-.aspx
Ciao,
G.
P.S.: Il testo descrive un OS e di un linguaggio in particolare, ma il
discorso è perfettamente applicabile a tantissime altre combinazioni "legacy".

 gestionale e ne scaturì un'accesa discussione sul valore dei cosiddetti
[...]
Un articolo a dir poco illuminante... :)
Più che altro secondo me ci illustra la tendenza odierna delle varie 
aziende (a questo punto non solo italiane) a cercare di mettere in piedi 
prodotti che siano il più remunerativi possibili abbattendo i costi di 
produzione/sviluppo.
Passare a visual basic, nella mente dei managers, equivale a dire minor 
costo/tempo di sviluppo.
Questo per le seguenti motiviazioni:
1) Ci metto a lavorare neolaureati (come citato nell'articolo) che mi 
costano pochissimo rispetto agli sviluppatori con esperienza.
2) Microsoft mi dice che ci vuole la metà del tempo per sviluppare visto 
che loro mi mettono a disposizione librerie con tutte le funzioni del 
mondo già pronte e tools di sviluppo innovativi.
3) Il software lo manutengo in maniera migliore e con più efficienza in 
quanto è tutto più gestibile con l'XML ecc. ecc.
Alla fine poi ci si ritrova come nell'articolo ad avere costi di 
sviluppo faraonici e prodotti scadenti che però poi vengono venduti 
comunque come innovativi e performanti (e mica ci possono rimettere la 
faccia/soldi).
E' molto interessante invece la fine dell'articolo, dove si è scelto di 
evolvere la metodologia/sistema "legacy" in modo di offrire più 
funzionalità e migliorie sempre in quell'ambito.
Gerry, rimanendo in quest'ambito, è possibile oggi aprire codice e 
programmi sviluppati e manutenuti da moltissimo tempo e su sistemi 
legacy come OS/400 / i5OS e VMS ad una esperienza d'utente di tipo 
moderno/visuale?
Bell'articolo e bello spunto per discussioni... :)
Grazie Gerry!!! :D
Ciao.
	Fabio.

essere à la page), ma anche gli altri sono ovviamente i benvenuti.
Non sono del settore ma e' molto interessante.
Parzialmene attinente, e forse gia' da molti conosciuto, segnalo le
"storie dalla sala macchine" che trovate su
http://www.soft-land.org/storie/index
--
Scambi di elettronica, informatica e pattume vario
http://www.avvocatoguatteri.it/retro/

 Non sono del settore ma e' molto interessante.
Sono discorsi interessanti, che ritornano ciclicamente, ma che spesso 
nascondono dei luoghi comuni. Attenzione a non pensare che tutto quello 
che e` consolidato e` buono. 
Conosco diverso sofwtare RPG/AS400 scritto 15 anni fa se non piu` che 
continua a funzionare perfettamente, peccato che faccia schifo oggi come 
allora. Gli utenti si sono semplicemente abituati, e rassegnati; la sw 
house non ha trovato economicamente vantaggioso rinnovarlo.
Attenzione, non sto parlando dell'interfaccia utente (le schermate 5250 
per determinati task battono ancora qualsiasi cosa), ma del livello 
funzionale del software, nonche` della qualita` del codice, per la gioia 
di chi ha dovuto metterci le mani.
Alla fine quello che conta  veramente e` il software buono, non il 
linguaggio o l'architettura, non so se mi spiego.

 
Ti sei spiegato benissimo, colgo lo spunto proprio da quanto hai 
evidenziato te per dire una cosa secondo me attinente.
Per scrivere del "buon software" bisogna seguire delle semplici regole, 
tra le quali ci sono:
1) Analisi dei requisiti
2) Progettazione delle funzioni del software per soddisfare i requisiti
3) Ingegnerizzazione delle funzioni in un linguaggio di programmazione
4) Assemblaggio del programma
5) Debug
6) Release
7) Manutenzione
E sicuramente me ne sono dimenticate moltissime.....
Ora, con i linguaggi di programmazione "classici" (passatemi il termine) 
(Assembler, Fortran, C, Basic, Pascal, RPG ecc. ecc.) tutti i passi che 
ho elencato  dall' 1 al 4 erano essenziali, altrimenti un qualsiasi 
programmatore usciva pazzo se provava semplicemente a buttare giù 
qualcosa "a video" e poi a rifinire il tutto (esperienza personale).
Oggi con le porcherie visuali (VisualBasic in primis!!!!) i passi sopra 
citati sono in genere molto più blandi se non proprio inesistenti.
Anche perché questo tipo di linguaggi con "tutto prefabbricato" ha 
creato schiere di "Self Made Programmers" che in genere di 
programmazione ne sanno poco e niente.
Pero' questo tipo di risorse sono molto richieste dalle aziende votate 
alla massimizzazione dei profitti, costano pochissimo e lavorano 
tantissimo, peccato che poi alla fine chi ci rimette è l'utente finale.
Quindi ben vengano anche le nuove metodologie di programmazione, i 
linguaggi visuali e tutto l'allegro trenino, però a patto che le cose 
vengano fatte bene....
Ciao.
	Fabio.


Questo dipende da quali applicazioni vengono fatte con quei linguaggi.
Io col Visual Basic ho scritto, per lavoro, un compilatore di
programmi per PLC, e l'unica parte "prefabbricata" è stata il
pulsantino che chiama la funzione "Compila". Ma la funzione stessa,
con il riconoscimento dei comandi, la loro trasformazione da stringhe
di testo in numeri che attivano la corrispondente funzione nel kernel
del PLC, la raccolta dei parametri, la conversione dei parametri
(scritti ovviamente in ASCII) a numeri in formato integer o float, la
trasformazione delle label in indirizzi numerici, la conversione delle
immagini dal formato BMP al formato custom del PLC, il riconoscimento
degli errori di sintassi commessi durante la scrittura dei programmi
per quel PLC... tutto questo non era prefabbricato! Ho dovuto scrivere
un'enorme quantità di codice per farlo funzionare, esattamente come
avrei dovuto fare se l'avessi scritto in C oppure in (puah!) Pascal.
Piuttosto, quello che detesto è che i requisiti di sistema per i
programmi fatti con le nuove versioni di Visual Basic sono aumentati
in maniera spropositata! Quel programma l'avevo scritto in Visual
Basic 6 e girava velocissimo anche su computer obsoleti come un
Pentium di prima generazione a 133 MHz. Convertendolo in Visual Basic
2005 è diventato lento e pesante anche su un Pentium 4 a 2 GHz!

 moderno/visuale?
Tutto dipende da com'è stato scritto il software originale, non tanto dalla
sua vecchiaia. Se è stato scritto bene, modulare, ben commentato, con una
buona separazione tra le varie funzioni, etc. etc. allora sì, è relativamente
facile sostituire le istruzioni di output verso terminali a carattere con
l'equivalente che produca output in ambito client/server (la "webbizzazione"
rimane comunque un po' più complessa). Viceversa, se l'originale è stato
scritto male, anche se è stato prodotto qualche mese fa, convertirlo potrebbe
essere addirittura impossibile, se non riscrivendo interi pezzi da capo.
Ciao,
G.

 linguaggio o l'architettura, non so se mi spiego.
Perň converrai con me che comunque ci sono certe architetture e soprattutto
certi linguaggi piů adatti di altri, ogni linguaggio ha uno scopo. O no?
Ciao,
G.