In a technical article, the conclusion usually indicates where you became tired of thinking, and want to leave the rest to the reader.
When doing analysis, I need to recognize behaviour in objects. In design, the type I give to my objects is the conclusion I reach. Programmers tend to favor duck typing because it allows them to skip the part where they have to build and recognize abstractions, and they can simply implement all needed objects without actually giving them a type.
When using duck typing, if an object implements walk() and quack() they can treat it like a duck, but they do not have to define exactly what a duck is, nor do they have to explicitly recognize duck behaviour in their objects. More precisely, they longer need to reflect the is-a hierarchy using types, but simply a behaves-mostly-like hierarchy using classes. This is of course much simpler to design, as they may throw theoretical issues (like the Liskov Substituion Principle) out of the equation.
When using static typing, I have to recognize up front that my function requires duck-like behaviour, I have to precisely define what duck-like behaviour means (that is define a type, not a class, in the form of a DuckInterface) and identify precisely which classes in my hierarchy exhibit duck-likle behaviour (and make them implement the DuckInterface.)
Static typing does not limit my expressiveness. It merely forces me to think about what I'm saying before I actually say it. It means that I have to carefully identify the abstractions and design the corresponding interfaces. It means that I have to recognize the difference between subtyping and subclassing.
I am reasonably good at building and recognizing abstractions, and that is why I don't usually need duck typing. If you are not good at handling abstractions, then you will find that duck typing greatly simplifies your work. Consider it the "lite" version of object oriented analysis and design. You do not define types, you just let the reader discover them.
However, the lack of clearly defined types has its price: interfaces are the building blocks of loose coupling, so you need to design them anyway. In duck typing, interfaces will tend to emerge from the code instead of the analysis; this might not be the best way, as you usually end up with ad-hoc types instead of carefully thought ones.
Friday, August 31, 2007
The conclusion indicates where you stopped thinking
Publié par Stephan Leclercq à l'adresse 7:15 PM 4 commentaires
Libellés : Dynamic typing
Sunday, August 26, 2007
From the master himself
I know it's a long time ago, but in an interview with Bill Venners, on November 17, 2003, the master Yukihiro Matsumoto himself said:
So for day-to-day programs that aren't not as serious as enterprise systems, you don't have to be as robust. It's not worth the cost of declaring types, for example.
So he agrees: declaring types has a cost, but it adds robustness.
http://www.artima.com/intv/tuesday3.html
Publié par Stephan Leclercq à l'adresse 6:32 PM 0 commentaires
Libellés : Dynamic typing, Ruby
Saturday, August 25, 2007
Dynamic typing, the keyboard and the mouse
Dynamic typing proponents like to think that way: type errors are not frequent. It is therefore best to have a language that allows you to plug any object anywhere, and write tests that ensure your program is doing what it should, instead of restricting your choices in the first place.
Using a dynamic language is therefore like not-so-long time ago computers that had exactly the same plug for the keyboard and the mouse. At startup, if you plugged the mouse in the keyboard socket and vice versa, your computer did not emit blue smoke but it did not work either, and you had to unplug and swap the cables.
This was not user friendly. Dynamic languages are not user (where the user is the other programmer that has to use your object) friendly.
Publié par Stephan Leclercq à l'adresse 10:22 AM 0 commentaires
Libellés : Dynamic typing
Friday, August 24, 2007
Yet another attempt at publishing my code
I registered an open source project on Google Code today. This is the n-th attempt at publising my source code reliably.
I tried SourceForge (a long time ago) and was never able to use it properly. Either you need a complicated set of tools to do SSL tunnelling (just in case someone impersonates your connection; hint: I don't care if FTP is not as secure as it should be.)
Next I tried to enable Subversion on SourceForge. Never worked.
Then I switched to GotDotNet. The source control client never worked properly. And the site was shut down shortly afterwards.
Then I gave a try to CodePlex. I was happy with that one. It had (almost) all I dreamed of. Except of course a reliable backup, so a guy hit the wrong switch and whoosh all my data was gone. This disagreement led Microsoft to discover that their backup procedure was sub-optimal (i.e. the backup could not be restored :-) Not only mine, by the way. Dozens of projects were gone for good.
Now I am willing to try again... Oh but I miss some of the CodePlex features though. Anyway, let's hope it will work this time.
http://flimbase.googlecode.com
Publié par Stephan Leclercq à l'adresse 5:22 PM 0 commentaires
What's in a title
Welcome to my coding blog. This is where I will rant about the features I miss in my usual programming languages, make fun of other people's errors, and sometimes say something sensible about programming. Expect topics about why I like multiple inheritance and static typing.
Now. Where does that silly title come from? From a book I owned a long time ago, titled Microsoft Basic Decoded & Other Mysteries for the TRS-80. This book contained the entire disassembly of the TRS-80 Model I, Level II Rom. It used a clever technique to avoid copyright problems. I think you can still order it... from Russia: http://www.urss.ru/cgi-bin/db.pl?cp=&page=Book&id=18425&lang=en&blang=en&list=319
Publié par Stephan Leclercq à l'adresse 4:06 PM 3 commentaires
Libellés : Welcome