Newsgroup: it.scienza.informatica
Titolo: Programmazione 'artigianale'

Negli anni Cinquanta-Sessanta, agli albori dell'informatica, si programmava
in maniera 'empirica'?
Qualcuno vuole discutere con me su come oggi possiamo venire influenzati da
questo modo di fare?
Certo, ho letto recentemente "Principi di ingegneria del software" :-)
Ciao
Michele

 Certo, ho letto recentemente "Principi di ingegneria del software" :-)
La produzione di software non e' ingegnerizzabile, poiche', assunta vera
la tesi di Church--Turing, il software non e' collaudabile!!!!!!!
E' come se l' ing. edile non avesse l' equaz. della trave per prevedere
qual'e' la sua portata ma dovesse andare ad occhio.
Consiglio:
Leggiti anche qualche libro sulla teoria degli algoritmi e della
decidibilita'
scoprirai che il termine stesso di "ingegneria informatica" e'
privo di significato.
--
Saluti,
 
cibe...@libero.it

 la tesi di Church--Turing, il software non e' collaudabile!!!!!!!
Beh, non esageriamo.
E' pur vero che, in virtù del teorema che citi, non esiste una "formula di
correttezza" per i programmi, ma è anche vero che alcuni metodi di procedere
sono migliori di altri.
Che questo sia vero perchè verificato sperimentalmente o perchè esista un
teorema, poco cambia in pratica.
Di sicuro, procedere alla cieca porta molto spesso a risultati catastrofici,
come se l'ingegnere costruisse la casa senza aver nessun progetto, dicendo
ad occhio: "adesso mettete una trave qui, l'altra là, quel muro è crollato,
allora ci piazziamo un tirante da quella parte, ecc.".
--
Alessandro Monti

la tesi di Church--Turing, il software non e' collaudabile!!!!!!!
Dai ciberneta non mi demolire cosi' l'Ingegneria del software che poi
il mio docente di "Ingebgneria del Software" appunto ci painbge :-))))
Augusto Pucci
Webmaster di Prospektiva On-line
http://go.to/Prospektiva

 privo di significato.
Balle. Il fatto che ci siano dei limiti a quello che si può fare
(indecidibilità) non significa che tutto sia impossibile. Non so perché, e
non so se è il tuo caso, ma molta gente si fa facilmente impressionare dai
risultati teorici di indecidibilità, quando nella pratica hanno un impatto
assolutamente nullo. Tanto più se si pensa che il primo limite che si può
incontrare praticamente non è l' indecidibilità ma è la complessità
computazionale e ancora prima l' efficienza computazionale. Può benissimo
capitare che un problema teoricamente indecidibile si possa risolvere
facilmente risolvere con un programma "reale" restringendo un po' la classe
di problemi a cui si applica, mentre un problema teoricamente "facile", per
esempio uno con complessità lineare, non possa essere risolto praticamente
per limiti tecnologici o per una cattica implementazione del programma
(ovvero per una cattiva ingegnerizzazione del software...)
Comunque, per confermare che, in genere, chi tira in ballo i problemi
teorici di decibilità in questioni di ingegneria del software, non ha ben
chiaro i termini della questione,  ti faccio sapere che problemi
riguardanti i programmi che possono girare sul computer che sto usando in
questo momento, sono tutti decidibili, ma questo non facilita il lavoro di
chi deve progettare i programmi che userò!

 chi deve progettare i programmi che userò!
LOL
Allora e' vera quella barzelleta sugli ingegneri informatici che sono
convinti
che un algoritmo debba sempre terminare!
\mode{humor}[off]
ESEMPIO semplice semplice per capire che sul software si puo' dire tutto
tranne che e' ingegnerizzabile.
Consideriamo l' ing. edile: non ha l' algoritmo che gli dice come
progettare una casa ma ha l' equazione della trave che gli permette
di DECIDERE per TUTTE le travi se soddisfano i requisiti richiesti.
L' informatico come l' ing.edile non ha l' algoritmo di come risolvere
un problema assegnato ma in piu' NON ha neanche l' equazione (o l'
algoritmo)
per DECIDERE per TUTTE le procedure se eseguono il compito
per cui sono state ideate.
Per ogn'una di queste l'informatico potrebbe o dovrebbe inventersi una
dimostrazione ad hoc per provarne la validita'.
Va da se' che cio' non viene (quasi) mai fatto per evidenti problemi
di economicita' della produzione del software.
Riassunto:
Non esiste una procedura UNIFORME che permetta di colladare
ogni procedura, quindi la produzione del software e' una
PRODUZIONE ARTIGIANALE e non ingegneristica!
--
Saluti,
 
cibe...@libero.it
--
_________________________________
Mensch ist Automat !
Kybernetik uber alles !!!
_________________________________

 PRODUZIONE ARTIGIANALE e non ingegneristica!
Ti ripeto quello che ho scritto alla fine del mio precedente messaggio:
Tutti i problemi riguardanti le procedure che possono essere eseguite sul
mio calcolatore (dico mio, per indicare un qualsiasi calcolatore reale)
sono decidibili (compresi quindi la terminazione, la correttezza ecc.).
Hai riflettuto su questa affermazione? Mi pare di no, perché l' hai
ignorata; ti lascio quindi rifletterci un po' prima di spiegarla
ulteriormente e di fare qualche commento sul paragone con gli ingegneri
edili :-)
Ciao

 PRODUZIONE ARTIGIANALE e non ingegneristica!
Hai subito centrato quello di cui volevo parlare.
Ora, perchè nonostante questo fatto verificato e innegabile, studiamo
all'università iNgegneria Informatica (con l'N maiuscola)?
Ciao
Michele

che un algoritmo debba sempre terminare!
Bhe per essere definito eventualmente corretto deve terminare si
scusa..altrimenti al massimo puoi dire che 'e parzialmente
corretto..se sono rispettate le specifiche..am non molto di +


 wrote in message 8bsu2l$52a$1...@nslave2.tin.it...

Bellissima domanda!!
La risposta, credo che vada cercata piu'  in motivazioni
politico corporativistiche che di tipo scientifiche.
Ovvero esistendo gia' il cdl in informatica (o scienze delle
informazioni) e quello di ing. elettronica che coprivano
tutto lo spettro dall' hardware al software perche' e'
stato creato il cdl in ing. informatica??
Se per lo meno lo avessero chiamato cdl in
"arte informatica" sarebbe stato piu' onesto!
In fin dei conti da piu' soddisfazione scrivere un algoritmo
(che  quindi e'  una forma d'arte) che non risolvere una
equaz. differenziale.


>
E ti do anche la triste notizia che la quasi totalita' dei prg. per
che si scrivono per il  calcolatore (tuo o mio che sia!) non appartenendo
al dominio del primitivo ricorsivo hanno il problema della
fermata indecidibile!!!
Scusami ma debbo consigliarti nuovamente la lettura di
un testo di teoria della calcolabilita' e decidibilita'
altrimenti continueresti questa discussione affermando
altre falsita'.


 corretto..se sono rispettate le specifiche..am non molto di +
Aaaaaaaaaaaaaaaaaargh!
No! Pucci, da te no!
Pucci perche' mi combini cio'!
:-)))
Controesempio banale:
Realizzare un interprete di un linguaggio di prg. a scelta.
Questo prg. (l'interprete) dovra', per rispettare le specifiche
andare in computazione non terminante quando ha in ingresso
come dati il codice di un prg. che non termina.
In generale ci sono soluzioni di problemi che devono necessariamente
avere algoritmi con domini parziali (ovv. per certi dati devono(!) non
terminare
affinche' siano la soluzione corretta al problema)
