View Full Version : [Vari] Critica alla programmazione ad oggetti.
Vi propongo un articolo interessante di Joe Armstrong (l'autore del linguaggio funzionale Erlang) che critica aspramente la programmazione ad oggetti.
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
Che ne pensate?
cdimauro
11-03-2009, 20:43
Vabbé, ma che t'aspettavi da uno che ha scritto un linguaggio puramente funzionale?
Bullshits.
Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds.
Chi diamine lo ha detto?
So I can't find all the data type definition in one place.
Si chiama incapsulamento ed è uno dei principali vantaggi dei linguaggi OO.
In an OOPL I have to choose some base object in which I will define the ubiquitous data structure
unicamente se non hai capito nulla dell'OO :doh:
Reason 1 - It was thought to be easy to learn.
Reason 2 - It was thought to make code reuse easier.
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.
I see no evidence of 1 and 2
La 1 e la 2 la vedo ovunque, in qualsiasi SDK mi sia stato dato usare. Non solo, la 2 con l'OOP ha una cifra di nuove possibilità.
In finale mi sembra il rant di uno che l'OO non ha manco capito da che parte si guarda, e fortuna che ha scritto un linguaggio. :doh:
Deve essere un po' frustrato perché dopo venti anni di sviluppo il suo linguaggio non ha ancora avuto il successo che sperava mentre la programmazione ad oggetti ha semplicemente conquistato tutti.
~FullSyst3m~
11-03-2009, 22:40
Ma la domanda è: in quale secolo ha iniziato a scrivere questo linguaggio? :D
Ecco i traumi che ti segnano per tutta la vita. Stai chiuso in una cantina a pane e acqua a programmare per due secoli, e quando esci scopri che c'è una cosa chiamata OO e non potendola uccidere se la prende con chiunque abbia anche una sola O nel proprio nome :asd:
Ma la domanda è: in quale secolo ha iniziato a scrivere questo linguaggio? :D
Fine ani ottanta. Quindi tecnicamente ha cominciato lo scorso millennio :asd:
~FullSyst3m~
11-03-2009, 22:55
Fine ani ottanta. Quindi tecnicamente ha cominciato lo scorso millennio :asd:
:rotfl:
Non sono d'accordo con quando ha scritto Armstrong anche se penso che i linguaggi funzionali meriterebbero maggior spazio.
Erlang in particolare sembra molto interessante sopratutto per la programmazione concorrente.
Facebook per la sua chat ha utilizzato appunto erlang e sono stati effettuati dei test in cui Yaws (web server scritto in erlang) ha surclassato apache.
http://www.sics.se/~joe/apachevsyaws.html
Ci sono anche dei framework per il web in erlang:
http://erlyweb.org/
Riguardo all'ultimo link: non dimostra certo che un linguaggio funzionale è migliore degli altri...al massimo dimostra che yaws sotto questo aspetto è migliore di Apache.
Magari quel test è stato creato appositamente per mettere in difficoltà Apache...è un po' strano come test...la richiesta GET viene inviata un carattere al secondo...quando mai succede ? Al massimo è un attacco DOS per Apache.
Riguardo all'ultimo link: non dimostra certo che un linguaggio funzionale è migliore degli altri...al massimo dimostra che yaws sotto questo aspetto è migliore di Apache.
Magari quel test è stato creato appositamente per mettere in difficoltà Apache...è un po' strano come test...la richiesta GET viene inviata un carattere al secondo...quando mai succede ? Al massimo è un attacco DOS per Apache.
Sono d'accordo sul fatto che il test sia un pò strano ma penso che l'ottimo risultato di yaws sia dovuto al modello di gestione dei processi di Erlang, non a YAWS.
Ecco qualche articolo interessante:
http://queue.acm.org/detail.cfm?id=1454463
http://gigaom.com/2007/12/19/erlang-a-new-way-to-program-thats-20-years-old/
Ma facciamo un test di carico serio e vediamo se la differenza sta ancora in questi termini, andando a vedere il tempo medio di esecuzione delle richieste.
Sicuramente l'unica cosa che suggerisce quel test è un modo per fare un DDoS ad Apache :D
Ma facciamo un test di carico serio e vediamo se la differenza sta ancora in questi termini, andando a vedere il tempo medio di esecuzione delle richieste.
Non c'è bisogno di farlo! Sappiamo entrambi la risposta.:D
Ciò non toglie che Erlang sia interessante sotto alcuni aspetti.
Ecco cosa ne pensano gli sviluppatori di facebook:
http://www.facebook.com/notes.php?id=9445547199
The channel servers are the most intricate piece of the backend. They're responsible for queuing a given user's messages and pushing them to their web browser via HTTP. We made an early decision to write the channel servers in Erlang. The language itself has many pros and cons, but we chose Erlang to power Chat because its model lends itself well to concurrent, distributed, and robust programming. It's easy to model our millions of concurrent users with a few lightweight processes each, where the same tactic in, say, C++ would have been more daunting. Programming languages are always a tradeoff; Erlang makes some hard things easy but, unfortunately, some easy things hard.
sottovento
12-03-2009, 05:47
Vi propongo un articolo interessante di Joe Armstrong (l'autore del linguaggio funzionale Erlang) che critica aspramente la programmazione ad oggetti.
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
Che ne pensate?
Ne penso bene, mi trovo fondamentalmente d'accordo. E' forse un po' tiepido.
Penso che attualmente la programmazione ad oggetti sia ultra utilizzata (spesso a sproposito) e che sia ritenuta il non-plus-ultra. Non sono cosi' intelligente per poter fornire un'alternativa, ma sono sicuro che un'alternativa migliore esista. E se non esiste, i tempi sono maturi per trovarla.
D'altronde, la scienza (anche l'informatica) e' sempre progredita mettendo in discussione (spesso asserendo addirittura il contrario) i principi che venivano ritenuti assodati, no?
Forse l'articolo riporta troppo poche motivazioni. E' facile trovare altre motivazioni sul fatto che la programmazione ad oggetti abbia dei limiti e che sia ora di trovare qualcosa di meglio:
1 - result = sin(a) * b + c;
result = Math.Add (Math.Times (Math.Trig.sin(a), b), c);
Quale dei due e' piu' semplice? (NOTA - So benissimo che in C++/Java/... posso scrivere entrambe, e' un esempio per rendere l'idea). Quale delle due e' da considerarsi object-oriented?
2 - In questo forum vengono molto frequentemente postati dei messaggi di persone che vogliono imparare a programmare.
Sintetizzando, le risposte sono del tipo: "Impara a programmare con le procedure e poi passa alle classi".
Perche'? Sempre nelle stesse risposte si dice che la programmazione ad oggetti e' piu' naturale! Allora, perche' non si parte ad imparare le basi della programmazione ad oggetti, lasciando per ultima la programmazione piu' difficile?
3 - Quando si usano i linguaggi ad oggetti, si tende a modellare tutto con classi, cioe' "proprieta'" e "metodi" o "messaggi". Questo e' piu' naturale?
Per esempio:
Bicchiere bicchiere;
bicchiere.riempi (acqua);
Cosa c'e' di naturale di un bicchiere che si auto-riempie di acqua? NOTA - non e' un esempio forzato, succede tantissime volte in tutti i software che mi e' capitato di vedere in 20 anni di programmazione: gli oggetti che subiscono l'azione diventano gli attori della stessa.
Comunque, se si preferisce:
Bicchiere bicchiere;
Acqua acqua;
acqua.riempi (bicchiere);
Sembra piu' naturale? Meno male che l'acqua ha un metodo per riempire il bicchiere ;)
4 - Perche' lo stesso bicchiere deve ereditare dalla classe Oggetti? E dalla classe Vetro? Cosa c'e' di naturale in questo? Perche' mi devo portare dietro dei "Metodi/Messaggi" che non mi serviranno a niente, visto che il mio programma usera' il bicchiere per bere l'acqua?
5 - La OOP funziona bene quando e' chiaro cosa deve FARE la classe. Assume che la classe sia un modello di qualcosa che l'utente della stessa conosce gia', nella realta'.
Per esempio, ho appena trovato una classe (in un software scritto da altri) di questo tipo:
class ModelizePlantWithEdgerWithoutL3System: public ModelizePlantWithEdgerOnDownstream
{
....
};
Ritengo di essere del settore (a cui questo software si riferisce), ma credetemi o meno non so come usare la classe!!
Riassumendo: se scrivi una classe che si chiama complex_number probabilmente tutti riescono ad usarla. Quando le cose diventano piu' complesse, siccome la classe si basa sulla conoscenza personale (del singolo programmatore) utilizzare la classe non e' piu' cosi' immediato.
Questo vale a maggior ragione quando la classe ha uno stato, e che obbliga lo sviluppatore a chiamare i metodi in sequenze ben determinate. Ma gli oggetti hanno per forza uno stato!
Nella azienda dove lavoro, si e' riscontrato che l'inserimento di nuovo personale nei progetti esistenti richiede un tempo di training maggiore di qualche anno fa. Domanda: non si dovevano ridurre, questi tempi?
6 - Sempre per il motivo 5, se non e' chiaro cosa deve fare le classe, l'ereditarieta' non fa altro che peggiorare le cose. E' come se il famoso INCAPSULAMENTO (inteso come dati e algoritmi nella stessa classe, i.e. nello stesso posto) venisse a mancare. In sostanza, non sai piu' dove andare a trovare le cose. Dov'e' il metodo che fa questo? Ed il metodo che fa quello? Apri la classe corrispondente all'oggetto con il metodo bacato, ma non lo trovi! Allora devi "risalire la china" delle ereditarieta', sperando di trovarlo.
Lasciamo ovviamente stare il costrutto friend, perche' ho voglia di piangere.
7 - Quando il software comincia a crescere, hai bisogno di un valido software per la documentazione automatica e la ricerca dei metodi. Purtroppo quando si comincia ad usare PESANTEMENTE il polimorfismo, potresti perdere giorni a cercare qual e' esattamente il metodo che viene eseguito ad una determinata condizione. Sto ovviamente parlando di software di milioni di righe, ma e' pur vero che in programmi con programmazione tradizionale NON perdevo quel tempo per cercare cosa succede, anche se il codice risultante era meno elegante (magari sequenze di switch()).
Con l'arrivo della programmazione ad oggetti, e' arrivata anche una serie di nuovi tool di cui prima non si sentiva l'esigenza. Ora sul muro del laboratorio c'e' un grande poster che descrive il diagramma delle classi, tanto per dare un'idea di cosa succede, ed abbiamo un software da 2000$ (per ogni PC) per tener aggiornato il progetto.
Intendiamoci: e' anche vero che il software e' cresciuto nelle dimensioni. Pero' e' anche vero che per poter avere un'idea di cosa sta succedendo si ha bisogno di altri tool, piu' potenti. Anche il semplice editor ti deve ora mostrare la lista dei metodi disponibili per oggetto, e spesso scrivere un programma significa scandire questa lista, alla ricerca del metodo "giusto" (cioe' che "suona" bene). Purtroppo di metodi che suonano "giusti" ce ne sono sempre 3 o 4...
Domanda: come sarebbe la produttivita' in generale senza questi tool? Per ogni metodo si dovrebbe andare a scorrere la documentazione?
8 - Le eccezioni!!! Basandosi su quanto viene affermato anche in comp.lang.c++.moderated (oppure basta leggere "Exceptional C++" del mitico Herb Sutter), ben pochi programmatori hanno capito fino in fondo cosa significa utilizzare le eccezioni (il sottoscritto si ritiene incluso nella lista degli ignoranti). Gli esempi che riporta sono a dir poco illuminanti.
Scrivere codice SICURO rispetto alle eccezioni e' un'impresa non da poco, nonostante tutti si dichiarino ben preparati nel loro uso.
Inoltre, se pensiamo che erano nate per evitare di mischiare il normale flusso di esecuzione dal flusso di esecuzione degli errori, mi viene quasi da piangere: nel codice che ho potuto vedere in questi anni, questo obiettivo non e' stato mai raggiunto. Altro che naturale!!!
In piu', con le eccezioni si doveva eliminare una volta per tutte il blind faith. Ho bisogno di aggiungere altro?
Forse si: qualcosa sulla propagazione delle eccezioni. Fino a quando deve essere propagata un'eccezione? Qual e' il giusto livello per catturarla in maniera efficiente?
In pratica, nella maggior parte del codice che ho visto:
- non si catturano eccezioni importanti ed il programma termina quando vengono sollevate;
- si catturano subito e si riporta un codice di errore (ORRORE! Non eravamo tutti orientati agli oggetti?)
- si catturano e si tappano con un orrendo catch (...).
E se l'eccezione e' riportata da una libreria che hai acquistato, e che magari e' carente nella documentazione? (quale documentazione riporta le eccezioni, e soprattutto, chi le legge?).
In piu', le eccezioni possono generare un sacco di problemi molto carini. Per esempio, sempre leggendo comp.lang.c++.moderated si puo' scoprire che il seguente codice:
MyObject *vect = new MyObject[100];
-- qui usiamo questo vettore, poi:
delete[] vect;
puo' generare dei memory leak ASSOLUTAMENTE NON ELIMINABILI. Quale istruzione genera il memory leak? Ovviamente delete[] vect!!!!
9 - Qualcuno vocifera che se la parte pubblica di una classe non cambia e si cambia solo la parte privata, basta ricompilare
il sorgente della classe e linkare al resto. BALLE. Non per nulla, si sono disegnate architetture (che, fra l'altro, trovo molto eleganti) come COM anche per ovviare a questo.
Esempio:
MyObject *pObject = new MyObject;
Prova a NON ricompilare questa istruzione nel tuo codice che usa l'oggetto MyObject.
In sostanza: cambi la parte privata? Prego, ricompila anche il tuo codice sorgente esattamente come facevi prima. Ci impieghi ore? Ce ne impiegavi anche prima, no?
10 - Ultima parola sul polimorfismo. Altra arma a doppio taglio, visto che non si puo' usare con i vettori! Chi sa cosa succede usando un vettore di oggetti polimorfici? Nessuno! Per fortuna non e' un errore molto comune nel software che mi e' capitato di vedere.
Disclaimer: ovviamente queste sono opinioni personali (piu' qualche *vera* dimostrazione). Anche l'autore dell'articolo in questione afferma che parlare male della programmazione Object Oriented e' come "swearing in church". Comunque non ritengo offensiva nessuna affermazione ho riportato a favore della mia tesi.
Inoltre, come la maggior parte di voi, per portare il pane a casa PROGRAMMO, e lo faccio usando linguaggi orientati agli oggetti...
Mi sembra (opinione personale) che il numero di articoli contro l'OOP sia cresciuto parecchio in quest'ultimo anno. E' ora di preparare la "revolucion" ;)
D'altronde non siete stanchi di usare ancora le stesse cose e riparare sempre gli stessi errori? Se qualcuno comincia a criticare lo stato delle cose, e' il benvenuto! E' il primo passo per tirar fuori qualcosa di nuovo...
cdimauro
12-03-2009, 08:43
1) result = a.sin() * b + c # Questo è object oriented. :D
2) Non ho trovato finora un testo introduttivo alla programmazione che parta dalla programmazione a oggetti. Purtroppo la tendenza di chi fa informazione a livello divulgativo/scolastico è a introdurla dopo quella strutturata. Il che non significa che non sia adatta per partire con la programmazione. Forse qualche tutorial su SmallTalk affronta il problema da questo punto di vista.
3) "si tende", non significa che bisogna strafare.
4) la classe Object mette a disposizione diversi metodi di carattere generale che sono mediamente utili. Poi è ovvio che puoi scrivere applicazioni che non li usano.
Il discorso è esattamente lo stesso delle funzioni built-in disponibili nei linguaggi funzionali: perché metterle nel namespace condviso, anche se non servono? Dovrebbero essere importate soltanto all'occorrenza. Lo si fa proprio perché si tratta di funzioni mediamente utili.
5) Se la OOP viene usata male non è "colpa sua".
6) Questo capita anche coi paradigmi strutturati e funzionali, dove andare a trovare una funziona "scognita" può essere un'impresa. Dipende, al solito, da come si strutturano le cose.
7) Qui può aiutare l'approccio test driven, che tra l'altro "autodocumenta" il codice. Ma vale anche per gli altri paradigmi.
8) Le eccezioni non fanno parte del paradigma OOP: le si può introdurre anche negli altri.
9) Con Delphi non m'è mai capito di dover ricompilare un'applicazione soltanto perché ho cambiato l'implementazione di una classe. Inoltre è in grado di compilare sorgenti da un milione di righe di codice in pochi secondi (grazie alla struttura del linguaggio, che è modulare e richiede una sola passata).
10) Questo dipende dal tipo di linguaggio. Con Python, dove qualunque cosa è un oggetto, posso crearmi una sottoclasse di Tuple o List e ridefinire qualunque loro metodo, se è utile.
P.S. Anche le mie sono opinioni personali. :)
Ne penso bene, mi trovo fondamentalmente d'accordo. E' forse un po' tiepido.
Penso che attualmente la programmazione ad oggetti sia ultra utilizzata (spesso a sproposito) e che sia ritenuta il non-plus-ultra. Non sono cosi' intelligente per poter fornire un'alternativa, ma sono sicuro che un'alternativa migliore esista. E se non esiste, i tempi sono maturi per trovarla.
D'altronde, la scienza (anche l'informatica) e' sempre progredita mettendo in discussione (spesso asserendo addirittura il contrario) i principi che venivano ritenuti assodati, no?
Forse l'articolo riporta troppo poche motivazioni. E' facile trovare altre motivazioni sul fatto che la programmazione ad oggetti abbia dei limiti e che sia ora di trovare qualcosa di meglio:
1 - result = sin(a) * b + c;
result = Math.Add (Math.Times (Math.Trig.sin(a), b), c);
Quale dei due e' piu' semplice? (NOTA - So benissimo che in C++/Java/... posso scrivere entrambe, e' un esempio per rendere l'idea). Quale delle due e' da considerarsi object-oriented?
2 - In questo forum vengono molto frequentemente postati dei messaggi di persone che vogliono imparare a programmare.
Sintetizzando, le risposte sono del tipo: "Impara a programmare con le procedure e poi passa alle classi".
Perche'? Sempre nelle stesse risposte si dice che la programmazione ad oggetti e' piu' naturale! Allora, perche' non si parte ad imparare le basi della programmazione ad oggetti, lasciando per ultima la programmazione piu' difficile?
3 - Quando si usano i linguaggi ad oggetti, si tende a modellare tutto con classi, cioe' "proprieta'" e "metodi" o "messaggi". Questo e' piu' naturale?
Per esempio:
Bicchiere bicchiere;
bicchiere.riempi (acqua);
Cosa c'e' di naturale di un bicchiere che si auto-riempie di acqua? NOTA - non e' un esempio forzato, succede tantissime volte in tutti i software che mi e' capitato di vedere in 20 anni di programmazione: gli oggetti che subiscono l'azione diventano gli attori della stessa.
Comunque, se si preferisce:
Bicchiere bicchiere;
Acqua acqua;
acqua.riempi (bicchiere);
Sembra piu' naturale? Meno male che l'acqua ha un metodo per riempire il bicchiere ;)
4 - Perche' lo stesso bicchiere deve ereditare dalla classe Oggetti? E dalla classe Vetro? Cosa c'e' di naturale in questo? Perche' mi devo portare dietro dei "Metodi/Messaggi" che non mi serviranno a niente, visto che il mio programma usera' il bicchiere per bere l'acqua?
5 - La OOP funziona bene quando e' chiaro cosa deve FARE la classe. Assume che la classe sia un modello di qualcosa che l'utente della stessa conosce gia', nella realta'.
Per esempio, ho appena trovato una classe (in un software scritto da altri) di questo tipo:
class ModelizePlantWithEdgerWithoutL3System: public ModelizePlantWithEdgerOnDownstream
{
....
};
Ritengo di essere del settore (a cui questo software si riferisce), ma credetemi o meno non so come usare la classe!!
Riassumendo: se scrivi una classe che si chiama complex_number probabilmente tutti riescono ad usarla. Quando le cose diventano piu' complesse, siccome la classe si basa sulla conoscenza personale (del singolo programmatore) utilizzare la classe non e' piu' cosi' immediato.
Questo vale a maggior ragione quando la classe ha uno stato, e che obbliga lo sviluppatore a chiamare i metodi in sequenze ben determinate. Ma gli oggetti hanno per forza uno stato!
Nella azienda dove lavoro, si e' riscontrato che l'inserimento di nuovo personale nei progetti esistenti richiede un tempo di training maggiore di qualche anno fa. Domanda: non si dovevano ridurre, questi tempi?
6 - Sempre per il motivo 5, se non e' chiaro cosa deve fare le classe, l'ereditarieta' non fa altro che peggiorare le cose. E' come se il famoso INCAPSULAMENTO (inteso come dati e algoritmi nella stessa classe, i.e. nello stesso posto) venisse a mancare. In sostanza, non sai piu' dove andare a trovare le cose. Dov'e' il metodo che fa questo? Ed il metodo che fa quello? Apri la classe corrispondente all'oggetto con il metodo bacato, ma non lo trovi! Allora devi "risalire la china" delle ereditarieta', sperando di trovarlo.
Lasciamo ovviamente stare il costrutto friend, perche' ho voglia di piangere.
7 - Quando il software comincia a crescere, hai bisogno di un valido software per la documentazione automatica e la ricerca dei metodi. Purtroppo quando si comincia ad usare PESANTEMENTE il polimorfismo, potresti perdere giorni a cercare qual e' esattamente il metodo che viene eseguito ad una determinata condizione. Sto ovviamente parlando di software di milioni di righe, ma e' pur vero che in programmi con programmazione tradizionale NON perdevo quel tempo per cercare cosa succede, anche se il codice risultante era meno elegante (magari sequenze di switch()).
Con l'arrivo della programmazione ad oggetti, e' arrivata anche una serie di nuovi tool di cui prima non si sentiva l'esigenza. Ora sul muro del laboratorio c'e' un grande poster che descrive il diagramma delle classi, tanto per dare un'idea di cosa succede, ed abbiamo un software da 2000$ (per ogni PC) per tener aggiornato il progetto.
Intendiamoci: e' anche vero che il software e' cresciuto nelle dimensioni. Pero' e' anche vero che per poter avere un'idea di cosa sta succedendo si ha bisogno di altri tool, piu' potenti. Anche il semplice editor ti deve ora mostrare la lista dei metodi disponibili per oggetto, e spesso scrivere un programma significa scandire questa lista, alla ricerca del metodo "giusto" (cioe' che "suona" bene). Purtroppo di metodi che suonano "giusti" ce ne sono sempre 3 o 4...
Domanda: come sarebbe la produttivita' in generale senza questi tool? Per ogni metodo si dovrebbe andare a scorrere la documentazione?
8 - Le eccezioni!!! Basandosi su quanto viene affermato anche in comp.lang.c++.moderated (oppure basta leggere "Exceptional C++" del mitico Herb Sutter), ben pochi programmatori hanno capito fino in fondo cosa significa utilizzare le eccezioni (il sottoscritto si ritiene incluso nella lista degli ignoranti). Gli esempi che riporta sono a dir poco illuminanti.
Scrivere codice SICURO rispetto alle eccezioni e' un'impresa non da poco, nonostante tutti si dichiarino ben preparati nel loro uso.
Inoltre, se pensiamo che erano nate per evitare di mischiare il normale flusso di esecuzione dal flusso di esecuzione degli errori, mi viene quasi da piangere: nel codice che ho potuto vedere in questi anni, questo obiettivo non e' stato mai raggiunto. Altro che naturale!!!
In piu', con le eccezioni si doveva eliminare una volta per tutte il blind faith. Ho bisogno di aggiungere altro?
Forse si: qualcosa sulla propagazione delle eccezioni. Fino a quando deve essere propagata un'eccezione? Qual e' il giusto livello per catturarla in maniera efficiente?
In pratica, nella maggior parte del codice che ho visto:
- non si catturano eccezioni importanti ed il programma termina quando vengono sollevate;
- si catturano subito e si riporta un codice di errore (ORRORE! Non eravamo tutti orientati agli oggetti?)
- si catturano e si tappano con un orrendo catch (...).
E se l'eccezione e' riportata da una libreria che hai acquistato, e che magari e' carente nella documentazione? (quale documentazione riporta le eccezioni, e soprattutto, chi le legge?).
In piu', le eccezioni possono generare un sacco di problemi molto carini. Per esempio, sempre leggendo comp.lang.c++.moderated si puo' scoprire che il seguente codice:
MyObject *vect = new MyObject[100];
-- qui usiamo questo vettore, poi:
delete[] vect;
puo' generare dei memory leak ASSOLUTAMENTE NON ELIMINABILI. Quale istruzione genera il memory leak? Ovviamente delete[] vect!!!!
9 - Qualcuno vocifera che se la parte pubblica di una classe non cambia e si cambia solo la parte privata, basta ricompilare
il sorgente della classe e linkare al resto. BALLE. Non per nulla, si sono disegnate architetture (che, fra l'altro, trovo molto eleganti) come COM anche per ovviare a questo.
Esempio:
MyObject *pObject = new MyObject;
Prova a NON ricompilare questa istruzione nel tuo codice che usa l'oggetto MyObject.
In sostanza: cambi la parte privata? Prego, ricompila anche il tuo codice sorgente esattamente come facevi prima. Ci impieghi ore? Ce ne impiegavi anche prima, no?
10 - Ultima parola sul polimorfismo. Altra arma a doppio taglio, visto che non si puo' usare con i vettori! Chi sa cosa succede usando un vettore di oggetti polimorfici? Nessuno! Per fortuna non e' un errore molto comune nel software che mi e' capitato di vedere.
Disclaimer: ovviamente queste sono opinioni personali (piu' qualche *vera* dimostrazione). Anche l'autore dell'articolo in questione afferma che parlare male della programmazione Object Oriented e' come "swearing in church". Comunque non ritengo offensiva nessuna affermazione ho riportato a favore della mia tesi.
Inoltre, come la maggior parte di voi, per portare il pane a casa PROGRAMMO, e lo faccio usando linguaggi orientati agli oggetti...
Mi sembra (opinione personale) che il numero di articoli contro l'OOP sia cresciuto parecchio in quest'ultimo anno. E' ora di preparare la "revolucion" ;)
D'altronde non siete stanchi di usare ancora le stesse cose e riparare sempre gli stessi errori? Se qualcuno comincia a criticare lo stato delle cose, e' il benvenuto! E' il primo passo per tirar fuori qualcosa di nuovo...
Molti di questi problemi però sono relativi al c++, non alla programmazione ad oggetti in generale.
sottovento
12-03-2009, 09:39
1) result = a.sin() * b + c # Questo è object oriented. :D
Forse si, forse no. Scrivevo cosi' anche prima di programmare con le classi.
2) Non ho trovato finora un testo introduttivo alla programmazione che parta dalla programmazione a oggetti. Purtroppo la tendenza di chi fa informazione a livello divulgativo/scolastico è a introdurla dopo quella strutturata. Il che non significa che non sia adatta per partire con la programmazione. Forse qualche tutorial su SmallTalk affronta il problema da questo punto di vista.
OK. Ci pensiamo noi. Al prossimo che chiede come iniziare a programmare, sappiamo che risposta dare ;)
3) "si tende", non significa che bisogna strafare.
Nell'esempio che ho aggiunto non mi sembra di aver strafatto. :D
Tutto sommato non mi sembrava cosi' male come esempio, vista la limitata capacita' del mio neurone....
4) la classe Object mette a disposizione diversi metodi di carattere generale che sono mediamente utili. Poi è ovvio che puoi scrivere applicazioni che non li usano.
Il discorso è esattamente lo stesso delle funzioni built-in disponibili nei linguaggi funzionali: perché metterle nel namespace condviso, anche se non servono? Dovrebbero essere importate soltanto all'occorrenza. Lo si fa proprio perché si tratta di funzioni mediamente utili.
Non me le tiro dietro per forza. Stanno li', non nell'oggetto (il quale incapsula dati + metodi).
E poi questo suona come: "OK, c'era il problema prima quindi c'e' anche adesso". Tutto sommato e' lecito mettere in discussione quanto si conosce per cercare qualcosa di nuovo. Mi sembra piu' una conferma: il problema non e' stato risolto.
C'e' ancora spazio per fare di meglio...
5) Se la OOP viene usata male non è "colpa sua".
Verissimo. Vale anche per l'assembler, il c, il Pascal e tutto il resto.
Si pensava di introdurre gli oggetti per migliorare il codice.
E' noto che possiamo programmare "a oggetti" anche in altri linguaggi che non supportano tale paradigma. Ma se lo supportano, abbiamo una programmazione migliore.
Allora, sicuramente c'e' qualcosa di meglio! Chissa', magari fra qualche anno l'avremo installato sul nostro computer!
6) Questo capita anche coi paradigmi strutturati e funzionali, dove andare a trovare una funziona "scognita" può essere un'impresa. Dipende, al solito, da come si strutturano le cose.
Esatto. La programmazione ad oggetti pero' ci mette dell'entusiasmo in questo :D
Certamente non risolve questo problema. Al punto che i tool di cui parlavo non sono solo utili durante l'attivita' di programmazione: sono vitali!
7) Qui può aiutare l'approccio test driven, che tra l'altro "autodocumenta" il codice. Ma vale anche per gli altri paradigmi.
8) Le eccezioni non fanno parte del paradigma OOP: le si può introdurre anche negli altri.
Ovviamente non posso discutere piu' di tanto su questo punto. Solo una cosa: le eccezioni vengono giudicate efficaci se usate con i costruttori.
9) Con Delphi non m'è mai capito di dover ricompilare un'applicazione soltanto perché ho cambiato l'implementazione di una classe. Inoltre è in grado di compilare sorgenti da un milione di righe di codice in pochi secondi (grazie alla struttura del linguaggio, che è modulare e richiede una sola passata).
Non conosco Delphi, ma se non ricompili come fai a sapere le dimensioni dell'oggetto che vai ad allocare?
Esempio di prima:
MyObject *p = new MyObject;
Immagino che anche Delphi dovra' allocare memoria. 10 bytes? Se poi aggiungi un nuovo campo di 4 bytes....
10) Questo dipende dal tipo di linguaggio. Con Python, dove qualunque cosa è un oggetto, posso crearmi una sottoclasse di Tuple o List e ridefinire qualunque loro metodo, se è utile.
Ti avevo promesso di imparare Python e non l'ho ancora fatto. Spero potrai perdonarmi.
In effetti mi riferivo principalmente a C++ (in java, per esempio, non e' possibile).
Se in Python e' possibile, ti rimane lo stesso il problema: la dimensione di una singola cella del vettore e' sbagliata. Immagino che Tuple o List siano le corrispondenti della STL. D'accordissimo: anche se uso STL non ho problemi.
P.S. Anche le mie sono opinioni personali. :)
:D D: Avevo solo paura di beccarmi un po' di parolacce.
Scusa se ho provato a rispondere ad ogni punto, ma volevo solo far capire che sono stanco della OOP venduta come il massimo della tecnologia.
Ovviamente il suo sporco lavoro lo fa....
sottovento
12-03-2009, 09:41
Molti di questi problemi però sono relativi al c++, non alla programmazione ad oggetti in generale.
Forse si! Mi sbaglio spesso ;)
2) io consiglio sempre di iniziare con Java proprio perché fare programmazione procedurale con Java è veramente difficile ;) Non mi piace consigliare di iniziare a programmare con linguaggi che consentono un approccio misto come Python o C++ usato alla C (è una delle abitudine che affossano di più questo linguaggio).
3) bicchiere.riempitoCon(acqua);
o
bicchiere.setContenuto(acqua);
Brutta lo so, ma questo metodo funziona bene con l'inglese.
Piccola modifica linguistica e tutto torna :sofico:
4) se i metodi non si usano, si tolgono ;)
5) concordo con cdimauro
6 e 7) il problema è relativo a tutti i linguaggi quando la dimensione del progetto aumenta. Sicuramente la documentazione automatica semplifica notevolmente la questione. Volevo portare ad esempio la documentazione delle QT4: in ogni classe sono riportati anche i metodi ereditati dalle classi padri. Questo dovrebbe fare una documentazione completa.
Fortunatamente i tool ci sono :D Certe volte si tende a considerare il solo linguaggio, ma non tutto l'universo di software di sviluppo che gli gira intorno. Secondo me la qualità dei tool di sviluppo è fondamentale. Per questo considero Java attualmente una spanna avanti a tutti i linguaggi.
8) Due cose sono fondamentali: applicazione con metodo e il ricordarsi che le eccezioni devono aiutare solo a gestire gli errori.
9) colpa di C++
10) cosa intendi ?
3) bicchiere.riempitoCon(acqua);
o
bicchiere.setContenuto(acqua);
O meglio ancora:
bottiglia_acqua.riempi( bicchere1 );
bottiglia_coca.riempi( bicchere2 );
Dove le sotto-istanze di Bottiglia creano sottotipi diversi di Liquidi gestibili da Bicchere (Factory pattern).
Questo per dire, che l'OOP è solo più potente della procedurale, non è più facile.
Magari è più intuitiva, ma si possono anche sbagliare molte più cose, architetturalmente.
Frank1962
12-03-2009, 11:31
secondo me la gran parte dei programmatori ancora non ha capito a fondo cosè la Programmazione ad Oggetti.... alla fine la OO è solo uno strumento in più; all'uni ho visto gente che scriveva in Java un progetto tutto in una sola classe ....se per loro era più intuitivo fare così chi dice nulla: non bisogna però poi lamentarsi che non si riesce ad andare oltre a una dama o una battaglia navale :muro: :D
comunque stò Erlang solo a vederlo mi vengono le convulsioni: http://it.wikipedia.org/wiki/Erlang_(linguaggio)
...mi sembra di essere tornati ai tempi dell'uni dove i linguaggi funzionali sembravano la soluzione a tutti i mali del mondo! :rolleyes:
C# e Python sono entrambi sia ad oggetti che parzialmente funzionali.
Conosco meglio il C#, e quando si riesce, e ci si riesce spesso, ad usare l'approccio funzionale se ne hanno grossi vantaggi in termini di leggibilita' e compattezza di codice.
Non in termini di velocita' di esecuzione per esempio, che resta ad oggi al limite uguale.
Sono riusciti a convogliare una programmazione funzionale in un linguaggio ad oggetti, e se ne possono trarre entrambi i benefici, compreso (almeno nel C#) l'approccio strong-type che io considero fondamentale per manovrare la mole di codice che mi passa sotto mano. (ma so che non e' necessario)
Alcuni degli altri problemi qui enunciati come memoryleak, polimorfismo nei vettori ed eccezioni poco gestibili fanno parte del mio passato e con il C# non le vedo piu' da almeno 6 anni.
Detto da uno che, con un pizzico di provocazione, lo ammetto, ha linkato il suddetto articolo nella propria firma, può sembrare provocatorio, appunto, ma non mi aspettavo reazioni del livello "OMG!!1 LOLz, shut teh f*ck up u n00b! OO rawkz!11". Senza sapere precisamente di cosa si parla, tra l'altro.
Prima di tutto, il "tizio" non ha sviluppato erlang in un garage per vent'anni e poi si è deciso a rilasciarlo oggi. E' un progetto che nasce in Ericsson, che è stato utilizzato PER ANNI, e che DOPO è stato rilasciato come progetto open-source. Quindi il tizio non è nè l'ultimo degli arrivati, nè uno impreparato. Non è Linus che parla di C++.
Seconda cosa, il tono è volutamente polemico e provocatorio, mi sembra si capisca piuttosto bene. E poi bisogna andare anche al di là di quello che dice, credo. Se uno dice "Data structure and functions should not be bound together" a me vengono in mente diverse altre cose, oltre a quelle che elenca lui.
Ad esempio, mi piacerebbe che i metodi fossero separati dalle classi per poter aggiungere i MIEI metodi alla classe String, e non dover spostare tutto in una StringUtils (perchè non ha senso, è brutto da vedere, ecc..ecc...)
Mi viene in mente anche una cosa che si chiama Multiple Dispatch, che non capirete mai se le uniche cose che avete visto sono C++ e Java. Mai. Dovete sbattervi e studiare qualcos'altro (Common Lisp, Clojure, Dylan, ecc...).
Senza contare che Amstrong dice anche cose perfettamente sensate, che sfido a controbattere, tipo "In particular functions with side effects should be avoided." Questo non è il grido di un haskeller fanatico. Lo dice anche Bloch nel suo Effective Java... "Prefer immutability".
E poi voglio dire... quanti in questo forum si sono presi la briga di studiare un pizzico di lisp/haskell/altro?? Semplicemente, non conoscete a sufficienza il punto di vista dal quale parte Amstrong quando pone quelle obiezioni; siete in una posizione svantaggiosa. Con questo ovviamente non dico che lui abbia al 100% ragione, che la programmazione funzionale risolva la fame nel mondo, e altre stronzate... there's no silver bullet. Ovviamente. Però un pò di studio, prima di sparare a zero, non farebbe male.
Ad esempio, mi piacerebbe che i metodi fossero separati dalle classi per poter aggiungere i MIEI metodi alla classe String, e non dover spostare tutto in una StringUtils (perchè non ha senso, è brutto da vedere, ecc..ecc...)
Anche questo si puo' fare in C#, (e pure in Javascript...) e penso anche in Python
Mi viene in mente anche una cosa che si chiama Multiple Dispatch, che non capirete mai se le uniche cose che avete visto sono C++ e Java. Mai. Dovete sbattervi e studiare qualcos'altro (Common Lisp, Clojure, Dylan, ecc...).
Pure.
Certo che continuiamo a pensare che OOP sia uguale solo a C++ e qualunque cosa venuta dopo gli anni 80 non si riesce a prendere in considerazione, allora ovvio che un linguaggio funzionale cresciuto negli anni 90 sara' meglio...
Anche questo si puo' fare in C#, (e pure in Javascript...) e penso anche in Python.
Si, anche in ruby. Ma sono due approcci diversi (a parte javascript che ha una filosofia ancora diversa). Da un lato hai le classi aperte (quello che puoi fare nei linguaggi qui sopra), dall'altro la classe è solo 'stato' e non 'comportamento' e i metodi stanno fuori.
Io preferisco il secondo.
edit: non a caso su C# ci lavora (intendo sul linguaggio proprio, alla microsoft) un sacco di gente che viene da un background funzionale (haskell in particolare, se la mia memoria non vacilla).
~FullSyst3m~
12-03-2009, 11:59
Detto da uno che, con un pizzico di provocazione, lo ammetto, ha linkato il suddetto articolo nella propria firma, può sembrare provocatorio, appunto, ma non mi aspettavo reazioni del livello "OMG!!1 LOLz, shut teh f*ck up u n00b! OO rawkz!11". Senza sapere precisamente di cosa si parla, tra l'altro.
Prima di tutto, il "tizio" non ha sviluppato erlang in un garage per vent'anni e poi si è deciso a rilasciarlo oggi. E' un progetto che nasce in Ericsson, che è stato utilizzato PER ANNI, e che DOPO è stato rilasciato come progetto open-source. Quindi il tizio non è nè l'ultimo degli arrivati, nè uno impreparato. Non è Linus che parla di C++.
Seconda cosa, il tono è volutamente polemico e provocatorio, mi sembra si capisca piuttosto bene. E poi bisogna andare anche al di là di quello che dice, credo. Se uno dice "Data structure and functions should not be bound together" a me vengono in mente diverse altre cose, oltre a quelle che elenca lui.
Ad esempio, mi piacerebbe che i metodi fossero separati dalle classi per poter aggiungere i MIEI metodi alla classe String, e non dover spostare tutto in una StringUtils (perchè non ha senso, è brutto da vedere, ecc..ecc...)
Mi viene in mente anche una cosa che si chiama Multiple Dispatch, che non capirete mai se le uniche cose che avete visto sono C++ e Java. Mai. Dovete sbattervi e studiare qualcos'altro (Common Lisp, Clojure, Dylan, ecc...).
Senza contare che Amstrong dice anche cose perfettamente sensate, che sfido a controbattere, tipo "In particular functions with side effects should be avoided." Questo non è il grido di un haskeller fanatico. Lo dice anche Bloch nel suo Effective Java... "Prefer immutability".
E poi voglio dire... quanti in questo forum si sono presi la briga di studiare un pizzico di lisp/haskell/altro?? Semplicemente, non conoscete a sufficienza il punto di vista dal quale parte Amstrong quando pone quelle obiezioni; siete in una posizione svantaggiosa. Con questo ovviamente non dico che lui abbia al 100% ragione, che la programmazione funzionale risolva la fame nel mondo, e altre stronzate... there's no silver bullet. Ovviamente. Però un pò di studio, prima di sparare a zero, non farebbe male.
Dato che hai nominato un mio intervento e non avendo capito il senso, chiarisco che era semplicemente una frase ironica. Credo che apparte questo nessuna abbia sparato a zero, hanno esposto tutti la loro opinione in base alle proprie esperienze.
Dato che hai nominato un mio intervento e non avendo capito il senso, chiarisco che era semplicemente una frase ironica. Credo che apparte questo nessuna abbia sparato a zero, hanno esposto tutti la loro opinione in base alle proprie esperienze.
Non prenderlo come un attacco personale. Stavo solo contestualizzando il lavoro dell'autore.
~FullSyst3m~
12-03-2009, 12:04
Non prenderlo come un attacco personale. Stavo solo contestualizzando il lavoro dell'autore.
No, figurati. Ma dato che hai nominato un mio intervento ho voluto chiarire per correttezza di informazione.
Per me comunque la stupidità dell'intervento del "tizio" sta in quanto è estremo:
si mette a dire che l'OO fa schifo, che è superato, e quant'altro... ma a mio parere per come la metti, è un grosso passo avanti rispetto al passato. E ha vantaggi e svantaggi esattamente come gli altr paradigmi.
Nessuno ha detto che l'OO è perfetto, ma sicuramente migliora di molto la produttività e l'eleganza rispetto al procedurale, basta vedere C vs C++, per non parlare di linguaggi più moderni...
preferire il funzionale, o altro, è solo questione di gusti e di necessità.
Per esempio, a me farebbe cordialmente schifo avere i metodi fuori delle classi, nello sviluppare giochi.
Tank.shoot( Vector3 dir ), cube.setMass(float), player.damage() sono decisamente molto simili al linguaggio umano, e spiegano benissimo la logica che c'è dietro... non capisco davvero come un altro paradigma di programmazione possa migliorare la mia esperienza sempre e comunque.
Se quel paradigma esiste, sicuramente non è il funzionale, cmq.
Chissà, magari un giorno basterà spiegare a voce al pc quello che deve fare, ma sicuramente per quella data avremo perso tutti il lavoro :asd:
sottovento
12-03-2009, 12:51
2) io consiglio sempre di iniziare con Java proprio perché fare programmazione procedurale con Java è veramente difficile ;) Non mi piace consigliare di iniziare a programmare con linguaggi che consentono un approccio misto come Python o C++ usato alla C (è una delle abitudine che affossano di più questo linguaggio).
Ho letto libri che insegnano la programmazione partendo da Java. Viene pero' usato per spiegare inizialmente la programmazione come se fosse procedurale.
3) bicchiere.riempitoCon(acqua);
o
bicchiere.setContenuto(acqua);
Brutta lo so, ma questo metodo funziona bene con l'inglese.
Piccola modifica linguistica e tutto torna :sofico:
Concordo, e' bruttina :D
Ad ogni modo, il problema resta (e resterebbero tonnellate di software da modificare, no?)
4) se i metodi non si usano, si tolgono ;)
Se sono nelle classi base (magari di librerie) si tengono ;)
5) concordo con cdimauro
6 e 7) il problema è relativo a tutti i linguaggi quando la dimensione del progetto aumenta. Sicuramente la documentazione automatica semplifica notevolmente la questione. Volevo portare ad esempio la documentazione delle QT4: in ogni classe sono riportati anche i metodi ereditati dalle classi padri. Questo dovrebbe fare una documentazione completa.
Fortunatamente i tool ci sono :D Certe volte si tende a considerare il solo linguaggio, ma non tutto l'universo di software di sviluppo che gli gira intorno. Secondo me la qualità dei tool di sviluppo è fondamentale. Per questo considero Java attualmente una spanna avanti a tutti i linguaggi.
Non posso dire che sia sbagliato. Dico che ritengo fisiologico che un progetto OOP tenda ad "esplodere" e che questi tool diventino piu' importanti rispetto ad altre metodologie di programmazione.
8) Due cose sono fondamentali: applicazione con metodo e il ricordarsi che le eccezioni devono aiutare solo a gestire gli errori.
9) colpa di C++
Colpa di chi si deve allocare un oggetto: ne deve conoscere le dimensioni
10) cosa intendi ?
[/QUOTE]
MyBaseClass *vect = new MeInheritedClass[100];
Puoi provare a googlare "Never treat arrays polymorphically"
sottovento
12-03-2009, 12:55
Detto da uno che, con un pizzico di provocazione, lo ammetto, ha linkato il suddetto articolo ...<CUT>
A dire la verita' me le aspettavo. Ma penso che in futuro questo discorso sara' piu' importante.
Nessuno nega che OOP sia stato un passo avanti rispetto ai precedenti metodi di programmazione. Quindi?
Ci fermiamo qui? La provocazione (quando intelligente come questa) serve a far riflettere.
Ci si rimette in gioco. Quello che si riteneva il massimo della vita, non lo e' piu'.
Ben vengano provocazioni come le tue. Servono a far crescere l'informatica e le persone che lavorano con essa.
MyBaseClass *vect = new MeInheritedClass[100];
Puoi provare a googlare "Never treat arrays polymorphically"
Ok, ok...era solo che non avevo capito il caso...le collection le hanno inventate anche per superare questo problema...no ?
Ok, ok...era solo che non avevo capito il caso...le collection le hanno inventate anche per superare questo problema...no ?
Anche se fosse, basta fare un array di pointers:
MyBaseClass **vect = new MeInheritedClass*[100];
Questo è perfettamente lecito.
Il problema secondo me e' un altro.
Immaginiamoci di avere una funzione che accetta un array di oggetti di una classe base
void MyFunction(BaseClass[] Param){
...
}
Posso richiamare questa funzione passandoci come parametro un array di oggetti di una classe figlia?
...
ChildClass[] pippo = new ChildClass[40];
MyFunction(pippo);
...
In buona sostanza, l'oggetto "Array di oggetti di classe figlio" deriva dall'oggetto "Array di oggetti di classe padre"?
Si puo' giocare con i puntatori e i cast
(PS: Immaginatelo per le estensioni di collezioni come le liste, dato che in C++ Un array e' in realta' solo un puntatore)
^TiGeRShArK^
12-03-2009, 14:16
iniziamo da queste minchiate.....
Objection 1 - Data structure and functions should not be bound together
Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds. Why is this?
Functions do things. They have inputs and outputs. The inputs and outputs are data structures, which get changed by the functions. In most languages functions are built from sequences of imperatives: "Do this and then that ..." to understand functions you have to understand the order in which things get done (In lazy FPLs and logical languages this restriction is relaxed).
Data structures just are. They don't do anything. They are intrinsically declarative. "Understanding" a data structure is a lot easier than "understanding" a function.
Functions are understood as black boxes that transform inputs to outputs. If I understand the input and the output then I have understood the function. This does not mean to say that I could have written the function.
Functions are usually "understood" by observing that they are the things in a computational system whose job is to transfer data structures of type T1 into data structure of type T2.
Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.
Intanto nei linguaggi ad oggetti NON esistono funzioni, ma esistono solo dei metodi.
Inoltre i metodi degli oggetti possono anche essere definiti essi stessi come oggetti, tanto è vero che ad esempio in Ruby essi stessi sono degli oggetti:
http://www.ruby-doc.org/core-1.8.7/classes/Method.html
Per cui non ha alcun senso questa distinzione che si è inventato, dato che sia le funzioni che le strutture dei dati, ovviamente ognuna con le sue peculiarità, possono essere modellate come oggetti.
Objection 2 - Everything has to be an object.
Consider "time". In an OO language "time" has to be an object. But in a non OO language a "time" is a instance of a data type. For example, in Erlang there are lots of different varieties of time, these can be clearly and unambiguously specified using type declarations, as follows:
-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...
Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system.
bella cagata.
Molto meglio avere un UNICO oggetto time su cui sia possibile agire in maniera diversa mediante i metodi che ti mette a disposizione.
E' semplicemente ORRENDO dover utilizzare una miriade di funzioni diverse per fare la stessa cosa.
Objection 3 - In an OOPL data type definitions are spread out all over the place.
In an OOPL data type definitions belong to objects. So I can't find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can't - the data type definitions are spread out all over the place.
Pensa te che discorsi devo leggere nel 2009.
Evidentemente l'ide + avanzato con cui ha avuto a che fare è notepad o quel cesso di vim. :rolleyes:
Se avesse usato un ide SERIO, quale Eclipse, avrebbe capito che questo che presenta come uno svantaggio è in realtà un grandissimo VANTAGGIO dei linguaggi OO.
Let me give an example of this. Suppose I want to define a ubiquitous data structure. ubiquitous data type is a data type that occurs "all over the place" in a system.
As lisp programmers have know for a long time it is better to have a smallish number of ubiquitous data types and a large number of small functions that work on them, than to have a large number of data types and a small number of functions that work on them.
A ubiquitous data structure is something like a linked list, or an array or a hash table or a more advanced object like a time or date or filename.
In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object. Suppose now I want to create some "time" object, where does this belong and in which object...
E qua mette in evidenza come in realtà non abbia nemmeno la minima idea di cosa sia la programmazione ad oggetti dato che per lui esiste solo l'estensione e, a quanto pare, ignora totalmente la composizione. :rolleyes:
Objection 4 - Objects have private state.
State is the root of all evil. In particular functions with side effects should be avoided.
While state in programming languages is undesirable, in the real world state abounds. I am highly interested in the state of my bank account, and when I deposit or withdraw money from my bank I expect the state of my bank account to be correctly updated.
Given that state exists in the real world what facilities should programming language provide for dealing with state?
OOPLs say "hide the state from the programmer". The states is hidden and visible only through access functions.
Conventional programming languages (C, Pascal) say that the visibility of state variables is controlled by the scope rules of the language.
Pure declarative languages say that there is no state. The global state of the system is carried into all functions and comes out from all functions. Mechanisms like monads (for FPLs) and DCGs (logic languages) are used to hide state from the programmer so they can program "as if state didn't matter" but have full access to the state of the system should this be necessary.
The "hide the state from the programmer" option chosen by OOPLs is the worse possible choice. Instead of revealing the state and trying to find ways to minimise the nuisance of state, they hide it away.
Questo potrebbe essere parzialmente vero.
E' vero soprattutto in un'ambiente multi-threaded con accessi concorrenti e necessità di suddividere il carico su + core.
Tanto è vero che proprio per queso motivo si stanno estendendo i linguaggi ad oggetti utilizzando l'approccio funzionale, come con LINQ che permette, tramite una semplice chiamata al metodo .AsParallel() di suddividere automaticamente e dinamicamente il carico di lavoro su tutti i core a disposizione del sistema.
Di sicuro se lui provasse ad implementare un'estensione ad oggetti di Erlang non mi fiderei proprio visto che ha dimostrato di ignorare anche LE BASI della programmazione OO.
Why OO was popular?
Reason 1 - It was thought to be easy to learn.
Reason 2 - It was thought to make code reuse easier.
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.
I see no evidence of 1 and 2. Reasons seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.
This is is the real driving force behind OOPs.
La 1 forse può non essere vera, ma la 2 lo è SICURAMENTE.
E, ripeto, meglio usare un linguaggio ad oggetti completo ma che non abbia il supporto alla programmazione funzionale come java che utilizzare Erlang con un supporto ad oggetti scritto da lui, o, ancora peggio, senza alcun supporto alla programmazione ad oggetti. :rolleyes:
^TiGeRShArK^
12-03-2009, 14:27
Detto da uno che, con un pizzico di provocazione, lo ammetto, ha linkato il suddetto articolo nella propria firma, può sembrare provocatorio, appunto, ma non mi aspettavo reazioni del livello "OMG!!1 LOLz, shut teh f*ck up u n00b! OO rawkz!11". Senza sapere precisamente di cosa si parla, tra l'altro.
Prima di tutto, il "tizio" non ha sviluppato erlang in un garage per vent'anni e poi si è deciso a rilasciarlo oggi. E' un progetto che nasce in Ericsson, che è stato utilizzato PER ANNI, e che DOPO è stato rilasciato come progetto open-source. Quindi il tizio non è nè l'ultimo degli arrivati, nè uno impreparato. Non è Linus che parla di C++.
Seconda cosa, il tono è volutamente polemico e provocatorio, mi sembra si capisca piuttosto bene. E poi bisogna andare anche al di là di quello che dice, credo. Se uno dice "Data structure and functions should not be bound together" a me vengono in mente diverse altre cose, oltre a quelle che elenca lui.
Ad esempio, mi piacerebbe che i metodi fossero separati dalle classi per poter aggiungere i MIEI metodi alla classe String, e non dover spostare tutto in una StringUtils (perchè non ha senso, è brutto da vedere, ecc..ecc...)
Lo puoi fare tranquillamente in ruby, e, con alcuni vincoli persino in C# tramite gli Extensions Method.
Mi viene in mente anche una cosa che si chiama Multiple Dispatch, che non capirete mai se le uniche cose che avete visto sono C++ e Java. Mai. Dovete sbattervi e studiare qualcos'altro (Common Lisp, Clojure, Dylan, ecc...).
Possono essere supportate anche da Java, python, ruby, C#, ecc... tramite delle estensioni.
Ma è una cosa di cui sinceramente non ho mai sentito la mancanza.
Tra l'altro se non erro in Objective C c'è qualcosa del genere qunado si usano i binding ruby-cocoa e py-cocoa, ma ora non ricordo bene dato che è passato un bel pò di tempo e l'ho dovuto abbandonare completamente.
Senza contare che Amstrong dice anche cose perfettamente sensate, che sfido a controbattere, tipo "In particular functions with side effects should be avoided." Questo non è il grido di un haskeller fanatico. Lo dice anche Bloch nel suo Effective Java... "Prefer immutability".
Questo è ovvio, e infatti è forse l'unica cosa sensata che dice.
Il problema è che lui la vorrebbe eliminare da TUTTO il linguaggio, cosa assolutamente inconcepibile.
Imho è ASSAI meglio la soluzione del C# con l'infrastruttura LINQ tutta basata su funzioni pure e gli oggetti normali che possono fare quello che vogliono.
E poi voglio dire... quanti in questo forum si sono presi la briga di studiare un pizzico di lisp/haskell/altro?? Semplicemente, non conoscete a sufficienza il punto di vista dal quale parte Amstrong quando pone quelle obiezioni; siete in una posizione svantaggiosa. Con questo ovviamente non dico che lui abbia al 100% ragione, che la programmazione funzionale risolva la fame nel mondo, e altre stronzate... there's no silver bullet. Ovviamente. Però un pò di studio, prima di sparare a zero, non farebbe male.
Ho provato con haskell e ho scoperto che i linguaggi funzionali puri non fanno per me.
Sono semplicemente un'estremizzazione imho inutile dato che con linguaggi multi-paradigma e misti si può ottenere il meglio dei due mondi.
Come al solito gli estremi sono sempre da evitare.
cdimauro
12-03-2009, 14:28
Forse si, forse no. Scrivevo cosi' anche prima di programmare con le classi.
a.sin() non mi pare faccia parte della programmazione strutturata o funzionale.
OK. Ci pensiamo noi. Al prossimo che chiede come iniziare a programmare, sappiamo che risposta dare ;)
Partiamo dal linguaggio nobile per eccellenza: quello macchina. :fagiano:
Non me le tiro dietro per forza. Stanno li', non nell'oggetto (il quale incapsula dati + metodi).
E poi questo suona come: "OK, c'era il problema prima quindi c'e' anche adesso". Tutto sommato e' lecito mettere in discussione quanto si conosce per cercare qualcosa di nuovo. Mi sembra piu' una conferma: il problema non e' stato risolto.
C'e' ancora spazio per fare di meglio...
Io non vedo il problema. Le funzioni "addizionali" da qualche parte devono stare.
Verissimo. Vale anche per l'assembler, il c, il Pascal e tutto il resto.
Si pensava di introdurre gli oggetti per migliorare il codice.
E' noto che possiamo programmare "a oggetti" anche in altri linguaggi che non supportano tale paradigma. Ma se lo supportano, abbiamo una programmazione migliore.
Allora, sicuramente c'e' qualcosa di meglio! Chissa', magari fra qualche anno l'avremo installato sul nostro computer!
Con le macchine attuali mi viene difficile pensare a qualcosa di diverso dai paradigmi che ormai imperano da diversi anni. Con i computer quantistici servirà un approccio completamente diverso, ma non credo che arriveranno alla massa a breve.
La programmazione a oggetti comunque ha portato complessivamente dei miglioramenti.
Esatto. La programmazione ad oggetti pero' ci mette dell'entusiasmo in questo :D
Certamente non risolve questo problema. Al punto che i tool di cui parlavo non sono solo utili durante l'attivita' di programmazione: sono vitali!
Oggi non si può pretendere di utilizzare un linguaggio "nudo e crudo". Da quando è stato introdotto il primo IDE, parecchia acqua è passata sotto i ponti.
Non si può far a meno di un editor "intelligente" che riesce a contestualizzare il codice su cui stai lavorando e a fornirti indicazioni, segnalazioni d'errore, possibilità di rifattorizzare, "navigare" nel codice, ecc.
C'è ancora gente che si ostina a utilizzare il classico editor di testo, magari con l'aggiunta del syntax highlight, ma... è da trogloditi informatici.
Ovviamente non posso discutere piu' di tanto su questo punto. Solo una cosa: le eccezioni vengono giudicate efficaci se usate con i costruttori.
Le eccezioni non necessariamente devono essere oggetti. In linguaggi come Python e Ruby lo sono, ma in altri la loro implementazione può essere realizzata diversamente.
Non conosco Delphi, ma se non ricompili come fai a sapere le dimensioni dell'oggetto che vai ad allocare?
Esempio di prima:
MyObject *p = new MyObject;
Immagino che anche Delphi dovra' allocare memoria. 10 bytes? Se poi aggiungi un nuovo campo di 4 bytes....
In Delphi le istanze di una classe sono puntatori. ;)
Ti avevo promesso di imparare Python e non l'ho ancora fatto. Spero potrai perdonarmi.
Figuati: quando avrai tempo, sperimenterai un modo nuovo e un utile strumento per approcciarti alla scrittura del codice. ;)
In effetti mi riferivo principalmente a C++ (in java, per esempio, non e' possibile).
Se in Python e' possibile, ti rimane lo stesso il problema: la dimensione di una singola cella del vettore e' sbagliata. Immagino che Tuple o List siano le corrispondenti della STL. D'accordissimo: anche se uso STL non ho problemi.
Non è lo stesso: tuple e liste sono oggetti che contengono altri oggetti. Le prime sono oggetti immutabili, mentre le secondo no.
La dimensione di ogni "cella" è sempre la stessa: un puntatore a un oggetto. L'oggetto avrà, poi, la sua dimensione.
:D D: Avevo solo paura di beccarmi un po' di parolacce.
Scusa se ho provato a rispondere ad ogni punto, ma volevo solo far capire che sono stanco della OOP venduta come il massimo della tecnologia.
Ovviamente il suo sporco lavoro lo fa....
Ognuno ha le sue idee e thread come questi sono molto interessanti perché si parla di qualcosa di più del classico problema da risolvere.
Per quanto mi riguarda la OOP complessivamente rappresenta il massimo della tecnologia. Nel senso che i pregi superano i difetti.
C# e Python sono entrambi sia ad oggetti che parzialmente funzionali.
Conosco meglio il C#, e quando si riesce, e ci si riesce spesso, ad usare l'approccio funzionale se ne hanno grossi vantaggi in termini di leggibilita' e compattezza di codice.
Non in termini di velocita' di esecuzione per esempio, che resta ad oggi al limite uguale.
Sono riusciti a convogliare una programmazione funzionale in un linguaggio ad oggetti, e se ne possono trarre entrambi i benefici, compreso (almeno nel C#) l'approccio strong-type che io considero fondamentale per manovrare la mole di codice che mi passa sotto mano. (ma so che non e' necessario)
Alcuni degli altri problemi qui enunciati come memoryleak, polimorfismo nei vettori ed eccezioni poco gestibili fanno parte del mio passato e con il C# non le vedo piu' da almeno 6 anni.
Vale lo stesso per me, con Python. Inoltre la programmazione con un linguaggio dinamico apre scenari diversi nella stesura del codice.
Detto da uno che, con un pizzico di provocazione, lo ammetto, ha linkato il suddetto articolo nella propria firma, può sembrare provocatorio, appunto, ma non mi aspettavo reazioni del livello "OMG!!1 LOLz, shut teh f*ck up u n00b! OO rawkz!11". Senza sapere precisamente di cosa si parla, tra l'altro.
Benvenuto nel calderone delle generalizzazioni allora. :D
Prima di tutto, il "tizio" non ha sviluppato erlang in un garage per vent'anni e poi si è deciso a rilasciarlo oggi. E' un progetto che nasce in Ericsson, che è stato utilizzato PER ANNI, e che DOPO è stato rilasciato come progetto open-source. Quindi il tizio non è nè l'ultimo degli arrivati, nè uno impreparato. Non è Linus che parla di C++.
A me interessa quello che ha detto, non il suo curriculum.
Seconda cosa, il tono è volutamente polemico e provocatorio, mi sembra si capisca piuttosto bene. E poi bisogna andare anche al di là di quello che dice, credo.
In tal caso bisogna integrare con le informazioni che mancano. I giudizi si creano sulla base di ciò che è stato detto, non sulle intenzioni ignote.
Se uno dice "Data structure and functions should not be bound together" a me vengono in mente diverse altre cose, oltre a quelle che elenca lui.
Ad esempio, mi piacerebbe che i metodi fossero separati dalle classi per poter aggiungere i MIEI metodi alla classe String, e non dover spostare tutto in una StringUtils (perchè non ha senso, è brutto da vedere, ecc..ecc...)
Questo si può fare in Python. In Python metodi e funzioni sono oggetti:
>>> strip = str.strip
>>> strip
<method 'strip' of 'str' objects>
>>> strip(' ciao ')
'ciao'
L'unica cosa che non puoi fare (in Ruby sì, però) è aggiungere o togliere metodi alle classi built-in. In tutti gli altri casi puoi farlo (anche nelle sottoclassi di quelle built-in):
>>> def strip(this):
... return this + ' nude!!!'
...
>>> str.strip = strip
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'str'
Mi viene in mente anche una cosa che si chiama Multiple Dispatch, che non capirete mai se le uniche cose che avete visto sono C++ e Java. Mai. Dovete sbattervi e studiare qualcos'altro (Common Lisp, Clojure, Dylan, ecc...).
Quando avrò tempo. Anche perché i linguaggi funzionali tendenzialmente non mi piacciono.
Senza contare che Amstrong dice anche cose perfettamente sensate, che sfido a controbattere, tipo "In particular functions with side effects should be avoided." Questo non è il grido di un haskeller fanatico. Lo dice anche Bloch nel suo Effective Java... "Prefer immutability".
Vero. Ma tante volte è molto comodo avere oggetti che mutano di stato. Coi linguaggi funzionali puri a volte è complicato riuscire a ottenere gli stessi risultati in maniera più efficiente e/o elegante e/o compatta.
E poi voglio dire... quanti in questo forum si sono presi la briga di studiare un pizzico di lisp/haskell/altro?? Semplicemente, non conoscete a sufficienza il punto di vista dal quale parte Amstrong quando pone quelle obiezioni; siete in una posizione svantaggiosa. Con questo ovviamente non dico che lui abbia al 100% ragione, che la programmazione funzionale risolva la fame nel mondo, e altre stronzate... there's no silver bullet. Ovviamente. Però un pò di studio, prima di sparare a zero, non farebbe male.
Vale anche per Armstrong allora. E se voleva contestualizzare prendendo come metro di paragone i linguaggi funzionali, avrebbe potuto scriverlo o lasciarlo intendere.
In questo modo s'è beccato dei legittimissimi bullshits. ;)
banryu79
12-03-2009, 14:31
Nessuno nega che OOP sia stato un passo avanti rispetto ai precedenti metodi di programmazione. Quindi?
Ci fermiamo qui? La provocazione (quando intelligente come questa) serve a far riflettere.
Ci si rimette in gioco. Quello che si riteneva il massimo della vita, non lo e' piu'.
Programmazione orientata agli aspetti (AOP)?
Qualcuno ne sa qualcosa (per esperienza diretta intendo)?
sottovento
12-03-2009, 14:45
Programmazione orientata agli aspetti (AOP)?
Qualcuno ne sa qualcosa (per esperienza diretta intendo)?
Purtroppo no, ma e' da tenere sotto stretta osservazione ;)
Anche se non troppo innovativa, e' interessante anche la Table Oriented Programming: si tratta di fare sempre piu' o meno le stesse code, ma "vedendole" diversamente. Sono convinto che qualcosa di buono saltera' fuori, prima o poi
sottovento
12-03-2009, 14:53
A proposito: alla pagina della programmazione orientata agli aspetti di wikipedia, ci sono anche altri problemi legati alla OOP che la AOP si prefigge di risolvere.
Scava scava, i problemi escono :D
http://it.wikipedia.org/wiki/Programmazione_orientata_agli_aspetti
banryu79
12-03-2009, 15:03
A proposito: alla pagina della programmazione orientata agli aspetti di wikipedia, ci sono anche altri problemi legati alla OOP che la AOP si prefigge di risolvere.
Scava scava, i problemi escono :D
http://it.wikipedia.org/wiki/Programmazione_orientata_agli_aspetti
Meglio la -> versione inglese (http://en.wikipedia.org/wiki/Aspect-oriented_programming)
@EDIT:
Inoltre volevo aggiungere una opinione personale, rispetto all'esempio che prende il caso del bicchiere da riempire con l'acqua e ne da una rappresentazione OO tramite invocazione di un metodo (riempi o analogo) dell'oggetto "bicchiere" con passaggio di argomento "acqua", che per alcuni è sembrato "innaturale" (proprio per via dei nomi scelti nel nominare gli oggetti e il metodo).
A parte che nella realtà un bicchiere non si riempie d'acqua o altro da solo: non è che, per come l'ho intesa io, la OOP deve riuscire ad astrarre in modo credibile esempi tratti dalla reltà materiale del mondo; di solito la si usa per astrarre concetti che rappresentano parti di un sistema informatico.
Hanno poco senso questi esempi del bicchiere e dell'acqua per capire se la OOP va bene o no e fino a che punto...
Per quanto riguarda invece il discorso dei diversi paradigmi: secondo me non esiste un paradigma perfetto o una prospettiva perfetta per tutti i casi; dipende sempre dal particolare tipo di sistema che si sta creando (e dall'interazione con quel sistema e l'esterno).
Per questo motivo ad oggi penso che la capacità di cambiare prospettiva in base all'esigenza possa in effetti essere un vantaggio: un linguaggio che in modo coerente permetta di passare da una prospettiva all'altra in modo chiaro e controllato (al momento ho in testa OO e funzionale, ma scommetto che ce ne sono anche altre promettenti).
Forse un linguaggio solo non basta, magari un linguaggio con estensioni particolari, una per ogni prospettiva? (librerie di estensioni del linguaggio).
Forse sto vaneggiando, infatti oggi il sole è forte e splende direttamente attraverso la finestra che ho dietro la testa :asd:
1) result = a.sin() * b + c # Questo è object oriented. :D
Ora fa conto che a sia un reale, b un razionale e c un complesso. La moltiplicazione in che classe sta ? E l'addizione ? In generale devi ricorrere o a un metodo statico di una classe che non centra nulla (Number ? Math ?), oppure ai multimetodi, che non sono poi cosi' diffusi (a me vengono in mente solo CL e Dylan, che e' tutto dire).
Al di la' dell'esempio specifico, la critica del link iniziale andrebbe considerata non nell'ottica della programmazione procedurale, ma in quell funzionale, e non mi sembra che qualcuno l'abbia fatto.
Objection 4 - Objects have private state.
State is the root of all evil. In particular functions with side effects should be avoided.
Parto da questo perche' secondo me e' il punto cruciale. Gli oggetti sono stato piu' metodi per operarvici sopra. Se elimino lo stato privato, allora la differenza tra un oggetto e una coppia funzioni + struttura dati diventa relativa.
Occhio che con stato si intende principalmente stato mutabile. Una volta che elimino quello ogni volta che chiamo un metodo devo tornare anche il nuovo oggetto con lo stato modificato, e a quel punto ho in mano piu' una funzione.
Objection 1 - Data structure and functions should not be bound together
Questo non lo vedo come cosi' rilevante, nel senso che secondo me e' un problema ortogonale. Diciamo che il metodo di accoppiamento della programmazione OO e' un po' limitante nel modo di riutilizzo. Sistemi di tipi presenti in linguaggi derivati da ML mi sembrano piu' ragionevoli.
Objection 2 - Everything has to be an object.
Si riallaccia al punto 4. Una volta che tolgo lo stato mutabile, e uso oggetti "leggeri", che considerarli oggetti e' superfluo.
Objection 3 - In an OOPL data type definitions are spread out all over the place.
in realta' questa obiezione non l'ho capita bene, non fosse altro perche' l'esempio riportato parla di altro...
Ho letto la pagina. E' sinceramente molto divertente e indubitabilmente ragionevole. Se la programmazione orientata agli oggetti fosse quella cosa lì sarebbe il cumulo di idee più bizzarre mai partorito dalla mente umana.
in realta' questa obiezione non l'ho capita bene, non fosse altro perche' l'esempio riportato parla di altro...
Da quello che ho capito si lamenta del fatto che i linguaggi di programmazione che fanno uso della OOP tendono ad organizzare tutte le varie classi in vari package/namespace. Mentre secondo lui sarebbe molto meglio avere tutti i vari tipi di dati comodamente in un unico file da poter includere all'inizio del programma.
^TiGeRShArK^
12-03-2009, 21:07
Da quello che ho capito si lamenta del fatto che i linguaggi di programmazione che fanno uso della OOP tendono ad organizzare tutte le varie classi in vari package/namespace. Mentre secondo lui sarebbe molto meglio avere tutti i vari tipi di dati comodamente in un unico file da poter includere all'inizio del programma.
da notare il comodamente :asd:
se ha anche solo visto da lontano eclipse questo qui giuro che me lo taglio con la spada del pojo warrior :asd:
da notare il comodamente :asd:
se ha anche solo visto da lontano eclipse questo qui giuro che me lo taglio con la spada del pojo warrior :asd:
Non so perché ma ho come la sensazione che sia uno dei vecchi hardcore programmer unix che fa tutto da shell. Probabilmente non riesce a staccarsi da vim e grep. :asd:
OT: Bullshits. bullshit (let. merda di toro) é uncountable, come milk; non ha plurale.
wingman87
13-03-2009, 00:36
OT: bullshit (let. merda di toro) é uncountable, come milk; non ha plurale.
:rotfl:
Lo sapevi o sei andato a controllare? :asd:
tomminno
13-03-2009, 01:06
2) io consiglio sempre di iniziare con Java proprio perché fare programmazione procedurale con Java è veramente difficile ;) Non mi piace consigliare di iniziare a programmare con linguaggi che consentono un approccio misto come Python o C++ usato alla C (è una delle abitudine che affossano di più questo linguaggio).
Ho visto codice C# totalmente procedurale. Basta che tutto sia static e il gioco è fatto.
3) bicchiere.riempitoCon(acqua);
o
bicchiere.setContenuto(acqua);
Brutta lo so, ma questo metodo funziona bene con l'inglese.
Piccola modifica linguistica e tutto torna :sofico:
Ecco una cosa che non ho mai capito è il bicchiere che deve sapere come riempirsi? (tramite factory ecc)
Perchè è facile scrivere bicchiere.setContenuto(acqua); si ma poi l'acqua come puoi metterla nel bicchiere? Potresti lasciarlo sotto la pioggia, potresti usare una bottiglia, potresti usare una cannella.
Non è più corretto usare una classe Filler per riempire un contenitore di cui bicchiere è un caso particolare con un materiale di cui acqua è un caso particolare?
Io nella pratica non ho mai usato un qualcosa di simile a bicchiere.setContenuto(acqua); proprio per i suddetti motivi, sbaglio qualcosa?
Come il classico light.TurnOn() è compito della classe Light sapere che può essere accesa in modo diverso a seconda del tipo di lampada su cui è monata? Sempre tramite il solito factory chiaramente, ma io light devo sapere che c'è un factory che consente di accendermi?
Non è che in definitiva TurnOn si riduce all'impostazione interna di un bool che dice che è accesa, mentre le modalità di accensione sono completamente estranee alla classe Light?
9) colpa di C++
Mica solo di C++. Prova a farlo in C# e dimmi se ci riesci o ti viene fuori un bell'errore a runtime che ti segnala che l'assembly che stai cercando di caricare non coincide più con quello originale.
^TiGeRShArK^
13-03-2009, 01:21
Ho visto codice C# totalmente procedurale. Basta che tutto sia static e il gioco è fatto.
Ecco una cosa che non ho mai capito è il bicchiere che deve sapere come riempirsi? (tramite factory ecc)
Perchè è facile scrivere bicchiere.setContenuto(acqua); si ma poi l'acqua come puoi metterla nel bicchiere? Potresti lasciarlo sotto la pioggia, potresti usare una bottiglia, potresti usare una cannella.
Non è più corretto usare una classe Filler per riempire un contenitore di cui bicchiere è un caso particolare con un materiale di cui acqua è un caso particolare?
Io nella pratica non ho mai usato un qualcosa di simile a bicchiere.setContenuto(acqua); proprio per i suddetti motivi, sbaglio qualcosa?
Come il classico light.TurnOn() è compito della classe Light sapere che può essere accesa in modo diverso a seconda del tipo di lampada su cui è monata? Sempre tramite il solito factory chiaramente, ma io light devo sapere che c'è un factory che consente di accendermi?
Non è che in definitiva TurnOn si riduce all'impostazione interna di un bool che dice che è accesa, mentre le modalità di accensione sono completamente estranee alla classe Light?
Mica solo di C++. Prova a farlo in C# e dimmi se ci riesci o ti viene fuori un bell'errore a runtime che ti segnala che l'assembly che stai cercando di caricare non coincide più con quello originale.
ovviamente ci deve essere un attore che compia l'azione.
Ma queste sinceramente sono le basi della programmazione OO; mi pareva assolutamente superfluo spiegarlo nella sezione "programmazione" del + grande forum tecnico italiano.
Quanto al C#, sinceramente non ci ho mai fatto caso dato che nei progetti che uso o importo tutti i progetti dipendenti nella soluzione o, nel caso di asp.net, c'è l'autoupdate settato per le dipendenze che sono sotto la directory bin.
Ma, ad occhio, non vedo un solo motivo per cui si debba ricompilare tutto nel caso in cui venga cambiato solo il funzionamento del progetto dipendente senza rcimpilare l'interfaccia se non per ricostruire il binding della nuova dll.
Se mi spiegate questo processo nei dettagli mi fate un favore dato che, come ho detto, non ho mai avuto il piacere di vederlo accadere nella realtà per i motivi di cui sopra. :mbe:
P.s: mi ero dimenticato di dirlo perchè mi sembrava implicito, ma cmq OVVIAMENTE in java tutto ciò assolutamente non accade tanto è vero che i jar li puoi sostituire quando vuoi, volendo anche al runtime se hai la fantasia di scriverti un classloader customizzato, e non devi ricompilare assolutamente niente se non cambia l'interfaccia.
sottovento
13-03-2009, 01:22
Ho letto la pagina. E' sinceramente molto divertente e indubitabilmente ragionevole. Se la programmazione orientata agli oggetti fosse quella cosa lì sarebbe il cumulo di idee più bizzarre mai partorito dalla mente umana.
Buongiorno! A dirla tutta, aspettavo un tuo intervento sull'argomento. Quanto meno ci speravo. Pero' sono un po' deluso dalla risposta, mi aspettavo almeno due fogli di protocollo ;)
Seriamente: cose ne pensi? So che sei fortissimo in Java, ma pensi che la OOP sia il massimo della tecnologia? Pensi che possa esistere qualcosa di meglio? Oppure no?
sottovento
13-03-2009, 01:30
Meglio la -> versione inglese (http://en.wikipedia.org/wiki/Aspect-oriented_programming)
<CUT>
Per quanto riguarda invece il discorso dei diversi paradigmi: secondo me non esiste un paradigma perfetto o una prospettiva perfetta per tutti i casi; dipende sempre dal particolare tipo di sistema che si sta creando (e dall'interazione con quel sistema e l'esterno).
Per questo motivo ad oggi penso che la capacità di cambiare prospettiva in base all'esigenza possa in effetti essere un vantaggio: un linguaggio che in modo coerente permetta di passare da una prospettiva all'altra in modo chiaro e controllato (al momento ho in testa OO e funzionale, ma scommetto che ce ne sono anche altre promettenti).
Forse un linguaggio solo non basta, magari un linguaggio con estensioni particolari, una per ogni prospettiva? (librerie di estensioni del linguaggio).
Forse sto vaneggiando, infatti oggi il sole è forte e splende direttamente attraverso la finestra che ho dietro la testa :asd:
Oggi invece qui a Pechino c'e' un vento che arriva direttamente dalla Siberia e ti taglia in due, letteralmente. Pero' non mi impedisce di essere d'accordo con quanto scrivi.
Vorrei aggiungere: in questi anni si e' fatto ABUSO della OOP. La si e' messa dappertutto, anche dove NON necessaria e NON utile, se non addirittura dannosa, ridondante, pesante.
Siamo tutti d'accordo che un determinato problema, se risolvibile tramite calcolatore, allora e' risolvibile tramite un programma OOP. La teoria ce lo garantisce, pertanto gli esempi che ho portato non erano certo per dire che un problema non si poteva risolvere!
Diamine, non e' ora di trovare qualcosa di meglio? La OOP era nata per risolvere molti dei problemi che aveva la programmazione procedurale.
Una buona parte sono stati risolti, altri permangono. Siamo d'accordo su questo? Oppure la OOP ha risolto tutti i problemi di programmazione?
Io direi proprio di no...
tomminno
13-03-2009, 01:39
ovviamente ci deve essere un attore che compia l'azione.
Già ma è corretto scrivere bicchiere.setContenuto(acqua); dando così l'idea che il bicchiere sappia dove andare a prendere l'acqua?
Ma queste sinceramente sono le basi della programmazione OO; mi pareva assolutamente superfluo spiegarlo nella sezione "programmazione" del + grande forum tecnico italiano.
Ma è anche vero che questi sono gli esempi base che ti fanno quando ti insegnano la programmazione ad oggetti, poi arrivi ai pattern e a casi pratici e qualcosa comincia a non tornare.
Quanto al C#, sinceramente non ci ho mai fatto caso dato che nei progetti che uso o importo tutti i progetti dipendenti nella soluzione o, nel caso di asp.net, c'è l'autoupdate settato per le dipendenze che sono sotto la directory bin.
Ma, ad occhio, non vedo un solo motivo per cui si debba ricompilare tutto nel caso in cui venga cambiato solo il funzionamento del progetto dipendente senza rcimpilare l'interfaccia se non per ricostruire il binding della nuova dll.
Se mi spiegate questo processo nei dettagli mi fate un favore dato che, come ho detto, non ho mai avuto il piacere di vederlo accadere nella realtà per i motivi di cui sopra. :mbe:
Il problema si presenta se si usa il numero di versione in una libreria (che è sempre bene usare altrimenti non si sa mai effettivamente con cosa stiamo trattando).
Se cambia il numero di versione (e cambia visto che ho modificato una classe) .NET semplicemente si arrabbia perchè non riconosce più la libreria nel momento in cui vai ad eseguire l'utilizzatore.
Il che obbliga a ricompilare portandosi dietro i nuovi riferimenti alla libreria.
^TiGeRShArK^
13-03-2009, 01:40
Buongiorno! A dirla tutta, aspettavo un tuo intervento sull'argomento. Quanto meno ci speravo. Pero' sono un po' deluso dalla risposta, mi aspettavo almeno due fogli di protocollo ;)
Seriamente: cose ne pensi? So che sei fortissimo in Java, ma pensi che la OOP sia il massimo della tecnologia? Pensi che possa esistere qualcosa di meglio? Oppure no?
Non credo proprio che nessuno dei partecipanti al thread lo pensi...
La programmazione ad oggetti ha ovviamente i suoi limiti.
Ma di certo non si può permetere di enunciarli chi ha dimostrato con le sue parole di non sapere nemmeno dove sta di casa questa metodologia di programmazione.
Per me piuttosto che usare VIM (se va bene -.- ) e pensare solo ad Erlang farebbe MOLTO bene ad allargare un attimo i suoi orizzonti, come sono assolutamente pronti a fare tutti quelli che come me sono consapevoli che il paradigma funzionale in futuro avrà un importanza sempre maggiore (soprattutto per via dei multi-core), ma non potrà sostituire la porgrammazione ad oggetti.
Se verrà qualcosa dopo (e sono sicuro che prima o poi arriverà), di sicuro NON sarà il paradigma funzionale puro che esiste oggi.
cdimauro
13-03-2009, 03:27
Ora fa conto che a sia un reale, b un razionale e c un complesso. La moltiplicazione in che classe sta ? E l'addizione ? In generale devi ricorrere o a un metodo statico di una classe che non centra nulla (Number ? Math ?), oppure ai multimetodi, che non sono poi cosi' diffusi (a me vengono in mente solo CL e Dylan, che e' tutto dire).
Francamente non capisco quale sia il problema:
>>> from fractions import Fraction
>>> from math import sin
>>>
>>> class myfloat(float):
... def sin(self):
... return sin(self)
...
>>> a = myfloat(0.5)
>>> b = Fraction(2, 3)
>>> c = 1 + 2j
>>> result = a.sin() * b + c
>>> result
(1.3196170257361353+2j)
L'unica "fregatura" è che con Python non posso aggiungere metodi agli oggetti built-in, come dicevo prima, per cui per inserire il metodo sin ai float sono costretto a estendere la classe. Ma per il resto, come vedi, funziona tutto perfettamente, e... a oggetti. ;)
Al di la' dell'esempio specifico, la critica del link iniziale andrebbe considerata non nell'ottica della programmazione procedurale, ma in quell funzionale, e non mi sembra che qualcuno l'abbia fatto.
L'avrebbe dovuto fare l'autore dell'articolo in primis, a mio avviso.
Non ha fatto confronti con altri paradigmi, ma si è lanciato in un attacco abbastanza generalista alla OOP.
OT: bullshit (let. merda di toro) é uncountable, come milk; non ha plurale.
Dove lo trovi un americano che non conosce l'inglese? Solo su hwupgrade. :asd:
Buongiorno!
Avevo iniziato con una filippica perchè sono sinceramente appassionato di OO e Dio solo sa quanti mesi abbia passato a studiarne radici, contorni e problemi.
Poi verso la tre quarti ho riletto quella pagina è m'è venuto da ridere.
Qui parliamo di orientamento agli oggetti, una prospettiva che ha due termini: oggetto e stato.
Ora quando l'autore si inarca in uno stupendo "le strutture dati e funzioni non devono essere vincolate insieme" si capisce al volo quale sia il problema: vede un programma orientato agli oggetti, lo osserva da un punto di vista strutturato e dice "a me sembra una stronzata".
E ti credo! Se osservi un programma orientato agli oggetti in termini di funzioni e strutture dati vedrai funzioni e strutture dati sparse ovunque senza una ragione. Se non lo vedessi saresti cieco.
E' come prendere un programma erlang e vederlo da un punto di vista orientato agli oggetti: vedi un unico enorme oggetto che fa tutto e anche di più. E' naturale domandarsi che si sia fumato uno che scrive un oggetto così.
E mi viene da ridere quando lo vedo inciampare sul selciato e tuffarsi in un pozzangherone di melma nel punto in cui dice "tutto deve essere un oggetto". Ma siamo seri! Sono tremila anni che si sa che le definizioni totalizzanti cadono nella regressio ad infinitum, questo si alza la mattina "Tutto dev'essere un oggetto" e parte cantando Area Krishna Are Are.
In un sistema orientato agli oggetti ci sono cose che NON SONO OGGETTI e il sistema sta in piedi proprio per questo. Sono quelle che cose che scopri di non poter cambiare altrimenti il tuo sistema resta in mutande di pagliericcio. A volte è una scelta consapevole, a volte no.
Sul private non mi pronuncio. E' certo che l'autore non sappia di che parla perchè l'esistenza di private non ha a che fare con lo stato di un oggetto ma con il tipo di rappresentazione di quello stato. Non mi pronuncio perchè nella teoria della prospettiva orientata agli oggetti che cerco faticosamente di ricostruire ormai da un bel po' di tempo tenderei ad escludere la rilevanza dei modificatori di accesso. Ed è una questione da prendere con le pinze.
Tolto dal nostro panorama quel pezzo d'avanspettacolo il futuro è, secondo me, nel significato originale dell'orientamento agli oggetti.
Che, a scanso di equivoci, oggi si è completamente perduto. Non è di molto tempo fa la notizia secondo cui Alan Kay avrebbe ridefinito il suo orientamento gli oggetti "Message Oriented Programming". Pardon, 50 anni fa ho detto una cazzata? No, semplicemente il termine ha assunto altre colorazioni.
Chi dice oggetto oggi pensa a classe, polimorfismo, ereditarietà ma queste sono conseguenze dell'orientamento agli oggetti, non principi, sono paradigmi nel senso di indicatori, non cause.
L'OO nasce come tentativo di superare prospettive intermedie tra un punto di vista che un essere umano assume quando acquisice conoscenza di un fenomeno e i termini della prospettiva procedurale, quei valori immagazzinati in registri di memoria che soggetti ad operazioni elementari producono la simulazione del fenomeno da parte di un calcolatore.
Nel tentativo, ahinoi, ci è morta. Più che altro ammazzata dai vari Gamma e Fowler con la complicità di chi gli è andato dietro senza farsi troppe domande.
Il futuro è ancora orientato agli oggetti nel senso che sarà ancora la ricerca di una forma più umana e meno schematica di dire a un calcolatore quello che deve fare.
Non sarà la programmazione funzionale perchè è settant'anni che gira e nonostante le presunzioni di alcuni c'è stata gente intelligente che l'ha studiata e ha semplicemente detto: fa schifo.
sottovento
13-03-2009, 05:50
PGI-Bis
grazie per il tuo intervento, sinceramente molto interessante.
Leggendolo, mi e' venuto in mente che forse stiamo dicendo le stesse cose. Solo che io, essendo di campagna, parlo di cose semplici :D (fra l'altro, sono originario di un posto non molto lontano da casa tua).
Tu vedi il futuro ad oggetti. Bene, e mi piacciono le tue motivazioni. Pero' anche tu vedi il presente come SICURAMENTE migliorabile. Anche su questo siamo d'accordo, no?
Le mie critiche erano forse troppo portate ad un aspetto pratico. Ho detto solo: l'OOP fa schifo. Forse avrei dovuto dire l'OOP attuale. Insomma, penso che ci siano i margini per fare il "salto di qualita'". Non so qual e' il futuro, tu prospetti un OOP migliore e sembra ragionevole.
Io non lo escludo, anche se spero che si possa avere qualcosa di meglio. Qualcosa che ci permetta di rendere i computer piu' "intelligenti" e soprattutto che possa migliorare la qualita' della vita di tutti noi (anche i non informatici).
L'unica cosa su cui non mi trovi d'accordo sono le critiche verso questo signore. Ha il difetto di aver semplificato troppo, ma se non avesse fatto cosi', chi l'avrebbe letto?
Per esempio, parla di dati e metodi insieme in un unico calderone. Nell'OOP viene visto come uno dei vantaggi principali, ma come si puo' negare che ci siano degli svantaggi? Logicamente sono due mondi separati, no? E' la maniera giusta di metterli insieme? Io sono troppo ignorante per rispondere, ma penso che la sua critica sia tutto sommato fondata.
Ho visto codice C# totalmente procedurale. Basta che tutto sia static e il gioco è fatto.
Ecco una cosa che non ho mai capito è il bicchiere che deve sapere come riempirsi? (tramite factory ecc)
Perchè è facile scrivere bicchiere.setContenuto(acqua); si ma poi l'acqua come puoi metterla nel bicchiere? Potresti lasciarlo sotto la pioggia, potresti usare una bottiglia, potresti usare una cannella.
Non è più corretto usare una classe Filler per riempire un contenitore di cui bicchiere è un caso particolare con un materiale di cui acqua è un caso particolare?
Io nella pratica non ho mai usato un qualcosa di simile a bicchiere.setContenuto(acqua); proprio per i suddetti motivi, sbaglio qualcosa?
Come il classico light.TurnOn() è compito della classe Light sapere che può essere accesa in modo diverso a seconda del tipo di lampada su cui è monata? Sempre tramite il solito factory chiaramente, ma io light devo sapere che c'è un factory che consente di accendermi?
Non è che in definitiva TurnOn si riduce all'impostazione interna di un bool che dice che è accesa, mentre le modalità di accensione sono completamente estranee alla classe Light?
Dipende da quello che vuoi modellare, se a me interessa solo sapere quale contenuto c'è nel bicchiere e se c'è del contenuto e non mi interessa l'azione del riempimento creare una classe Filler non ha senso. Non perché risparmio tempo, sia chiaro, ma solo perché non mi interessa. Se non mi torna l'azione transitiva, proprio per come è definito il nome del metodo, basta trasformarla in una azione già "finita":
da
bicchiere.fillWith(water);
a
bicchiere.filledWith(water);
Da azione transitiva, che evidentemente può far storcere il naso, ad una semplice proprietà. Al pari di un setColour... Ripeto: questo ovviamente se non ci interessa modellare l'azione del riempimento.
In ogni caso non mi sembra un fault della OOP.
banryu79
13-03-2009, 12:20
Dipende da quello che vuoi modellare, se a me interessa solo sapere quale contenuto c'è nel bicchiere e se c'è del contenuto e non mi interessa l'azione del riempimento creare una classe Filler non ha senso. Non perché risparmio tempo, sia chiaro, ma solo perché non mi interessa. Se non mi torna l'azione transitiva, proprio per come è definito il nome del metodo, basta trasformarla in una azione già "finita"
[omissis]
In ogni caso non mi sembra un fault della OOP.
Mi autoquoto:
Inoltre volevo aggiungere una opinione personale, rispetto all'esempio che prende il caso del bicchiere da riempire con l'acqua e ne da una rappresentazione OO tramite invocazione di un metodo (riempi o analogo) dell'oggetto "bicchiere" con passaggio di argomento "acqua", che per alcuni è sembrato "innaturale" (proprio per via dei nomi scelti nel nominare gli oggetti e il metodo).
A parte che nella realtà un bicchiere non si riempie d'acqua o altro da solo: non è che, per come l'ho intesa io, la OOP deve riuscire ad astrarre in modo credibile esempi tratti dalla reltà materiale del mondo; di solito la si usa per astrarre concetti che rappresentano parti di un sistema informatico.
Hanno poco senso questi esempi del bicchiere e dell'acqua per capire se la OOP va bene o no e fino a che punto...
Concordo, dipendo tutto da quello che ci interessa nel nostro modello.
mindwings
13-03-2009, 13:26
Il futuro e` gia qui :D http://channel9.msdn.com/pdc2008/TL11/ presentazione di luca bolognese su F#...Ma poi ci sono anche Clojure, Scala... I programmi funzionali sono piu`compatti e piu` leggibili essendo mooolto dichiarativi.
Se il numero dei bugs e` proporzionale con le linee di codice(studi lo dimostrano da tempo) perche` non si usano strumenti piu` espressivi/dichiarativi e compatti?!?!
Il numero di bug è proporzionale al numero di linee, ma solo a parità di linguaggio ;)
banryu79
13-03-2009, 15:19
bah, da quanto ne so io Dijkstra era ampiamente critico verso l'OOP e non mi pare fosse un pirla. :D
Sì, e quindi?
O meglio: di preciso su quali aspetti/implicazioni della OOP, era critico? Cosa contestava di preciso (io non lo so)?
Se mi spieghi la "versione lunga della storia" magari ci si può anche fare una riflessione su, altrimenti una frase buttata così di per se non è molto stimolante.
^TiGeRShArK^
13-03-2009, 15:22
Il futuro e` gia qui :D http://channel9.msdn.com/pdc2008/TL11/ presentazione di luca bolognese su F#...Ma poi ci sono anche Clojure, Scala... I programmi funzionali sono piu`compatti e piu` leggibili essendo mooolto dichiarativi.
Se il numero dei bugs e` proporzionale con le linee di codice(studi lo dimostrano da tempo) perche` non si usano strumenti piu` espressivi/dichiarativi e compatti?!?!
e cmq non mi ha entusiasmato molto....
continuo a preferire C# + LINQ x ora...
banryu79
13-03-2009, 15:30
L'OO nasce come tentativo di superare prospettive intermedie tra un punto di vista che un essere umano assume quando acquisice conoscenza di un fenomeno e i termini della prospettiva procedurale, quei valori immagazzinati in registri di memoria che soggetti ad operazioni elementari producono la simulazione del fenomeno da parte di un calcolatore.
Il futuro è ancora orientato agli oggetti nel senso che sarà ancora la ricerca di una forma più umana e meno schematica di dire a un calcolatore quello che deve fare.
PGI, tu che hai dedicato molto tempo e ricerche a sviscerare il perchè della prospettiva orientata agli oggetti, che idee hai maturato circa le cause del suo parziale fallimento rispetto allo scopo che si prefiggeva?
Secondo te in quale aspetto cruciale è fallita?
@EDIT:
Hai qualche risorsa 'autorevole' da citare che presenta un'analisi pertinente rispetto al relativo fallimento di questo paradigma di programmazione rispetto le sue iniziali promesse?
Comunque, rispetto al paradigma procedurale puro effettivamente il paradigma OO per quanto mi riguarda è riuscito a darmi una prospettiva un pochino più "human-friendly".
@RI-EDIT:
Humm, mi è appena venuto in mente che nel processo di astrazione dalla prospettiva procedurale verso una forma di più semplice cognizione per la mente umana sorge appunto il problema di definire un attimo quale sia questa "prospettiva più umana"... La vedo difficile la cosa, che si fa, si prende spunto dalla più gettonata al momento tra le teorie cognitive del cervello?
Non credo affatto che la prospettiva orientata agli oggetti abbia fallito. Da un punto di vista "evolutivo" la OOP è sopravvissuta evolvendosi al punto di diventare, nel suo ambiente, la specie dominante.
E' la ragione per cui parlare di OO oggi non è parlare della OO di cinquant'anni fa.
Adattandosi alcune delle sue caratteristiche hanno perso rilevanza. Esempi tipici sono il concetto di classe ed ereditarietà: non servono più, permangono perchè non contraddicono lo scopo.
Il grosso dei problemi risiedono nella premessa: vediamo le cose come le vedrebbe un essere umano.
Il nostro bizzarro bicchiere che si riempie da solo è una manifestazione di quella premessa.
Si chiama personificazione, è prodotta dalla proiezione dell'io nello spazio ed è una delle caratteristiche della percezione che gli esseri umani hanno dell'altro da sè. Esiste cioè nell'interpretazione dei fenomeni una tendenza alla personificazione: attribuiamo alle entità qualità tipiche del nostro essere. Si fa probabilmente per questioni di economia. Se posso prevedere una conseguenza senza dover memorizzare più di quanto già so allora è inutile sfrugulliarsi: proietto sull'oggetto le mie caratteritische che conosco bene.
Capita allora che le entità inanimate inizino a "fare" e ad "avere".
Questa tendenza è irrilevante per i fenomeni immaginari. Un buffer di byte che viene riempio da un flusso di dati non è più naturale di un buffer di byte che acquisisce i suoi dati da un altro buffer o che si trasforma in vettore.
E' problematica per fenomeni reali.
La fisica dice che le cose non "hanno" e non "fanno". Le cose sono, punto e basta. Gravità, pressione e tensione superficiale causano una mutazione di stato nell'acqua le cui particelle passano da uno stato di quiete ad uno di moto. Nessuno versa niente.
Così troviamo "facile" dire che il bicchiere si riempie d'acqua ma non ne siamo convinti perchè quella conoscenza acquisita attraverso la proiezione dell'io contrasta con la conoscenza della fisica.
Si potrebbe evitare la "personificazione"? Occorre un notevole sforzo perchè richiede il superamento di un meccanismo che deriva probabilmente da quando gli uomini correvano coi leoni alle calcagna.
Tra quelli che dicevano "toh, la contrazione delle fibre muscolari connesse agli arti inferiori causano un'acquisizione di moto contrastata da..." e quelli che dicevano "toh, il leone sta per saltarmi addosso" erano i secondi ad avere più chance di portare a casa i garretti.
Tutto questo per dire che "pensare umano" ha delle conseguenze e non sempre queste conseguenze sono razionali o addirittura prevedibili. Perchè, tra l'altro, ci sono tante teorie su come pensi un uomo.
Pattern, funzioni, strutture dati, classi, ereditarietà... sono dettagli di implementazione. La programmazione orientata agli oggetti è molto più divertente :D.
banryu79
13-03-2009, 16:47
...
Capita allora che le entità inanimate inizino a "fare" e ad "avere".
Questa tendenza è irrilevante per i fenomeni immaginari. Un buffer di byte che viene riempio da un flusso di dati non è più naturale di un buffer di byte che acquisisce i suoi dati da un altro buffer o che si trasforma in vettore.
E' problematica per fenomeni reali.
...
Perfetto PGI, su questo punto sono perfettamente d'accordo con quanto esprimi qui (hai espresso con chiarezza lo stesso concetto che volevo trasmettere anch'io).
Tra quelli che dicevano "toh, la contrazione delle fibre muscolari connesse agli arti inferiori causano un'acquisizione di moto contrastata da..." e quelli che dicevano "toh, il leone sta per saltarmi addosso" erano i secondi ad avere più chance di portare a casa i garretti.
:sbonk: :rotfl: ecco perchè i Vulcaniani non esistono :asd:
Il grosso dei problemi risiedono nella premessa: vediamo le cose come le vedrebbe un essere umano.
Credo anche io che sia il nocciolo della questione.
Forse è poco probabile riuscire ad ottenere il miglior risultato possibile per avvicinarsi a questo scopo con un unico paradigma: perchè in campo non entra solo la faccenda del "come le vedrebbe un essere umano" riferito a fenomeni materiali che interagiscono fra loro ma è più un "come se le rappresenterebbe un essere umano" riferito non a fenomeni ma a relazioni logiche tra concetti, e in tal caso, secondo me, non può bastare sempre e solo una prospettiva o paradigma, proprio perchè la mente umana può assumerne di diversi nel guardare/studiare/analizzare/modellare/concettualizzare/strutturare/eccetera uno stesso "costrutto".
Può cioè (e se ne ha la possibilità e le conviene lo fa) "guardare lo stesso punto da una pluralità di punti di vista".
Il punto di vista cambia, l'oggetto osservato forse no...
Adattandosi alcune delle sue caratteristiche hanno perso rilevanza. Esempi tipici sono il concetto di classe ed ereditarietà: non servono più, permangono perchè non contraddicono lo scopo.
Come non serve piu' l'ereditarieta'.
la sto usando proprio adesso adesso, per modellare una gerarchia di oggetti che provengono da un Database...
Per il resto sono d'accordo.
Avevo iniziato con una filippica perchè sono sinceramente appassionato di OO e Dio solo sa quanti mesi abbia passato a studiarne radici, contorni e problemi.
Poi verso la tre quarti ho riletto quella pagina è m'è venuto da ridere.
Qui parliamo di orientamento agli oggetti, una prospettiva che ha due termini: oggetto e stato.
Ora quando l'autore si inarca in uno stupendo "le strutture dati e funzioni non devono essere vincolate insieme" si capisce al volo quale sia il problema: vede un programma orientato agli oggetti, lo osserva da un punto di vista strutturato e dice "a me sembra una stronzata".
E ti credo! Se osservi un programma orientato agli oggetti in termini di funzioni e strutture dati vedrai funzioni e strutture dati sparse ovunque senza una ragione. Se non lo vedessi saresti cieco.
E' come prendere un programma erlang e vederlo da un punto di vista orientato agli oggetti: vedi un unico enorme oggetto che fa tutto e anche di più. E' naturale domandarsi che si sia fumato uno che scrive un oggetto così.
E mi viene da ridere quando lo vedo inciampare sul selciato e tuffarsi in un pozzangherone di melma nel punto in cui dice "tutto deve essere un oggetto". Ma siamo seri! Sono tremila anni che si sa che le definizioni totalizzanti cadono nella regressio ad infinitum, questo si alza la mattina "Tutto dev'essere un oggetto" e parte cantando Area Krishna Are Are.
In un sistema orientato agli oggetti ci sono cose che NON SONO OGGETTI e il sistema sta in piedi proprio per questo. Sono quelle che cose che scopri di non poter cambiare altrimenti il tuo sistema resta in mutande di pagliericcio. A volte è una scelta consapevole, a volte no.
Sul private non mi pronuncio. E' certo che l'autore non sappia di che parla perchè l'esistenza di private non ha a che fare con lo stato di un oggetto ma con il tipo di rappresentazione di quello stato. Non mi pronuncio perchè nella teoria della prospettiva orientata agli oggetti che cerco faticosamente di ricostruire ormai da un bel po' di tempo tenderei ad escludere la rilevanza dei modificatori di accesso. Ed è una questione da prendere con le pinze.
Tolto dal nostro panorama quel pezzo d'avanspettacolo il futuro è, secondo me, nel significato originale dell'orientamento agli oggetti.
Che, a scanso di equivoci, oggi si è completamente perduto. Non è di molto tempo fa la notizia secondo cui Alan Kay avrebbe ridefinito il suo orientamento gli oggetti "Message Oriented Programming". Pardon, 50 anni fa ho detto una cazzata? No, semplicemente il termine ha assunto altre colorazioni.
Chi dice oggetto oggi pensa a classe, polimorfismo, ereditarietà ma queste sono conseguenze dell'orientamento agli oggetti, non principi, sono paradigmi nel senso di indicatori, non cause.
L'OO nasce come tentativo di superare prospettive intermedie tra un punto di vista che un essere umano assume quando acquisice conoscenza di un fenomeno e i termini della prospettiva procedurale, quei valori immagazzinati in registri di memoria che soggetti ad operazioni elementari producono la simulazione del fenomeno da parte di un calcolatore.
Nel tentativo, ahinoi, ci è morta. Più che altro ammazzata dai vari Gamma e Fowler con la complicità di chi gli è andato dietro senza farsi troppe domande.
Il futuro è ancora orientato agli oggetti nel senso che sarà ancora la ricerca di una forma più umana e meno schematica di dire a un calcolatore quello che deve fare.
Non sarà la programmazione funzionale perchè è settant'anni che gira e nonostante le presunzioni di alcuni c'è stata gente intelligente che l'ha studiata e ha semplicemente detto: fa schifo.
Concordo su molti punti ma cosa avrebbero fatto Gamma e Fowler di preciso per "ammazzare" la OO?
L'ereditarietà è la trasmissione di caratteristiche essenziali da un genere ad una specie. La sua inutilità - o, meglio, la sua infondatezza - è stata dimostrata negli anni '80 (o '90 non mi ricordo bene) con la critica alla teoria classica dei concetti.
Quando si affronta la creazione di una gerarchia ereditaria la domanda che uno dovrebbe farsi è: quali tra le caratteristiche che hanno i miei oggetti sono essenziali per definirli di tipo A, B, C?
Bene, la critica alla teoria classica dice che l'essenzialità in sè è indimostrabile e se non posso dimostrare l'essenzialità di una caratteristica ai fini dell'appartenenza di una specie al genere allora l'ereditarietà non ha senso - perchè è fondata su questa essenzialità.
Non è un caso che, negli ultimi anni, il baricentro delle relazioni tra oggetti si sia spostato dall'ereditarietà alla composizione: la composizione è molto più facile da giustificare. E' il meccanismo attraverso cui si realizza l'esistenza di uno stato.
Dunque la tua gerarchia ereditaria è sbagliata? Assolutamente no. Il punto a cui prestare attenzione è che non puoi dare per scontato che tutto ciò che definisci nel supertipo sia anche tutto e solo ciò che è necessario ai sottotipi per operare in modo conforme al tuo sistema di riferimento. E' possibile che ad un certo punto un "metodo" del supertipo perda utilità nel sottotipo o che si scopra l'esigenza di aggiungerne un altro. Questa possibillità non deve essere interpretata come un errore nella creazione della gerarchia: è proprio un problema insito nell'ereditarietà.
L'ereditarietà è la trasmissione di caratteristiche essenziali da un genere ad una specie. La sua inutilità - o, meglio, la sua infondatezza - è stata dimostrata negli anni '80 (o '90 non mi ricordo bene) con la critica alla teoria classica dei concetti.
Quando si affronta la creazione di una gerarchia ereditaria la domanda che uno dovrebbe farsi è: quali tra le caratteristiche che hanno i miei oggetti sono essenziali per definirli di tipo A, B, C?
Bene, la critica alla teoria classica dice che l'essenzialità in sè è indimostrabile e se non posso dimostrare l'essenzialità di una caratteristica ai fini dell'appartenenza di una specie al genere allora l'ereditarietà non ha senso - perchè è fondata su questa essenzialità.
Non è un caso che, negli ultimi anni, il baricentro delle relazioni tra oggetti si sia spostato dall'ereditarietà alla composizione: la composizione è molto più facile da giustificare. E' il meccanismo attraverso cui si realizza l'esistenza di uno stato.
Dunque la tua gerarchia ereditaria è sbagliata? Assolutamente no. Il punto a cui prestare attenzione è che non puoi dare per scontato che tutto ciò che definisci nel supertipo sia anche tutto e solo ciò che è necessario ai sottotipi per operare in modo conforme al tuo sistema di riferimento. E' possibile che ad un certo punto un "metodo" del supertipo perda utilità nel sottotipo o che si scopra l'esigenza di aggiungerne un altro. Questa possibillità non deve essere interpretata come un errore nella creazione della gerarchia: è proprio un problema insito nell'ereditarietà.
Sono meno critico nei confronti dell'ereditarieta'.
Mi ritrovo molto bene con la progettazione a pattern, dove l'ereditarieta' e' usata a piene mani, e ne faccio largo uso anche io.
Certo, capita come dici che un metodo possa non servire in una delle classe figlie, ma se non serve non significa che faccia male. Semplicemente non lo userai, e non avrai speso piu' tempo in quanto comunque scritto e testato una sola volta per tutte.
Non servire non significa neppure che non abbia senso. Avrebbe comunque senso se venisse usato, altrimenti e' un problema di disegno.
Idem per il dynamic binding. Non capita spesso di usarlo, ma quando lo si usa il disegno assume subito uno stato di consistenza che ti fa dire: "Si', ho fatto la cosa giusta". E' un trigger che ti fa pensare di avere capito e usato la programmazione ad oggetti per la sua capacita'.
Un altro esempio di qualche mese fa. Stavo (e ancora parzialmente ora) lavorando su un progetto web. Tutte le pagine sia client che server side derivano da un oggetto BasePage comune, tutti i controlli derivano da un altro oggetto BaseControl comune.
Ovviamente le classi base hanno sia metodi propri che metodi astratti da implementarsi, e in men che non si dica tutte le pagine vengono dotate di facilities impagabili. Autenticazione scritta una volta sola, metodi per la ricerca di sotto-controlli, handlers degli errori e tanto altro.
Non so. Ritengo l'ereditarieta' fondamentale in molti aspetti della programmazione ad oggetti.
Poi non nego che la maggior parte delle classi utente sono strutture piatte in cui si fa uso solo dell'incapsulamento come proprieta' della OOP. Ma senza l'ereditarieta' molte parti di codice sarebbe davvero piu' prolisse e alcune cose verrebbero fuori proprio male.
Concordo su molti punti ma cosa avrebbero fatto Gamma e Fowler di preciso per "ammazzare" la OO?
Quello che non riesco a "perdonare" alla Gang Of Four è il fatto di essersi "inventati" questa idea dei pattern come modelli applicabili allo sviluppo di software orientato agli oggetti.
I pattern, e lo dicono loro, nascono come pratiche diffuse. Sono schemi ricorrenti nella rappresentazione software della soluzione di certi problemi.
E fin qui siamo in una botte di ferro. E' anche una lettura interessante.
Il problema nasce quando dallo schema ricorrente passo allo schema che dovrei applicare nel software. E non ditemi che non c'è un'aura di doverosità intorno ai pattern. A volte si potrebbe parlare di Pattern Oriented Programming.
Il salto dalla ricorrenza all'applicabilità è inusitato. Una cosa non è corretta perchè tanti lo fanno.
Qui facciamo la fine dei Lemming. "Ragazzi tuffiamoci dalla scogliera che qui l'acqua è alta". Cento beccano la pozza e gli altri quaranta milioni si schiantano sugli scogli.
L'uso di un pattern è di per sè ingiustificabile. Perchè non è fondato su una teoria, che può essere vera o falsa. Il pattern è poco più di una rilevazione statistica.
La cosa assume i contorni della presa in giro quando un "pattern" si trasforma in "anti-pattern". C'è uno schema ricorrente che viene rilevato e diventa pattern. Dopodichè si scopre che in corrispondenza dello schema si produce una divergenza tra il sistema di riferimento ed il modello di sistema. A quel punto uno direbbe: guardate che a volte capita che tanti facciano una stupidata. Questo pattern è uno di quei casi. No. Creiamo il concetto di anti-pattern. Ora, se il pattern è una pratica ricorrente l'anti-pattern dovrebbe essere una pratica quantomeno sporadica. Invece è una sorta di errore demoniaco in cui incorre chi non dispone dell'ultimo volume di Design Pattern, in cui gli autori si rimangiano quando detto la volta prima.
Non mi sembra che questi siano rilevi assurdi.
Eppure ci sono schiere di adoranti per i quali non mettere "pattern" ogni tre righe sembra essere un insulto.
Fowler fa lo stesso solo che i pattern stavolta si chiamano refactoring.
Il punto è sempre quello. Per quanto variegata l'informatica è pur sempre una scienza. In quanto tale richiede che si provi quantomeno a fondare ciò che si dice su una teoria falsificabile.
Un esempio di teoria falsificabile sarebbe ad esempio quella che dicesse "la quantità di errori contenuti nel codice sorgente di un programma è una funzione del numero di righe di codice di cui è composto quel sorgente"
E' vera fintantochè non si trovi una qualsiasi coppia di codici sorgente aventi un diverso numero di righe di codice dei quali il più lungo abbia meno errori del più corto.
Apparirà bizzarro ma questa è informatica, i pattern e il refactoring no.
^TiGeRShArK^
13-03-2009, 17:49
Sono meno critico nei confronti dell'ereditarieta'.
Mi ritrovo molto bene con la progettazione a pattern, dove l'ereditarieta' e' usata a piene mani, e ne faccio largo uso anche io.
Certo, capita come dici che un metodo possa non servire in una delle classe figlie, ma se non serve non significa che faccia male. Semplicemente non lo userai, e non avrai speso piu' tempo in quanto comunque scritto e testato una sola volta per tutte.
Non servire non significa neppure che non abbia senso. Avrebbe comunque senso se venisse usato, altrimenti e' un problema di disegno.
Idem per il dynamic binding. Non capita spesso di usarlo, ma quando lo si usa il disegno assume subito uno stato di consistenza che ti fa dire: "Si', ho fatto la cosa giusta". E' un trigger che ti fa pensare di avere capito e usato la programmazione ad oggetti per la sua capacita'.
Un altro esempio di qualche mese fa. Stavo (e ancora parzialmente ora) lavorando su un progetto web. Tutte le pagine sia client che server side derivano da un oggetto BasePage comune, tutti i controlli derivano da un altro oggetto BaseControl comune.
Ovviamente le classi base hanno sia metodi propri che metodi astratti da implementarsi, e in men che non si dica tutte le pagine vengono dotate di facilities impagabili. Autenticazione scritta una volta sola, metodi per la ricerca di sotto-controlli, handlers degli errori e tanto altro.
Non so. Ritengo l'ereditarieta' fondamentale in molti aspetti della programmazione ad oggetti.
Poi non nego che la maggior parte delle classi utente sono strutture piatte in cui si fa uso solo dell'incapsulamento come proprieta' della OOP. Ma senza l'ereditarieta' molte parti di codice sarebbe davvero piu' prolisse e alcune cose verrebbero fuori proprio male.
ma l'autenticazione non viene gestita automaticamente dal .net framework a partire dalla versione 2 utilizzando la membership e i suoi provider? :fagiano:
^TiGeRShArK^
13-03-2009, 17:51
Quello che non riesco a "perdonare" alla Gang Of Four è il fatto di essersi "inventati" questa idea dei pattern come modelli applicabili allo sviluppo di software orientato agli oggetti.
I pattern, e lo dicono loro, nascono come pratiche diffuse. Sono schemi ricorrenti nella rappresentazione software della soluzione di certi problemi.
E fin qui siamo in una botte di ferro. E' anche una lettura interessante.
Il problema nasce quando dallo schema ricorrente passo allo schema che dovrei applicare nel software. E non ditemi che non c'è un'aura di doverosità intorno ai pattern. A volte si potrebbe parlare di Pattern Oriented Programming.
Il salto dalla ricorrenza all'applicabilità è inusitato. Una cosa non è corretta perchè tanti lo fanno.
Qui facciamo la fine dei Lemming. "Ragazzi tuffiamoci dalla scogliera che qui l'acqua è alta". Cento beccano la pozza e gli altri quaranta milioni si schiantano sugli scogli.
L'uso di un pattern è di per sè ingiustificabile. Perchè non è fondato su una teoria, che può essere vera o falsa. Il pattern è poco più di una rilevazione statistica.
La cosa assume i contorni della presa in giro quando un "pattern" si trasforma in "anti-pattern". C'è uno schema ricorrente che viene rilevato e diventa pattern. Dopodichè si scopre che in corrispondenza dello schema si produce una divergenza tra il sistema di riferimento ed il modello di sistema. A quel punto uno direbbe: guardate che a volte capita che tanti facciano una stupidata. Questo pattern è uno di quei casi. No. Creiamo il concetto di anti-pattern. Ora, se il pattern è una pratica ricorrente l'anti-pattern dovrebbe essere una pratica quantomeno sporadica. Invece è una sorta di errore demoniaco in cui incorre chi non dispone dell'ultimo volume di Design Pattern, in cui gli autori si rimangiano quando detto la volta prima.
Non mi sembra che questi siano rilevi assurdi.
Eppure ci sono schiere di adoranti per i quali non mettere "pattern" ogni tre righe sembra essere un insulto.
Fowler fa lo stesso solo che i pattern stavolta si chiamano refactoring.
Il punto è sempre quello. Per quanto variegata l'informatica è pur sempre una scienza. In quanto tale richiede che si provi quantomeno a fondare ciò che si dice su una teoria falsificabile.
Un esempio di teoria falsificabile sarebbe ad esempio quella che dicesse "la quantità di errori contenuti nel codice sorgente di un programma è una funzione del numero di righe di codice di cui è composto quel sorgente"
E' vera fintantochè non si trovi una qualsiasi coppia di codici sorgente aventi un diverso numero di righe di codice dei quali il più lungo abbia meno errori del più corto.
Apparirà bizzarro ma questa è informatica, i pattern e il refactoring no.
questo è più che altro un problema dovuto al non corretto utilizzo dei pattern dovuto al loro abuso ;)
Un pattern è uno strumento e va utilizzato SE e QUANDO serve.
Utilizzare in maniera impropria uno strumento solo perchè è pratica comune è sbagliato e perfino dannoso. :p
ma l'autenticazione non viene gestita automaticamente dal .net framework a partire dalla versione 2 utilizzando la membership e i suoi provider? :fagiano:
Occorreva scrivere un proprio "RoleProvider" perche' il server di autenticazione non era un LDap classico.
Una volta scritto il Framework l'ha accettato e tutto e' andato bene.
Ma fatto 30 abbiamo fatto 31, e ogni pagina dispone sia lato client che lato server di altre facilities correlate.
questo è più che altro un problema dovuto al non corretto utilizzo dei pattern dovuto al loro abuso ;)
Un pattern è uno strumento e va utilizzato SE e QUANDO serve.
Utilizzare in maniera impropria uno strumento solo perchè è pratica comune è sbagliato e perfino dannoso. :p
Pragmaticamente dirò che vediamo la cosa in modo diverso :D.
^TiGeRShArK^
13-03-2009, 18:06
Pragmaticamente dirò che vediamo la cosa in modo diverso :D.
infatti. :p
d'altronde ognuno è libero di utilizzare gli strumenti che ritiene + opportuni nelle varie situazioni, e io mi trovo benissimo in taluni casi con i pattern e praticamente sempre col refactoring. :D
PGI, la tua spiegazione la trovo troppo generica.
Il refactoring che cosa c'entra con i pattern?
Inoltre il refactoring non e` assolutamente legato alla programmazione OOP quindi non capisco perche` lo stai menzionando.
^TiGeRShArK^
13-03-2009, 18:14
PGI, la tua spiegazione la trovo troppo generica.
Il refactoring che cosa c'entra con i pattern?
Inoltre il refactoring non e` assolutamente legato alla programmazione OOP quindi non capisco perche` lo stai menzionando.
beh.. per me il refactoring è il naturale completamento della programmazione ad oggetti dato che permette di definire in maniera migliore il codice di un oggetto, portandoti anche a strutturarlo meglio.
Anche se ovviamente è trasversale e non è legato alla OOP :p
banryu79
13-03-2009, 18:26
Anche secondo me la fattorizzazione del codice non è appannaggio esclusivo del paradigma OO.
Non riesco a immaginare che influenze abbia avuto questa pratica rispetto l'evoluzione della prospettiva OO.
mindwings
13-03-2009, 18:37
cut
Un esempio di teoria falsificabile sarebbe ad esempio quella che dicesse "la quantità di errori contenuti nel codice sorgente di un programma è una funzione del numero di righe di codice di cui è composto quel sorgente"
cut
Insomma la probabilita` di trovare errori in un codice piu` prolisso e' sicuramente maggiore rispetto ad un sorgente piu` compatto a questo non si scappa...Oltre agli errori e` importante considerare che piu` e` lungo il codice sorgente piu` e` difficile da manutenere... qualcuno dovra` leggerlo/comprenderlo/adattarlo in base alle esigenze :doh:
mindwings
13-03-2009, 18:42
Il numero di bug è proporzionale al numero di linee, ma solo a parità di linguaggio ;)
Fonte?:stordita:
banryu79
13-03-2009, 18:42
Insomma la probabilita` di trovare errori in un codice piu` prolisso e' sicuramente maggiore rispetto ad un sorgente piu` compatto a questo non si scappa...Oltre agli errori e` importante considerare che piu` e` lungo il codice sorgente piu` e` difficile da manutenere... qualcuno dovra` leggerlo/comprenderlo/adattarlo in base alle esigenze :doh:
Non è detto, io non penso che il semplice numero di caratteri (lunghezza del codice) sia determinante; tenenderei a cercare le cause del maggior numero di bug nella complessità del flusso di esecuzione codificato.
Poi va da sè che tra un sorgente di 50.000 linee e un sorgente di 5.000.000 di linee il secondo sia quello che ha più probabilità di codificare un flusso di esecuzione più complesso...
^TiGeRShArK^
13-03-2009, 18:44
Fonte?:stordita:
prova a confrontare un codice scritto in python/ruby con uno scritto in java.
Non è detto che quello in java debba avere + bug anche se è + lungo.
Inoltre le LOC sono solo un parametro per valutare la complessità del codice, un altro piuttosto utilizzato è la complessità ciclomatica.
Io comunque preferisco scrivere di + se può aumentare la leggibilità del codice dato che una leggibilità maggiore dovrebbe abbassare il numero di bug.
mindwings
13-03-2009, 18:48
Poi va da sè che tra un sorgente di 50.000 linee e un sorgente di 5.000.000 di linee il secondo sia quello che ha più probabilità di codificare un flusso di esecuzione più complesso...
E` quello che intendo ci sono certi linguaggi che permettono di esprimere molto con poche righe... Un esempio banale potrebbe essere il confronto tra il quicksort in haskell e quello codificato in C/C++/Java
PGI, la tua spiegazione la trovo troppo generica.
Il refactoring che cosa c'entra con i pattern?
Al pari dei pattern anche il refactoring è infondato. E' una questione di definizione. Un cambiamento alla struttura interna del software per rendere più facile da capire e più economico da modificare senza cambiare il suo comportamento osservabile.
In grassetto il fuoco che scotta e l'acqua che bagna. La fondatezza di una teoria è un fatto, non è un'opinione.
Inoltre il refactoring non e` assolutamente legato alla programmazione OOP quindi non capisco perche` lo stai menzionando.
Dovresti dare un'occhiata a Refactoring, Improving Design of Existing Code, di M. Fowler. Oltre alle parte introduttiva (i meccanismi della programmazione OO sono di grande aiuto all'applicazione del refactoring, M. Fowler, Refactoring, prefazione) mi riferisco al fatto che solo le mutazioni più elementari siano effettivamente applicabili senza far uso di strumenti OO. In particolare sono applicabili a linguaggi procedurali i refactoring da Extract Method a Substitute Algrithm (con un dubbio su Replace Method With Method Object che tuttavia sarebbe riproducibile con una struttura dati e una funzione quindi riterrei appartenere alla specie "procedurale").
Da Move Method a Introduce Local Excetion mi appare tutto presuppore l'esistenza del concetto di Oggetto salvo Move Field.
Da self encapsulate field a replace class with sub fields escluderei il primo e l'ultimo e basta.
Si salvano le strutture di controllo (incluso replace conditional with polimorphysm) ma sono 7 o 8.
Tralascio il resto.
Quel libro parla di oggetti, parla di programmazione orientata agli oggetti e dice un mucchio di stupidaggini.
^TiGeRShArK^
13-03-2009, 18:52
E` quello che intendo ci sono certi linguaggi che permettono di esprimere molto con poche righe... Un esempio banale potrebbe essere il confronto tra il quicksort in haskell e quello codificato in C/C++/Java
per questo il paragone va fatto solo a parità di linguaggio ;)
mindwings
13-03-2009, 18:55
per questo il paragone va fatto solo a parità di linguaggio ;)
Si ma se tu conoscessi haskell quale versione preferiresti? :)
mindwings
13-03-2009, 19:09
Non so perché ma ho come la sensazione che sia uno dei vecchi hardcore programmer unix che fa tutto da shell. Probabilmente non riesce a staccarsi da vim e grep. :asd:
Adoro questo genere di commenti:D , davvero sono altamente utili ai fini della discussione...
Qui c'e' qualcosa di interessante prodotto da Armstrong (http://www.google.it/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fwww.sics.se%2F~joe%2Fthesis%2Farmstrong_thesis_2003.pdf&ei=FaC6SYSbCsqKsAbd3anoDg&usg=AFQjCNFu5wUDnslt8V30HaUcKdQ_eT3JIw&sig2=NlvDU7AAwcIMaHiZMctHsQ)
Deve essere un po' frustrato perché dopo venti anni di sviluppo il suo linguaggio non ha ancora avuto il successo che sperava mentre la programmazione ad oggetti ha semplicemente conquistato tutti.
Concordo in toto :D
~FullSyst3m~
13-03-2009, 20:00
Perfetto PGI, su questo punto sono perfettamente d'accordo con quanto esprimi qui (hai espresso con chiarezza lo stesso concetto che volevo trasmettere anch'io).
:sbonk: :rotfl: ecco perchè i Vulcaniani non esistono :asd:
Credo anche io che sia il nocciolo della questione.
Forse è poco probabile riuscire ad ottenere il miglior risultato possibile per avvicinarsi a questo scopo con un unico paradigma: perchè in campo non entra solo la faccenda del "come le vedrebbe un essere umano" riferito a fenomeni materiali che interagiscono fra loro ma è più un "come se le rappresenterebbe un essere umano" riferito non a fenomeni ma a relazioni logiche tra concetti, e in tal caso, secondo me, non può bastare sempre e solo una prospettiva o paradigma, proprio perchè la mente umana può assumerne di diversi nel guardare/studiare/analizzare/modellare/concettualizzare/strutturare/eccetera uno stesso "costrutto".
Può cioè (e se ne ha la possibilità e le conviene lo fa) "guardare lo stesso punto da una pluralità di punti di vista".
Il punto di vista cambia, l'oggetto osservato forse no...
Però, se parliamo di rappresentare nel modo più simile possibile il ragionamento e il punto di vista umano, dobbiamo anche ricordare che un oggetto, un "qualcosa", se osservato, può anche cambiare il suo stato.
^TiGeRShArK^
13-03-2009, 20:06
Si ma se tu conoscessi haskell quale versione preferiresti? :)
per il quicksort haskell.
Per molte altre cose il C# o ruby.
Adoro questo genere di commenti:D , davvero sono altamente utili ai fini della discussione...
Un po' acidello questa sera mind? :D
mindwings
13-03-2009, 21:26
Un po' acidello questa sera mind? :D
No davvero la discussione e` interessante :) e sarebbe bello discutere pacificamente senza fare gli integralisti:p
mindwings
13-03-2009, 21:34
Concordo in toto :D
Il linguaggio e` nato per risolvere un problema specifico... E l'ha risolto.
Successivamente e` stato reso opensource
Non so perché ma ho come la sensazione che sia uno dei vecchi hardcore programmer unix che fa tutto da shell. Probabilmente non riesce a staccarsi da vim e grep. :asd:
Io sono un Java fan boy, ma quando mi tocca fare da sysadmin, ho il mio bel pacchetto di bash script pronti. E sotto alcuni punti di vista sono anche più potenti di Java :)
beh.. per me il refactoring è il naturale completamento della programmazione ad oggetti dato che permette di definire in maniera migliore il codice di un oggetto, portandoti anche a strutturarlo meglio.
Anche se ovviamente è trasversale e non è legato alla OOP :p
il refacoring lo puoi applicare a un metodo di una classe, o a una funzione.. quindi non è direttamente legato alla programmazione OOP o funzionale..
il refacoring lo puoi applicare a un metodo di una classe, o a una funzione.. quindi non è direttamente legato alla programmazione OOP o funzionale..
Applicami un replace type code with class ad una funzione.
Al pari dei pattern anche il refactoring è infondato. E' una questione di definizione. Un cambiamento alla struttura interna del software per rendere più facile da capire e più economico da modificare senza cambiare il suo comportamento osservabile.
In grassetto il fuoco che scotta e l'acqua che bagna. La fondatezza di una teoria è un fatto, non è un'opinione.
Dovresti dare un'occhiata a Refactoring, Improving Design of Existing Code, di M. Fowler. Oltre alle parte introduttiva (i meccanismi della programmazione OO sono di grande aiuto all'applicazione del refactoring, M. Fowler, Refactoring, prefazione) mi riferisco al fatto che solo le mutazioni più elementari siano effettivamente applicabili senza far uso di strumenti OO. In particolare sono applicabili a linguaggi procedurali i refactoring da Extract Method a Substitute Algrithm (con un dubbio su Replace Method With Method Object che tuttavia sarebbe riproducibile con una struttura dati e una funzione quindi riterrei appartenere alla specie "procedurale").
Da Move Method a Introduce Local Excetion mi appare tutto presuppore l'esistenza del concetto di Oggetto salvo Move Field.
Da self encapsulate field a replace class with sub fields escluderei il primo e l'ultimo e basta.
Si salvano le strutture di controllo (incluso replace conditional with polimorphysm) ma sono 7 o 8.
Tralascio il resto.
Quel libro parla di oggetti, parla di programmazione orientata agli oggetti e dice un mucchio di stupidaggini.
Cioe` tu attacchi il refactoring basandoti sugli esempi scritti su un libro? Come dire che Ruby fa schifo perche` non ti e` piaciuto uno dei tutorial che hai trovato online...
Che cosa in particolare non va bene nel refactoring? Nel tuo mondo ideale come si produce il software?
Quali sono le alternative valide a: Unit Testing, Refactoring, Design Patterns? Rispetto moltissimo le tue opinioni ma non ho ancora visto nessuna alternativa nei tuoi commenti, solo critiche!
Applicami un replace type code with class ad una funzione.
Puoi scriverlo in italiano, per favore?
per il quicksort haskell.
Per molte altre cose il C# o ruby.
Il quicksort in C e' qsort(...)
In C# e' .Sort()
non conosco haskell ma mi sembra comunque gia' compatto.
mindwings
13-03-2009, 22:37
Il quicksort in C e' qsort(...)
In C# e' .Sort()
non conosco haskell ma mi sembra comunque gia' compatto.
Ma lol l'implementazione qualcuno l'avra` scritta...
Io ho il pieno rispetto di tutte le opinioni di chiunque.
Le mie alternative a Pattern, Refactoring, Unit Testing (sì, pure questo è insensato) si chiamano: studio, studio, studio.
Sul punto riconosco di essere un po' talebano ma, esemplificando, ecco qual'è la mia soluzione.
Se programmi nel linguaggio X significa che conosci le specifiche del linguaggio dalla prima all'ultima pagina come fosse l'ave maria. Accanto a questo aggiungi la piena completa e ferrea conoscenza della API di X che dovrai usare. Se nel codice scrivi una virgola devi sapere perchè l'hai scritta, cosa succede se non la scrivi, che alternative hai a quella virgola e devi essere in grado di dimostrare che la scelta che hai fatto tra quelle alternative è obiettivamente la migliore.
Questo è quello che deve sapere uno che voglia avvicinarsi ad una tastiera "in produzione".
Non ho la fortuna di essere un tale programmatore ma ho avuto il privilegio di conoscerne qualcuno e in fede ti assicuro che la produttività di queste persone vale trent'anni di refactoring, due betoniere di pattern e tutti i test che uno può immaginare.
Quanto alla progettazione occorre avere una completa ed esaustiva conoscenza del fenomeno. Il che richiede conoscenze trasversali. Pagare un terzo per farsi dire come funzionano le cose non è un'opzione.
Sia i programmatori che i progettisti devono inoltre avere una conoscenza superiore della prospettiva che intenderanno usare per la traduzione del progetto. Vita, morte e miracoli.
Di questi francamente non ne ho mai conosciuto uno.
Per fare software bisogna ammazzarsi sui libri e sul campo. Fine. Non c'è la ricetta magica del mago zurlì, il dado che fa il brodo più semplice e digeribile. C'è solo il lavoro, lavoro, lavoro.
Ecco, questa è la mia soluzione. Possibilità che sia adottata? ZERO.
Perchè il motto dell'informatica nell'anno del signore 2009 è: credere, obbedire, programmare.
A sapere ci pensiamo la prossima volta.
Quanto al "replace type code with class", Refactoring, Fowler, pagina 218, ed. 2005.
Ma lol l'implementazione qualcuno l'avra` scritta...
Gia', ma magari rispettivamente non in C o in C# (sull'ultima non ci scommetto pero')
^TiGeRShArK^
13-03-2009, 22:57
Il quicksort in C e' qsort(...)
In C# e' .Sort()
non conosco haskell ma mi sembra comunque gia' compatto.
:asd:
ovviamente parlavamo di un'ipotetica implementazione ex-novo :p
:asd:
ovviamente parlavamo di un'ipotetica implementazione ex-novo :p
Ma si', era solo per sottilettare.
E poi comunque capitava in passato di trovare in giro implementazione di un improbabilmente brutto sort a caso scritto in C, ma solo perche' lo sviluppatore di turno non conosceva l'esistenza della funzione qsort di libreria.
Per esempio mi aspetterei che la qsort di libreria C, o la OrderBy e la Sort di libreria C# siano scritte ottimizzate, ovvero che degradino alla Bubble Sort (o altri O(N2) per piccole lunghezze di array da ordinare, dove il vecchio Bubble Sort e' piu' veloce del QuickSort. Magari addirittura iterativo.
Io ho il pieno rispetto di tutte le opinioni di chiunque.
Le mie alternative a Pattern, Refactoring, Unit Testing (sì, pure questo è insensato) si chiamano: studio, studio, studio.
Sul punto riconosco di essere un po' talebano ma, esemplificando, ecco qual'è la mia soluzione.
Se programmi nel linguaggio X significa che conosci le specifiche del linguaggio dalla prima all'ultima pagina come fosse l'ave maria. Accanto a questo aggiungi la piena completa e ferrea conoscenza della API di X che dovrai usare. Se nel codice scrivi una virgola devi sapere perchè l'hai scritta, cosa succede se non la scrivi, che alternative hai a quella virgola e devi essere in grado di dimostrare che la scelta che hai fatto tra quelle alternative è obiettivamente la migliore.
Questo è quello che deve sapere uno che voglia avvicinarsi ad una tastiera "in produzione".
Non ho la fortuna di essere un tale programmatore ma ho avuto il privilegio di conoscerne qualcuno e in fede ti assicuro che la produttività di queste persone vale trent'anni di refactoring, due betoniere di pattern e tutti i test che uno può immaginare.
Quanto alla progettazione occorre avere una completa ed esaustiva conoscenza del fenomeno. Il che richiede conoscenze trasversali. Pagare un terzo per farsi dire come funzionano le cose non è un'opzione.
Sia i programmatori che i progettisti devono inoltre avere una conoscenza superiore della prospettiva che intenderanno usare per la traduzione del progetto. Vita, morte e miracoli.
Di questi francamente non ne ho mai conosciuto uno.
Per fare software bisogna ammazzarsi sui libri e sul campo. Fine. Non c'è la ricetta magica del mago zurlì, il dado che fa il brodo più semplice e digeribile. C'è solo il lavoro, lavoro, lavoro.
Ecco, questa è la mia soluzione. Possibilità che sia adottata? ZERO.
Perchè il motto dell'informatica nell'anno del signore 2009 è: credere, obbedire, programmare.
A sapere ci pensiamo la prossima volta.
Quanto al "replace type code with class", Refactoring, Fowler, pagina 218, ed. 2005.
Sei ancora riuscito a non dire niente... Cosa vuol dire studio, studio, studio? Diventare perfetti nell'uso di un linguaggio prima di iniziare a scrivere e non dover mai testare codice ne rifattorizzare perche` doveva essere gia` perfetto e privo di bug in origine?
Ti prego di non fraintendermi se ti faccio questa domanda ma che lavoro fai e quanti anni di esperienza hai?
~FullSyst3m~
13-03-2009, 23:53
Sei ancora riuscito a non dire niente... Cosa vuol dire studio, studio, studio? Diventare perfetti nell'uso di un linguaggio prima di iniziare a scrivere e non dover mai testare codice ne rifattorizzare perche` doveva essere gia` perfetto e privo di bug in origine?
Ti prego di non fraintendermi se ti faccio questa domanda ma che lavoro fai e quanti anni di esperienza hai?
Credimi, non stai parlando con il primo che passa. Sei caduto male qua.
Niente direi di no. Mi hai chiesto quale fosse la mia soluzione e io te l'ho detta. Bisogna studiare di più. Ritengo che una conoscenza migliore migliori la qualità del software. E' implicito il fatto che io ritenga insufficiente il livello medio di conoscenza, sia generale che specialistica, degli operatori nel campo informatico.
Di lavoro non faccio niente, fortunatamente per scelta, campo in cui ho un'esperienza di circa 40 giorni e che intendo protrarre per i prossimi 40 anni. Dato che fumo come un turco e ho 33 anni forse è un po' ottimistico ma ci proviamo.
Prima ho fatto il MAGAZZINIEREper un anno e un mese.
Adesso per correttezza mi fai il favore di dirmi perchè me l'hai chiesto.
Credimi, non stai parlando con il primo che passa. Sei caduto male qua.
Neanche tu stai parlando col primo che passa, so chi e` PGI-BIS.
Ma cosa vuol dire questo post? Stai contribuendo alla discussione?
E' divertentissimo :D
E' come immaginare una platea che d'improvviso apre la bocca escalamando: "ohhhhhh".
Ebbene, portate fuori le signore!
Nel 1996 (credo) ho fatto VOLANTINAGGIO (per credo sei mesi).
:eekk: :eekk: :eekk: :eekk:
:rotfl: :rotfl: :rotfl:
Prima di tutto conoscere bene il linguaggio non e` un'alternativa, e` una cosa completamente trasversale, puoi studiare bene il linguaggio E fare refactoring e testing.
Nessuno dice che queste due metodologie siano la bibbia dell'informatica ma offrono alcuni vantaggi e non capisco perche` dovrebbero "ammazzare la OOP" come tu dici.
La tua risposta secondo me gira intorno alla mia domanda e non offre valide alternative.
In realta` la mia domanda doveva essere formulata diversamente; non mi interessa se lavori, anche se facessi il magazziniere tutta la vita non avrebbe importanza.
Sarebbe bello sapere in che modo partecipi allo sviluppo di software scrivendo codice ed affrontando problemi reali legati a questo ambiente visto che da come scrivi sembri piu` legato alla filosofia dell'informatica, i modelli della comunicazione uomo-macchina ed altro.
~FullSyst3m~
14-03-2009, 01:35
Neanche tu stai parlando col primo che passa, so chi e` PGI-BIS.
Ma cosa vuol dire questo post? Stai contribuendo alla discussione?
Questo post vuol dire ciò che ho detto. Da come parli sembra che le tue idee siano legge. Apparte questo, se leggi il post nella sua interezza, ho contribuito anche io.
Questo post vuol dire ciò che ho detto. Da come parli sembra che le tue idee siano legge. Apparte questo, se leggi il post nella sua interezza, ho contribuito anche io.
OK, ora pero` mi spieghi quali leggi avrei dettato visto che sto solo facendo domande.
Sto chiedendo delucidazioni ad una persona che mi sembra preparata su un argomento ma che sta usando argomentazioni che secondo me non hanno significato.
wingman87
14-03-2009, 02:09
@PGI-Bis: ma stai dicendo che refactoring, unit testing e pattern sono inutili/insensati o stai dicendo che in una evoluzione futura delle tecniche di programmazione non serviranno più a nulla? Oppure non ho capito niente? Sai parli di argomenti che ho visto solo da lontano e lo fai anche in maniera abbastanza specifica...
Nella mia ignoranza di (ex) magazziniere - stupenda esperienza di vita reale che consiglio a chiunque voglia conoscere la parte vera delle persone - non vedo cosa centri il tuo interesse per quello che ho fatto, faccio, o farò. Se dicessi che ho insegnato fondamenti di informatica, cosa cambierebbe? Se dicessi che possiedo uno studio di consulenza finanziaria, cosa cambierebbe?
Forse il mio modello Unico sarebbe in grado di convincerti che dire (cito):
"Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observalbe behavior"
non ha significato scientifico? Non è logico dire che essendo lo studio attività di acquisizione di una coscienza critica chiunque prenda per anche solo plausibile quella definizione debba cominciare o ricominciare a studiare?
Quella definizione non ha significato perchè usa due termini di valore, easy e cheap, i termini di valore sono relativi e questa relatività impedisce all'affermazione di creare almeno due ripartizioni del tutto, ciò che corrisponde e ciò che non corrisponde alla definizione.
Questa è la mia critica al refactoring: è indefinito.
Ritengo la critica pertinente all'argomento del thread perchè delle 72 specie di refactoring che Fowler cita nel volume Refactoring, Improving The Design of Existing Code, almeno 48 presuppongono concetti comunemente, ancorchè in parte erroneamente, ricondotti all'orientamento agli oggetti.
Anche ove questa frequenza non fosse significativa basterebbe che l'applicabilità a programmi orientati agli oggetti non fosse esclusa per poter dire che parlare di Refactoring in tema di Orientamento agli Oggetti è pertinente.
Ritieni sensato dire che l'uso di uno strumento le cui premesse sono LOGICAMENTE non valide nello sviluppo di software abbia conseguenze non prevedibili?
Questa esposizione, che peraltro mi fa sentire un cattedratico ottuagenario, soddisfa la tua esigenza di verificare se ciò che dico è vero o falso?
Spero di sì perchè in altro modo non saprei dirla. La questione è simile per i pattern.
Attendo sempre la risposta alla mia domanda: perchè mi hai chiesto che lavoro facessi?
Lo diceva sempre Milton Erickson: fate i magazzinieri se volete conoscere le persone veramente. No comment dai.
Comunque ho gia` risposto alla tua domanda, se la risposta non ti soddisfa non so che farci, ero curioso e basta. Forse sospetti che stessi cercando di smontarti sull'esperienza lavorativa ma non e` cosi`, non sono quel tipo di persona.
Se il refactoring e` indefinito come ha fatto ad "uccidere la OOP" come hai detto in qualche post precedente? Per la definizione che hai appena citato il Refactoring non e` legato alla OOP no?
Che cosa c'entrano gli esempi poi? Io il refactoring lo vedo come una pratica e non come un set di casi specifici. Il fatto che gli esempi si riferiscono alla OOP magari e` solo per comodita`/diffusione/scopo informativo.
Ma poi Gamma lo hai accusato per i Design Pattern o anche per il contributo sul Unit Testing?
@PGI-Bis: ma stai dicendo che refactoring, unit testing e pattern sono inutili/insensati o stai dicendo che in una evoluzione futura delle tecniche di programmazione non serviranno più a nulla? Oppure non ho capito niente? Sai parli di argomenti che ho visto solo da lontano e lo fai anche in maniera abbastanza specifica...
Io ritengo (e penso di poter dimostrare) che il Refactoring per come è definito da Fowler, lo Unit Testing in sè - credo che sia perorato da Beck ma non ne sono sicuro - e i Pattern per come definiti da Gamma e altri, siano insensati.
Questo non significa negare che:
1. esistano schemi organizzativi statisticamente ricorrenti nei modelli di sistema
2. il codice sorgente di un programma possa essere modificato senza che questo abbia ripercussioni sulla corrispondenza dello stesso al sistema di riferimento
3. l'assunzione da parte del sistema di uno stato che contraddice una precondizione implicita o esplicita dimostri la presenza di un errore
cioè che esistano i pattern, che si possa fare refactoring, che lo unit testing serva a qualcosa.
Ma che una cosa esista, che si possa fare o che serva a qualcosa non significa che debba esistere sempre, che si debba fare o che risolva tutti i problemi.
Rispondo anche a UFO.
La programmazione orientata agli oggetti è già malata di suo. Facciamo le cose come le fanno gli umani significa, al meglio delle conoscenze attuali, fare almeno tre cose quasi del tutto diverse. Queste tre cose hanno in comune talmente poco che fondarci sopra uno strumento applicabile allo sviluppo di software è uno sforzo immane.
Se io dovessi spiegare oggi l'orientamento agli oggetti a qualcuno dovrei iniziare dicendogli: vedi quel contatore sulla pompa di filtraggio dello scarico? Ecco, quella pompa ha una relazione esclusiva con sè stessa definita nell'orientamento agli oggetti come principio di identità. E guardandolo negli occhi dovrei poi chiarire dicendo: è una funzione dell'oggetto nell'oggetto.
Anche supponendo di riuscire a farglielo entrare in testa senza che mi prenda a ceffoni poi dovrei aspettarmi che questo povero disgraziato si sieda ad un tavolo per sentirsi dire: ragazzi abbiamo in programma una sessione di refactoring. Perchè? Perchè lo dice Fowler. Oppure "qui applicheremo il pattern X". Perchè? Perchè l'hanno già fatto in tanti.
Può una prospettiva espressa in termini minimi ma rigorosi sopravvivere a queste contraddizioni? Penso di no, ritengo che questi fattori abbiano causato o causeranno il collasso della OOP che resta una punto di vista magnifico e quindi sarà in tutto o in parte presente anche nella sua prossima evoluzione.
rеpne scasb
14-03-2009, 08:46
■
cdimauro
14-03-2009, 09:37
Io ritengo (e penso di poter dimostrare) che il Refactoring per come è definito da Fowler, lo Unit Testing in sè - credo che sia perorato da Beck ma non ne sono sicuro - e i Pattern per come definiti da Gamma e altri, siano insensati.
Questo non significa negare che:
1. esistano schemi organizzativi statisticamente ricorrenti nei modelli di sistema
2. il codice sorgente di un programma possa essere modificato senza che questo abbia ripercussioni sulla corrispondenza dello stesso al sistema di riferimento
3. l'assunzione da parte del sistema di uno stato che contraddice una precondizione implicita o esplicita dimostri la presenza di un errore
cioè che esistano i pattern, che si possa fare refactoring, che lo unit testing serva a qualcosa.
Ma che una cosa esista, che si possa fare o che serva a qualcosa non significa che debba esistere sempre, che si debba fare o che risolva tutti i problemi.
Nessuno ha mai detto questo, ma è innegabile che generalmente sono utili e anche comodi.
Quello che noto in ciò che dici è un attaccamento troppo viscerale alla teoria e al formalismo.
Noi programmatori siamo gente un po' più semplice, ma soprattutto pragmatica. Se non fosse così ci saremmo già fermati al teorema dello stop (o dell'arresto) piangendo e autopercuotendoci per il fatto di non avere garanzie di "certezze" nella scrittura del codice.
Peggio ancora, se dovessimo modellare un'applicazione sulla base di una sola prospettiva, per realizzare un "hello, world!" dovremmo scrivere qualcosa del genere:
public class HelloWorld {
public static void main(SomeWeirdArrayOfStringsObject args) {
StringBuffer s = new StringBuffer();
s.append(new Char("H"));
s.append(new Char("e"));
s.append(new Char("l"));
s.append(new Char("l"));
s.append(new Char("o"));
s.append(new Char(","));
s.append(new Char(" "));
s.append(new Char("W"));
s.append(new Char("o"));
s.append(new Char("r"));
s.append(new Char("l"));
s.append(new Char("d"));
s.append(new Char("!"));
System.out.println(s.toString());
}
}
Non so tu, ma io preferisco il classico:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
con buona pace della teoria, del formalismo e della perfetta adesione alla prospettiva orientata agli oggetti. ;)
^TiGeRShArK^
14-03-2009, 10:18
Prima di tutto conoscere bene il linguaggio non e` un'alternativa, e` una cosa completamente trasversale, puoi studiare bene il linguaggio E fare refactoring e testing.
Nessuno dice che queste due metodologie siano la bibbia dell'informatica ma offrono alcuni vantaggi e non capisco perche` dovrebbero "ammazzare la OOP" come tu dici.
La tua risposta secondo me gira intorno alla mia domanda e non offre valide alternative.
In realta` la mia domanda doveva essere formulata diversamente; non mi interessa se lavori, anche se facessi il magazziniere tutta la vita non avrebbe importanza.
Sarebbe bello sapere in che modo partecipi allo sviluppo di software scrivendo codice ed affrontando problemi reali legati a questo ambiente visto che da come scrivi sembri piu` legato alla filosofia dell'informatica, i modelli della comunicazione uomo-macchina ed altro.
Sarebbe interessante notare come sia possibile conoscere ALLA PERFEZIONE un linguaggio di programmazione e non saper programmare. ;)
Per me refactoring e pattern, come ho già detto, sono imprescindibili dalla programmazione ad oggetti, dato che, per definizione il programmatore che non produce bug, come quello teorizzato da pgi-bis, semplicemente non esiste. :p
^TiGeRShArK^
14-03-2009, 10:22
Nella mia ignoranza di (ex) magazziniere - stupenda esperienza di vita reale che consiglio a chiunque voglia conoscere la parte vera delle persone - non vedo cosa centri il tuo interesse per quello che ho fatto, faccio, o farò. Se dicessi che ho insegnato fondamenti di informatica, cosa cambierebbe? Se dicessi che possiedo uno studio di consulenza finanziaria, cosa cambierebbe?
Forse il mio modello Unico sarebbe in grado di convincerti che dire (cito):
"Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observalbe behavior"
non ha significato scientifico? Non è logico dire che essendo lo studio attività di acquisizione di una coscienza critica chiunque prenda per anche solo plausibile quella definizione debba cominciare o ricominciare a studiare?
Quella definizione non ha significato perchè usa due termini di valore, easy e cheap, i termini di valore sono relativi e questa relatività impedisce all'affermazione di creare almeno due ripartizioni del tutto, ciò che corrisponde e ciò che non corrisponde alla definizione.
Questa è la mia critica al refactoring: è indefinito.
Ritengo la critica pertinente all'argomento del thread perchè delle 72 specie di refactoring che Fowler cita nel volume Refactoring, Improving The Design of Existing Code, almeno 48 presuppongono concetti comunemente, ancorchè in parte erroneamente, ricondotti all'orientamento agli oggetti.
Anche ove questa frequenza non fosse significativa basterebbe che l'applicabilità a programmi orientati agli oggetti non fosse esclusa per poter dire che parlare di Refactoring in tema di Orientamento agli Oggetti è pertinente.
Ritieni sensato dire che l'uso di uno strumento le cui premesse sono LOGICAMENTE non valide nello sviluppo di software abbia conseguenze non prevedibili?
Questa esposizione, che peraltro mi fa sentire un cattedratico ottuagenario, soddisfa la tua esigenza di verificare se ciò che dico è vero o falso?
Spero di sì perchè in altro modo non saprei dirla. La questione è simile per i pattern.
Attendo sempre la risposta alla mia domanda: perchè mi hai chiesto che lavoro facessi?
Allora, seguendo il tuo punto di vista, anche la semplificazione e la trasformazione di una formula matematica sarebbe inutile?
No, perchè praticamente tutte le dimostrazioni degli attuali teoremi non potrebbero avvenire senza delle trasformazioni che rendano + leggibile a noi umani un espressione senza modificarne il significato. ;)
Per me refactoring e pattern, come ho già detto, sono imprescindibili dalla programmazione ad oggetti, dato che, per definizione il programmatore che non produce bug, come quello teorizzato da pgi-bis, semplicemente non esiste. :p
Concordo. Di sicuro quelli introdotti nel libro di Fowler sono i più famosi ma esistono decine di altri libri sull'argomento. Lo scorso anno ho visto in uni un libro che trattava del refactoring di Database e so per certo che ne esiste uno che parla di HTML.
^TiGeRShArK^
14-03-2009, 10:27
Anche supponendo di riuscire a farglielo entrare in testa senza che mi prenda a ceffoni poi dovrei aspettarmi che questo povero disgraziato si sieda ad un tavolo per sentirsi dire: ragazzi abbiamo in programma una sessione di refactoring. Perchè? Perchè lo dice Fowler. Oppure "qui applicheremo il pattern X". Perchè? Perchè l'hanno già fatto in tanti.
I pattern e il refactoring, se fossimo esseri perfetti, non avrebbero alcun senso.
Il loro fine unico è quello di aumentare la "bellezza" intima del codice mantenendone la funzionalità.
Un pò come i vari passaggi di un'elegante dimostrazione matematica.
Ovvio che però bisogna avere una certa dose di "sensibilità" per riuscire a cogliere questa "bellezza" :p
mindwings
14-03-2009, 11:57
Giusto per citare un esempio di vita reale, lavorando ad un progetto per un esame - ho dovuto rifattorizzare del codice a causa di un collega che ogni
volta che trovava la soluzione per un problema anziche` rendere la soluzione
generale si limitava a copiare ed incollare la soluzione in n posti diversi :eekk:
Oppure rifattorizzavo per abbassare il numero ciclomatico dei metodi...
Capita a volte che per pigrizia/mancanza di tempo molte persone non cercano la "soluzione perfetta" piuttosto si limitano a far si che le cose funzionino...
Il problema arriva quando si vogliono fare delle modifiche aggiungendo features o migliorando alcuni aspetti e i moduli sono molto accoppiati:mad: ...
Giusto per aggiungere carne al fuoco :D alla discussione
http://codebetter.com/blogs/matthew.podwysocki/archive/2009/03/14/functional-programming-in-net-adding-extensibility.aspx
http://codebetter.com/blogs/matthew.podwysocki/archive/2009/03/09/which-is-more-beautiful-architecture-fp-or-oop.aspx
http://www.defmacro.org/ramblings/fp.html
che i patterns/refactoring/unit testing siano degli strumenti utili mi pare fuori di discussione
Giusto per citare un esempio di vita reale, lavorando ad un progetto per un esame - ho dovuto rifattorizzare del codice a causa di un collega che ogni
volta che trovava la soluzione per un problema anziche` rendere la soluzione
generale si limitava a copiare ed incollare la soluzione in n posti diversi :eekk:
Oppure rifattorizzavo per abbassare il numero ciclomatico dei metodi...
Capita a volte che per pigrizia/mancanza di tempo molte persone non cercano la "soluzione perfetta" piuttosto si limitano a far si che le cose funzionino...
Il problema arriva quando si vogliono fare delle modifiche aggiungendo features o migliorando alcuni aspetti e i moduli sono molto accoppiati:mad: ...
Uno degli approcci della extreme programming e' quello di tirare giu' la prima soluzione funzionale in modo piu' veloce possibile, anche eventualmente brutta, scomoda e assolutamente non perfetta.
In modo tale da dare modo al cliente, chiunque esso sia, di renderesi conto di cio' che molto similmente avra' come prodotto finito, validarne le richieste e tirare fuori modifiche o nuove direttive nel piu' breve tempo possibile.
Questo perche' purtroppo il cliente non sempre sa a priori cosa vuole, se sa lo spiega male oppure non aveva idea di cio' che si sarebbe potuto fare.
Passata questa prima fase si passa subito alla vera progettazione e al refactoring di parti di codice che si manuterranno.
L'esperienza quindi sta nello scrivere, gia' la prima volta, qualcosa che possa essere anche solo parzialmente riusato, per evitare di perdere tempo anche gia' alla prima volta, seppur previsto dalla metodologia.
Questo post vuol dire ciò che ho detto. Da come parli sembra che le tue idee siano legge. Apparte questo, se leggi il post nella sua interezza, ho contribuito anche io.
Allora me lo dici quali leggi avrei dettato? :)
@^TiGeRShArK^
Se andassi da uno che ha passione per la matematica e gli dicessi che le riduzioni si fanno perchè sono easy e cheap mi tirerebbe un cazzotto in faccia che a fatica riuscirei a rialzarmi :D La semplificazione è il processo di riduzione di una relazione ai termini minimi necessari e sufficienti per esprimerla. E' un procedimento logico deduttivo (cioè non dico nulla più di quanto è già nella relazione) e dunque dimostrabile. Se fosse il processo di riduzione di una relazione ai termini facili ed economici sarebbe insensata.
@cidimauro, nella prospettiva OO i due HelloWorld sono quasi identici. Entrambi definiscono un Oggetto ciascuno (HelloWorld), il primo dichiara uno stato in più del secondo, StringBuffer. Che StringBuffer sia uno stato di HelloWorld dipende dal fatto che l'identità del secondo è passibile di mutazioni riflesse (il cosidetto side effect). Non confondere il termine oggetto della prospettiva orientata agli oggetti con il termine oggetto di questo o quel linguaggio di programmazione. Il rapporto tra l'orientamento agli oggetti ed il linguaggio orientato agli oggetti è di causa ad effetto: l'effetto non determina la causa.
@repne: :D purtroppo non ricordo. Ma a sostegno delle mie affermazioni posso produrre copia di un regolare certificato di cresima. E visto che praticamente stiamo discutendo di religioni potrebbe fare la sua porca figura.
La semplificazione è il processo di riduzione di una relazione ai termini minimi necessari e sufficienti per esprimerla.
Infatti il refactoring e` praticamente la stessa cosa, riduci il codice (non solo in termini quantitativi ma anche qualitativi) ai termini minimi necessari e sufficienti per esprimere le funzionalita` richieste definite dagli unit test.
P.S. Siate adulti, il cameratismo da quattro soldi e` veramente patetico :)
Evidentemente non sono in grado di esprimermi in modo comprensibile.
Buon proseguimento.
Vabe` dai edito, grazie comunque per aver tentato
"Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observalbe behavior"
non ha significato scientifico? Non è logico dire che essendo lo studio attività di acquisizione di una coscienza critica chiunque prenda per anche solo plausibile quella definizione debba cominciare o ricominciare a studiare?
Quella definizione non ha significato perchè usa due termini di valore, easy e cheap, i termini di valore sono relativi e questa relatività impedisce all'affermazione di creare almeno due ripartizioni del tutto, ciò che corrisponde e ciò che non corrisponde alla definizione.
Questa è la mia critica al refactoring: è indefinito.
Quella definizione ha un significato preciso, basta essere in grado di comprenderlo. E non e' neppure particolarmente complesso.
Il resto che hai scritto sono chiacchiere senza alcun significato.
Alla fine della fiera l'attivita' di refactoring e' necessaria in qualunque code base piu' complessa di un centinaio di righe di codice, perche' migliora costantemente la struttura del codice, rendendolo meno costoso da mantenere, gestire e modificare all'occorrenza con il cambiamento dei requisiti.
Senza costante refactoring il codice diventa man mano ingestibile.
Io ritengo (e penso di poter dimostrare) che il Refactoring per come è definito da Fowler, lo Unit Testing in sè - credo che sia perorato da Beck ma non ne sono sicuro - e i Pattern per come definiti da Gamma e altri, siano insensati.
Quello che ritieni e' indifferente: esistono svariati studi ai quali ti rimando che dimostrano come pratiche quali unit testing (che non e' nato con Beck, ma diverse decine di anni fa) e refactoring (anche questo non e' nato con Fowler) portano a codice con meno difetti.
Qui ti mancano le basi per poter discutere di questi argomenti. E come se io volessi parlare di punto croce senza aver mai preso l'uncinetto in mano. Infatti non ne parlo.
Bentornato ;)
Avresti qualche link sulla storia dello unit testing e sul refactoring ? Avresti qualche link anche sugli studi a cui facevi riferimento ?
Il fatto è che il cosidetto "refactoring" sembra una pratica da applicare, una cosa da studiarsi ecc... invece a conti fatti è quello che fa qualsiasi buon programmatore.
Gli obiettivi cambiano -> il programma si espande -> la struttura cambia -> gli algoritmi si adattano di conseguenza.
Non è niente di esoterico in effetti, anzi, dovrebbe venire da se...
Quindi secondo me PGI-Bis ha ragione (se ho capito cosa intendeva :asd:), nonostante sia abbastanza "fondamentalista": se sai che stai facendo non dovresti aver bisogno di un tizio che ti dice che li ci vuole il pattern o che quella cosa merita un refactoring... prenderlo come un automatismo, e usare queste "buzzwords" perchè va di moda probabilmente non migliora affatto la qualità del codice.
Bentornato ;)
Avresti qualche link sulla storia dello unit testing e sul refactoring ? Avresti qualche link anche sugli studi a cui facevi riferimento ?
Riguardo il refactoring.. penso che esista da quando esiste la programmazione.
Riguardo il refactoring.. penso che esista da quando esiste la programmazione.
Chiaro, ma mi riferisco a pubblicazioni che ne parlano.
Non è niente di esoterico in effetti, anzi, dovrebbe venire da se...
Fowler e Gamma nei rispettivi campi, lo ripetono n-mila volte: quelle proposte sono solo pratiche comuni, non esauriscono assolutamente l'argomento. Non vogliono imporre alcuna teoria, ma introdurre il lettore ad un modo di pensare.
Quindi secondo me PGI-Bis ha ragione (se ho capito cosa intendeva :asd:), nonostante sia abbastanza "fondamentalista": se sai che stai facendo non dovresti aver bisogno di un tizio che ti dice che li ci vuole il pattern o che quella cosa merita un refactoring... prenderlo come un automatismo, e usare queste "buzzwords" perchè va di moda probabilmente non migliora affatto la qualità del codice.
E' proprio questo quello a cui servono quei libri: farti capire cosa stai facendo :D
Permetterti di esprimere a parole in quale direzione si sta muovendo il tuo codice, queste "buzzwords" ti permettono di parlare con un collega e dare un nome alla forma che potrebbe prendere il tuo codice. E non sono vincoli, ma solo suggerimenti.
Avresti qualche link sulla storia dello unit testing e sul refactoring ? Avresti qualche link anche sugli studi a cui facevi riferimento ?
Questo e' uno studio interessante e gratuito:
http://www.nist.gov/public_affairs/releases/n02-10.htm
The path to higher software quality is significantly improved software testing. Standardized testing tools, suites, scripts, reference data, reference implementations and metrics that have undergone a rigorous certification process would have a large impact on the inadequacies currently plaguing software markets. For example, the availability of standardized test data, metrics and automated test suites for performance testing would make benchmarking tests less costly to perform. Standardized automated testing scripts, along with standard metrics, also would provide a more consistent method for determining when to stop testing.
sottovento
15-03-2009, 14:42
Evidentemente non sono in grado di esprimermi in modo comprensibile.
Buon proseguimento.
Ti quoto ;) ma per un altro motivo.
Come sempre, anche quando si richiede semplicemente un'opinione, si possono dividere gli interventi in due categorie:
1 - inerenti a quanto chiesto (i.e. l'opinione a cui eri interessato);
2 - SIC ("Sali In Cattedra"). (L'ho inventato io :D )
Questo thread e' il piu' classico esempio del punto #2. Alla fine della fiera, c'era da dire se la tecnologia OOP fosse alla frutta o avesse ancora qualcosa da dire. Oppure se fosse il non plus ultra della tecnologia.
Insomma, c'era da commentare una critica allo stato delle cose.
Immagino che le opinioni in questo senso, anche quelle discordanti da quella personale, sarebbero state le benvenute.
Purtroppo, rileggendo gli interventi, la maggior parte sono state delle claudicanti salite in cattedra, per spiegare l'incapsulamento, ereditarieta', ecc.
Wow! Ma quanti cattedratici ci sono!!!! E quanto si impara!
Tempo fa, leggendo un giornale, avevo trovato una statistiche che affermava che il 90% degli automobilisti italiani pensava di essere un guidatore di bravura sicuramente superiore alla media.
Sarebbe interessante fare la stessa intervista riguardo all'informatica: "che programmatore sei?". Cionci, si puo' fare?
Mamma mia, quanti numeri 1 troveremmo!
Buon proseguimento
^TiGeRShArK^
15-03-2009, 14:48
Ti quoto ;) ma per un altro motivo.
Come sempre, anche quando si richiede semplicemente un'opinione, si possono dividere gli interventi in due categorie:
1 - inerenti a quanto chiesto (i.e. l'opinione a cui eri interessato);
2 - SIC ("Sali In Cattedra"). (L'ho inventato io :D )
Questo thread e' il piu' classico esempio del punto #2. Alla fine della fiera, c'era da dire se la tecnologia OOP fosse alla frutta o avesse ancora qualcosa da dire. Oppure se fosse il non plus ultra della tecnologia.
Insomma, c'era da commentare una critica allo stato delle cose.
Immagino che le opinioni in questo senso, anche quelle discordanti da quella personale, sarebbero state le benvenute.
Purtroppo, rileggendo gli interventi, la maggior parte sono state delle claudicanti salite in cattedra, per spiegare l'incapsulamento, ereditarieta', ecc.
Wow! Ma quanti cattedratici ci sono!!!! E quanto si impara!
Tempo fa, leggendo un giornale, avevo trovato una statistiche che affermava che il 90% degli automobilisti italiani pensava di essere un guidatore di bravura sicuramente superiore alla media.
Sarebbe interessante fare la stessa intervista riguardo all'informatica: "che programmatore sei?". Cionci, si puo' fare?
Mamma mia, quanti numeri 1 troveremmo!
Buon proseguimento
L'unico a salire in cattedra è stato il personaggio che ha scritto le cagate riportate nel primo post. :)
Correggere quelle castronerie, scritte da uno che EVIDENTEMENTE non sa nemmeno cosa sia la programmazione ad oggetti, mi pare proprio il minimo. :)
Quanto a me mi pare di essere stato MOLTO chiaro in merito al mio pensiero sulla programmazione ad oggetti attuale e sul suo futuro. ;)
~FullSyst3m~
15-03-2009, 15:11
Ti quoto ;) ma per un altro motivo.
Come sempre, anche quando si richiede semplicemente un'opinione, si possono dividere gli interventi in due categorie:
1 - inerenti a quanto chiesto (i.e. l'opinione a cui eri interessato);
2 - SIC ("Sali In Cattedra"). (L'ho inventato io :D )
Questo thread e' il piu' classico esempio del punto #2. Alla fine della fiera, c'era da dire se la tecnologia OOP fosse alla frutta o avesse ancora qualcosa da dire. Oppure se fosse il non plus ultra della tecnologia.
Insomma, c'era da commentare una critica allo stato delle cose.
Immagino che le opinioni in questo senso, anche quelle discordanti da quella personale, sarebbero state le benvenute.
Purtroppo, rileggendo gli interventi, la maggior parte sono state delle claudicanti salite in cattedra, per spiegare l'incapsulamento, ereditarieta', ecc.
Wow! Ma quanti cattedratici ci sono!!!! E quanto si impara!
Tempo fa, leggendo un giornale, avevo trovato una statistiche che affermava che il 90% degli automobilisti italiani pensava di essere un guidatore di bravura sicuramente superiore alla media.
Sarebbe interessante fare la stessa intervista riguardo all'informatica: "che programmatore sei?". Cionci, si puo' fare?
Mamma mia, quanti numeri 1 troveremmo!
Buon proseguimento
Quoto il discorso dei numeri uno (tutti da Chiambretti), ma quoto anche Tiger, come come giustamente ha detto, ha esposto il suo pensiero, come molti altri utenti del resto.
Sono felice che fek sia tra noi, sebbene intervenga in un modo poco che mi appare poco educato.
Mi rallegro del fatto che ti preoccupi delle mie basi e ti conforto dicendoti che sono saldissime, sia in teoria che in pratica.
Hai pienamente ragione quando dici che quello che ritengo è irrilevante. E' per questo che ho aggiunto "e ritengo di poter dimostrare".
Quanto al metodo, puoi tranquillamente tralasciare collegamenti a studi esterni: possono anche impressionare le menti deboli ma è logicamente noto che una teoria - cioè un'affermazione di verità su un fatto reale o immaginario, dove il fatto reale è ciò che è o è stato, l'immaginario ciò che sarà o avrebbe potuto essere - può essere comprovata da un esperimento solo se il fatto si manifesti in un numero non infinito di forme.
Significa che non posso addurre come dimostrazione della teoria "le mele subiscono la legge di gravità" uno studio che rileva la caduta delle mele, perchè la teoria si applica a tutte le mele presenti passate e future e io dovrei osservare la caduta di tutte per poter dire che tutte le mele subiscano la legge di gravità.
Non ripeto le ragioni per cui ritengo la definizione di refactoring di fowler priva di significato (scientifico). Ti dirò invece che essendo la critica basata sull'indeterminatezza dei termini cheap e easy per dimostrare che ho torto ti sarebbe sufficiente fornirmi una definizione quantitativa di cheap e easy.
E non me ne frega niente se ritieni che io non abbia titolo per dirlo. E' la logica, bellezza.
Sono felice che fek sia tra noi, sebbene intervenga in un modo poco che mi appare poco educato.
Detto da te lascia il tempo che trova... perche' ti appare male.
E non me ne frega niente se ritieni che io non abbia titolo per dirlo. E' la logica, bellezza.
Non e' logica. E' semplicemente parlare di qualcosa che non conosci, e fare affermazioni assurde che vanno contro il senso comune e le rilevazioni empiriche. Nonche' le piu' banali leggi dell'Ingegneria del Software.
Non ritengo io che tu non abbia titolo, e' ovvio dagli errori grossolani che commetti nei tuoi ragionamenti.
La logica è una scienza, e la scienza si basa sulla possibilità di sbagliare ;)
In effetti se non c'è una definizione quantitativa di "economico" e "semplice", è solo che non ci si arriva... di certo non significa che questi due concetti non esistono o non hanno applicazione nel mondo reale.
D'altra parte intuitivamente chiunque sa capire cosa richiede sforzo e cosa ne richiede meno no?
sottovento
15-03-2009, 15:29
L'unico a salire in cattedra è stato il personaggio che ha scritto le cagate riportate nel primo post. :)
Correggere quelle castronerie, scritte da uno che EVIDENTEMENTE non sa nemmeno cosa sia la programmazione ad oggetti, mi pare proprio il minimo. :)
Quanto a me mi pare di essere stato MOLTO chiaro in merito al mio pensiero sulla programmazione ad oggetti attuale e sul suo futuro. ;)
Non mi riferivo a nessuno in particolare. Anzi, quando faccio queste critiche le riporto "in primis" al sottoscritto.
Mi piace pensare che posso diventare una persona (ed un informatico) migliore :D
e vabbè Fek, se mi dici che ho torto perchè ho torto che vuoi che risponda. Hai ragione.
e vabbè Fek, se mi dici che ho torto perchè ho torto che vuoi che risponda. Hai ragione.
So che ho ragione. Hai torto perche' i dati sperimentali e le evidenze empiriche ti danno torto.
Ma se io sto parlando di una definizione come fai a dirmi che un'evidenza empirica mi da torto?
Quando ho scritto che discutere della definizione non significa negare che si possa fare "refactoring" a chi parlavo, ai pesci gatto?
Ma se io sto parlando di una definizione come fai a dirmi che un'evidenza empirica mi da torto?
Quando ho scritto che discutere della definizione non significa negare che si possa fare "refactoring" a chi parlavo, ai pesci gatto?
Stai facendo confusione.
E io credo che tu ti stia divertendo. Sai cos'è il Therac-25? Be' fai una ricerca in rete e vedi quant'è divertente non sapere cosa si faccia prima di farlo.
E io credo che tu ti stia divertendo. Sai cos'è il Therac-25? Be' fai una ricerca in rete e vedi quant'è divertente non sapere cosa si faccia prima di farlo.
Per cortesia attieniti all'argomento senza scendere nel personale. E' un brutto vizio che non sembri toglierti.
Non è un attacco personale, è un fatto.
Il Therac-25 era un apparato hardware-software usato per scansioni radiologiche. Il mancato rispetto di una precondizione di concorrenza nel codice sorgente del software causava una violazione di integrità.
L'apparato ha ucciso sei persone.
E' in topic. Discutere dei problemi della programmazione orientata agli oggetti significa verificare la definizione di orientamento agli oggetti, significa parlare di distinzione tra certezze ed opinioni.
Il caso del Therac è un triste monumento all'importanza di questa distinzione.
Hai scoperto che il software ha bug. E' gia' un passo avanti.
cdimauro
15-03-2009, 17:51
PGI, il problema qui è che nessuno sta parlando di teoria, ma di puro pragmatismo basato su dati EMPIRICI.
Come dire: non mangio carne tutti i giorni perché statisticamente corro un rischio molto elevato di sviluppare un cancro.
Rifattorizzare non ha nulla a che vedere con la teoria? Va benissimo. NON è una teoria e nessuno ha preteso di imporla come tale.
Lo unit test non è un teoria? Va benissimo anche questo.
Dal punto di vista puramente formale non v'è dubbio che tu abbia ragione.
Ma pragmaticamente, senza la rifattorizzazione e soprattutto lo unit testing rappresentato dall'estesa batteria di test in dotazione, non avrei impiegato poco più di un mese per cambiare la virtual machine, il generatore di AST, il generatore di codice e il peephole optimizer (con annessi e connessi) di Python.
Realisticamente avrei impiegato mooooooolto più tempo, e rimanendo col dubbio di aver dimenticato qualcosa o di aver lasciato qualche bug rognoso piazzato chissà dove. E i bug, con un linguaggio come il C e senza nemmeno un traceback, sono particolarmente difficili già soltanto da individuare.
My 2 cents.
mindwings
15-03-2009, 17:52
Anche se non condivido le opinioni di PGI le rispetto lo stesso :) , detto questo possiamo tornare in topic che ricordo - "In cosa ha fallito l'OOP, dove si puo` migliorare e con che mezzi?"
Molte discussioni su questo forum mi sembrano battaglie inter-personali che non hanno senso... Del resto ognuno e` libero di avere le proprie convinizioni i pareri discordanti arricchiscono la discussione.:mbe:
rеpne scasb
15-03-2009, 19:11
■
Portate pazienza se parto da molto indietro con le risposte, ma magari riusciamo pure a riportare il thread IT :D.
Francamente non capisco quale sia il problema:
>>> from fractions import Fraction
>>> from math import sin
>>>
>>> class myfloat(float):
... def sin(self):
... return sin(self)
...
>>> a = myfloat(0.5)
>>> b = Fraction(2, 3)
>>> c = 1 + 2j
>>> result = a.sin() * b + c
>>> result
(1.3196170257361353+2j)
L'unica "fregatura" è che con Python non posso aggiungere metodi agli oggetti built-in, come dicevo prima, per cui per inserire il metodo sin ai float sono costretto a estendere la classe. Ma per il resto, come vedi, funziona tutto perfettamente, e... a oggetti. ;)
Che funziona lo so anche io :D, ma la domanda che avevo posto non ha avuto risposta: una operazione tra un razionale e un reale a che classe appartiene ? In un certo senso a tutte e due ma in pratica, visto che nella maggior parte dei linguaggi non si puo' fare, a nessuno dei due e cosi' devi magari esporre l'implementazione, o una sua parte.
L'avrebbe dovuto fare l'autore dell'articolo in primis, a mio avviso.
Non ha fatto confronti con altri paradigmi, ma si è lanciato in un attacco abbastanza generalista alla OOP.
Al di la' che l'incipit parla di come non hanno aggiunto la programmazione OO ad un linguaggio funzionale, quel che intendevo dire e' che le repliche non sono entrate nel merito, ma che la programmazione OO e' migliore di altro; un po' come se ad uno che dice che la bicicletta fa schifo perche' se piove ci si bagna, si rispondesse che e' comunque meglio di andare a piedi.
L'attacco sara' stato generalista (?) ma le repliche che ho visto non mi sono parse piu' sensate, anzi.
[...] E i bug, con un linguaggio come il C e senza nemmeno un traceback, [...] se ti riferisci allo stack trace diciamo che il C non lo supporta nativamente, come Java, ma qualunque accoppiata compilatore/debugger degni di questi nomi ti permette di esaminarlo.
anzi: non sono ancora riuscito a trovare in Java qualcosa che mi permetta di fare quello che riesco a fare con un crash dump quando devo diagnosticare un problema in un programma scritto in Visual C++. (da notare come in .NET invece esista il modo)
eh, Java Java... quanto fai cacare :asd:
cdimauro
15-03-2009, 19:33
Portate pazienza se parto da molto indietro con le risposte, ma magari riusciamo pure a riportare il thread IT :D.
Non c'è problema. :)
Che funziona lo so anche io :D, ma la domanda che avevo posto non ha avuto risposta: una operazione tra un razionale e un reale a che classe appartiene ? In un certo senso a tutte e due ma in pratica, visto che nella maggior parte dei linguaggi non si puo' fare, a nessuno dei due e cosi' devi magari esporre l'implementazione, o una sua parte.
Qui più che altro vedo un problema di coercizione, non di appartenenza di un metodo a una classe.
Dipende tutto da come si è deciso di implementare il "passaggio" dal razionale al float, e dal float al complesso.
Questo, per quanto mi riguarda, può essere gestito da una libreria apposita anziché da una precisa classe. Ma sono dettagli implementativi.
Al di la' che l'incipit parla di come non hanno aggiunto la programmazione OO ad un linguaggio funzionale, quel che intendevo dire e' che le repliche non sono entrate nel merito, ma che la programmazione OO e' migliore di altro; un po' come se ad uno che dice che la bicicletta fa schifo perche' se piove ci si bagna, si rispondesse che e' comunque meglio di andare a piedi.
L'attacco sara' stato generalista (?) ma le repliche che ho visto non mi sono parse piu' sensate, anzi.
E' vero, in alcuni casi ci siamo lasciati andare (io per primo). Ma le repliche ben motivate mi sembra ci siano state. ;)
[...] (per chi ha un ISAS<100 la frase e' volutamente sarcastica). [...] eh? :huh:
http://en.wikipedia.org/wiki/ISAS
http://it.wikipedia.org/wiki/ISAS
e che é?
cdimauro
15-03-2009, 19:35
se ti riferisci allo stack trace diciamo che il C non lo supporta nativamente, come Java, ma qualunque accoppiata compilatore/debugger degni di questi nomi ti permette di esaminarlo.
Fortunatamente esiste "santo" Visual Studio per casi disperati come questo. :D
Anche se io ODIO i debugger (ma d'altra parte il codice non è mio, per cui ho poco da recriminare).
anzi: non sono ancora riuscito a trovare in Java qualcosa che mi permetta di fare quello che riesco a fare con un crash dump quando devo diagnosticare un problema in un programma scritto in Visual C++. (da notare come in .NET invece esista il modo)
eh, Java Java... quanto fai cacare :asd:
Per questo preferisco Python. :cool:
rеpne scasb
15-03-2009, 20:02
■
Poi verso la tre quarti ho riletto quella pagina è m'è venuto da ridere.
Qui parliamo di orientamento agli oggetti, una prospettiva che ha due termini: oggetto e stato.
Ora quando l'autore si inarca in uno stupendo "le strutture dati e funzioni non devono essere vincolate insieme" si capisce al volo quale sia il problema: vede un programma orientato agli oggetti, lo osserva da un punto di vista strutturato e dice "a me sembra una stronzata".
No, mi sembra piuttosto che dica che il punto di vista dell'OOP e' sbagliato; non e' la stessa cosa. Da un lato abbiamo un approccio del tipo "maneggiare lo stato e' un affare serio, te lo nascondo e ti offro io gli unici metodi per farlo". Dall'altro invece si preferisce rendere meno pericoloso il maneggiamento dello stesso, e lasciando staccati algoritmi dai dati, che rimangono "aperti" (dando comunque la possibilita' di nasconderne una parte qualora sia proprio necessario).
La prima scelta in teoria e' interessante, ma funziona fintanto che i metodi offerti sono quelli che servono; altrimenti e' un continuo spostare in qua il limite tra quel che serve e quel va nascosto. Oggi magari il problema lo si nasconde dietro nomi altisonanti che fanno pure "cool", ma permane.
E mi viene da ridere quando lo vedo inciampare sul selciato e tuffarsi in un pozzangherone di melma nel punto in cui dice "tutto deve essere un oggetto". Ma siamo seri! Sono tremila anni che si sa che le definizioni totalizzanti cadono nella regressio ad infinitum, questo si alza la mattina "Tutto dev'essere un oggetto" e parte cantando Area Krishna Are Are.
Posso prenderla come una ammissione che di per se' l'orientamento agli oggetti da solo non funziona :P :D ? Ora, che un approccio puro non funzioni e che ci voglia del pragmatismo mi sta piu' che bene, pero' in questo thread (e in altri della sezione) abbiamo scoperto che la programmazione OOP funziona benissimo, a patto di aggiungerci tipi generici, lambda, closures, linguaggi embedded non OO, first order functions e chi piu' ne ha piu' ne metta . OOPs :D.
Tolto dal nostro panorama quel pezzo d'avanspettacolo il futuro è, secondo me, nel significato originale dell'orientamento agli oggetti.
Che, a scanso di equivoci, oggi si è completamente perduto. Non è di molto tempo fa la notizia secondo cui Alan Kay avrebbe ridefinito il suo orientamento gli oggetti "Message Oriented Programming". Pardon, 50 anni fa ho detto una cazzata? No, semplicemente il termine ha assunto altre colorazioni.
Sebbene non sia un amante della OOP, mi interessa molto di piu' l'approccio di Alan Kay. Se non altro penso che Smalltalk presentasse aspetti che mascheravano alcuni dei problemi insiti nell'OO, e che oggi si ritrovino solo in Ruby e in parte in Python (tra i linguaggi mainstream intendo).
Non sarà la programmazione funzionale perchè è settant'anni che gira e nonostante le presunzioni di alcuni c'è stata gente intelligente che l'ha studiata e ha semplicemente detto: fa schifo.
Beh, c'e' fior di gente che dice che la matematica fa schifo, ma dubito che passera' di moda. Il "problema" della programmazione funzionale e' che richiede un approccio piu' matematico alla programmazione, e mal si adatta alla cultura da hacker di chi diventa programmatore smanettando fin da giovane sul PC.
~FullSyst3m~
15-03-2009, 20:47
Beh, c'e' fior di gente che dice che la matematica fa schifo, ma dubito che passera' di moda. Il "problema" della programmazione funzionale e' che richiede un approccio piu' matematico alla programmazione, e mal si adatta alla cultura da hacker di chi diventa programmatore smanettando fin da giovane sul PC.
Si ma questa è una boiata dai! Ora un paradigma di programmazione si deve adattare alle culture che non hanno nemmeno dei fondamenti statistici? :D
Beh, c'e' fior di gente che dice che la matematica fa schifo, :mbe: vorrei qualche esempio.
le uniche persone del genere che ho visto in vita mia erano persone che, giustappunto, non capivano la matematica; quindi il paragone non calza.
Non c'è problema. :)
Qui più che altro vedo un problema di coercizione, non di appartenenza di un metodo a una classe.
Dipende tutto da come si è deciso di implementare il "passaggio" dal razionale al float, e dal float al complesso.
I float non sono un vero superset dei razionali visto che nel passaggio vengono introdotte delle approssimazioni, per cui una gerarchia complex->float->rational non e' propriamente corretta, perlomeno non sempre. Il senso del mio intervento (che forse si e' perso nei dettagli del caso specifico) era che a volte ci sono delle operazioni che logicamente appartengono a due rami distinti di una gerarchia per cui devi esporre (parte dei) dettagli implementativi, e non sempre ti basta convertire un tipo in un altro.
Si ma questa è una boiata dai! Ora un paradigma di programmazione si deve adattare alle culture che non hanno nemmeno dei fondamenti statistici? :D
Non mi sembra di aver detto nulla del genere :mbe: che intendi dire ?
~FullSyst3m~
15-03-2009, 23:30
Non mi sembra di aver detto nulla del genere :mbe: che intendi dire ?
Infatti non ho detto che lo hai detto tu, mi riferivo solo a questa frase:
e mal si adatta alla cultura da hacker di chi diventa programmatore smanettando fin da giovane sul PC.
Tutto qua.
Per favore...limitiamoci a discutere sulle affermazioni e non diamo giudizi sulle persone.
^TiGeRShArK^
16-03-2009, 01:13
Per favore...limitiamoci a discutere sulle affermazioni e non diamo giudizi sulle persone.
quindi non posso dire che sembri così dolce quando ti comprano la birra dopo che sei andato a spostare la macchina? :flower:
:asd:
quindi non posso dire che sembri così dolce quando ti comprano la birra dopo che sei andato a spostare la macchina? :flower:
:asd:
Birra :oink:
cdimauro
16-03-2009, 08:27
I float non sono un vero superset dei razionali visto che nel passaggio vengono introdotte delle approssimazioni, per cui una gerarchia complex->float->rational non e' propriamente corretta, perlomeno non sempre.
Vero, ma se devono "coesistere" qualche passaggio diventa obbligatorio (e francamente non vedrei bene un razionale rappresentato da una coppia di float, pur di non perdere precisione).
Il senso del mio intervento (che forse si e' perso nei dettagli del caso specifico) era che a volte ci sono delle operazioni che logicamente appartengono a due rami distinti di una gerarchia per cui devi esporre (parte dei) dettagli implementativi, e non sempre ti basta convertire un tipo in un altro.
Ho capito, e condivido il tuo pensiero.
Sulla OOP, per quanto sia uno dei motivi che ha portato alla sua definizione, personalmente non condivido i meccanismi di protezione rappresentati dalla visibilità dei membri di una classe. L'ho già detto altre volte: basta un errore di design (tutt'altro che remoto come possibilità) del progettista, per "condannare" tutti gli utilizzatori della stessa.
Sulla "cultura hacker" che allontana dalla programmazione funzionale un po' dissento: a me fanno schifo anche il C e i suoi derivati, che proprio "funzionali" non sono. :D
E' una questione di gusti. ;)
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.