Newsgroup: it.lavoro.informatica
Titolo: Un pò di storia del software

Un articolo molto interessante sulla storia dello sviluppo dei
software usati dalla Nasa nelle sue sonde automatiche:
http://www.flownet.com/gat/jpl-lisp.html
L'autore esprime l'opinione che certe cose sarebbero state
difficilissime od impossibili se fatte in C++, od altri linguaggi
imperativi, piuttosto che in Lisp, come invece furono.
Particolarmente interessante il punto in cui parla del debug
interattivo di una sonda da 100 mil. $, in volo a 100 mil. km dalla
terra. Un compito "abbastanza" delicato.... :-)

 terra. Un compito "abbastanza" delicato.... :-)
Considerato che agli estremi di un programma stanno da una parte il 
linguaggio macchina, cio� riferito ad un processore, e dall'altra 
l'interfaccia con l'essere umano programmatore, si puo' dire che ci� che 
differenzia un linguaggio dall'altro � solo la sintassi e la possibilit� 
  di tradurre, pi� o meno facilmente, i concetti in istruzioni per computer.
In teoria, TUTTO � possibile, cio� NULLA � impossibile, con un 
linguaggio che ti permette di scrivere istruzioni 'inline' in assembler.
(ad es. il C).
Ergo : "the problem is all in your mind" cio� nella mente del programmatore.
:-))

 (ad es. il C).
Nella realtà alla possibilità teorica devi abbinare il costo in
termini di tempo e risorse. L'autore senz'altro a quello si riferisce,
quando parla di impossibilità.

 imperativi, piuttosto che in Lisp, come invece furono.
Beh, anche un programmatore in VB6 direbbe che solo e solamente in
quel linguaggio sarebbe potuto essere realizzato il sistema di
sportello di poste.

 imperativi, piuttosto che in Lisp,
Sostituisci x a C++, ed y a List, fai variare x ed y distinti a
piacere tra i valori nell'insieme dei linguaggi di programmazioni
esistenti, e l'opinione dell'autore può essere sempre veritiera e
condivisibile, oppure no, a seconda del dominio applicativo, delle
persone coinvolte nei progetti e delle risorse a disposizione.
--
ale
http://ale.riolo.co.uk

 sportello di poste.
Ti sfugge che parla di sonde spaziali. Una "piccola" differenza di
complessità e di affidabilità richiesta.... :-)
Senza contare che in quel caso il tizio ha comparato risultati reali
dell'uso effettivo dei due linguaggi.
Bisognerebbe vedere Lisp usato alle poste od in banca.

 complessit� e di affidabilit� richiesta.... :-)
Pero', sai, mi sa che ci ha preso abbastanza.
Io ho un amico che, da giovane, programmava software per i satelliti in
Ada. Eppure, il tale guarda Ada con una certa sufficienza.
-- 
Ciao!
Luca

 persone coinvolte nei progetti e delle risorse a disposizione.
Sono d'accordo. Ogni opinione è tale.
Però hai dimenticato che c'è anche la variabile Z, carriera. In questo
caso Nasa/Jpl, ed anche Google.
Ognuno può decidere se l'opinione di questo signore ha lo stesso peso
di certi teorici del software che vanno per la maggiore, con ben
diversa risonanza multimediale.

 Ada. Eppure, il tale guarda Ada con una certa sufficienza.
Cioè non apprezza Ada? Dipende anche cosa ci ha fatto e quali
risultati ha raggiunto.
PS:  Google mi raddoppia tutti i messaggi, non li cancello più

 Ada. Eppure, il tale guarda Ada con una certa sufficienza.
Cioè non apprezza Ada? Dipende anche cosa ci ha fatto e quali


 risultati ha raggiunto.
No. Quando parlo del 'tale', intendo l'autore dell'articolo cui tu
inizialmente hai fatto riferimento, e che ne  accenna.
L'amico mio ha una grande considerazione di Ada.
-- 
Ciao!
Luca

ispas ha scritto:
Se la conclusione e':
The situation is particularly ironic because the argument [...] is that
JPL should use "industry best practice." 
e che quindi le "industry best practice" sono basate sul niente piu'
assoluto, concordo in pieno.
Invece se la conclusione e':
"Lisp e' bello", "tutto il resto e' brutto", allora concordo meno.
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 "Lisp e' bello", "tutto il resto e' brutto", allora concordo meno.
Non so se ci hai mai fatto caso, ma accade *sempre* che quando
qualcuno di vera, grande e comprovata esperienza propone una
alternativa al bagno di sangue in C e/o C++, gli si risponde picche
senza manco farlo parlare. Io l'ho visto accadere di persona più
volte. Non ho idea chiaramente se questo sia il caso del racconto nel
link (nessuno di noi può dal solo racconto, del resto) ma il trend è
di sicuro quello e si ripete così spesso da essere praticamente un
pattern (un anti-pattern, in questo caso).
Il mondo del software è pieno di esempi di fallimenti dovuti alla
coccia dura dell'uomo, molto più che di quelli di natura tecnologica.
Per fortuna, oggi viviamo un periodo di fermento in cui sono in molti
a farsi tante domande e le cose sono sensibilmente virate rispetto ad
anni fa.

 anni fa.
E poi comunque esiste la massima libert� di provare quello che si vuole, 
e poi decidere cosa usare.
Io ad esempio, se avessi abbastanza tempo, vorrei sollazzarmi un po' con 
Lisp, Smalltalk e Ada e vedere un po' come si comportano.
Ma penso che lo lascer� per la prossima vita.

 In cosa saranno scritti i loro software ?  List ? Ada ? C++ ??
In C/C++ ;-)
<
http://trs-new.jpl.nasa.gov/dspace/bitstream/
2014/37499/1/05-0539.pdf>
Forse hanno usato Java per interfacce a terra e per il simulatore.

 e poi decidere cosa usare.
Dove? A casa? :-) In molte situazioni di una certa grandezza
l'ambiente è imposto, magari dai responsabili tecnici che non
conoscono neppure come si scrive  Lisp, Ada, Haskell, ecc. ecc.

 "Lisp e' bello", "tutto il resto e' brutto", allora concordo meno.
Non so se hai provato a fare qualcosa in Lisp, Scheme,  Haskell,  e
simili. Nel caso, sarai d'accordo con me che passare dai "soliti"
linguaggi ad uno di questi è fare un enorme salto, dal punto di vista
della potenza concettuale e di sintesi.
Per dire, un linguaggio che ha come tipo base la lista parte già
enormemente avvantaggiato, visto che le liste e loro parenti (array,
vettori, alberi, matrici, ecc.) sono praticamente in ogni programma di
una minima complessità.
Magari anni fa i tempi non erano tecnologicamente maturi per usare al
meglio quei linguaggi (anche se a leggere l'articolo non si direbbe).
Comunque tentare qualche evoluzione non mi sembra errato. Non a caso
alcuni linguaggi "di grido" inglobano già una certa parte di paradigma
funzionale ( Python, Net con Linq ed F#, e non so quali altri). Solo
un fuoco di paglia? Vedremo.

 Dove? A casa? :-) 
Certo. O perlomeno in un ambiente dove sei 'libero e indipendente'.
Anni fa (ca. 15) la mia ditta compr� (tra l'altro su mia richiesta) un 
compilatore ADA che purtroppo non ebbi mai il tempo di provare.
Cos� rest� sullo scaffale a prendere polvere. Dubito che i posteri 
l'abbiano mai aperto. Peccato. Sento un po' di complessi di colpa per 
questo. Mi � rimasta una 'voglia non soddisfatta'. :-)))

 Forse hanno usato Java per interfacce a terra e per il simulatore.
Pareva strano pure a me. Resta l'implemetazione ad oggetti, le
interfacce, i layer ecc.. Tutte cose che rendono possibile realizzare
un software così complesso.
Bello il documento che hai scovato, posto un frammento :
The Flight Software is coded primarily in ANSI C, with some targeted
assembly code and some C++.
The size of the system, in source lines of code (SLOC), is [300K] but
this value does not include the operating system.
Although many aspects of the design are objected-oriented, the
features of the language incorporating inheritance and polymorphism
are not exploited.
We have found that when implemented to their fullest extent in C++,
these constructs result in detrimental code size and add the potential
for non-deterministic behavior. These costs, especially in time and
effort to achieve a robust implementation, outweigh the benefits.


Se è per questo, anche applicare "Effective Java" di Bloch e fare
functional programming in Java riesce molto poco spesso, se ci si deve
attenere a quello che sanno fare in media gli sviluppatori software.
Non è un caso che tanti sviluppatori di grande talento hanno una
carriera "al contrario": prima le grandi realtà, poi ambienti via via
sempre più piccoli, dove poche persone esperte hanno idee simili alle
tue e il creare software torna ad essere il centro di tutto, con buona
pace di marketing e piani alti (wannabe) onniscenti.
E' questo che mi auguro sempre di trovare, rispetto a chissà quali
grandi realtà dove creare qualcosa di decente diviene un lavoro di
brute force contro tutto e tutti...

 effort to achieve a robust implementation, outweigh the benefits.
Da questa frase mi sembra che l'OO alla fine l'hanno messa ai margini.
Mi colpisce la frase:


 "add the potential for non-deterministic behavior"
Dicono che hanno scelto di non usare "inheritance and polymorphism",
hanno usato solo una parte dell'OO, declinandola sul caso specifico ed
in questo mi trovano pienamente d'accordo.
Come nel gesionale : l'OO è una bellissima teoria, ma i dati sono in
tabella bellezza.

 tabella bellezza.
Finche` non trovi qualcosa tipo PostgreSQL che consente l'ereditarieta` 
tra tabelle :)
Bye.

 anni fa.
Il problema non sono le domande ma le risposte.
La domanda "e' meglio C++ o Lisp" puo' prevedere come risposte
e' meglio c++
oppure
e' meglio Lisp
Entrambe le risposte sono ugualmente idiote.


 l'ambiente � imposto, magari dai responsabili tecnici
Il problema e' che i "responsabili tecnici" non sono quasi mai
tecnici. 
E quindi se qualcuno dice loro "j2ee e' bello", per loro "j2ee e' bello".
Il problema qui sono effettivamente quelli che fanno i tecnici:
se questi capissero che i linguaggi sono del tutto equivalenti ci
sarebbero molti meno problemi. Ma ogni tecnico e' convinto che ci sia un
linguaggio "piu' figo" degli altri. Oggi ad esempio nelle aziende romane
sostanzialmente  java e' "figo", C++ e' una me**da.
E' anche vero che, dal punto di vista aziendale c'e' sempre da rispodere
alla domanda: "come faccio a trovare tante persone che conoscano questo
linguaggio che io voglio usare e che costino poco". Oggi la risposta e':
"scelgo j2ee."
Se scegliessi Haskell puo' anche darsi che troverei persone che "costano
poco" ma non ne troverei "tante".


 Bisognerebbe vedere Lisp usato alle poste od in banca.
Per vederlo alle poste e' sufficiente implementare il seguente algoritmo:
- salire sulla metro B (a Roma)
- scendere alla fermata Eur Palasport. 
- andare in viale Europa 
- incontrare le "persone giuste" (sostanzialmente i PM addetti alla
gestione dello sviluppo software) 
- convincerle che lisp e' meglio di altre cose
Se riesci ad implementare il seguente algoritmo avrai Lisp alle poste
(crisi permettendo).


 (crisi permettendo).
Un perfetto algoritmo funzionale alla Lisp :-)

 "scelgo j2ee."
Non dimenticare che Java (in parte  C) è largamente insegnato nelle
università. Trovi sicuramente tutte le risorse che vuoi. Lisp, Haskell
ecc. no. Java è poi spinto da grandi aziende.
Voglio dire, confrontiamo un mondo grande e diffuso con tecnologie più
particolari, di nicchia. Che non vuol dire per forza inefficienti nei
campi di maggior uso di Java o C.

 Entrambe le risposte sono ugualmente idiote.
Invece il problema sono esattamente le domande che ci si fa. Se non
ti
chiedi mai come migliorare qualcosa e migliorarti, non migliorerai
mai
nulla.
E' tipico di chi non ha fatto esperienze diversificate pensare ai
confronti tra linguaggi/modelli/piattaforme/metodologie e quant'altro
come perdite di tempo e guerre di religione. Niente di più sbagliato e
limitante.
Per dirti, sono stato con un amico che mi ci ha portato ad una
riunione del London Perl Mongers. Per quanto non mi interessi lavorare
in Perl e approfondirlo più di tanto, posso dire che è stata
un'esperienza veramente ganza, ho conosciuto persone anche di una
certa età che sono stati all'epoca un pò pionieri del software sul web
ed altri che mantengono progetti di una certa rilevanza in ambito
bioinformatico. Un paio di persone (a parte la fama che le precedeva)
mi hanno così colpito che se ne sapessi di più di quei domini
applicativi e di quegli strumenti di sicuro gli chiederei lavoro. La
cosa triste, è che quando ne parlo qui con amici e conoscenti mi
guardano come fossi un alieno.


Sono daccordo. La questione è sempre quella economica e di "forza
lavoro", come già altri hanno detto qui. Per un progetto chiamiamolo
"comune, tipico" si cerca la tecnologia che garantisca tanta gente e a
costi il più bassi possibili. E' noto poi come il grosso del lavoro,
la parte critica sarà realizzato dai pochi bravi e più esperti.
E' per questo che, come tanti, sostengo ci si deva specializzare tanto
in ambito di dominio quanto in quello degli strumenti. Ed è questo che
quelli che parlano a sproposito di "equivalenza" tra soluzioni
tecniche non capiscono. Non essendosi mai cimentati in altro (perchè
spesso non ne hanno avuto la possibilità, in Italia ma anche altrove
eh...) non si rendono conto che per certe categorie di problemi, così
come esistono strutture dati e relativi algoritmi e/o patterns più
adeguati, così esistono linguaggi/strumenti e processi che fanno fanno
la differenza in termini di qualità del codice, tempi di sviluppo,
chiarezza e manutenibilità e chi più ne ha più ne metta.
Non è questione di chiacchiere o pareri, è che se non ne hai
esperienza non ce l'hai e morta li.

 riunione del London Perl Mongers. ..
Anni fa sono per caso capitato in un pub sul Tamigi dove stavano
facendo un social, uno spasso :)
--
ale
http://ale.riolo.co.uk

 campi di maggior uso di Java o C.
Infatti io non dico che siano inefficienti ne' peggio degli
altri.
Ma nemmeno piu' efficienti e migliori. 
Semplicemnte piu' o meno equivalenti
Ciao,
Marco.


 guardano come fossi un alieno.
Io ho partecipato a 2 python conference italiane su 3 (e specialmente
la prima mi piacque molto...)  ma non posso ignorare quello che vedo
ormai da oltre un decennio.
Ciao,
Marco.


 tecniche non capiscono.
L'equivalenza è una bufala anche per me. Per ogni problema ci vuole lo
strumento più adatto. D'altronde se certi linguaggi non si usano
praticamente mai per fare determinate cose, allora è impossibile dire
che sono equivalenti. Non c'è prova di questo, nè in bene nè in male.

 Semplicemnte piu' o meno equivalenti
Non sono d'accordo. C'è un abisso tra certe categorie di linguaggi per
fare certe cose.
Pensa scrivere un driver di periferica in Cobol o Java invece che C...
Ogni linguaggio sa fare benissimo certe cose, male certe altre, altre
non le fa proprio. Per ragioni a volte legate all'implementazione più
che al linguaggio (es. il terrificante binomio Java server side-
Javascript client side!!)

 .. Io sono sempre un poco critico verso il mondo estero, ma non toccatemi ..
Io non capisco perché tu ti debba limitare ad essere critico verso il
mondo estero, quando di occasioni di essere critici verso il sistema
paese della RI ce ne sono a bizzeffe, a mai finire per un comune
mortale direi.
BTW, delle 4 che citi, per 2 ci ho sviluppato e/o fatto assistenza su
software (web services, oracle, reportistica, bug fixing, più una cosa
un po più complessa), per un totale complessivo di qualche mese di
lavoro. Secondo te, lavorando nella RI, mi sarebbe mai capitato?
--
ale
http://ale.riolo.co.uk

 lavoro. Secondo te, lavorando nella RI, mi sarebbe mai capitato?
Penso di sì, ci sono numerose università, enti ed altro che
collaborano con la Nasa, per esempio.
Certo il numero totale dei coinvolti non è alto, quindi la probabilità
è molto minore.

 ormai da oltre un decennio.
Vedi, quello che alla fine è alla base del mio discorso è che in
Italia la media è di lavori di <beep> con poche eccezioni (alcune
delle quali, per me, sono tra le aziende che sponsorizzano il Pycon
italiano) mentre altrove ho trovano la situazione completamente
capovolta, sia in termini contrattuali che pratico/tecnologici/
culturali.
Ad un certo punto, ad ognuno il suo. Nel senso, ognuno fa le sue
scelte e si accontenta o meno di quello che riesce a trovare. Però,
per favore, non confondiamo la realtà lavorativa italiana con la
produttività tra linguaggi di programmazione ;).

 facendo un social, uno spasso :)
Si, direi che la concentrazione di tipi eccentrici è piuttosto alta
li :)

 per diversi motivi.
Aspetta, avevo letto male di algoritmi *diversi*: non tener conto di
quello che ho scritto al riguardo.

 tra tabelle :)
E mica lo so se è un bene..

 li :)
alcuni sono anche qui ... avete mai visto Marco Belinaso dal vivo ?
;-)

 
Il problema invece è la domanda.
"è meglio C++ o Lisp?" non significa nulla, la domanda corretta è
"è meglio C++ o Lisp per il progetto X?"
Comunque i linguaggi non sono tutti uguali, e ci sono linguaggi 
progettati meglio di altri.
Ciao  Manlio

 guardano come fossi un alieno.
Non saranno famosi come gli amici londinesi ma, se ti interessa, di 
mongers (bravi) ce ne sono anche qui da noi:
http://www.pm.org/groups/europe.html
Il gruppo pi� vicino a te � quello di Roma, temo:
http://roma.pm.org/
(frequentato anche da qualche napoletano).

 (frequentato anche da qualche napoletano).
Conosco, anche se non è ambiente mio come dicevo e comunque Michele
Beltrame è ben noto anche a Londra :).
Più che famosi loro, è il mercato che permette loro di lavorare a cose
interessanti e con continuità. Insomma, è la possibilità di fare
esperienze molto significative che li contraddistingue dagli italiani,
secondo me.