Microsoft ha creato un nuovo linguaggio per la piattaforma .NET, chiamato F# che è un linguaggio per Functional Programming (come Lisp, Erlang, ...).
Dopo tanti anni di programmazione OOP Microsoft ha deciso di avvicinarsi al FP?
giovedì 26 marzo 2009
The Javascript Trap
La FSF è impegnata a combattere l'esecuzione di codice non libero in tutti i suoi aspetti, e a tal proposito c'è un articolo molto interessante circa la Javascdript Trap ossia il fatto che tramite il proprio Web browser si possa eseguire codice non libero.
mercoledì 25 marzo 2009
L'importanza di final
La parola chiave final in Java viene utilizzata per rendere "blindata" l'implementazione di un metodo o di una variabile. Nel caso di una variabile questa non potrà essere modificata successivamente, mentre nel caso di metodi questi non potranno essere resi polimorfici nelle varie sottoclassi.
Java per default considera ogni metodo come virtual, ovvero potenzialmente polimorfico, sempre che non vengano definiti come final.
L'utilizzo di final è suggerito come una "best-practice", poiché consente di blindare meglio le classi e non fornire possibili punti di estensione permanenti. Ma non finisce qui: l'utilizzo di final garantisce ad un ottimizzatore che il metodo non sarà soggetto a dispatching dinamico: il metodo può essere messo in-line senza nessun problema, con guadagno in performance (un metodo virtual non può essere messo in-line perché un caricamento di classi successive - on demand - potrebbe invalidare l'operazione di in-lining).
Rispettando anche i principi dell'XP e quindi non essendo spaventati da un eventuale refactory, è bene usare final di default in tutti i metodi.
Devo ammettere che una delle cose che mi è sempre piaciuta in Java è proprio il fatto di considerare i metodi come potenzialmente polimorfici. In effetti, programmando OOP, penso che sia plausibile che gli sviluppatori vogliono "naturalmente" fornire un modo per estendere le proprie librerie. Si hanno quindi due approcci esattamente opposti: Java che considera tutto potenzialmente polimorfico, e C++ / C# che considera tutto come non polimorfico. Mentre quindi in Java occorre specificare cosa non deve essere polimorfico, in C# si deve specificare cosa deve essere polimorfico. Da qui entrano anche in gioco le preferenze personali per uno o l'altro metodo. Io personalmente preferisco quello adottato da Java, anche se in ambito di ottimizzazione è più comodo quello C#. Perchè? Perché il metodo Java è quello che trovo più OOP di tutti, e dopotutto l'ottimizzazione preventiva è una enorme fonte di errori e disastri!
Java per default considera ogni metodo come virtual, ovvero potenzialmente polimorfico, sempre che non vengano definiti come final.
L'utilizzo di final è suggerito come una "best-practice", poiché consente di blindare meglio le classi e non fornire possibili punti di estensione permanenti. Ma non finisce qui: l'utilizzo di final garantisce ad un ottimizzatore che il metodo non sarà soggetto a dispatching dinamico: il metodo può essere messo in-line senza nessun problema, con guadagno in performance (un metodo virtual non può essere messo in-line perché un caricamento di classi successive - on demand - potrebbe invalidare l'operazione di in-lining).
Rispettando anche i principi dell'XP e quindi non essendo spaventati da un eventuale refactory, è bene usare final di default in tutti i metodi.
Devo ammettere che una delle cose che mi è sempre piaciuta in Java è proprio il fatto di considerare i metodi come potenzialmente polimorfici. In effetti, programmando OOP, penso che sia plausibile che gli sviluppatori vogliono "naturalmente" fornire un modo per estendere le proprie librerie. Si hanno quindi due approcci esattamente opposti: Java che considera tutto potenzialmente polimorfico, e C++ / C# che considera tutto come non polimorfico. Mentre quindi in Java occorre specificare cosa non deve essere polimorfico, in C# si deve specificare cosa deve essere polimorfico. Da qui entrano anche in gioco le preferenze personali per uno o l'altro metodo. Io personalmente preferisco quello adottato da Java, anche se in ambito di ottimizzazione è più comodo quello C#. Perchè? Perché il metodo Java è quello che trovo più OOP di tutti, e dopotutto l'ottimizzazione preventiva è una enorme fonte di errori e disastri!
martedì 24 marzo 2009
Why OO does not suck!
Well, I've just finished reading the article Why OO Sucks by Joe Armstrong, the inventor of Erlang, and I must admit I'm almost disappointed.
I believe the article faces the problem of OOP in a very shallow way, there are no concrete side-effects of OO as described in the paper and, by the way, I was expecting something better and stronger than that from a person like Armstrong.
While it is true that functions and data structures does not belong to the same space, that is the former are active entities, while the latter are passive entities, it is true that they are bound together. The reason is that, as stated in the paper, functions manipulates data structures, and thus data structures are inputs (and outputs) of funtions. This is a very strong bind, and since it is well known that the wrong data structure passed to the right function can lead to a crash, binding the function to the data structure it expects to get as input is a very clever idea.
Moreover, understanding classes and objects is the same difficult as understanding functions, since after all a class is a prototype of a behaviour connected to an internal implementation.
I believe that modelling the OO way really simplifies software development. After all, in the OOP way you can have someone building a class engine and providing you with functions to accelerate, decelerate and so on. This is what happens in the real world, when you buy car. Nobody must understand what engine functions do, how they do or how the engine data structure has been assembled. All you have to do is to understand how to use operations (functions) defined for the engine. It is a matter of abstraction.
Now it is clear that, in an OO language, everything is supposed to be an object, or at least it is desiderable to be. Of course there are exceptions, like static classes, static methods, and so on. But with a good hierarchy, every function can be able to manipulate every object and variable in the system (just think at the java.lang.Object). So there's an escape way even for OO to be as much general as possible and, at the same time, as less typed as possible!
Remember that OOP is an evolution of modular programming (like C).
It is true that, in OO, data type definition are spead along the system, but this is natural because in this paradigm data definition are the system! And it is false that to use some functions of an object you have to inherit from it! In fact, as a best practice, you should not inherit at all, al least use composition!
Finally, it is surely true that OOP has opened a new problems/solutions range on which industry has made different business, but saying that this is the only reason why OOP has been pushed to developers sounds odd to me.
I believe that Mr. Armstrong has understood what OOP is, but he could elaborate more his article because it appears a little much simple and shallow in all his statements.
I believe the article faces the problem of OOP in a very shallow way, there are no concrete side-effects of OO as described in the paper and, by the way, I was expecting something better and stronger than that from a person like Armstrong.
While it is true that functions and data structures does not belong to the same space, that is the former are active entities, while the latter are passive entities, it is true that they are bound together. The reason is that, as stated in the paper, functions manipulates data structures, and thus data structures are inputs (and outputs) of funtions. This is a very strong bind, and since it is well known that the wrong data structure passed to the right function can lead to a crash, binding the function to the data structure it expects to get as input is a very clever idea.
Moreover, understanding classes and objects is the same difficult as understanding functions, since after all a class is a prototype of a behaviour connected to an internal implementation.
I believe that modelling the OO way really simplifies software development. After all, in the OOP way you can have someone building a class engine and providing you with functions to accelerate, decelerate and so on. This is what happens in the real world, when you buy car. Nobody must understand what engine functions do, how they do or how the engine data structure has been assembled. All you have to do is to understand how to use operations (functions) defined for the engine. It is a matter of abstraction.
Now it is clear that, in an OO language, everything is supposed to be an object, or at least it is desiderable to be. Of course there are exceptions, like static classes, static methods, and so on. But with a good hierarchy, every function can be able to manipulate every object and variable in the system (just think at the java.lang.Object). So there's an escape way even for OO to be as much general as possible and, at the same time, as less typed as possible!
Remember that OOP is an evolution of modular programming (like C).
It is true that, in OO, data type definition are spead along the system, but this is natural because in this paradigm data definition are the system! And it is false that to use some functions of an object you have to inherit from it! In fact, as a best practice, you should not inherit at all, al least use composition!
Finally, it is surely true that OOP has opened a new problems/solutions range on which industry has made different business, but saying that this is the only reason why OOP has been pushed to developers sounds odd to me.
I believe that Mr. Armstrong has understood what OOP is, but he could elaborate more his article because it appears a little much simple and shallow in all his statements.
lunedì 23 marzo 2009
WhiteCat mewls
After 6 months since its creation, the WhiteCat approach is becoming more concrete day by day. I'm proud to say that a paper I wrote with the collaboration and support of Dr. Haibin Zhu, has been accepted to IEEE CTS 2009 with a really good revision. During my academic life I've never seen a paper accepted as it is with a lot of accomplishment, and this is what happen with the four revisors assigned to the WhiteCat paper.
During the writing of this paper, the development of the frameork has continued and the framework is now improved. Most notably changes and improvements are the followings:
Stay tuned for updates!
During the writing of this paper, the development of the frameork has continued and the framework is now improved. Most notably changes and improvements are the followings:
- the RoleEngine has changed name, and it is now called RoleBooster. The motivation behind this is that the word engine could be misleading, and since the idea is to have a boosting of interaction and behaviour capabilities (thru roles), this name is more appropriate;
- the agent proxy now can be identified thru an unique identifier (that in the simpler case is a sequence number), automatically generated at the time of the proxy creation. Such identifier is copyied thru proxy manipulations, so that after a role assumption a proxy will have the same identity. The meaning of this is to allow a client (e.g., an agent) to know that two different proxies refers to the same agent (i.e., they have the same identity);
- an AOP-based notification system has been developed. It is now possible to register an event listener to a proxy and be notified about role assumptions/releases (i.e., proxy manipulations). The idea behind this is to allow agents to be notified about the needing of a proxy update due to a bytecode manipulation;
- the proxy update mechanism has been completed. Now there is a central map that stores the last version available of each proxy (indexed by the proxy identity). When a proxy update is required, the proxy is extracted from this map. Proxies are inserted in the map after a succesfull bytecode manipulation by an aspect.
Stay tuned for updates!
A new version of the Manual is ready for download!
After four years a new version of the Aglets User Manual is available for downloading at SourceForge.net.
Please note that we have always worked to the manual, improving and fixing the first version I wrote once I was in charge of the project itself, but before now no downloadable versions were officially available (even if the CVS repository allows public checkout).
Now, thanks to the efforts of some developers, the manual has been improved and is now available for users. Please refer to this last version of the manual.
Work on the manual has not yet finished, and we are continuously improving it.
Please note that we have always worked to the manual, improving and fixing the first version I wrote once I was in charge of the project itself, but before now no downloadable versions were officially available (even if the CVS repository allows public checkout).
Now, thanks to the efforts of some developers, the manual has been improved and is now available for users. Please refer to this last version of the manual.
Work on the manual has not yet finished, and we are continuously improving it.
Gigetto, dove sei (se ci sei)?
Giovedì della scorsa settimana il caro Gigetto, il reno che collega Modena a Sassuolo, non è passato per Casinalbo.
Stavo attendendo l'arrivo del treno per Sassuolo delle 7.55, e che già era in ritardo, quando alle 8.03 si iniziano ad abbassare le sbarre. Io e gli altri utenti tiriamo un sospiro di sollievo, preparandoci a salire sul treno, quando invece arriva il treno dalla direzione opposta (Sassuolo) che sfreccia senza fermarsi presso la stazione!
Ancora una volta un treno è stato soppresso per non si sa quale motivo e nessun avviso/informazione è stata fornita agli utenti (inutile ricordare come i monitor informativi siano stati sfasciati da vandali e mai più sostituiti).
Ovviamente l'ATCM ignora qualunque richiesta di speigazioni da parte degli utenti.
Stavo attendendo l'arrivo del treno per Sassuolo delle 7.55, e che già era in ritardo, quando alle 8.03 si iniziano ad abbassare le sbarre. Io e gli altri utenti tiriamo un sospiro di sollievo, preparandoci a salire sul treno, quando invece arriva il treno dalla direzione opposta (Sassuolo) che sfreccia senza fermarsi presso la stazione!
Ancora una volta un treno è stato soppresso per non si sa quale motivo e nessun avviso/informazione è stata fornita agli utenti (inutile ricordare come i monitor informativi siano stati sfasciati da vandali e mai più sostituiti).
Ovviamente l'ATCM ignora qualunque richiesta di speigazioni da parte degli utenti.
lunedì 16 marzo 2009
Java vs. .NET
Qualche sera fa ho incontrato in treno uno studente dell'università che aveva seguito anche i miei corsi Java, e che ora lavora esclusivamente usando .NET.
Ebbene si parlava un po' delle differenze fra Java e :NET, tutte cose abbastanza banali, ma la cosa che mi ha stupito è come si stia diffondendo l'idea che Java sia antico, sia ormai superato.
Non voglio assolutamente aprire una guerra religiosa o un flame, a mio avviso Java ha dato molto ed ha ancora molto da dare. Certamente .NET, essendo un linguaggio maturato anche dall'esperienza fatta con Java, si propone come linguaggio più moderno e privo di alcune lacune di cui Java ancora soffre. Ma questo è naturale, rappresenta una semplice evoluzione dell'idea di un linguaggio ad oggetti fortemente tipizzato e portabile.
Noto però con rammarico come l'uso di questi linguaggio moderni stia facendo disimparare la vera programmazione ad oggetti. Mi ritengo molto fortunato ad aver imparato Java dalla versione 1.0, quando effettivamente c'era poco e ci si doveva arrangiare per forza con un buon design ad oggetti, perché non c'erano altri modi per procedere. Questo mi ha insegnato a distinguere fra le cose che realmente servono nella programmazione, almeno ha contribuito a creare un mio stile di programmazione solido e coerente.
Un esempio per tutti: io non uso mai argomenti di default per i metodi. Perchè? Perché sono abituato a fare un sovraccarico dei metodi, che ritengo essere più chiaro anche se più prolisso, e perché sono ottuso!
E poi a cosa serve avere un linguaggio moderno che reintroduce concetti abbandonati, quali l'overload degli operatori, se poi questi sono scarsamenti usati? Il mio studente mi ha infatti confermato che queste carattestiche sono scarsamente utilizzate nei loro progetti. Ora, inutile fare di tutta l'erba un fascio, ma questo rappresenta comunque un'indicazione delle caratteristiche non usate....
Infine ho provato un grande rammico quando ho appreso che molte aziende ancora usano .NET senza sapere realmente perché, o meglio, solo perché è una buona piattaforma per lo sviluppo in Microsoft Windows. Possibile che nessuno si sia mai posto il problema della portabilità Linux/Unix con Mono?
Ebbene si parlava un po' delle differenze fra Java e :NET, tutte cose abbastanza banali, ma la cosa che mi ha stupito è come si stia diffondendo l'idea che Java sia antico, sia ormai superato.
Non voglio assolutamente aprire una guerra religiosa o un flame, a mio avviso Java ha dato molto ed ha ancora molto da dare. Certamente .NET, essendo un linguaggio maturato anche dall'esperienza fatta con Java, si propone come linguaggio più moderno e privo di alcune lacune di cui Java ancora soffre. Ma questo è naturale, rappresenta una semplice evoluzione dell'idea di un linguaggio ad oggetti fortemente tipizzato e portabile.
Noto però con rammarico come l'uso di questi linguaggio moderni stia facendo disimparare la vera programmazione ad oggetti. Mi ritengo molto fortunato ad aver imparato Java dalla versione 1.0, quando effettivamente c'era poco e ci si doveva arrangiare per forza con un buon design ad oggetti, perché non c'erano altri modi per procedere. Questo mi ha insegnato a distinguere fra le cose che realmente servono nella programmazione, almeno ha contribuito a creare un mio stile di programmazione solido e coerente.
Un esempio per tutti: io non uso mai argomenti di default per i metodi. Perchè? Perché sono abituato a fare un sovraccarico dei metodi, che ritengo essere più chiaro anche se più prolisso, e perché sono ottuso!
E poi a cosa serve avere un linguaggio moderno che reintroduce concetti abbandonati, quali l'overload degli operatori, se poi questi sono scarsamenti usati? Il mio studente mi ha infatti confermato che queste carattestiche sono scarsamente utilizzate nei loro progetti. Ora, inutile fare di tutta l'erba un fascio, ma questo rappresenta comunque un'indicazione delle caratteristiche non usate....
Infine ho provato un grande rammico quando ho appreso che molte aziende ancora usano .NET senza sapere realmente perché, o meglio, solo perché è una buona piattaforma per lo sviluppo in Microsoft Windows. Possibile che nessuno si sia mai posto il problema della portabilità Linux/Unix con Mono?
PHP e variabili di istanza: un errore da principianti!
Qualche giorno ho perso diverso tempo cercando di capire quale problema avesse una applicazione PHP, per poi scoprire che ho mescolato mentalmente le regole di Java e PHP.
In sostanza avevo una classe che definiva delle variabili di istanza che venivano poi usate in un metodo come segue:
Come si può notare io usavo la variabile di istanza seguendo le regole Java, ovvero ricerca della variabile nell'oggetto qualora non sia già definito nella funzione (o nel blocco di codice). Ebbene, questo in PHP non funziona, è bensì necessario dereferenziare automaticamente la variabile passando attraverso l'oggetto:
Un vero errore da principianti!
E dire che solitamente uso sempre i qualificatori this, super, ecc. proprio per identificare meglio la visibilità delle variabili e non incorrere in simili errori.
Insomma, una distrazione che mi è costata diverso tempo.
In sostanza avevo una classe che definiva delle variabili di istanza che venivano poi usate in un metodo come segue:
class MyClass{
private $ORDER_BY_NAME = " ORDER BY name ";
public function doQuery(){
...
$sql .= $ORDER_BY_NAME;
...
}
}
Come si può notare io usavo la variabile di istanza seguendo le regole Java, ovvero ricerca della variabile nell'oggetto qualora non sia già definito nella funzione (o nel blocco di codice). Ebbene, questo in PHP non funziona, è bensì necessario dereferenziare automaticamente la variabile passando attraverso l'oggetto:
class MyClass{
private $ORDER_BY_NAME = " ORDER BY name ";
public function doQuery(){
...
$sql .= $this->ORDER_BY_NAME;
...
}
}Un vero errore da principianti!
E dire che solitamente uso sempre i qualificatori this, super, ecc. proprio per identificare meglio la visibilità delle variabili e non incorrere in simili errori.
Insomma, una distrazione che mi è costata diverso tempo.
Iscriviti a:
Post (Atom)