Newsgroup: it.comp.retrocomputing
Titolo: Linguaggi e compilatori preistorici (FACT, FLOW-MATIC, COMTRAN & Co.)

La scorsa estate avevo scritto in questo NG a proposito dei miei esperimenti
con DBMS-10 (
http://goo.gl/inWDI
). Un paio di sere fa ho ritrovato quel post
mentre cercavo un vecchio messaggio che mi serviva, e l'ho riletto.
Mi sono voluto levare lo sfizio di verificare se ancora il Cobol HP per VMS
supporta nativamente gli statement DBMS (sě, lo fa anche nell'ultimissima
release per IA64) e nella prefazione dello specifico DBMS Programming Manual
ho trovato il seguente curioso paragrafo, presente anche negli altri manuali
relativi al compilatore in questione (
http://goo.gl/JaSZk
): 
| COBOL is an industry language and is not the property of any company or 
| group of companies, or of any organization or group of organizations.
| [...]
| The authors and copyright holders of the copyrighted material used herein 
| are as follows: FLOW-MATIC (trademark of Unisys Corporation), Programming
| for the UNIVAC (R) I and II, Data Automation Systems, copyrighted 1958,
| 1959, by Unisys Corporation; IBM Commercial Translator Form No. F28-8013,
| copyrighted 1959 by IBM; FACT, DSI 27A5260-2760, copyrighted 1960 by
| Minneapolis-Honeywell.
|
| They have specifically authorized the use of this material, in whole or in
| part, in the COBOL specifications. Such authorization extends to the 
| reproduction and use of COBOL specifications in programming manuals or 
| similar publications.
Le due cose che mi sono subito saltate agli occhi sono il riferimento al
linguaggio FLOW-MATIC della mitica Grace Hopper e gli anni di copyright.
Non ci č voluto molto per trovare qualche riferimento su Wikipedia, con
tanto di relativi link ai manuali originali archiviati su Bitsavers:
 
http://en.wikipedia.org/wiki/FLOW-MATIC
 
http://en.wikipedia.org/wiki/COMTRAN
 
http://en.wikipedia.org/wiki/FACT_computer_language
Il piů interessante dei tre mi č sembrato il manuale originale del 1960 del
linguaggio FACT, che nella sua prefazione spiega:
| FACT (Fully Automatic Compiling Technique) is a complete programming 
| system which constitutes a major breakthrough in programming cost 
| reduction. It can be used on any data processor for which it is 
| implemented. In the past, problem preparation for a major data processing 
| application has been exceedingly expensive and time consuming. In some 
| cases, its cost has approximated that of the equipment itself. Initial 
| efforts by many people to reduce this cost led gradually to an assortment 
| of programming aids, each of which contributed a little to making the 
| programmer's task easier. Though the combined effect of these aids has 
| been significant, their very abundance has limited their usefulness. 
| Furthermore, the variation from installation to installation has been 
| unfortunate. Now for the first time, a tool is presented which provides 
| for easy and uniform handling of all aspects of data processing, including
| input editing, sorting, processing of variable-length records, and report
| writing.
E piů avanti, nell'introduzione al compilatore aggiunge:
| As implemented on the Honeywell 800, FACT can compile with only four 
| magnetic tape units and minimum memory.
Č incredibile quanto potesse essere avanzato un compilatore cosě antico e
indubbiamente limitato nelle risorse a disposizione e nella tecnologia,
essendo uno dei primi in assoluto. Eppure il manuale mostra come fosse
flessibile e in grado di fare senza problemi il parsing di elementi
piuttosto complessi o sinonimi fra loro come i seguenti (alla faccia anche
di alcuni parser moderni):
	WAREHOUSE PART NUMBER
	NUMBER OF PART IN WAREHOUSE
	PART NUMBER IN WAREHOUSE
	NUMBER OF WAREHOUSE PART
Oppure come potesse riferirsi a parti di campi dati (oggi diremmo substring)
con una sintassi assolutamente self-commenting, che non fa mai male:
	FIRST DIGIT OF POLICY NUMBER
	(24)TH LETTER OF NAME
	THIRD CHARACTER OF ADDRESS
Oppure ancora come si potessero creare delle definizioni complesse da
riutilizzare successivamente (la prima riga definisce SENIOR, la seconda č
un esempio di riutilizzo della definizione):
	SENIOR. TENURE IS GREATER THAN 10 AND RANK IS GREATER THAN LEADMAN.
	IF SENIOR ADD BONUS TO PAY.
Alla fine del manuale c'č un programma di esempio. Non dico che sembra di
leggere un testo descrittivo in inglese, ma quasi. :-)
Saluti e buona lettura,
G.
P.S. 
http://www.flickr.com/photos/olddognewtrick/5104878214/


In realtà era parte della filosofia del tempo: non si concepiva ancora
una vera e propria separazione tra utente e sviluppatore, e ci si
aspettava che chi usasse quei sistemi dovesse in buona parte
programmarli per conto proprio o comunque conoscerli nel dettaglio. La
sintassi molto prolissa e "discorsiva" del COBOL viene fuori proprio
da lì, con l'idea che anche dirigenti, o comunque personale con una
preparazione non iper-specialistic, dovesse poter comprendere la
logica e intervenire.
m.

 logica e intervenire.
Io credo che il mito della prolissità del Cobol vada in parte sfatato.
Certo, se come pietra di paragone si prende il classico "Hello world", si
troveranno linguaggi molto più concisi. Ma in un'applicazione reale la
differenza potrebbe non essere poi così evidente, anzi potrebbe addirittura
capitare l'incredibile, e cioè un programma Cobol più corto della sua
controparte in un altro linguaggio, semplicemente perché il Cobol ha delle
funzionalità integrate che in altri linguaggi vanno scritte esplicitamente
consumando righe di codice. Così su due piedi mi vengono in mente cose tipo
i costrutti INSPECT, SEARCH ALL, STRING e diversi altri.
Naturalmente ogni linguaggio è adatto al suo ambito: non scriverei mai in
Cobol un programma tipo quello che utilizziamo per la nostra DECnet (scritto
in C), ma non utilizzerei mai il C per scrivere un'applicazione gestionale
con accesso a un database e produzione di stampe. Tanto per fare un esempio.
Quanto alle variabili-sempre-piuttosto-lunghe del Cobol, si tratta solo di
una tradizione, ma non c'è nulla che vieti di creare variabili con nomi di
un solo carattere (come non è obbligatorio avere variabili brevissime in un
programma C). Però bisogna dire che una cosa tipo importo-lordo-fattura è
molto più facile da trovare rispetto a X in un sorgente di cui magari si sa
poco o nulla. E se proprio vogliamo, i caratteri sprecati causa prolissità
sono poi recuperati grazie alla minor necessità di scrivere commenti che
spieghino cosa fanno certe righe condensatissime che si fatica a suddividere
nelle loro parti elementari tanto sono compatte. Visto poi quanto poco i
programatori amino scrivere commenti, un linguaggio self-descripting può
essere anche un vantaggio, specie quando si eredita il lavoro di altri.
Comunque, con un po' di impegno si riesce a scrivere codice incomprensibile
con qualunque linguaggio. :-)
Ciao,
G.

 G.
A tal proposito, per chi non lo conoscesse :)
The International Obfuscated C Code Contest
http://www.ioccc.org/main.html

 con qualunque linguaggio. :-)
Assolutamente sì!
m.

 paragone con cose molto più recenti.
Scusa, ma francamente non ho capito cosa intendi dire. :-) Intendi dire che
all'epoca il Cobol risultava prolisso o che risulta prolisso oggi?
Se è la prima ipotesi, allora sono d'accordo: in un mondo dominato da
stringatissimi linguaggi assembly e ancora dal codice macchina inserito
direttamente, il Cobol dovette certamente apparire veramente molto
discorsivo, ma probabilmente anche una boccata d'ossigeno.
Se invece l'ipotesi era la seconda, allora sono meno d'accordo: oggi — con
l'abbondanza di storage che abbiamo — molti linguaggi sono decisamente
ingombranti in termini di caratteri utilizzati; il che però non significa
automaticamente che siano anche prolissi o discorsivi e chiari. Sto pensando
a certi pezzi di codice Java che mi è capitato di osservare e che non erano
certo brevi in termini di caratteri utilizzati, eppure non si può certo dire
che fossero molto discorsivi nel senso "cobolistico" del termine. Java è
solo un esempio, ma se ne potrebbero fare diversi altri, moderni e antichi.
Ciao, :-)
G.

 solo un esempio, ma se ne potrebbero fare diversi altri, moderni e antichi.
Qualcuno si e' dimenticato che negli anni '50 e '60 si usavano 
principalmente coding sheets, che poi venivano materialmente digitati 
(su schede o nastro perforato) da personale addetto al data-entry ? ;)
Più che altro, il personale addetto alle perforatrici (in generale erano 
stenotipisti..) non si lamentava troppo, avendo a che fare con "parole 
vere" e non "astruse sigle" ;)
Saluti,
dott. Piergiorgio.

 vere" e non "astruse sigle" ;)
Giusto. E per un profano è certamente più semplice scrivere senza errori
parole inglesi di uso comune piuttosto che incomprensibili sigle di tre
caratteri (ho visto un pezzo di assembly per IBM 7090 ed è impressionante).
Considerando poi quanto era scomodo correggere gli errori di perforazione,
ecco un altro punto a favore di un linguaggio discorsivo. C'è comunque da
dire che quest'ultima osservazione non si adatta solo al Cobol, ma un po' a
tutti i linguaggi mediamente composti da parole semplici e chiare.
Alla fine anche un linguaggio "prolisso" come il Cobol ha i suoi vantaggi
pure dopo tanti anni. Il fatto che sia praticamente solo usato per cose poco
esotiche come bolle e fatture e non per cose "da hacker" come lo sviluppo di
sistemi operativi et similia ha contribuito a farlo passare per una vecchia
schifezza, facendo dimenticare il suo glorioso retaggio e quanto sia e sia
stato importante nella storia dell'informatica.
Negli stessi anni nasceva anche il Fortran, molto più limitato, tanto da non
avere neppure un tipo character fino almeno al 1977. Però solo per il fatto
di essere di uso universitario non gli è stato riservato lo stesso scherno.
L'ironia della sorte è che molti di quelli che già 40 anni fa parlavano male
del Cobol, se venivano pagati regolarmente era (è) proprio grazie a qualche
programma scritto da un così poco sexy cobolista in giacca e cravatta...
Con questo non voglio comunque togliere nulla al Fortran, che trovo sia un
linguaggio molto interessante e bello, specie il 77 con le estensioni del
1978 ad opera del dipartimento della difesa americano (MIL-STD 1753).
Quanto ai coding sheet, li ho usato anch'io non più tardi di 10 anni fa
durante un corso di RPG/400 (per AS/400). In particolar modo ricordo quelli
per le specifiche O (di Output). Nella directory ibm/forms su Bitsavers si
può vedere a cosa mi riferisco. Da qualche parte dovrei anche avere qualche
foglio originale — non fotocopiato — con la sua tipica stampa verdolina. :-)
Ciao,
G.

 linguaggio FLOW-MATIC della mitica Grace Hopper e gli anni di copyright.
Mi quoto da solo per segnalare questa interessante mostra virtuale del
National Museum of American History presso lo Smithsonian Institution:
http://americanhistory.si.edu/exhibitions/small_exhibition.cfm?key=1267&exkey=988
Fra le varie immagini, ce ne sono anche due con Grace Hopper (la donna
vestita di bianco):
http://americanhistory.si.edu/cobol/COBOL002-800.jpg
http://americanhistory.si.edu/cobol/COBOL001-800.jpg
Ciao,
G.

 foglio originale — non fotocopiato — con la sua tipica stampa verdolina. :-)
eh... qui praticamente ho un buon mirror di bitsavers ;) Comunque, se 
vuoi, puoi anche scannerizzare a colori i forms che hai ancora, reputo 
che il buon Kossow sara' lietissimo di aggiungerli al suo archivione ;)
Saluti,
dott. Piergiorgio.