goran.krampe at bluefish.se
goran.krampe at bluefish.se
Mon Oct 6 15:26:57 UTC 2003
I don't really want to get dragged into this thread :-) but I wrote down
some of my thoughts while reading. Perhaps it is of interest to someone,
what do I know.
- Type assertions/checks...
The test is "Does x refer to an object that I, the original programmer
at the time of writing, consider to be a valid object here?". This
demands that the original programmer come up with a rule of
distinguishing a valid object.
Java uses types (class or interface) for this and checks it statically.
In Smalltalk we *could* introduce Java-like interfaces (and it has been
done) but whichever mechanism you use (except for one which I am a bit
interested in, see sidenote below) you would end up "hardcoding"
something that may change in the future. How so? Sure, interfaces are
better than only having classes - but they are still a static construct
typically written by somebody else than the user of the objects. I mean,
I *know* my Snickers bar could be sent in there but hey, if it doesn't
implement interface Fruit - then it can't get eaten according to the
daft programmer of the library I just bought...
In Smalltalk we have the "if it quacks like a duck..."-typing (as Avi
wrote I think) so again, the idea that the code only expresses exactly
what it needs to express in this case makes it easier to change - as in
we don't need to change it, it works just fine with the Snickers bar
Another aspect is that we don't generally try to predict what the users
of our objects will do with them. The notion of
private/protected/interfaces blabla in the curly world typically makes
the assumption that the programmer of the objects knows *all* the ways
the objects will and can be used by other programmers, both now and in
the future. Very often this assumption proves to be false.
- Assertions only catch "bad" situations that I can predict. Not the
By this I mean that in order to write an assert I need to know what
exceptional situation I want to detect. And if I already know that -
then IMHO there is a great chance that I will not make that particular
Test code on the other hand tends to catch both predicted and many of
the unpredicted bad situations.
- To sum it up
When reading and writing code I personally just want to write *exactly*
what is needed for the code to run. Not an ounce more. The track record
in the Smalltalk world has shown that this indeed can have very positive
effects, sure the compiler has a tougher job - but we think it mostly
sums up on the positive side.
The curly brace land simply can not accept this :-) - curly bracers
firmly believe that code needs to be specified "as much as possible" in
order to increase productivity. Or stability. So we are talking about
different philosophies here:
Square bracketers generally think that speed and ease of development
(less to type, less to read, easier to change) in the end increases
productivity (faster development -> less bugs). We like fast tools, no
compile-link-edit cycle, loose coupling, late binding, minimalism etc.
For example, you can easily type in a short self-send expression right
into an inspector and press alt-p to see the value - fast, fast, fast...
Curly bracers think more or less in the opposite direction - the more
that can be typed, the more information that can be specified about
*exactly* how the program should execute, trying to predict every
possible situation - the less bugs will "get through" and the better the
end result. This puts a tremendous focus on the compiler - the language
is more complex, static typing, love of assertions :-),
templates/generics etc. More declarations, belt and suspenders on.
In the curly brace world the program turns into a truly fortified castle
that tries to close every little hole that the darn bugs might slip
into. The castle takes a lot of time to build - lots of code to type.
And it is hard to change or move.
In the square bracket world we emphasize agility and dynamics. The
program turns into a slick dynamic cooperating loosely coupled group of
fighting vehicles that can easily be changed and adapted to the nasty
over and out, Göran
Sidenote: regarding interfaces: I would think it could be interesting to
talk about "interfaces" as in a matching of sent messages. Instead of
declaring that x needs to implement the (Java flavour) interface Fruit -
I could say that x needs to respond to messages #eat, #throw and
#ferment. Then *any* object actually responding to those messages would
work. Note the subtle difference here - there is no named interface
here, just a collection of selectors. Typically these
"x-responds-to-this-collection-of-messages-assert" could be used in the
unit tests. I am saying "could" because they are still a step towards
the "castle", but could make someone happy at least.
PS. And of course - the TRTFTRJ - The Right Tool For The Right Job.
Curly braces are great for building operating systems or close to the
metal stuff. I just don't do that. :-)
More information about the Squeak-dev