27 November, 2005
Progettazione galileana
Soprattutto all'interno del paradigma ad oggetti, la fase di design (molto discussa su cui è difficile trovare unanimità sul suo reale significato - può destare meraviglia ma è così), dicevo durante questa fase l'architetto è chiamato ad effettuare scelte e ad applicare regole che molto hanno a che fare con il metodo scientifico preconizzato da Galileo (e Bacone e da tanti altri e sui cui in un prossimo post proverò a dire qualcosa). Vediamo dunque le similitudini di metodo:
Astrazione. Senza andarne a cogliere il significato profondo, per un fisico questo significa far risultare dall'osservazione il passaggio dalla realtà ai simboli attraverso i quali la dominante osservata è quantificata (l'astrazione scorpora l'osservazione dai dettagli ritenuti non essenziali). Analogamente per l'architetto software quei simboli saranno i costrutti UML che nel loro insieme veicolano il significato del sistema (anche l'architetto effettua una scelta determinante nel quantificare gli aspetti essenziali da quelli secondari).
Modello. Dall'astrazione segue per il fisico un modello che semplifica il fenomeno osservato incapsulandolo in un "oggetto" molto più maneggevole e riproducibile su cui fare inferenza. Dall'altra sponda, l'architetto crea modelli software (che semplificando possiamo considerare artefatti molto tangibili) per aiutare a capire e su cui ragionare. Una immediata conseguenza è che si riduce l'ampiezza di indagine e si gestisce la complessità intrinseca in maniera diretta.
Il fisico poi procede alla ricerca di una legge che descriva il fenomeno, per poi passare agli esperimenti per giungere finalmente ad una teoria. Molto meno impegnativamente un architetto è chiamato a generalizzare i risultati - esperienza e sudore - per poter riusare l'esperienza. Questa è un specola di osservazione interessante da cui vedere la nascita dei pattern di design.
Giova sottolineare che sia i contenuti (scontato) sia gli strumenti (scontatissimo) delle due discipline sono assai differenti e a favore degli architetti (non essendo un fisico :)) vedo l'utilizzo facile di UML inteso però come strumento che fa leva sulle umane capacità di "visualizzione" dei concetti.
Certo loro hanno tutta la matematica che li sorregge...
Astrazione. Senza andarne a cogliere il significato profondo, per un fisico questo significa far risultare dall'osservazione il passaggio dalla realtà ai simboli attraverso i quali la dominante osservata è quantificata (l'astrazione scorpora l'osservazione dai dettagli ritenuti non essenziali). Analogamente per l'architetto software quei simboli saranno i costrutti UML che nel loro insieme veicolano il significato del sistema (anche l'architetto effettua una scelta determinante nel quantificare gli aspetti essenziali da quelli secondari).
Modello. Dall'astrazione segue per il fisico un modello che semplifica il fenomeno osservato incapsulandolo in un "oggetto" molto più maneggevole e riproducibile su cui fare inferenza. Dall'altra sponda, l'architetto crea modelli software (che semplificando possiamo considerare artefatti molto tangibili) per aiutare a capire e su cui ragionare. Una immediata conseguenza è che si riduce l'ampiezza di indagine e si gestisce la complessità intrinseca in maniera diretta.
Il fisico poi procede alla ricerca di una legge che descriva il fenomeno, per poi passare agli esperimenti per giungere finalmente ad una teoria. Molto meno impegnativamente un architetto è chiamato a generalizzare i risultati - esperienza e sudore - per poter riusare l'esperienza. Questa è un specola di osservazione interessante da cui vedere la nascita dei pattern di design.
Giova sottolineare che sia i contenuti (scontato) sia gli strumenti (scontatissimo) delle due discipline sono assai differenti e a favore degli architetti (non essendo un fisico :)) vedo l'utilizzo facile di UML inteso però come strumento che fa leva sulle umane capacità di "visualizzione" dei concetti.
Certo loro hanno tutta la matematica che li sorregge...
18 November, 2005
Fuzzimiento
I numerosi ed interessantissimi commenti al post precedente hanno dato un segnale di vivacità e di energia all'argomento. Abbiamo compreso bene le due grandi linee di pensiero che sono emerse, infecondo ora attardarsi sui dettagli, a meno che naturalmente non ci siano elementi di novità.
E' difficile aggiungere qualcosa mi limito solo a ricordare che la logica fuzzy fu strenuamente combattuta da un allievo di Lofti Zadeh (considerato -a ragione?- il padre della logica fuzzy. Un personaggio istrionico e rivoluzionario) ovvero il professore Rudolf Kalman (si, proprio lui, l'inventore del "filtro di Kalman", le cui applicazioni oggigiorno sono sotto gli occhi di tutti seppur inconsapevolmente).
Io sottoscrivo completamente il pensiero di Kalman espresso in presenza di Zadeh nel 1972 ad un convegno tenutosi a Bordeaux:"His [Zadeh] proposals could be severely, ferociously, even brutally criticized from a technical point of view. This would be out of place here. But a blunt question remains: Is Professor Zadeh presenting important ideas or is he indulging in wishful thinking? No doubt Professor Zadeh's enthusiasm for fuzziness has been reinforced by the prevailing climate in the U.S. - one of unprecedented permissiveness. "Fuzzification" is a kind of scientific permissiveness; it tends to result in socially appealing slogans unaccompanied by the discipline of hard scientific work and patient observation."
Anche Kosko è stato allievo di Zadeh e da questo ha ereditato il tipico livore del presuntuoso offeso.
E' difficile aggiungere qualcosa mi limito solo a ricordare che la logica fuzzy fu strenuamente combattuta da un allievo di Lofti Zadeh (considerato -a ragione?- il padre della logica fuzzy. Un personaggio istrionico e rivoluzionario) ovvero il professore Rudolf Kalman (si, proprio lui, l'inventore del "filtro di Kalman", le cui applicazioni oggigiorno sono sotto gli occhi di tutti seppur inconsapevolmente).
Io sottoscrivo completamente il pensiero di Kalman espresso in presenza di Zadeh nel 1972 ad un convegno tenutosi a Bordeaux:"His [Zadeh] proposals could be severely, ferociously, even brutally criticized from a technical point of view. This would be out of place here. But a blunt question remains: Is Professor Zadeh presenting important ideas or is he indulging in wishful thinking? No doubt Professor Zadeh's enthusiasm for fuzziness has been reinforced by the prevailing climate in the U.S. - one of unprecedented permissiveness. "Fuzzification" is a kind of scientific permissiveness; it tends to result in socially appealing slogans unaccompanied by the discipline of hard scientific work and patient observation."
Anche Kosko è stato allievo di Zadeh e da questo ha ereditato il tipico livore del presuntuoso offeso.
Labels: Science
14 November, 2005
Fuzzy vs Aristotele
Tranne rare eccezioni, è difficile trovare serrate critiche al "pensiero" fuzzy (se qualcuno conosce un autore che ha scritto un saggio mirato all'anti-fuzzification è pregato di segnalarmelo). Infatti funziona, ci sono svariate applicazioni fuzzy-based, fuzzy-chip, decision making,...
Si può eventualmente obiettare che funziona perché si tratta della logica aristotelica "sotto mentite spoglie" (sinceramente lo credo anch'io. Ricordo che feci questa obiezione all'esame di AI ma non ci fu nessuna reazione come a dire che solo un pazzo può mettere in discussione i fondamenti della logica fuzzy).
Merito di Bart Kosko (nel suo famoso "Il Fuzzy Pensiero") l'aver messo in evidenza le implicazioni filosofiche di tale teoria (o forse più argutamente le implicazioni tecnico scientifiche di una impostazione filosofica che affonda le sue radici nel pensiero orientale). Per chi non ha letto il libro forse è utile stigmatizzare alcune critiche mosse alla logica occidentale a stampo aristotelica/tomista (un inciso: il libro inizia in maniera assurda:"One day I learned that science was not true". Dico assurdo non partendo assolutamente da una posizione scientista/positivista, anzi):
Si può eventualmente obiettare che funziona perché si tratta della logica aristotelica "sotto mentite spoglie" (sinceramente lo credo anch'io. Ricordo che feci questa obiezione all'esame di AI ma non ci fu nessuna reazione come a dire che solo un pazzo può mettere in discussione i fondamenti della logica fuzzy).
Merito di Bart Kosko (nel suo famoso "Il Fuzzy Pensiero") l'aver messo in evidenza le implicazioni filosofiche di tale teoria (o forse più argutamente le implicazioni tecnico scientifiche di una impostazione filosofica che affonda le sue radici nel pensiero orientale). Per chi non ha letto il libro forse è utile stigmatizzare alcune critiche mosse alla logica occidentale a stampo aristotelica/tomista (un inciso: il libro inizia in maniera assurda:"One day I learned that science was not true". Dico assurdo non partendo assolutamente da una posizione scientista/positivista, anzi):
- L'opzione "vero o falso" è falsa (sic!)
- Tertium datur. La realtà è costellata da sfumature che trovano la loro migliore rappresentazione con una matematica che ha a che fare con il vago. Basta con l'imperativo dicotomico, è la logica polivalente che rappresenta nel modo migliore possibile l'essenza della realtà (alle ortiche il principio di non-contraddizione di Aristotele: "E' impossibile che, per il medesimo rispetto, la stessa cosa sia e non sia")
- Panta rei, tutto scorre. La realtà è un frenetico passaggio dall'essere al non essere. Se date un morso ad una mela vi troverete tra le mani una mela e una non mela. Se la calvizie vi assale sappiate che oltre al danno la beffa consiste nell'essere meno uomini...
- Corollario del punto precedente: non esiste la realtà in sé, tutto è rappresentazione, tutto è questione di misura (variante nominalista nella scienza: non esistono gli universali. La mela in sé è un concetto, non ha né identità né valore)
Senza nascondermi dietro un dito ho comunque provato ad estrarre il succo dalla mela (un pò marcia) del fuzzy pensiero che - su questo saremo d'accordo tutti - non ha nessun carattere di novità.
Ah dimenticavo: il libro è permeato da un risentimento personale verso alcuni colleghi antifuzziani di Kosko che proveremo a inquadrare in un prossimo post.
Labels: Science
06 November, 2005
Tuples
Qualcuno (offline. Vi invito naturalmente a fare uso dei commenti) mi ha chiesto maggiori dettagli sul significato delle tuple (citate nel precedente post).
Dato che ho sottomano Nice provo a dare qualche esempio non prima però di una informale definizione: una tupla può essere vista come un insieme di valori referenziabili tramite un solo tipo. Ad esempio t1=("Tuples", 5, 't') è una tupla del tipo (String,int,char)
Si può dunque avere un metodo che ritorni più valori:
oppure una ricerca che ritorni l'esito e l'eventuale posizione:
Un qualcosa di più interessante sono i slick-iterator (iteratori smart embedded) sulle tuple che combinati con i metodi anonimi (simili alle classi anonime) possono dar vita a codice snello e pulito:
Il codice merita qualche secondo di "osservazione" per superare il gap sintattico ma poi tutto risulta semplice. L'unico punto di attenzione è la definizione "a volo" di un metodo anonimo (tramite l'operatore =>) alla cui destra compare l'implementazione.
Considerazione
A mio avviso Nice è un utile supporto a Java, non credo che farà "tremare" il mercato. E poi, da un altro punto di vista (come riportato anche da Bonniot, l'autore del linguaggio) è vera l'affermazione di Alan J. Perlis (il primo ad essere insignito del Turing Award nel 1966): "A language that doesn't affect the way you think about programming, is not worth knowing."
Dato che ho sottomano Nice provo a dare qualche esempio non prima però di una informale definizione: una tupla può essere vista come un insieme di valori referenziabili tramite un solo tipo. Ad esempio t1=("Tuples", 5, 't') è una tupla del tipo (String
Si può dunque avere un metodo che ritorni più valori:
(int,int) minMax(int x, int y) = x < y ? (x,y) : (y,x); |
oppure una ricerca che ritorni l'esito e l'eventuale posizione:
(boolean,int) search(int[] a, int val) |
Un qualcosa di più interessante sono i slick-iterator (iteratori smart embedded) sulle tuple che combinati con i metodi anonimi (simili alle classi anonime) possono dar vita a codice snello e pulito:
List<(String, String)> tuples = new ArrayList(); |
Il codice merita qualche secondo di "osservazione" per superare il gap sintattico ma poi tutto risulta semplice. L'unico punto di attenzione è la definizione "a volo" di un metodo anonimo (tramite l'operatore =>) alla cui destra compare l'implementazione.
Considerazione
A mio avviso Nice è un utile supporto a Java, non credo che farà "tremare" il mercato. E poi, da un altro punto di vista (come riportato anche da Bonniot, l'autore del linguaggio) è vera l'affermazione di Alan J. Perlis (il primo ad essere insignito del Turing Award nel 1966): "A language that doesn't affect the way you think about programming, is not worth knowing."
Labels: IT
04 November, 2005
Ancora sui linguaggi
A proposto della similitudine di alcuni linguaggi, ne aggiungiamo alla lista altri tre (questi hanno interessanti particolarità):
- Nice, come riportato nel sito "Nice is a new object-oriented programming language based on Java. It incorporates features from functional programming, and puts into practice state-of-the-art results from academic research. Among the advanced features: parametric types, anonymous functions, multi-methods, tuples, optional parameters to methods, design by contract, detection of many errors during compilation (in particular, concerning casts and null references). This results in more expressivity, modularity, and type safety."
- D, come riportato nel sito "D was conceived in December 1999 by Walter Bright as a reengineering of C and C++, and has grown and evolved with helpful suggestions and critiques by friends and colleagues."
- C Omega, di casa Microsoft che si basa su C# (sbilanciato verso la concorrenza ed un intelligente accesso ai dati)
Difficile mettere questi linguaggi (e C/C++/C#, Java) in coordinate ortogonali...la cosa più semplice è provare ad "ortogonalizzare" la caratteristica dominante in ognuno di essi. Se questo esercizio sarà risolto emergerà lo specifico (=identità, particolarità, valore) di ognuno di essi.
Labels: IT
01 November, 2005
Agileft
Ho una marcata tendenza a relazionare tutto (quel poco) che conosco. Generalmente mi giustifico (e quando ci riesco?) in questo modo con chi continuamente mi fa notare la mia abilità di "buttarla sempre in politica" anche quando si parla di informatica (e qualche post ha già evidenziato questa che molti considerano una tara...bah).
Dunque, i metodi agili sono di sinistra? Autorevolmente Zio Bob esprime una sua opinione attraverso un simpatico episodio (ha un blog per parlare di politica). Non è affatto un caso isolato, anzi.
Io sono fermamente convinto che moltissime mode, tendenze, filosofie (non parlo innanzitutto di persone) che ci coinvolgono giornalmente nel nostro lavoro hanno una forte relazione con le idee politiche, e questo non è un male in sé...è quando tutto questo diventa volutamente implicito che si abusa di ipocrisia.
Dunque, i metodi agili sono di sinistra? Autorevolmente Zio Bob esprime una sua opinione attraverso un simpatico episodio (ha un blog per parlare di politica). Non è affatto un caso isolato, anzi.
Io sono fermamente convinto che moltissime mode, tendenze, filosofie (non parlo innanzitutto di persone) che ci coinvolgono giornalmente nel nostro lavoro hanno una forte relazione con le idee politiche, e questo non è un male in sé...è quando tutto questo diventa volutamente implicito che si abusa di ipocrisia.
Labels: IT
