Check this out, then close your eyes.
Monday, January 31, 2005
Saturday, January 29, 2005
I've watched some of Doug Engelbart's videos lately. It is very irritating to see how little progress we have achieved in the last 40 years. Today's average programs are so cumbersome as far as human interface goes. You should see how easily Doug manipulated a flow chart with an optical pen in the 60s. It makes me feel we should be more than ashamed and humbled by the fact that all we have achieved is colorizing and complicating something that should have been simple to begin with!
Posted by Andrés at 17:28
Thursday, January 27, 2005
I got the video file for Alan Kay's OOPSLA '97 presentation, The Computer Revolution Hasn't Happened Yet.
It's amazing to see how simple yet profound are Alan's contributions, how much meat in them is directly connected to drawing distinctions, and how much genius is necessary to recognize, realize, and reify these ideas regardless of how straightforward they seem.
"It requires a very unusual mind to make an analysis of the obvious" - Alfred North Whitehead.
The concept of encapsulation based on a cell wall is a good example: the cell wall is the distinction between the inside and the outside. Our skin is the distinction between outside and inside. And so on.
The boundary, drawn by intention, makes things exist in terms of what is inside of it.
You can see this in Croquet, too. Each space is a form, each portal is a distinction leading into another form. It may be the case that the form being crossed into is the one the distinction is in - the Croquet mirror.
I like to think about objects in these terms, too. Each object corresponds to a Croquet space. Each distinction corresponds to every object that can be named from the context of the space. Through the portals, spaces send signals to each other. Upon receiving a signal, each space does something to it based on its behavior and, possibly after sending the signal somewhere else, answers another signal to the original sender.
The signal is, like everything that exists, a space marked by a portal.
The act of creating a portal and connecting it somewhere is that of assignment, of giving a name to a space.
Looking in the mirror is evaluating self. Every space should have a mirror.
I have the feeling that, in Smalltalk and other languages, we take the ubiquitous ability to give names for granted too much.
Continuing on, if spaces behave like this, you can arrange portals in such a way that if you send a signal, the signal never stops. Given a complex enough network of spaces connected to each other, a signal that can trigger multiple other signals, and at least one first signal to trigger the domino effect... where have I seen that before?
Posted by Andrés at 12:00
Tuesday, January 25, 2005
Let's call q(method)=
+amount of arguments
+amount of temporary variables
+amount of instance variable references
+amount of global references
+1 for self
+1 if using super
+1 if the answer is not self
The function q(x) represents the amount of named distinctions referenced in a method. Logically, this amount should not exceed the amount we can hold in our heads. Therefore, for any method x, it should be that q(x) is no higher than 9, and preferably no higher than 7.
We humans don't have a lot of scratch RAM space - but it certainly doesn't show by the way we write code, er, amass spaghetti together!
Personally, I'd rather let the average person have no trouble reading code I write, so let's take q(x)<=7 for all x. It only takes some effort to get used to, but in the end you write code that is easier to maintain even for yourself.
Remember all those lovely algorithms in Knuth's The Art of Computer Programming?... well, hmpf.
Posted by Andrés at 16:16
No class should explicitly reveal that it has implemented the singleton pattern.
If you want access to an instance of a class, whether it's a singleton or not is irrelevant. From the sender side, as long as you get an instance when you send #new, why should you care if it is a singleton or not? Therefore, you should just send #new to the class. How the class implements #new is the class' business.
Any method like #default, #singleton, #theOne, etc makes the class reveal details that should be kept private. There should be no such implementation-revealing method.
From the implementation side, the singleton should be remembered in a class instance variable. My favorite class instance variable name for singletons is 'current'. I use accessors, therefore the class should have #current and #current: accessors, preferably in a private category. #new should send these accessors.
Posted by Andrés at 16:03
Monday, January 24, 2005
I commented earlier how irritating it is to find that something you saw or heard has been pulled out of your reach.
There is an item I am looking for, but I have encountered heavy duty obstacles when I tried to track it down. James Burke of Connections' fame also filmed another miniseries back in the late 70s called The Real Thing. It was funded by the BBC, and shared much of the production team of the original, late 70s, ten 50-some-minute episode Connections series.
The Real Thing is six 30-minute chapters long. At some point in Argentina, it was shown on cable TV. Of course, only the last 5 chapters were shown. I called the TV channel, found the programming manager... and rats, he was aware of the fact that they didn't have the first chapter. So they were showing what they got.
No video distributors in Argentina had the 6 chapters, even in the rare case they had heard about the series at all. Hmpf.
At the end of some chapters, the TV transmission went long enough and you could see a logo of Estudios Lain, the guys that dubbed it into Spanish. After a long time of Internet searching, I found Estudios Lain in Venezuela. I also got a phone number. I talked with this lady that, even though she raked all the files she could...
... COULD NOT FIND ANY RECORD ABOUT THEM DUBBING THE SERIES!!!
The BBC, of course, does not have any record of it whatsoever. I could find no United States library that has The Real Thing. The highly recommended first Connections series, yes. The Real Thing, no.
Every time I have tried a new approach to get a copy of the first chapter, or even better, the full 6 chapters in English, I have failed. So here is a question for you guys: do you know where can I get hold of The Real Thing? I would really appreciate any hints :).
Posted by Andrés at 17:18
So... let's say you want to watch some nice Alan Kay videos such as those found in here. But one of them is a Windows Media Player video, and if you try to get it all you can save is a silly .asx file. Then you wonder where will you be able to save the video file if the site goes down.
But Net Transport will pretend to be a player and stream most videos down to a file, besides ftp/http transfers. That's nice! Yet... the video will be streamed by the server at whatever bitrate it was encoded at. So a long video should take a long time to stream down, right?
Not with Net Transport, because it will launch up to 10 simultaneous threads on the same file at different positions. Now that's an efficient video stream transmission! And now, if the site where Alan Kay's .asx video is decides to take it offline or otherwise becomes unavailable, it's ok because you have a copy :).
Silly typical streaming restrictions. Don't you hate it when something you saw or heard is pulled out of your reach?
Posted by Andrés at 16:41
Sunday, January 23, 2005
Did you watch "2001: a space oddysey"? The music of this movie is extremely strange at some points. How come?
It turns out to be that Stanley Kubrick, the director, had asked Alex North to come up with the soundtrack. However, when Alex was 75% done, Stanley asked him to stop working on it. Later, Alex went to a preview of the movie. Surprise! None of his tracks had been used. You can get the unused 2001 soundtrack... and if you listen to it, you will realize how conventional, how Hollywood it is. You will also realize how much of the movie's punch is because of the music Stanley chose.
What music is this? Well, 2001 sports some classical music. Johann Strauss' Blue Danube waltz is well known. Thus Spoke Zarathustra, by Richard Strauss, is also well known - and after watching 2001, can you listen to it without remembering the opening shot?
After that, there is a piece from the Gayaneh ballet suite by Aram Khachaturian. This is the music that introduces the Discovery and the rotating chamber where everybody lives. So ok, not as well known.
The remainder of the soundtrack is very unusual music by a 20th century composer named György Ligeti. I had always wondered who was different enough to think up music like that! If you watched the movie, you know what music I am talking about. The music of the monolith, the music of Bowman's trip. Indeed, as in Blaine's blog quote section, true madness requires significant intelligence.
Arthur C. Clarke came up with the short stories that were cherry-picked, massaged heavily and blended together by Stanley Kubrick. Stanley then ditched North's soundtrack and favored Johann Strauss, Richard Strauss, Aram Khachaturian and György Ligeti. Good for you Stanley!
Thank you for the excelent music and for the excellent movie, guys.
Posted by Andrés at 21:58
Friday, January 21, 2005
I find it less than desirable to read confused statements like the following.
"[...] every programmer has imagined what it would be like to work directly with the deep structure of the code"
What I find strange first is the expression "deep structure of the code". Without proper names, like reflection, any statement becomes wishy washy. At any rate, the issue is that this is already being done. Yet, for most developers, when the facilities are available even in rudimentary shape, they are ignored, or too difficult to use, or used carelessly. After enough times of hearing this argument, it seems as if for some people there is always a good excuse to keep procastinating and doing things the harder way :(.
Here's another statement.
"It's worth pondering [...] what we could do with tools that didn't think of programs as strings of text"
The Refactoring Browser comes to mind. Next!
Posted by Andrés at 21:22
Wednesday, January 19, 2005
I do not like the term Object Oriented Programming. You can have objects all you want even in x86 assembler. Smalltalk and others, however, are much more about messages. In this light, let's consider the following:
"Consider the profound contradiction between the OOP practices of encapsulation and inheritance. To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it."
No. The encapsulation part is not to keep your code bug-free, although in practice it's a desirable tendency. Encapsulation is there to allow messaging, which is the whole point of most OO languages, e.g.: Smalltalk.
Encapsulation describes how well objects are distinguished. There should be a strong boundary between the outside and the inside. In this environment, everything must happen by sending messages because messages are the only things that are allowed to cross boundaries. It is not an arbitrary decision - it's the only way to do it even if we decide to call messages something else.
Note how in Java for example, encapsulation is not as strict - and all of a sudden you are calling functions instead of sending messages! What a subtle, yet profound, difference.
If there were no clear distinctions between objects, everything would be one single incoherent blob. If there is only one blob, there cannot be a sender and a received for a message, then why send messages at all, right?
In languages in which this is allowed to occur, things happen because the programmers are thrown on some emperor's throne to rule on every bit that can possibly be addressed. This single blob is not diverse enough to route message traffic, much less reflect, on its own.
This language design trait puts the developers in the position of having to know everything so that everything that must happen inside this single blob can actually happen. But it is impossible to know everything.
Therefore, programs written within this control-oriented point of view tend to be buggier because of two big reasons. The first one is that after you are keeping 7 +- 2 things in mind, you suffer from brain overflow unless you spend time chunking. By then, you get hit with change that happens faster than you can chunk, so you can never win. The second reason is that, in addition to never being able to win, the cost of change in this environment is tremendous. Since there are no strong distinctions, there is a single incoherent blob. And in this scenario, local change can easily trigger global change and major rewrites. Not only you tend to lose - you tend to lose like Sisyphus.
Objects, on the other hand, allow you to consider constrained contexts that are easier to deal with in everyday programming. To get the maximum benefit out of this, the boundary between contexts should be as strict as possible - encapsulation. And since you want perfect continence for your contexts so there is a reasonable chance of you having to think about at most 7 +- 2 things, then you need messaging to let distinguished contexts coordinate themselves. And to allow a development style that avoids the pitfalls of copy+paste, you allow contexts to refine others by means of inheritance.
It's not that hard, really.
Posted by Andrés at 20:14
Sunday, January 16, 2005
So if having too many things just keeps you busy, and it seems we as humans developed a lot but evolved too little in these past 10 thousand years, what do you do?
Hard work and practice make difficult things happen. That is really priceless. The possibility to achieve is there for us, and taking advantage of it is very special.
Last Friday, the Huygens probe made Titan become an orange place with shorelines, drainage channels and ice boulders. And as happens with Huygens, Cassini and so many other space probes, extremely large amounts of work go into making these things happen. I am sure some people are really enjoying their lives right now.
So come on... where is your challenge? What is it that you would enjoy achieving? The opportunity is yours - take it.
Posted by Andrés at 21:25
Regarding this comment in James' blog... I am suspicious that new features are what marketers need in order to provide good excuses to go out and buy stuff when there was no yearning for the stuff to begin with.
Since shareholders are behind your back, what is necessary are features for the least cost possible - hence cost control as James says.
Refinement doesn't seem to be an excuse to buy something as strong as new features. I still remember that little phrase from quality management books: the consumer defines what is quality. In other words, volume of sales is the measure of quality because it helps pleasing shareholders.
This looks like the world as designed by very few people for their own benefit. As long as we keep buying...
Posted by Andrés at 19:54
It has never been easier to communicate with people you do not know. You'd think we ought to have really good news.
But it seems as if corporations, on average, assume we're total idiots. Frivolous so-called "local" news to stroke our emotional strings, life presented as a shallow soap opera by shallow anchors, obviously biased slogans to push products to feed our ever growing consumism, lies that go unpunished.
Could it be that, for the short term benefit of being a momentary leader in any research field, people pushing the frontier of knowledge got too carried away and forgot to care for students? As soon as their shine of glory goes away, who is left that remembers these people? Enough of these researchers and you get the bulk of the population to ignore their work just because they seem arrogant, selfish, or just removed from day to day life.
~30% of adults in this country cannot deal with percentages at all, e.g.: can't work out a tip, what is the real significance of an APR rate, or how significant is a tax hike/cut.
A ham glazing envelope lists, among its contents, less than 2% silicon dioxide to prevent caking. If I didn't know any chemistry, I would have not realized it had sand. How are some folks going to decide if the actions of the FDA are ok?
Hydrogen sure seems cool. But where are you going to get the energy to produce it in the first place? And where are you going to store it in enough amounts? Can't we just be efficient with oil in the mean time?
We cannot work out why do we keep paying for an extraordinarily expensive missile defense system that, for all practical purposes, is useless.
And let's don't forget that the latest monster hamburger, with its huge amounts of fat and over 1400 calories, can also help you lose weight as part of a balanced diet.
Meanwhile, each time something bad crops up in a shape that most people can understand, some people come out and make strong statements to say everything is ok.
Covered by all this mud, we ignore clear signs that we are headed towards a new Dark Age in a ruined and polluted planet. Sigh...
Posted by Andrés at 18:51
Thursday, January 13, 2005
I wrote a most beautiful method two nights ago:
- distinguish: aPath
- inject: self form
into: [:form :each | form cross: each]
Those of you who have read Laws of Form will recognize the selectors. It is so beautiful! What this thing does it to build a tree with all the references to an object as found by my beautiful PathTracer. Yes this merges all paths together and does not get confused.
What? You have not read Laws of Form by G. Spencer-Brown? Did you know that G. Spencer-Brown was at Xerox PARC in 1979? Did you know that Design Principles Behind Smalltalk has almost verbatim quotes from the book?
It's strange. It's definitely weird. It has a bit of stuff that I feel is just ranting. But the ideas in it... wow... just remember: it's all about the signal running on the signal path.
PS1: Just a few more hours left. Go Huygens!!!
Posted by Andrés at 18:15
Friday, January 07, 2005
Not a long time ago, a prototype space probe managed to swing by a comet and take pictures when it was definitely not designed to do that. It even used its ion engine's monitoring instruments to sample comet data while facing the tail's stream of debris with zero shielding - and survived to tell the tale! What a great success out of a daunting challenge!
Later, I had my second thoughts when I learned that the Mars Rovers had a minimum life expectancy of 90 days. I couldn't help feeling "all that travel and $800 million for 90 days, after building twin rovers?". I felt the engineers could not have resisted the temptation to, in order to ensure 90 days of survivability, build a rover that could possibly survive Martian winter. I wanted them to have sinned as bad as possible :). I am so happy the rovers are still roving around!
More recently, Cassini has been sending the most spectacular pictures of Saturn. The snapshot of the Encke ring division with its gravity waves is extraordinary. There's another setup for the photobook when one of Saturn's moons seems to hover above the rings, while the rings cast a blue shadow on the planet. Mind boggling. They are such fabulous pictures!
Writing about the Voyager space probes, Carl Sagan wrote that because now we had pictures of celestial bodies we knew very little about, they were no longer just light blips or a name written somewhere. They became places.
And now, finally, it is time. The Huygens probe will drop into Titan next week. I can't wait for the descent pictures, the data... will it splash or come to rest with a bump? What is the chemistry like? How far did the temperature allow organic substances to evolve? What kind of place is it?
We have the ability to get the answers to such cool questions these days! I am definitely asking for more.
Posted by Andrés at 08:56
Thursday, January 06, 2005
There is a referenced article against accessors in Blaine's blog. In that article, you can find the following assertion:
A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.
The conclusion does not follow. Messages provide behavior, and if you complain that the accessors are giving you implementation details it's because you are being too smart.
In other words, if you look at an object that understands a set of messages and, violating encapsulation, you look at the implementation details and find that some of those messages are accessors, then you complain because the object is violating encapsulation. But wait a minute: who was the smarty pants developer that violated encapsulation in the first place?!
Sigh... another instance of curiosity killing the sender.
When you send a message, you should only care about the behavior. Then why is it that a sender of a message needs to care about whether a message is an accessor or not? Senders should stay at whiskers' distance from the receivers.
If you, following proper programming practices, judiciously send a message for a good reason, whether it's an accessor or not is irrelevant. If you need to send the message, then chances are it makes sense, therefore any implementation should implement it. How this is done is the implementor's business.
Blaine's main conclusion is that whatever you choose, you should be consistent. I would like to add that one of the few inconsistencies left in Smalltalk is that assignment is not a message, thus violating the tenet "everything is done by sending messages".
In my opinion, sticking the instance variable assignment in an accessor helps containing the inconsistency in a rather small spot. This "almost consistency" then helps out in the following ways.
1. Using accessors provides a uniform referencing mechanism that can tell who is using the instance variable by just asking for senders. If you don't use accessors and want to find who sets and reads the instance variable, you are forced to ask for references to the instance variable first, followed by reading all the methods to make sure they don't propagate the instance variable access responsibility somewhere else, making sure that you are not reading superclass implementations that are refined in the subclass you are interested in, oops then you find that the messages referencing the instance variable call each other so now to understand you need to walk the graph of the code making sure you keep in mind at which point things are read/written...
... and by this time you need to remember more than 7 +- 2 things, and just sending senders was more efficient, less time consuming and less prone to code reading mistakes to begin with.
2. Code without accessors is hard to change, too. Do you want to add or remove lazy initialization? What about clustering some instance variables in a new object? What if, oh no... you need to move some methods to another object? Aaargh! Now something that should be trivial becomes a half-hour refactoring task! This is just another small accomplishment having its value artificially increased.
3. Instance variables without accessors are object-wide globals. We already half-despise class variables and pool dictionaries. Why do instance variables without accessors get any mercy in our refactoring quest?
Too bad temporary names can't have accessors too :(. But on the other hand, always using accessors for instance variables implies that all assignments you see in something other than an accessor must be to a temporary name - "almost consistent".
Posted by Andrés at 11:08