[Python] Python vs UML

[Enrico Franchi]

On Feb 6, 2008, at 5:21 PM, Java wrote:

>> Non mi pare di avere letto alcuna di queste mail.
>> Ad ogni modo sono sicuro che portando anche la tua esperienza non  
>> puoi
>> che alzare il livello della discussione.
>>
> La mia esperienza è quella espressa all'inizio.

Io avevo chiesto anche un'altra cosa, in effetti.

> Non esiste dire che l'UML fa schifo. Come non ha senso dire Java fa  
> schifo, Perl fa schifo,
> il minestrone fa schifo.

E' una posizione 'strana'. In primo luogo sono perfettamente convinto  
che qualcuno che lavora nell'IT abbia tutto il diritto di farsi la sua  
idea su una data tecnologia/metodologia. Questo a prescindere dal  
fatto che abbia o meno ragione.

Non solo: qualcuno che lavora nell'IT ha spesso il *dovere* di farsi  
un'idea su una data tecnologia. Che può anche essere 'fa schifo'. Non  
è che tutto deve essere 'buono' o 'buonino'. Poi possiamo intenderci  
sulla terminologia; forse 'fa schifo suona male', ma non è che usando  
giri di parole si cambi la realtà dei fatti. Si, certo, forse si è  
meno estremi e tutto.

Perchè vedi in questo relativismo in cui il 'fa schifo' non esiste,  
non può esistere neppure il 'è fatto bene'. Per cui sospendiamo il  
giudizio e... cosa decidiamo?

Forse vogliamo contestualizzare tutto: non diciamo che Java fa schifo;  
diciamo che richiede hardware classe enterprise[0] per fare quasi  
qualunque cosa non banale e che è circa 3 volte meno produttivo di  
Ruby/Python? Wow, così suona molto più pro. Ma se leggi fra le righe  
cosa ho detto? Che fa schifo. Nota, poi posso anche sbagliare, ma sono  
semplicemente stato esplicito sulle ragioni per cui non mi piace  
(esempio), invece che dare la versione corta.

----
[0]: no, non è il vecchio discorso del 'è lento', è il discorso 'ha  
una gestione della ram allucinante'.

> 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.

E quindi? Ho anche scritto una piccola libc in asm, ma non per questo  
direi che è sensato farlo (a meno che -- apresi dibattito su embedded  
etc etc etc).

> 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.

Ugh? Ma qui siamo all'assurdo! Fai dell'UML per il codice praticamente  
macchina del controller del braccio e tutto?
Quello è un tipico caso in cui UML serve a *molto* poco; tipicamente  
non starai nemmeno usando un linguaggio ad oggetti, figuriamoci.

Non so chi ti ha dato l'idea del 'codice critico -> UML', ma questa è  
*totalmente* sbagliata, a prescindere da quello che pensi di UML. UML  
ha un'altra funzione. E' un linguaggio di *modellazione*: quando hai  
un problema che *non* richiede modellizzazione, *sicuramente* è lo  
strumento sbagliato.

E scrivere il codice che sopra dicevi ha bisogno di verifiche formali,  
test molto accurati, whatever. Non di 'modellazione'. Anche perchè  
quello che fa il braccio, dipende anche e in buona parte  
dall'hardware, il come lo fa, etc etc etc.


> 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."

Ma mi chiedo che accidenti di esempi fai. Questa è roba che è grazia  
ricevuta se ti lasciano usare il C.
Sempre ammesso che non sia fatto direttamente con una rete logica +  
eventualmente un po' di microcodice.

Sempre tipicamente, questa roba la modelli in verilog etc

> Capo: "Col cazzo, eccoti gli schemini UML. Tu devi estendere la classe
> "Vibro" implementando qualcosa per la regolazione dell'intensità"

ROTFL. Immagino ci sarà la manovella che chiama setIntensity. Non ho  
parole.

> 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.
>
> 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.

Ah. Ed è necessario l'UML. Faccio notare che se ti schianta una roba  
del genere, è per i *parametri* e l'*intensità*, non per il design.
Ammesso che ci sia design.

Che so, hai presente il software per avionica? (tipo quello che fa  
abbattere l'arianne 5?).

Ti assicuro che è *molto* diverso dal codice che vedi normalmente. E  
tipicamente hanno procedure iper-standardizzate e *molto* più strette  
di UP/RUP e whatever. D'altra parte la questione 'costi' è totalmente  
differente. E' un modo piuttosto differente *sia* dal software  
applicativo 'desktop' sia dalle infrastrutture di rete (dove la  
sicurezza dall'esterno è un problema molto più rilevante), sia da tool  
specifici (ottimizzatori di query, database systems, ottimizzatori di  
compilatori), sia da oggetti come il kernel di un sistema operativo  
general purpose.