To interface or not to interface

I've posted some comments on Troy Brumley's blog here . He liked the metaphor interface is a "firewall": we use it in order to isolate "changes": I don't want to be affected by your changes, and you don't want to be affected by my changes.

Actually an interface is a "wall", a very thin layer, which hides implementation details. And we should use is at framework, package and object level. In practice it doesn't happen: we "trust" our object within an package, or within a framework.

An interface defines a "contract": somebody understands this set of messages. Why don't we have interfaces in dynamic languages? Because we don't need this wall, we are always talking to a duck.The implementation is always hidden.The contract  resides in the UnitTests.

Qumana

I tried to download wbloggar, but the site is down. Let's see how is this working...

Powered by Qumana

Before and After Ruby

found on the "journal of jess".

Also Torsten is wondering here:

What I dont understand is that people complain about Java and start with Ruby right after it.
What if they would take the next step and directly start using Smalltalk. I'm sure they will enjoy the wonderfull world full of objects.

Well I think that Smalltalk environment is too scary for a java developer: no code files, no cvs/subversion, everything is in an image file, etc.

When a java developer plunges in Smalltalk, he has a "What now" moment: everything is there, but he does not know where to start.

Ruby is the "way" to Smalltalk: easier to learn, but OO imperfect (ruby has "syntax" and not everything is an object)

The Quality of Many Eyes

here:

Linux kernel development model implies that the developers can't directly add their changes to the main code branch, but publish their changes. Other developers can review and provide comments, and, more importantly, there is a dedicated person who reviews all the changes, asks for corrections or clarifications, and finally incorporates the changes into the main code branch. This model is extremely rare in producing commercial software, and in the open source software world only some projects use it. Linux kernel has been using this model from the beginning quite effectively.

Raise your hand: Who's doing code-reviews? Who's doing pair-programming?

saturday reading

Lisp is Not an Acceptable Lisp
and
Steve is Not an Acceptable Lisper

from reddit.

Smalltalk Flexible Exception Handling

when *everything* is an object
- via James Robertson

Ruby and Lisp

found here:

So, Ruby was a Lisp originally, in theory.
Let's call it MatzLisp from now on. ;-)
– Matz
Larry Wall never understood Lisp
Guido Van Rossum once read a book on Lisp
Yukihiro Matsumoto once read a book on Lisp and understood some of it
– Keith Playford

Code Generation

Bill Veners here
Dave Thomas here

I don't like code generation. It feels to me as a step backwards and not forwards to a solution.

Instead of saying: "let's write a class/object with this functionality", we say: "let's write another class and a template, to generate a file, which compiled, gives us the needed object and functionality". Hmmm....

If the algorithm is so generic that we can express it in a template/file generator, why can't we write a class which through reflection generates the needed functionality?

How do you unit-test generated files? Do you test the output code, or do you test the new object? If you test the created object (the new functionality), than you have one additional step in unit-testing: compilation.

My point is that:

Ruby is dynamic enough to let be do what I want without leaving the language

Smalltalk is more "extreme" than ruby. There you don't have source files !!!

Java/C# should be "dynamic" too. I think they already are, through reflection and dynamic code generation, almost as flexible/generic as Ruby. But the developers are always scare of the performance loss. So they prefer an "immature" optimization, instead of a "clean" solution.

SPA 2006

James Robertson blogs about spa 2006.

chaos = order

hmmm

Testing Hypothetically

If you make abstraction of the code you write, you are specifying a behaviour for your objects.

saturday reading

Bambi Meets Godzilla
The Rise of "Worse is Better"
Jao has some good blog entries.

It's not about the content.
It's about the "sparkle which starts the engine".