To Closure or Not

First, read this before continuing.

Both of the extreme cases seem comical. One takes the position of nothing but objects and the other nothing but blocks. It seems that pure object-oriented programming is at odds with functional programming. But, it's not. They need each other. I think Smalltalk and Ruby strike a good balance in this area. Blocks are used as lightweight objects (ala syntactically cheap) where a full object definition would be cumbersome. But, having nothing but blocks would also be problematic. For bigger things, we use full objects. It's the balance of having both that allows us to choose the one that allows us to more succinctly express our solution.

I don't know why people argue these things. There are problems that are better expressed in objects and others in closures (blocks). Why do I have to choose one over the other? I want both! There's also a lot that object-oriented programmers can learn from functional programmers and visa-versa. In fact, I'm always shocked how much functional programming is in pure object-oriented languages like Smalltalk and Ruby.

I'm going to go message something.

Notes From One of Alan Kay's Talks

Notes from Alan Kay's talk at O'Reilly Emerging Technology Conference 2003. Now, I was searching for something else and came across this. The interesting bit is the exchanges of emails between L. Peter Deutsch and Alan Kay.

"interactive LISP -- a metainvention, the Maxwell's Equations of programming. Today is the 40th aniversary of the first interactive implementation by a 16-year-old Peter Deutsch. It was the first time a programming language became an operating system."

WOW! Really, that's all I can say. Peter does correct the above quote. But, I'll leave that to you to discover. Makes me wish I would have asked more questions when I met Peter at Camp Smalltalk. Darn it!

Prefactoring Hate

I was shocked to find developers appalled by Ken Pugh's "Prefactoring" book. In both cases, it's amazing how much they missed the whole point behind the book by focusing on exact definitions. I think it's an excellent book on design and who couldn't use another of those? It seems to me that the XP zealots are the only ones that have a problem with it (look at the comments at Amazon). I remember the Amazon comments when the book came out, but I just ran across the above blog entries. Oh well, each to his own and if you're curious, Read this article by Ken Pugh for more on "Prefactoring". I strongly suggest you read the book. There's too much good advice in there to be ignored. The discussions on abstract data types and collections are awesome.

After A Rough Day, This Made Me Laugh.

I was browsing the net and found this....

I don't why, but it made me chuckle. It cheered me up a little from a very dark day.

About Time

The glorious end to text-based command line environments is around the corner:

Commands are not Text-based
Unlike traditional command-line interface commands, Windows PowerShell cmdlets are designed to deal with objects - structured information that is more than just a string of characters appearing on the screen. Command output always carries along extra information that you can use if you need it. We will discuss this topic in depth in this document.
If you have used text-processing tools to process command-line data in the past, you will find that they behave differently if you try to use them in Windows PowerShell. In most cases, you do not need text-processing tools to extract specific information. You can access portions of the data directly by using standard Windows PowerShell object manipulation commands.

This was taken from the documentation for Microsoft's PowerShell. All I can say is: FINALLY! Tools like grep have their place, but man, working with objects is so much nicer. I just started to look into this, but I'm liking it thus far. I've been waiting forever for a command line environment that dealt with objects instead of dumb old text.

Compile Time Reflection

I want compile time reflection in Java. They came close with giving me this:

Class someClass=MyObject.class

But, I wish it went further. If you're going to make me go through the pain of verifying everything at compile-time, then make my life easier for example:

try {
    Method method=MyObject.class.getDeclaredMethod("doSomethingCool", AnotherObject.class, String.class);
} catch(NoSuchMethodException problem) {
   //handle reflection exception that could have been caught at compile-time
} catch(SecurityException problem) {
   //handle reflection exception that could have been caught at compile-time
}

Right now, if I mis-typed "doSomethingCool" then it wouldn't get caught until run-time.Now, we don't want to make the baby Gosling cry, do we? How about this:

Method method=MyObject.class.doSomethingCool(AnotherObject,String);

For one, it's more succint and no need for any try/catch blocks because the compiler did all of the work. Another nice side effect is that you can check regular visibility constraints (if I call the above in MyObject and doSomethingCool is private, then all is good. Otherwise, don't allow it if outside of MyObject). Now, I don't have to set the setAccessible() method on Method and no security check. Now, of course, you can also use this for fields as well. In fact, it's simpler.

Now, I ask since they gave us ".class", why didn't they finish the job? Java reflection has always seemed half way there to me.

Just don't get me started on JavaBeans (where are the collections?).

Beauty. Remember that word.

Cool story about Lisp from Conscientious Software by Richard Gabriel:

In 1958, John McCarthy was thinking about a symbolic differentiation program in a programming language that was later to become Lisp. He was concerned about the “erasure problem”: no-longer-needed list structure needs to be recycled for future use. In subsequent languages, such problems were handled either by the structure of the program being restricted to trees (stack allocation of data and its trivially automatic deallocation through stack popping) or by explicit allocation and deallocation (malloc/free). His comment on erasure / explicit deallocation:

The recursive definition of differentiation made no provision
for erasure of abandoned list structure. No solution
was apparent at the time, but the idea of complicating
the elegant definition of differentiation with explicit
erasure was unattractive.-John McCarthy

It’s worth a pause to notice the style of research described. McCarthy and his colleagues were trying to design a programming language. Part of their methodology was to write the program they thought should be able to do the job and not the program that a compiler or execution system would require to make the program run well. In fact, the beauty of the program was foremost in their minds, not correctness down to the last detail. Beauty. Remember that word.

Eventually the first Lisp implementers decided to ignore the bug—the fault of not explicitly erasing abandoned list cells, causing the error of unreachable cells accumulating in memory, leading to a failure to locate a free cell when one is expected—until the failure occurred and to repair it then. This avoided the problem of entangling a common set of functionality (keeping available all the memory that should be) with a pure and clear program (symbolic differentiation). The failure the fault eventually caused was repaired, along with a lot of other similar errors in a process named at the time and still called garbage collection.

What are you waiting for read the whole thing. It's awesome and will make you think about how we can write better software. The garbage collection story put a smile on my face. "Beauty. Remember that word." I couldn't have said it better. We should always strive for beauty in our designs.

I Am Object

One thing that many Java developers that I work with think is weird is that I speak in first-person for my objects. For example:

"I should calculate the total when given a new line item"
"...that is not my responsibility..."

I act like I am the object. It's so natural to me that I don't even think about it. Now, this is very common when designing with other Smalltalkers as well. Are we the only ones that do this? And if so why? Is it because we are behavior-ists (ala Wirfs-Brock) and not data-ists? I don't know, but I think it's funny and it's what makes being a Smalltalker a joy.

Fate Is Weird

I said good-bye to Smalltalk earlier this year for what I thought was the last time. Now, by good-bye, I mean no longer working full-time in it. Did you really think that I could ever *NOT DO* Smalltalk? Anyway, I had relegated myself to Java-land with possible probation to Javascriptville or Rubypolis.

Well, I am pleased to announce that I will be returning (once again) to the land of messages and freedom. I can't wait to start. I will be working with some scary smart folks and doing outrageously cool feats of programming acrobatics. And it can only be done in Smalltalk. How lovely.

The railroad was awesome in retrospect and I had a blast. It was short-lived and I wish I could have stayed longer because I was just getting some steam on my project. Oh well, this new opportunity was just too good to pass up. The railroad has some cool aspects that I never thought about and the shipping industry is an interesting domain.

ROCK! Pass the messages and hold the data. I'm back to writing elegant code unhampered by a stuffy old compiler!

Why Lisp Has The Parentheses

I finally figured it out. It's so that you keep things small. When you have too many paranthesises, you're doing too much in your function. Small is elegant. And that is why Lisp makes you a better programmer in my mind. Of course, figuring out the Y combinator (recursive functions without names) from "The Little Schemer", macros (programs writing programs) from "Advanced Lisp", and all of "Structure and Interpretation of Computer Programs" help you make you great as well.

Null: The Runtime Error Generator

I never for the life of me want to hear another argument about how static typing catches errors at compile. I really don't. It drives me crazy! When you have to cast arguments to get them to the right thing in generic situations, it's frustrating. But, that's not the biggest sin. After writing the following line for the uptenth time:

if (something != null) {
    something.doWhatYouWereBornToDo()
}

You know what I mean. It's inevitable in legacy java applications. Now, I generally only do null checks on my inputs and avoid null conditions at all cost. But, the other day it got me thinking:

Null gets around all static type checking at compile time.

It's not a real type. It can be ANYTHING. At compile time, it slips under the radar because it only exists at runtime. So, what is my typing system doing for me? I find NullPointerExceptions tend do great damage on lazy (bad, whatever you want to call it) code. And let's face it, we've all had those days where we weren't exactly on the ball. NullPointerExceptions are sitting there to wake us up.

I really don't mind static typing. But, let's not kid ourselves. Allowing nulls throws out the safety of the compiler catching our dumb mistakes because most of mine are of the null variety (the dumb ones that is).

Of course, we could just reference everything by their interface and do the Null Object pattern and be smart about messages to ignore and which ones to worry about. But, it's a lot of typing without much gain.

Now, you might be saying to me, "But, Blaine, you imbecile! Don't you have nulls in Smalltalk, Ruby, and Lisp?" Yes, we do and it's called nil. But, we don't pretend to catch all of our dumb mistakes up front. And our nil is an ordinary object which we can add messages to. Nil, our null, is a little bit more powerful. Does it still sting when we make a programming mistake? You bet it does.

Enough on that, just don't get me started on primitive arrays in java. They are even sneakier and there's a plethora of stuff that the compiler doesn't catch.

Till next rant, keep your objects small and your messages plenty. AMEN!

Worst Web Site Ever?

Could this be the worst website? Probably not, but I'm sure it could be in the running...This is the site of one of the independents running for governor of Nebraska. Embarrassing. Not only is it annoying to read, it says absolutely nothing about the "issues" except ones that everyone can agree on. It even comes complete with an inappropriate cartoon. I expect republicans and democrats not to address issues, but I expect more from independents. Needless to say, he didn't get my vote. But, it's funny to look at his site. It's truly bad.

Happy Belated Halloween

We carved pumpkins this halloween. My wife did the scariest spider you have ever seen. Check it out!

How cool is that? So, you might guess what I might have done. I was thinking carving either Alice Cooper or this:

And of course, my wife, Michelle had to quickly take a snapshot of me in all of my techy glory.

Now, I must ask the question, am I knight now or what? I even used Squeak to edit the pictures.

By the way, I used Melissa Winger's "Powered By Smalltalk" logo. Thanks! It was a blast to carve!