[Python] Python vs UML

[dialtone a divmod.com]

On 6 Feb, 04:21 pm, quilospam a email.it wrote:
>La mia esperienza è quella espressa all'inizio. Non esiste dire che
>l'UML fa schifo. Come non ha senso dire Java fa schifo, Perl fa schifo,
>il minestrone fa schifo. Come già detto ci sono diversi campi di
>applicazione. Personalmente l'ho usato solo *una* volta, e con 
>profitto,
>durante lo svolgimento del tirocinio. Tutte le altre volte (siti web e
>robe del genere) mi sono fatto due pallini a penne in un foglio e ho
>risolto egregiamente.

Non capisco perche` non si possa dire che qualcosa faccia schifo. Magari
non lo faceva quando e` nato ma con l'evoluzione inizia a fare schifo o
a essere inadatto un po' per tutto. D'altronde se pure i Javisti stanno
cercando un sostituto di Java con Scala un motivo ci sara` credo.

Diverso e` il discorso se sia o meno una cosa che fa schifo a te, nel 
senso
che se a te basta Java allora siamo tutti contenti. Ci sono persone a 
cui
Java non piace ma non per partito preso, piuttosto perche` l'hanno 
usato,
poi hanno imparato altri linguaggi e hanno visto che riuscivano ad 
essere
piu` produttivi per fare sostanzialmente qualsiasi cosa e allora la 
conseguenza e` che ad oggi il linguaggio vecchio non sia piu` adatto. 
Poi
si puo` provocare un po' dicendo che fa schifo.
>Qualuno ha fatto notare che "If the implementation is hard to explain,
>it's a bad idea;". Ma purtroppo la mondo esistono cose complicate da
>spiegare a voce e/o con codice vario. Se devo fare un'applicazione che
>regola il braccio meccanico che esegue un'operazione laser sugli occhi,
>l'UML serve.

Diceva Einstein che hai veramente capito una cosa solo quando riesci a
farla capire anche a tua nonna. Devo ancora conoscere un argomento che
non si possa imparare facilmente nel suo concetto. Sono riuscito a 
spiegare
come funziona un JIT a una dottoressa di lingue orientali, penso di 
poter
riuscire a spiegare come funziona un'applicazione che esegue 
l'operazione
laser sugli occhi.

Resta oscuro il motivo per cui UML porterebbe a software piu` robusto e
con meno bachi. Da quando il livello di dettaglio di UML e` tale da 
impedire
i bachi?
>Prima di tutto potrei non sapere che linguaggio di programmazione 
>usare:
>
>Capo:  "Hey tu? Ci serve un programma che permetta di utilizzare questo
>fantastico dispositivo "embeddato" all'interno di un vibratore che
>regoli la frequanza degli impulsi."
>
>Io: "Ah, si ok, in cosa lo scrivo? c, c++ o  turbo pascal?"
>Capo: "Non lo so, non ci è ancora arrivato, però mi assicurano che è a
>oggetti"

E` a oggetti cosa significa? Il vibratore e` un oggetto non e` a 
oggetti.
>Io: "Hey! Ma se non è ancora arrivato come faccio a sviluppare 
>qualcosa?
>Ho il codice?"
>Capo: "Col cazzo, eccoti gli schemini UML. Tu devi estendere la classe
>"Vibro" implementando qualcosa per la regolazione dell'intensità"

Non funziona cosi`... Nei dispositivi embedded ci sono una serie di 
problemi
di basso livello che vanno affrontati altro che UML. Se quando ti arriva
l'amplificatore scopri che invece di 2MB di EPROM ce n'e` solo la meta` 
cosa
fai col codice che hai scritto? Lo butti via, altro che UML. Se quando 
arriva
scopri che non puoi usare glibc (per dire) ma devi usare tiny-libc-from- 
vattelapesca-srl il codice lo puoi buttare via. Se quando arriva... (e 
via dicendo, ci sono un milione di problemi nelle tecnologie
embedded, che mica per niente si chiamano embedded visto che software e
hardware sono mortalmente accoppiati).
>Quindi mooolto prima che inizi l'implementazione, tutti i diagrammi
>vengo analizzati da diverse persone, in diretto rapporto con il
>commitente e con esperti del settore, ad esempio medici e ingegneri
>biomedici. Perciò il progetto subirà  svariate modifiche. Iniziare a
>scrivere codice ora, sarebbe una cosa piuttosto noiosa. Dato che molto
>di esso verrà cancellato e/o profondamente modificato.

E` assurdo ragionare di architettura quando non hai la piu` pallida idea
di quello che potrai farci sull'hardware che ti danno. Nel campo 
embedded
la sperimentazione e` fondamentale, UML non aiuta.

Tanto peggio e` il pensiero di aver realizzato qualcosa avendo scritto 
un
diagramma UML. L'UML e` un disegno, anche quando lo traduci in codice 
hai
solo lo scheletro, nessuna funzionalita` e niente di niente.

Mentre scrivi codice sarai COSTRETTO (perche` capita sempre) a cambiare
architettura e se ogni volta devo tornare a UML l'iterazione inizia a 
impiegare settimane invece che minuti.
>Poi supponiamo che questo software si faccia. E che il braccio 
>meccanico
>regoli male l'intensità del laser decapitando il paziente e 
>distruggendo
>l'intera ala ovest dell'ospedale. Di chi è la colpa?  Si prendono
>specifiche, progetto UML e implementazione. E si controlla se il
>progetto rispetta le specifiche, e se l'implementazione rispetta il
>progetto.

Come fa l'UML a stabilire in che modo viene regolata la potenza del 
laser?

Se nel codice il programmatore ha scritto:

laser.power = input_from_user + MegaWatt(2000)

UML ci puo` fare davvero poco. Detto questo, e anche se la cosa e` nota 
e l'ho ormai ripetuta mille volte, pensare di riuscire a garantire il 
funzionamento
di qualcosa senza aver scritto il codice che la fa funzionare (perche` 
al
massimo UML e` uno scheletro) e` ridicolo e fa a gara con quelli che 
dicono
che la tipizzazione statica aiuta ad evitare gli errori dopo che 
l'ariane
e` esploso a mezz'aria per colpa di una conversione tra numeri.