Happy birthday and thanks

Today is Diego Maradona's birthday. Thank you so much for your art, and for being a source of inspiration.

Getting to know Mr. Warhol

I lost myself at Powell's main branch, looking for the new postcards they have, each with a different design based on the room they are in. And in the Pearl Room, I found a book about Andy Warhol. Well, I had heard a lot about Mr. Warhol, but had never done research on my own. Therefore, I looked at this book which was extraordinarily large, both in page count and page size.

The thick paper reproduced his art, which I have to say did not impress me much. More interestingly, however, the paper also reproduced quotes. Soon enough, I was flipping pages looking for the quotes and skimming over the glossy prints. Out of all the ones I read, besides the famous 15 minute one, here are three that called my attention.

They always say that time changes things, but you actually have to change them yourself.

When you think about it, department stores are kind of like museums.

It's the movies that have really been running things in America since they were invented. They show you what to do, how to do it, when to do it, how to feel about it, and how to look how you feel about it.

Alas... I find them to be so true... especially the last one, in particular when one replaces "movies" with "TV shows"...

Life Index Lyrics --- Update

So... listening to FR-034 again, I filled a couple blanks since last time.

1. From simplicity into complexity.
   
2. From singular cell into freewill.
   
3. As my heart beats, I feel the seconds less.
4. I shall cherish it where others don't understand.
5. Violent nectar [?] of life, something you never knew.
   
6. This rose is for you only, Kammi my absent friend.
7. It has bloomed in the garden of my subconsciousness,
8. in the tragedy I wish not to comprehend.
9. We slow down.

What a beautiful work... if you have not seen it yet, check it out.

Update: here are the actual strings used for the synthesizer.

1. !frAAm 1 sIHmpl2IHsI1HtIY !IHntOW kAAmpAXlEHksIHtIY
2. !frAAm sIHNGgyUWlER sE2Hl !IHntUfrI2YwIHl
3. !AEs mAY hAArtbI1Yts !AY fI3Yl DHAX sEHkAOnds 1 llE2Hs
4. !AY 4 SHAOl CHEHrIHSH IHt WHEHr !AHDH1ERz !dOWnt3AHnd2ERst2AEnd
5. !vAYWlEHnt 1 nEYtCHER !AXv l2AYf !s1AHmTHIHNG yUW 2 n2EHvER nUW
6. !1DHIHs !rOWz IHz f1AOr 2 yUW 3OWnlIY kAAmmAX mAY 2AEbsEHnt frIYEHnd
7. !IHt hAEz blUWmd IHn DHAX g1AArdEHn !AXv mAY sAHbkAAnSHAXsnEHs
8. !IHn DHAX trEYjEHdIY 6 AY wIHSH nAAt tUW k1AAmprIHhEHnd
9. !w3IY sl2OW d4AWn

If somebody could please verify the beginning of line 5, I'd be very grateful. Thanks in advance! See here for more details, data files, and a winamp plugin that plays V2 synthesizer files.

Lambda calculus, Smalltalk, and you

So... after thinking about the whole issue of types for quite a bit... I have to say that I am happy I work with Smalltalk. But the reason why is interesting, because I think it's more than just some sort of "it struck my fancy".

From the label experiment and the conversations with Dan Ingalls, I gathered the fact that when designing a language, it is important that it does not have too much stuff in it. This is because whatever you put in the language, you will have to mess with via a computer interface. And this makes interacting with it slower, in the same way that hard drive access causes considerable lag for a modern CPU.

In short: the more stuff a language has, the slower the interaction with it will become.

Now, since productivity is one of the values I care about, I cannot help reaching the conclusion that I want a language with the least possible stuff so I can be most productive with it.

So what is this least possible stuff? Well, if a language had nothing, then everything would be in our mind, and this is an issue because then we don't take advantage of the computer, and we also overflow the rather scarce 7 plus minus 2 slots of scratch ram we come with.

Therefore, a balance must be chosen such that what stresses our scratch ram the most stays there, and what stresses our scratch ram the least goes into the computer. Language design is a register allocation issue.

Consider then lambda calculus. If we're reasonably trained to do natural deductions in logic, then adding lambda calculus does not seem like that much of an additional imposition. Putting lambda calculus annotations in the computer however causes human interface traffic because in order to think in one's mind, one has to make reference to stuff in the computer. We can cache all we want by remembering, but eventually we will hit the hard drive and then our overall productivity will go down just because of the particular register allocation model we chose.

Therefore: do lambda calculus in one's mind together with the logic. Then, simply store the results of all this calculation in the computer. And do it in a way that makes it easy to reconstruct the deductions and lambda calculus annotations on demand, but without resorting to verbose artifacts that cause human interface chatter. In other words, be intention revealing.

Enter Smalltalk. No type explicit annotations of things we do in our minds, just one of the places where expressing results of deductions with type annotations is easy. Because, as we know, when we write Smalltalk we think about types in the sense that we have to keep track of what messages will be sent to what objects.

I insist that by designing a network of objects such that each local evaluation context fits in our scratch ram, and such that the chaotic interaction of the parts is designed in such a way that the overall system has the emergent property of solving the problem at hand, is (one of) the most efficient ways to get things done. This is just because working this way implies taking advantage of a human friendly scratch ram register allocation strategy.

Watch how you think, run a time profiler in your daily work, and see where the time is going. If most of it goes to clicks, typing and reading, then you have a register allocation issue. Then, solve it by allocating your registers more appropriately, and then training yourself to take advantage of the new register allocation. Most brain cycles should be going into design anyway.

Eventually this will drive the language you choose to work. And the good thing is that Smalltalk is just one option... and even if it were and you happened not to like it, you can change it to your heart's content.

I find myself very productive in Smalltalk. How about you? :)

Smalltalk Solutions 2007

So... where's the STS 2007 website? Does anybody know the submission deadlines?

OOPSLA 2006 is over!

As all things do, OOPSLA 2006 has also come to an end. What a good experience it has been! But now, it is the time to work so we will have cool things to talk about at the next OOPSLA.

Fourth demo went well

So, finally... the fourth demo is done. It was cool, some C/C++ guys came by and had a great time (I think!) seeing an alternate approach make code run really really fast. I am happy because, overall, I had a varied audience --- which is one of the things I was hoping for.

It was also good to go through the motions of giving talks again. It is so much fun, but I was so rusty! I need to do this kind of thing more often.

The last OOPSLA keynote: Philip Wadler

So there is this guy with a Lambda superman suit talking about stuff... what is this stuff? It certainly tickles my curiousity! Well, I have been exposed to the type system in Haskell. And, in addition, I have been exposed to generics in Java. Both of them are based on lambda calculus, which is types for natural deduction.

Hmmm, to summarize, generics in Java is incredibly verbose and, according to the presenter, even cumbersome. Enough said about that.

Haskell's type classes are, as I understood them, a way to pass a sort of "method dictionary" so that type inference works. However, the type inference breaks when not all sends are "monomorphic". Well right, if all sends are monomorphic, then types are essentially method lookups --- hence my previous claim that good type inference engines are hard to come by*.

What struck me again, just like with the experiment I did yesterday, is that you can think about typed lambda calculus all you want and that's fine... but you should never explicitly write any of it down. Just the sheer amount of typing and manipulation required to prevent, say, comparing apples to oranges, is disappointing. Because if the problem is that the comparison does not make sense, one should not do it --- period.

Even from a pragmatic point of view, what are you going to fix? The type declarations to prevent the comparison if and only if you run into the particular problematic scenario, or think of issues when you imagine what could possibly go wrong before anything actually happens? I do not think this is particularly productive because we all have known many a great problem, most of which did not occur.

Incidentally, doing refactoring work on type classes is, according to the Lambda guy, nearly impossible. Hence, cost of change is high even with type classes.

So, to me, it comes down to two paths so far. You can try the guessing and adivination game, or you can just fix the bug if and only if it occurs, or as shown by functional testing. Currently, I feel I am more productive with functional testing, so that's what I choose for myself.

However, I wish there was some proper research done to clarify this issue so this decision can be made more rationally. Alas, according to the Lambda guy there's no scientific research available to answer this question properly once and for all.

So, given the material available to me at this point, I have to fall back to my previous position. I can use all that in my head, should I choose to do so, but there should be no explicit manifestation of such artifacts.

As I close the lid of the laptop, I cannot help feeling that types, described this way, remind me too much of the "warning a baby could drown in this recipient if it is filled with water" labels printed on 5 gallon buckets.

Then again, as far as Haskell goes, it is certainly a huge improvement over Java.

* I have a feeling I might have gotten this wrong somehow the first time, please excuse my trying to take down notes as the presentation is still going on. I wish I could have updated this sooner, but Wifi had gone down after a power system failure that tripped the fire alarm and caused everybody to end up on the street.

Update: I changed the title because I didn't choose the first one very well, and reworded a couple things that did come out to reflect what I intended. Please excuse the mess :(.

Firefox and Mozilla

I can't help noticing... the more time goes by, the more old quirks of Netscape appear in Firefox. Here are a few that keep coming up:

• Pages do not load and seem to get stuck. Retrying the request works just fine...
• Sometimes, for no apparent reason, pages render incorrectly. If you reload, things looks fine.
• The web cache is too persistent. You update your blog, and it fails to update. You hit refresh, and it shows fine. Sometime later, you bring up your blog again and you get a 2 day old cached version. Some other times, comments are missing too. Hitting refresh fixes the problem... at least for a while...

Hopefully these are glitches that are about to go away with Firefox v2.0.

Stormless lightning

So lunch was more or less over, and I had had a lovely discussion with Rik Smoody and Rebecca Rikner, the lady who designed the logos for the next OOPSLA... art, Sweden, style when programming, the state of the school system, even Perelman books... fantastic conversation.

And then I went with Rik to the lightning talks scheduled at 1:30pm. But there was no chairman. And only one person from the schedule was there to give talks. What in the heck?...

... so we simply self-organized into giving spur of the moment talks. I shamelessly decided to go first, and spoke for about 5 minutes about JP Morgan's Kapital project and how Smalltalk and GemStone enable us to deliver exceptional value to our customers. I hope I can do this one more often and with more material because working on Kapital is really exciting :).

Then this physicist gave a talk about how the same geological feature can be seen differently by different people, and how one can abstract a quite informal but working model of movement and spatial constraints...

... and then he said something that I found suspicious. He said that in order to get outside the room, one had to exit. Seemingly innocent. But in my mind, that got reformulated as "to change position with regards to the room, one has to cross its boundary". And there was that funny wording in his slide, "form follows from function"...

So I had to ask. Had he read Laws of Form? And the answer was yes! So he goes "hey, I've never been around people that have read Laws of Form, how many of you read Laws of Form?". Many hands go up. Astonishing.

Then this guy Evan Phoenix came up to the stand and gave another improvised talk, based on a talk he had given at RubyConf a few days ago. In brief words, he described the following.

• Ruby stole from Smalltalk... but it has all this mixture of stuff...
• So what if we steal from Smalltalk and Lisp even more?
• So he took the Blue Book, shuffled the stuff, and got a first working prototype of a more proper VM for Ruby.
• But it was crap so he ditched it and did another one.
• And another one.
• And another one.
• With the idea that the first working models would be implemented in C by hand translation, but eventually the working model would generate C instead.

Astonishing. Just like that, "oh yeah I took the Blue Book and implemented the stuff" --- !!!.

After he was done, since there was interest in Laws of Form, I gave a quick demo of my Reference Finder. Some guy had this almost gutural reaction when a browser uncovered the classes Form and Distinction on the big screens... I wish I had recorded his almost diabolical laughter... something proper of uttering "and now I control the world!!!". Strange, but so fitting...

I had to hurry up because I had to go give my 3rd Writing Truly Efficient Smalltalk demo. At first there was nobody... sigh...

I thought that well, yesterday the 2nd demo had quite an audience... not only in quantity but also in quality. Like, what am I doing talking about these things to Mr. Wirfs-Brock? This is insane! So I assumed people had decided to see other things... and there was this keynote going on, so I just took advantage of there being nobody and put up more 64kb Farb-Rausch demos on the projector.

Then this guy comes over... Australian researcher, and I start the demo. Then another guy came by. And they really liked it! I had another two guys come in a bit later, and I had to replay the debugger section that shows the efficient code in action. It was very good overall because I could have a closer relationship with the audience, something that is more difficult to do when 50 people are listening to you.

The feedback on the previous demos is working great. I would like to thank Vassili and the GemStone guys again for their invaluable and honest suggestions. Really, good suff.

So now... after the OMSI dinner with Starwars troopers, Darth Vader, Luke, and Han Solo walking around, it is finally time to sleep.

Update: I finally got the names right --- sheesh!

A longer chat with Mr. Ingalls

Dan was gracious enough to entertain a discussion about his new project --- besides the work he's doing at Sun.

He would like to mount a new and refactored framework for authoring visual content over a standardized language (e.g.: Javascript), so the following goals can be achieved:

1. Make a uniform web content authoring platform, instead of all this aggregation of different technologies one on top of the other (http, css, flash, graphics, layout, floating objects, etc etc etc) --- which raise the creativity tax for no good reason.
2. Make this thing run independently of the web browser. All of a sudden, all your UI painters become easier to deal with --- and you get consistent cross platform results inside and outside Explorer, Firefox, etc.
3. Make creation of content easy for everybody.
   

Ian's talk at the Dynamic Language Symposium, in particular the claim that with no optimization a self-bootstrapping implementation of Javascript was faster than Firefox makes so much sense. But then, there is this guy that got hired by Google to make fast Javascript implementations, so who knows. Intrigue, intrigue...

Saw a Java demo based on Eclipse

What to say. It was about this tool to automatically add more or less repeated code to methods, like some sort of "unrefactor" tool. No parse tree, just text based. All in Eclipse, based on files, etc.

Man... we are so spoiled with stuff like our debuggers and things like the Refactoring Browser... that I think sometimes we take it too much for granted... I wish others were more open to taking a look at them, so they would stop all that suffering for no good reason!

Follow up on types

I got a comment that started by quoting a question I made in the original post, "And why do type systems cause so much grief?". What I meant by that question was why talking about types causes so much friction.

The comment went on saying that lack of precision when talking about type systems can be misleading (my own paraphrasing). However, the rest of the original post talks about specific characteristics of type systems. For example, if they explicitly appear in your development work, they cause grief because it's more stuff that you need to take care of.

I wondered last night about the fraction of the developer time that is spent dealing with explicit type systems as opposed to doing the work. What could it be in languages like Java?

Let's say it's 10%, for illustration purposes. Now, go to a manager and tell her/him that 10% of the development resources are going into a system that addresses a particular kind of simple mistakes. Not even the hard ones, not even most of the simple ones, but just a particular variety of the simple ones. So, out of 10 months of work, 1 goes into (essentially) fluff.

I do not think the realization would be well received. Does anybody know the actual time percentage?

An experiment

So finally I decided to implement what I dreamt some time ago... an environment in which there is a soup of labels out of which you distinguish blobs, on which you mount behavior by means of name maps... but then of course behavior is also a name map, and so are blobs, so it's very clear that all of these are just functions from the label manifold into itself.

I knew that this was equivalent to Smalltalk. What I didn't expect was to see how Smalltalk could be derived from that interpretation, and how much more compact and concise Smalltalk is. The only thing "missing" from Smalltalk is more refactoring to take advantage of similarity of behavior patterns more effectively.

Even then, it's interesting to look at Smalltalk from that point of view... a "user optimized" implementation of an information manifold manipulation framework.

Update: I commented what happened to Dan Ingalls, who promptly responded that right, that is what Smalltalk was designed to do.

Oh the implications

I am sure you have heard how Vista builds take 24 hours to be created. But that's nothing.

Running the tests takes weeks.

Talk about lack of timely feedback to help our natural abilities to correlate cause and effect, man...

Conversations about types

Today, as yesterday, the issue of whether explicit/early type declarations are a Good Thing or a Bad Thing came up. Sometimes, I even saw how the discussions got a bit too personal. Besides the fact that talking about people is not going to address technical issues, the observation remains: clearly, it is a tough issue to discuss. But why? And what is it about types that causes so much grief?

I had great exchanges about this topic... and I came to the following summary that I would like to write down before going to sleep.

Overall, the issue of whether to use types or not is a matter of which values you want to emphasize. Do you care about preventing errors from occurring at run time? Do you care about cost of change?

When I work with Smalltalk, I think mostly about the problem at hand because Smalltalk has this tendency to become a mirror for my thoughts. As I put more stuff into it, I get feedback that I can apply to converge to the solution I am looking after more quickly.

As with numerical integration of differential equations, the key here is the size of each integration step. Shorter feedback cycles will lead to better overall results because they allow more fine adjustments to occur more frequently. And since finding a valuable solution to pretty much any problem more difficult than a CS homework assignment requires a Serious Amount of Thought, I think it is a good idea to make the feedback cycle lag as short as possible.

Immediately, this implies that an explicit type system is detrimental. I only have 7 plus minus 2 slots in my mind's scratch ram, and the more I need them for thinking about things other than my problem is going to cause me grief. If I need to swap out parts of my problem to think about explicit type declarations, then I am going to spend time and energy

1. thinking about the problem of specifying explicit types, which also comes with rules and process to follow etc, and
   
2. forgetting and remembering how I was thinking about my actual problem,

instead of thinking about what I should be thinking about: how am I going to express and manifest my (vague) ideas about something in a formal system of computation.

Since I only have so much time to achieve my goals, I'd rather spend time with my problems rather than with manual tools for finding simple errors. In particular, since explicit type tools are typically associated with "write-compile-run-crash-post mortem debug" programming cycles, my feedback cycles would be much more longer. This will inevitably lead to decreased solution accuracy, or at best, to increased energy expenditure to obtain an equivalent result.

Plus, of course, type systems do not let us fix problems in an execution context, thus making us imagine how things would break instead of seeing the actual bug in action. And we know how wrong we can be when we imagine things. So it seems to me that debugging in a debugger is more valuable.

Therefore, if we are to get value out of a type system, it must be of the kind that does not cause us additional work when we are writing actual code --- such as in the form of a button that we press when we so desire.

But good type inference engines are hard to come by. So instead of writing a better tool, let's cause tolerable manual work for the developers and use type annotations instead. In other words, you write your code first, then you annotate and run a type checker.

And it seems like an ok thing to do. You do not pay when you write the code, and whatever amount you pay seems reasonably bounded. Until, of course, comes change and new version 2.0 requirements. The moment you start changing the code again, all those type annotations become invalid. So now you have two options.

1. Maintain type annotations as you change code... but that gets you into the situation where your actual development process is hindered with productivity taxes, or...
2. Forget about the type annotations until you are about to release, then fix them all.

Since the first option seems undesirable, one would go with the second one. But then you ask... why put so much work into something that you are going to throw away? Why can't we put our intentions into a place where they do not lose value so quickly when the slightest change occurs? And why should overall cost of change be allowed to increase? Because the more time you spend type checking version 2.0, the further out version 3.0 is pushed into the future.

So, in conclusion, a type system that provides actual value to developers must

1. be non intrusive with respect to developer work, and
   
2. not need manual maintenance from developers.

I get to these conclusions because I think what developers should do is this most difficult thing of materializing a computer expression of a problem such that a process running through this expression can produce valuable answers. That is what is difficult about being a software developer, not this "secretary work" about filling type declaration forms, complying with syntax sugar, and smuggling our work through the compiler customs so we can see it crash sometime later.

Thus, given the following two options,

• A mandatory, early declaration type system, or
• No type system at all,

I am forced to take the no type system at all option because I think spending considerably more time trying to find an elegant solution will make it far easier to fix whatever simple errors slip through my fingers only to be almost certainly caught by functional testing.

I simply cannot waste time working on anything else than my problems. I only have one life to find elegant solutions to problems. I do not need to think about blame. I do not need to think about shame. I do not need something to tell me I didn't comply. I need something that helps me be more creative. Mandatory type systems do not help neither bring overall value to this endeavor.

Now, for the times when I really want a safety net, I'd rather write a framework that lets me express what those safety nets are. This, of course, is also covered in my book.

A little chat with Mr. Ingalls

I saw Dan again today, and I asked him about the previous post. After all these years of Smalltalk, hadn't it happened to him to become a bit, "bored", by it?

The answer was no, because to him Smalltalk is a vehicle for exploration, for understanding new things, for learning new stuff. For him, what is fun is how to put down what characterizes a problem into a computer so it can be solved, and Smalltalk is a good canvas for doing so.

In a way, he is interested about the meta aspect of it. How to put down what characterizes the problem of helping to put down what characterizes a problem so one can be productive.

How refreshing. And how true. Let's not forget that.

The surprise factor

There has been some conversation today about how, over time, one seems to lose interest in the language one uses. I think to a point it might be boredom, or perhaps it's a feeling of "yeah I see how that can be done" because you have a lot of experience... and then perhaps what follows is some sort of disappointment because it's not exciting as the first time used to be.

As if we needed a dose of dopamine as strong as the first one.

I think that if we stagnate because we do not get as excited anymore, it's not because the language isn't as exciting, and it's not because the venue at which we meet isn't as exciting. To a point it might be because the low hanging fruit has already been picked, and the hard problems make more time go by between the dopamine doses that come with success.

But perhaps, to a certain extent, it's because we keep looking at the same tree. So what do we do?

• We can start a new language where no matter which tree we pick, there will be lots of low hanging fruit.
• Or we can build ourselves a ladder so higher hanging fruit becomes closer.

I am starting to get a feeling that we need more ladders. We keep fixing the same old problems, and we keep running into the same relatively fruitless spots. Seaside was such a ladder. We need more of that.

And... above all... we need to remain able to be surprised. Here is a small story.

Some guy had been studying the teachings of the masters for many many years. No book had gone unread, no anecdote had gone by, this person knew everything there was to know. Finally, he got to meet one of the masters at the master's house. So the guy started telling the master all he had learned. The master got some tea prepared. The guy just kept talking, telling the master as to how he had learned what things and so on. The master started serving the tea, and... well, he just kept pouring and pouring in the same cup and it started overflowing. The guy kept talking though, worrying to embarrass the master if he pointed out the mess that was quickly spilling everywhere. But finally, he couldn't put up with it anymore, he stopped and asked "master, the cup is overflowing... why don't you stop pouring?". And the master answered "if you are full, you cannot take anything further in".

Another amazing day at OOPSLA

The second demo went better with the feedback from Vassili, and it's still running in its alloted time. But of course it can still use some improvement. So this time I got feedback from some GemStone folks that, quite obviously, have been doing Smalltalk for a long time. Tomorrow's demo should be even better.

Here is something that I really appreciate about OOPSLA. If you are open to learning new stuff, if you are open to searching something that can make you better, and if you are open to finding how astonishingly wrong you can be about something... then this is a place to be. Personally, I'd rather get criticism from people with a lot of experience. Because otherwise, how am I going to get where these people got in less time than what it took them? Why should I go down a doomed path when I can avoid it?

More of the same, please.

Next demo coming up...

So... after lunch and enough time for my brain to perform a good scavenge of the new space... the time for the next demo is coming up. Just 75 minutes to go. Hopefully the laptop won't keep thinking it got disconnected from the projector every so often. Also, I am hoping to put some of Vassili's feedback to good use. We'll see how it goes, v2.0 should be better than v1.0.

First demo shown! Three more to go

Man... the jitters... it's so much fun, but after you're done you have the semi-sweaty hands and all that. Particularly nice was how the laptop's video card would keep thinking there was no projector attached --- but only during the slides! For fun, I showed a 64kb demo while we waited for the time to come, and it worked perfectly. I think it has to do with the background of the slides being black. Silly NVIDIA driver...

Three more stress tests to go :).

Off to a good start at OOPSLA today

So... I was sitting on the E tables updating the slides for the first showing of my demo... in about 45 minutes... and the topic of the book came up, and then whether I had a publisher or not. Then, Göran mentioned the book counterpart of cdbaby. I will definitely have to check it out.

Update: compared to the printing costs I had checked out not long ago, Lulu's are more than 4x cheaper! Thanks Göran!!!

Low Space Notifier keeps coming up

Conferences like OOPSLA always do this to me. It's not even beginning to be late, and I already feel like I seriously need to do a compacting GC on my brain because of the information overload.

For example, I had many conversations about the nature of behavior today. They're rather abstract so I cannot quite put them in a blog without writing a booklet, but man... it's great to be able to have many such conversations in a single day!!!

OOPSLA is great. It just makes me want to sleep...

Assembly for Python

At the Dynamic Languages Symposium, the current talk is about exposing the CPU to Python programs in a way consistent with Python. Interestingly, they exposed all instructions of the CPU to Python.

While on one hand this gives great power, it also opens the door to bugs that are rather difficult to track down. I wonder if the risks outweigh the benefits... ???...

Dynamic Language Symposium at OOPSLA

I saw a very interesting talk a while ago, given by Ian Piumarta. Essentially, what is the least possible set of machinery that you need to build dynamic (e.g., modify objects at runtime, modify behavior at run time, etc) languages.

Just as an example, it was surprising to see things like a full Javascript implementation in 400 lines of code.

The necessary material you need is Meta-II, written in the early sixties. Or, on the other hand, ask Ian for their implementation which they will release in 1-2 months.

Very very iiiiiiiinteresting, my friend.

Note about Camp Smalltalk

Good idea: bring power cords and power strips. With wifi, hubs and switches are no longer needed. Also, good thing, wifi is free at OOPSLA.

Those Smalltalk shirts

So how come when I come to these places I see Those Smalltalk Shirts, the ones that have particular vintage such as "this is from OOPSLA 1992" or something like that, but such things cannot be obtained anymore? We should set something up at Cafe Press.

Sunday at OOPSLA so far

Well... since this morning, many things have been going on.

I met with Vassili Bykov this morning, eventually Roger Whitney came by, then Travis, Martin McClure, Eric Winger, John Brant, and others. We went to have lunch and we had a great time. Some of the conversations included: optimization of 32-bit GemStone performance of GbxLargeDictionaryBucket, Smalltalk being used for generating code for sensors running on tiny hardware (900mhz Crossbow CPU, 4kb ram, 512kb flash), Smalltalk being used at JP Morgan, performance of VisualAge GC when the old space is almost full (the new space won't get tenured leading to spending most time copying between the semispaces), performance of Smalltalk code, John Brant's torture tests for RB (e.g., go to String and inline basic methods over and over again and make sure the image doesn't crash), a P2P approach to using shared page caches in GemStone to avoid overloading the Stone with traffic, and many other things.

I insist --- if you are not here, then you're missing all the fun.

We're currently by the E rooms as the wiki conveniently informs. Come on by and join the fun :).

Saturday, Starbucks, and Beyond

I just got back to the hotel. I was at a Starbucks this afternoon, updating the OOPSLA wiki and writing the book (248 pages now). But as there was no movement on the wiki page, I thought that people would get in late today so I wouldn't get a chance to see anybody.

Eventually I decided to go to Powells bookstore. I made two blocks on 9th instead of 10th because I decided 10th looks a bit less happy before getting to Powells. I got to a corner, and I saw this guy walking towards me from the other end of the street. Like any other guy. I could have just let him stroll by.

Not this time. I asked him if I hadn't seen him before, perhaps at a Smalltalk Solutions or an OOPSLA. He turned out to be Roger Whitney, who was coming back from buying an AC adaptor for his laptop as the one he had was at home. Needless to say, we had never met each other before. Now I think I got confused with Hans-Martin Mosner, who I had met in STS 2006...

We went back to the Starbucks, we updated the wiki page, and we had an interesting conversation about artful Smalltalk. In particular, Roger teaches Smalltalk at SDSU (as you can see from his link). Here are some interesting things I did not know.

• Enrollment is way down, there are 4,000 students for about 10,000 places. Computer science, in particular, is down 40% since the dot com bubble bust. This figure is consistent with other campuses.
• Universities train students into writing comments for even the simplest methods because instructors do not read the students' work. Therefore, comments are perceived as a feature by the instructors who grade work by skimming, reinforcing the notion that even "x := x + 1" needs a comment.
• Students think that "console output" is enough of a good way to obtain a result out of an object oriented program. Get every 2nd node out of a doubly linked list is interpreted as dumping the stuff into the Transcript. The inspector is unused.
• A full 25% of the grade Roger assigns to students is based on the comments. Are they bad comments? Sorry, now you get markdowns. Even after careful instruction, on average about 1 student every 40 will do their homework assignments properly.

Welcome to reality --- we really need to do something about that.

So Starbucks was closing down at 8pm. I updated the wiki again because we were going to have dinner at Mandarin Cove. I was putting the laptop away to leave and at that instant John McIntosh walked in through the door. He had arrived with Tim Rowledge a while ago and they were starving.

Off to Mandarin Cove we went and we had a great conversation about the status of our projects. If you were not there, then I am really sorry for you my friend because what you missed is simply too much to be put down in a blog.

What a great start for OOPSLA 2006. More of the same, please. See you tomorrow!

Enjoying PDX

Portland is such a nice city... if you're in and you'd like to meet, come on over to the Starbucks at SW 9th and Taylor (don't forget to check out the wiki as well).

Welcome to Brave New World

But yes, what a good idea... manufacture babies. And what happens when one neglects a nourishing environment and wants to exercise the warranty? A complete mess and an exercise in misinformation, coming from this article in New Scientist. Shameful.

Now go read Brave New World by Aldous Huxley.

OOPSLA --- Red Lion Hotel Hint

If you will be staying at the Red Lion hotel across from the conference center, ask for a room facing North. According to Marisa (helpful lady at the front desk), rooms facing North experience much less noise due to traffic.

OOPSLA Wiki Page

If you are coming to OOPSLA, check out this Wiki page. See you here :).

OOPSLA is coming up --- no wiki page?

OOPSLA is essentially next week. Did I miss something or is there no wiki page somewhere so that Smalltalkers can synch up with each other? Personally, I think missing the chance to see each other outside the context of OOPSLA would be a shame.

I think we should get something going --- here are my 2 cents. If there are better alternatives, then by all means let's use them!

Update: people are signing up! This is great stuff!

How these things begin

I had a chance to wonder about the circumstances in which I learned Smalltalk. To a point, they were a bit miraculous.

I did not like a university, I went to another. I realized how much I disliked how Computer Science was being taught, so I shifted to Mathematics. The Algebra instructor I had was not fun at all, so I decided to change to another Algebra class. The guy there also knew how to program computers, very nice. I started talking to him about computer programming things, and eventually he insisted so much about this thing called Smalltalk. I was curious, and in time he spent 3 hours and taught me the basics. I paid attention to what he had to say. Although my Pascal/Assembler past was not the best background for it, I took a more or less unbiased look at it. And I liked Smalltalk because you could have things that behaved in a much more real sense than a bunch of bits thrown somewhere.

I saw my old programs, in which I had invested so much time and energy, become obsolete overnight. It didn't bother me. I had something new and better to learn.

Had I insisted with any of the things I did not like, I do not think I would have heard about it. Had I determined that Smalltalk was bad because I couldn't do xor ax, ax or any other far fetched thing, or had I been too attached to what I had done already, I would not have paid attention to it.

So what is the mechanism that draws people to Smalltalk? These small miracles? Or something else? What is your story with Smalltalk?

More and more Smalltalk blogs

Going through blog comments, I found Tim's blog called Pintside Thoughts. Welcome!

Us vs. Them mentality

I went over the page Blaine linked, the one with the quotes about Smalltalk people being arrogant and such.

Let's assume all that is true. After all, even today I meet Smalltalkers that are nearly intractable because they won't listen, or they will be unnecessarily aggressive, and in general will care more about themselves than about getting the job done.

But wake up and smell the coffee, my friend:

The Smalltalk community does not have exclusive rights to such people.

There are people like that everywhere! In fact, how about the people you meet every single day, all those with whom you cannot even utter certain words because otherwise you get judged as guilty of all possible crimes? Isn't doing that equivalent to assuming that "this person has idea X, I do not like idea X, therefore I do not like this person"? Isn't that awful close to concluding that "I do not like this person, therefore I do not like any of this person's ideas either"? How's that for being arrogant?

What should happen is that the arrogant people should get ostracized for being obnoxious, and that some other less arrogant people should take their place. Fortunately, that has a healthy tendency to occur over time. But by far the most important thing that should happen is that people become able to listen to each other. And please note that listening is much more than hearing some sound coming off from some mouth nearby.

In the mean time, why do we have to mix whether the arrogant person knows Lisp, Java, or Cobol with the fact that we cannot stand the person to begin with? What in heck do the qualities of whatever programming language have to do with how unbearable the person that knows such languages is?

Computer programming issues are perpendicular to how beautifully people look in a mirror.

This whole so-called issue is pointless, and a complete waste of energy. The lesson we should learn once and for all is to let go of people issues when we deal with technical problems. Because it's not like if Moe, Larry and Curly are pissed off at each other, all of a sudden their development tasks become easier to accomplish.

Once we ditch all this nonsense away, we will be more able to just do our best. And that would be bad because... ???...

SUnit Benchmark Runner v1.0

Haha! So now I have the benchmark running version of SUnit ready for OOPSLA. Right now, it has a notorious lack of more or less obvious features. But I like to do my homework in advance, so now I may have a chance to improve it before show time.

All that manual work automated down to a click... so nice...

Different rythms, different people

Reading random stuff I ran into this article about a society organized around the idea that whatever is "good" only comes in limited amounts, and that therefore each member is entitled to a fair share. In particular,

With the belief of the "image of limited good", these [people] would therefore condemn as immoral many of our Western economic and business practices and social behaviors. Among these would be our allowance of the amassing of great fortunes whilst others are poor, the driving of business rivals into bankruptcy, the unwillingness of many to be charitable in heart as well as mind. The list goes on.

Those naive people, questioning the infinite amounts of whatever is "good"... in fact, the absolute truth, our unquestionable right to have faith in that there will be an endless, ever exponentially growing supply of "good" things.

Wait a moment now. We already know that to be false. There are only so many resources on this planet, on other planets, in the universe as a whole. Their amount is not infinite. But we just go pretending they are because it is so much easier. Facing the facts and dealing with the consequences of our actions is tough when one is spoiled beyond repair. Our unchecked greed shortchanges us because, overall, we end up allowing whatever we hold dear to be destroyed. We know this too.

Regardless of which posture is more "correct", the fact remains. We are such primitive, selfish little beeeep...

More abuse of SUnit

And again, I wrote another testing framework by extending SUnit. This time, it's a benchmark tool that can measure iterations per second of many different implementations of the same functionality against many different test cases.

To think that for the book I tested 28 test cases against 6 implementations with two varieties, for a total of 336 printIts and 70kb of workspace code... all done by hand just because I thought it was a one time effort...

In the new framework, all that has been reduced to 6 test methods and 56 set up methods. Now all I need is the results UI and it will be ready for OOPSLA.

Incidentally, SUnit 3.0 as shipped with VW 7.2.1, could use some refactoring.