Quote:
Originariamente inviato da Morkar Karamat
Cmq programmare in Fortran ora come ora lo ritengo "delinquenziale", che i salti incondizionati siano totalmente simulabili attraverso quelli condizionati è stato dimostrato ormai da molti anni
|
Si, ma anche quel codice dovrebbe avere molti anni (non ricordo esattamente quanti, ma è passato un po' di tempo da quando quella sonda "prese il largo"). Le versioni più recenti del Fortran integrano istruzioni per la programmazione strutturata (non so dirti sugli oggetti, ma non mi stupirei più di tanto), e già poco tempo dopo il "boom" del Pascal fu introdotto il RatFor (rational fortran), che consisteva nel Fortran più le istruzioni per la creazione di strutture a blocchi, tradotte nelle istruzioni "normali" prima della compilazione vera e propria. Onestamente non ricordo se quel lancio funesto avvenne prima ancora, ma in ogni caso la programmazione strutturata non era ancora lo standard (tant'è che il basic, più o meno contemporaneo del pascal, ma anche nelle versioni successive, non la contemplava). Il fatto è che in generale si tende a riutilizzare il codice scritto in precedenza (specialmente se funziona bene) e in certi ambiti, sia che si tratti di manutenzione ordinaria, sia di modifiche/aggiunte un po' più corpose, si preferisce evitare un refactoring profondo (ovvero una riscrittura del codice) anche a costo di continuare a usare un linguaggio vecchio e uno stile di programmazione superato, pur di non rischiare di introdurre nuovi bug nelle porzioni di codice dove non ce ne sono (o si può ritenere ragionevolmente che non ce ne siano, non essendosi presentati bug per un periodo sufficiente lungo). Sicuramente questo era vero allora, ma in alcuni casi lo è ancora: ad esempio, il sistema di gestione del database al centro di calcolo dell'Università di Palermo è scritto in PL1 (più vecchio del Pascal) e funziona egregiamente, un refactoring potrebbe costare caro, ma si potrebbe pensare anche a un programma che fa i calcoli di una costruzione (pensa se si trattasse di un ponte, di una centrale elettrica, di un'industria metallurgica: te la sentiresti di rischiare riscrivendo in un altro linguaggio un programma che funziona? certo, se lo devi scrivere ex novo allora il discorso cambia...)
Mi pare dicesse qual cosa del tipo: "Le capacità di un programmatore sono inversamente proporzionali al numero di goto presenti nel programma", ovviamente vale anche per la correttezza e la leggibilità (e di conseguenza, la bravura del programmatore).
Quote:
|
Anche C/C++ comincia ad essere datato e credo che con la prossima generazione di SO scritti in Java/.NET ci saranno molti meno bug e anche gli interventi di manutenzione sul codice saranno molto facilitati
|
Sono d'accordo con te, ma questo è vero fino a un certo punto. Innanzi tutto, così il problema si sposta dal "controllo" esercitato dal programmatore, umano e tutt'altro che infallibile, a quello del compilatore/framework, che è comunque un software e quindi può contenere errori sui quali tu, lavorando ad un livello più alto, non puoi avere nessun controllo (se ti colleghi al sito di Java troverai l'elenco dei bug periodicamente trovati e risolti); è anche vero che così i problemi eventuali possono essere ristretti, localizzati e ridotti nel numero, ma non eliminati del tutto. Poi, quel risultato è ottenuto in parte mediante limitazioni alla libertà del programmatore: ad esempio, Java ti impedisce di gestire direttamente l'allocazione della memoria (intendendo per direttamente la richiesta al sistema operativo di allocarne quanta ne vuoi e più o meno come vuoi: in definitiva lo fa lui), cosa che per un OS è di fondamentale importanza, inoltre non è possibile sovraccaricare gli operatori, limitazione utile da un lato, potenzialmente eccessiva ai fini della scrittura di un OS: in C++, ad esempio, potresti scrivere una tua versione dell'operatore new (o più versioni) per accedere in memoria e gestirne l'allocazione nella maniera più opportuna in determinate circostanze (ma potresti farlo anche con apposite funzioni in C, non potresti farlo in alcun modo in Java). In definitiva, difficilmente il kernel di un OS potrà essere scritto con quei linguaggi; i moduli che poggiano sul kernel, e gli strati superiori, invece si
. Salvo situazioni particolari, comunque, lo standard dovrebbe diventare quello per la maggior parte delle applicazioni, con tutti i vantaggi che ciò comporterà. Chissà che non si finisca per spostare i driver in "user space" e scriverli con questi linguaggi (non a breve termine comunque, ci vorrà un po' di tempo per giungere a scenari del genere)...
Ciao
