Olimpo Informatico

[Pistix]

Il mitico linguaggio,nato 50 anni fa,ripreso e sviluppato fino allo stremo,ancora oggi utilizzato da molte aziende,molto valido soprattutto per le banche

per uno che lo sostiene,ne trovi almeno 10 che lo criticano
voi,Dei dell'Olimpo ,cosa ne pensate al riguardo?

[spikexx84]

"The use of cobol cripples the mind; its teaching should therefore be regarded as a criminal offence." Edgar Dijkstra 1975

Traduzione:

L'uso del COBOL storpia la mente, il suo insegnamento dovrebbe quindi essere considerato un reato penale.

Il cobol è ad oggi usato da molte aziende (la mia compresa) perchè si deve mantenere (e a volte continuare a sviluppare) programmi enormi fatti in quel linguaggio, la cui riscrittura totale è economicamente sconveniente, inoltre (diamo a Cesare quel che è di Cesare), la stabilità del cobol è leggenda, i programmi in cobol sono dei trattori: lenti, casinisti, brutti da vedere (sia come risultato grafico che come scrittura del codice), ma funzionano sempre e in applicazioni a criticità relativamente elevata (banche, grossi gestionali, etc), sacrificare grafica, velocità e convenienza economica in cambio di stabilità è un buon affare.

Ovviamente parlò di criticità "relativamente" elevata, non credo proprio che programmi di gestione di un areoporto o di una centrale nucleare siano fatti in cobol.

Ora (visto che lo uso) cercherò di spiegare il perchè il cobol è terribile da usare:

Non esistono ne le funzioni, ne le procedure, si è vero si possono "simulare" anzi si DEVONO simulare o impazzisci, però sono simulazioni, ergo non esiste lo stack di memoria aposito per ogni procedura, quindi TUTTE le variabili sono globali, un sorgente medio da 5000 righe di codice ha in testa 800 righe di variabili...
Ho già detto che non esistone le funzioni? Quindi bisogna scordarsi cos'è come "if funzione" o "var1 = funzione".

Per dichiarare un finto booleano (non esistono in realtà i booleani) servono due righe di codice e due variabili!

Le righe di codice sono lunghe al massimo 61 caratteri (tutti rigorosamente maiuscoli)! 80 totali (come le vecchissime schede perforate) di cui i primi sei contengono il numero di pagina/riga, il settimo l'eventuale asterisco che indica i commenti, dalla 8 alla 11 si ha la cosidetta "zona a" in cui solo particolari istruzioni/etichette possono/devono essere inseriti, infine gli ultimi otto caratteri non sono utilizzabili (80 -6 -1 -4 -8= 61).

Mi stavo dimenticando, ti piacciono le lettere accentate? Scordatele il cobol riconosce solo l'ascii standard (US-ASCII, quello a 7 bit per capirci), quindi tutti i caratteri che esulano da questa rappresentazione (primi fra tutti i caratteri accentati) non possono essere usati.
Lasciamo perdere le bestemie per tentare di interfacciarsi ad un database.....

Ultimo, ma non ultimo, mamma se è prolisso!
Guarda ti faccio vedere nell'ordine una moltiplicazione e un assegnamento di stringa:

MULTIPLY PAR-1 BY PAR-2 GIVING VAR-RES.
MOVE "CIAO" TO VAR-STRING.

In un altro linguaggio:

VAR-RES = PAR-1 * PAR-2
VAR-STRING = "CIAO"

Dopo ovviamente, sono stati sviluppati degli ide che permettono di aggirare alcuni di questi limiti, quello che uso io consente ad esempio di scrivere in minuscolo, implementa qualche funzione interessante (anche solo la mod, la uppercase e la lowcase per fare degli esempi, ma non solo), volendo si potrebbe aggirare il limite degli 80 caratteri (ma questo causerebbe dei problemi ai sorgenti vecchi), ma resta comunque un linguaggio scomodo da usare.

Concludendo, non inizierei mai per nessun motivo un progetto nuovo in Cobol, ciò non toglie che lavorando parecchio si possano comunque ottenere lavori più che dignitosi (lo usano le banche.....).

IMHO

[SverX]

non mi pronuncio più di tanto sull'argomento perché non ho mai programmato in COBOL, però immaginavo che come molti linguaggi della stessa epoca sia piuttosto "limitato" (e il post di spikexx84 me ne dà la conferma)

Poi non so, a volte diventa un po' come la musica: dimmi di che anno sei e ti dirò quale è il tuo linguaggio di programmazione preferito. Il mio ad esempio è il C ...

[GrayWolf]

Ho lavorato per vent'anni in COBOL.
Ho iniziato scrivendo i programmi sui "fogli di programmazione"
che poi venivano perforati su scheda: ogni scheda era una riga di istruzioni.

Come giustamente dice SverX, ogni epoca ha i suoi linguaggi, e non solo di programmazione.

Non lo difendo e non lo denigro, ma a suo favore devo dire che è un linguaggio estremamente "colloquiale",
l'unico che ti permetteva "di scrivere una lettera" al calcolatore
[si pensi alla sintassi del'RPG 1 o 2 e forse 3].

Sicuramente di adatta molto poco alla programmazione a oggetti, ma non è nato per questo,
all'ufficiale della marina statunitense che l'ha ideato [una donna]
è stato chiesto di produrre un linguaggio che fosse:

COmmon Business Oriented Language

e con i calcolatori di allora, secondo me, era il massimo che si potesse raggiungere.

Il paragone, con i linguaggi e le potenze di calcolo attuali, non si può fare, ma...
non si va ad arare un campo con la Ferrari così come i trattori non partecipano alle corse di Formula 1.

[freemind]

In un post su questo forum avevo dichiarato qualche cosa tipo: "cobol è stato un cancro per l'informatica" e tutt'ora questa è la mia opinione.
Come lo è stato visual basic.
Quando è stato inventato non c'era nulla che permettesse di lavorare "semplicemente" a certi tipi di progetti, c'era l'assembler, c'era qualcos'altro ma alla fine tutto e troppo solo a basso livello quindi la sua invenzione ha fatto sospirare molta gente.
Il punto che è nato con i difetti esposti da spike e li ha mantenuti.
Essendo all'epoca facile, ora ci ritroviamo con miliardi di righe scritte in cobol che non potranno mai essere cambiate (alcuni istituti bancari stanno riscrivendo in altri linguaggi le parti più critiche dei loro sistemi, ma sono pochi a farlo e il costo è enorme).
In pratica bisogna tenerselo per mantenere roba vecchia ma chiunque crei un nuovo progetto da zero con questo aborto dovrebbe essere ucciso.
Nel 2011 si programma ad oggetti, punto e basta! Non deve esistere nulla che con sia una classe, un oggetto e anzi, oggi occorrerebbe salire ancora più in alto con l'astrazione (tanto è vero che si sta studiando qualcosa di più generale ancora...).
Solo per questioni di basso livello come di driver, i kernel, i filesystem etc... l'oop non va bene perchè lì bisogna essere velocissimi; oppure qualche funzione particolare di programmi mostro che necessitano lì la massima velocità; però se si programma ad alto livello roba di qualunque tipo, solo oop.

Quindi Pistix, cobol è stato un danno? Sì perchè poi la gente ha esagerato e l'azienda che ora lo maneggia non ha mai fatto nessun passo avanti nella struttura del suo gingillo.

Visual basic pre .net è lo stesso: si è arrivati ad usarlo in mega progetti ottenendo gli aborti a cui tutti i giorni siamo abituati a convivere quando andiamo alle poste, negli uffici pubblici etc...

Una tecnologia non deve mai essere spinta oltre al suo scopo: per cobol e vb è stato fatto e questo è male.

[GrayWolf]

[freemind]

GrayWolf, forse sono stato un po' brutale ma di fatto intendevo dire quello che hai scritto tu.
E' ovvio che se hai a che fare col passato o comunque con un'integrazione con esso, hai poca scelta però oggi c'è gente che se gli commissioni da zero un gestionale lo fa in cobol: sono questi che devono sparire!

Guarda, io sono costretto a programmare praticamente non ad oggetti e pure in fretta quindi pensa che cosa si può ottenere però mi girano le palle e quando vedo aziende che possono permettersi di gestire la creazione di un software nuovo, per grande che sia, con le metodologie corrette e non lo fanno mi vien voglia di dagli fuoco!

[GrayWolf]

[SverX]

[spikexx84]

Mi sono perso, le utlime risposte dopo quella di Sverx....

Che dire, immagino che il concetto (più o meno condiviso da tutti) sia che per i tempi è stata una grande innovazione e lo ammetto, anchio mi sono divertito a scrivere un paio di cose tipo "if x not less then zeros", oggi come oggi però, è un linguaggio che ha senso di esistere solo per convenienza economica su enormi gestionali o simili che non val la pena (solo ed esclusivamente a livello economico) di rifare.

Poi è male, perchè ti fa ragionare male, c'è poco da fare, niente procedure, niente funzioni e niente oggetti, questo ti obbliga a far ragionamenti astrusi (senza contare il pesante uso di goto che fa il programmatore medio di cobol) ed è per questo che ho riportato quella frase all'inizio:
"L'uso del COBOL storpia la mente, il suo insegnamento dovrebbe quindi essere considerato un reato penale."

Nella ditta in cui lavoro adesso ho portato delle innovazioni e ci lavoro da tre mesi, sono cose a cui gente che lavora li da 20 anni non ha mai pensato e non perchè non erano in gamba o capaci, ma semplicemente perchè certe cose sono fuori dalla filosofia cobol e a furia di programmare così la tua mente ragiona così.

Ho reso l'idea?

[SverX]

[freemind]

Buondì, mi son perso un po' di cose perchè ho fatto una vacanza forzata in ospedale...
Dunque, l'oop può essere usata sempre tranne dove si deve scrivere a basso livello (come già detto driver, kernel etc...) e non è che se uno scrive una classe non può picchiarci giù della roba lowlevel!
Non tutti i linguaggi però supportano però le chiamate dirette in assembler però è chiaro che se uno sa che dovrà scrivere parti di codice a basso livello sceglierà un linguaggio che lo supporta.
In c++ uno può scrivere del codice asm dentro al suo progetto così se alcuni metodi devono lavorare direttamente a contatto con l'hardware lo si può fare...
Non vedo quindi perchè non si possa sempre e solo usare l'oop...

[SverX]

freemind: mi riferisco principalmente a questo. Non sono un detrattore dell'OOP, anzi insisto che secondo me per non usarlo servono buonissime e circostanziate ragioni.

Ad esempio se devi scrivere un set di algoritmi di ridimensionamento di fotogrammi in cui ogni singola elaborazione deve poter girare in un tempo inferiore a 1/n di secondo (n=60 o 30 o 15 a seconda dei casi) e che il codice risultante non occupi più di qualche KB in totale...

In questo caso ad esempio ovviamente gli algoritmi sono stati scritti in ASM per una maggiore efficienza e sono stati collegati tra loro usando C e non C++ perché il codice prodotto sarebbe stato più grande.

[freemind]

SverX, siamo d'accordo e quando dico basso livello intendo pure quello.

[corrado63]

Ho letto velocemente tutti i commenti sul cobol su alcune cose non sono daccordo del tipo si puo' scrivere anche in minuscolo, le righe possono essere anche lunghe, il calcolo si fa con compute x=y*z.
Tutto quello che ci sta intorno si puo' modernizzare,
si puo' fare l'interfaccia web che dialoga con il cobol per esempio in modalita' cgi-bin attraverso chiamate ajax o con comandi sql...si possono mandare le email dal gestionale..io praticamente ci faccio tutto da almeno 25 anni...
trovatemi un altro linguaggio con questa longevita' !!!

ciao

[freemind]

@Corrado63: c'è troppa roba da svecchiare. Per esempio cgi-bin per motivi di sicurezza non dovrebbe più essere usata; è una tecnologia vecchia e pericolosa.
Se questo è l'unico modo per lavorare sul web con cobol, meglio non farlo!

[corrado63]

Ho detto che si accede anche con i comandi sql, poi per le cgi-bin ci sono tutti gli accorgimenti con i permessi ed è impossibile sconfinare in altre dir o lanciare applicazioni non esplicitamente attivate, stiamo parlando principalmente di ambiente linux dove accendi il server e lo spegni anche dopo anni...

[freemind]

Si corrado, ma il punto è che quello che viene lanciato tramite cgi, non è più sotto il controllo del webserver quindi restano tutte le beghe di un programma normale che gira senza un controllo superiore come potrebbe essere il webserver.
Puoi mettere tutti i permessi che vuoi ma se lanci un eseguibile,per esempio scritto in c, soggetto ai vari stack/buffer overflow a quel punto un exploit potrebbe venir eseguito.

Parlando di web abbiamo già tanti problemi di sicurezza anche se siamo dentro al webserver che comunque fa un gran lavoro di sicurezza, se lo bypassiamo ciao...

Ma a parte quello, come ha spiegato spike all'inizio è fondato su principi completamenti sbagliati rispetto alla buona programmazione quindi andrebbe eliminato.
Dobbiamo tenercelo per le cose vecchie, ok, ma solo per quelle.
Scrivere roba nuova con cobol è come ammazzare un bambino!

L'ingegneria del software si è evoluta in una direzione completamente diversa (anche se ora si sta cercando di fare alcuni passi indietro su alcuni concetti chiave come per esempio ereditarietà multipla sì/no) ma in generale se l'ingegneria va a destra, cobol va a sinistra!

[corrado63]

Il Cobol per me rimane un linguaggio affidabile proprio per il fatto che i programmi (i gestionali) da me iniziati negli anni 80 ancora funzionano egregiamente.... ovviamente aggiornando solo il runtime compatibile con il nuovo sistema operativo... poi se i linguaggi più moderni hanno delle istruzioni più raffinate ben vangano...ma non voglio sentire dire che chi insegna il cobol uccide qualcuno...aggiungo sicuramente un nuovo lavoro non lo si inizia certo in cobol !!!

[freemind]