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. _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
