Presentations

I finally broke down and started a page with my presentations. Check it out here. I included the talk I gave tonight at the Java User's Group. There's not much up there, but I will be adding more soon. Lastly, I would like to thank everyone for coming out and supporting me. It meant a lot to me when people told me that they read my blog and enjoyed it. Omaha rocks. Thanks for the support. I love you all!

Hugs

I think some folks in the Ruby community need a hug. If you find one, give them one and tell them it'll be OK. Not everyone can have a job doing Rails.

Reflection on Everything

Smalltalk allows you to reflect on everything. You can not reflect on objects to find their instance variables and methods. But, you can also reflect on code running and on the stack. It's powerful stuff. Why would you need this extra power? You might be a lazy developer. You might constantly remind yourself, "I work in a dynamic language and it should work for me!" Let's go digging shall we?

One thing you have to be careful in dynamic languages are message not understood or method missing errors. One easy mistake to make is to do the following:

[someObject doSomething] 
 on: MessageNotUnderstood 
 do: [:ex | 
  "log something"
  ^self]

What's wrong with the above code? Well, are you trying to catch if doSomething is not understood by someObject? If so, the call can still succeed and there could be a nasty bug further down in the code. The handler will be giving misinformation on the true problem. Frustrating to say the least. It's better to do something like this:

[someObject doSomething]
 on: MessageNotUnderstood
 do: [:ex |
  (ex message selector == #doSomething and: [ex receiver == someObject])
   ifTrue: ["log"
     ^self]
   ifFalse: [ex pass]]

Yuck. But, it does check the receiver and selector to make sure we captured the right exception. Lots of typing for something simple. Granted you shouldn't be doing a lot of guarding against MessageNotUnderstoods (polymorphism anyone?). But, sometimes it is necessary. Besides, we wouldn't have this fun little blog post would we. Basically, the above method checks for the right selector and receiver that we expected to have a MessageNotUnderstood and if it did we do our logging code. If not, it's something we didn't account for and is a bug, thus we "pass" the exception to the next handler. But, how can we prevent ourselves from all of this typing?

Squeak has this method implemented:

BlockConext>>onDNU: selector do: handleBlock
 "Catch MessageNotUnderstood exceptions but only those of the given selector (DNU stands for doesNotUnderstand:)"

 ^ self on: MessageNotUnderstood do: [:exception |
  exception message selector = selector
   ifTrue: [handleBlock valueWithPossibleArgs: {exception}]
   ifFalse: [exception pass]
   ]

It does not check the receiver, but that's OK. It turns our code into this:

[someObject doSomething] onDNU: #doSomething do: ["log something" ^self]

Nice. It's much more succinct, but I don't like the duplication of "doSomething". What are we to do? I came up with this method:

BlockConext>>onImmediateNotUnderstoodDo: anExceptionBlock 
 ^ self
  on: MessageNotUnderstood
  do: [:problem | 
   | myContext problemContext | 
   myContext := thisContext home.
   problemContext := problem signalerContext sender sender sender.
   (problemContext == myContext
     and: [self method messages includes: problem message selector])
    ifTrue: [anExceptionBlock
      valueWithPossibleArgs: (Array with: problem)]
    ifFalse: [problem pass]]

Here's what it makes our code look like now:

[anObject doSomething] onImmediateNotUnderstoodDo: ["log something" ^self]

It looks like what we started with, but this version is safe. It will pass the MessageNotUnderstood exception if the send did not happen directly from the block we defined.

What is the method above doing? The method I wrote reflects on the stack and the compiled code. I use the stack to find the receiver that should be in the block. The compiled code is needed to find all of the selectors that are called directly from the block. Pretty cool, huh?

Smalltalk is one of the few languages where you can reflect on everything on the stack. Stack frames are objects too. It makes doing difficult things possible.

Favorites of 2007

1. No World For Tomorrow - Coheed and Cambria
More hooks and punches than a lightweight boxing match make this my favorite of the year. I simply can not get enough of this band. The groove, vocals, harmonies, and everything is perfection. Roll down the windows and sing loudly.

2. Act II - The Dear Hunter
I loved the previous disc and this one continues down that path. Clever lyrics with instrumentation that puts me in an 1800's brothel. Indie rock with unique instrumentation. This band has its own identity. I can't wait to hear more.

3. From Beale St. To Oblivion - Clutch
One of my favorite rock bands. The go-go influence takes a bit of backseat in this one, but they still rock and roll better than anyone. Their groove is just unbeatable. These guys should be in the upper ranks with rock's other elite. Not a disappointment yet with their enjoyable old school rock with funk, blues, and hardcore blended in the right doses. This is unpretentious rock that is catchy, fun, and smart.

4. Strum Sum Up - Dug Pinnick
I loved the last King's X and have always enjoyed Doug's output. He is one of my favorite vocalists of all time. But, nothing set me up for this. Wow. Doug takes all of his influences and gives us a ride through them all without losing sight of hooks or groove. Doug proves he is a jack of all trades and gives me an album that makes me want to hit repeat.

5. Killing Peace - Onslaught
OK, I wasn't a big fan of their 80's output until Steve Grimmitt sang for them. I wasn't expecting much out of this at all, but thought what the hell. It was getting good reviews and who can't live without another thrash record right? This blew me away. In a day when retro-thrash bands are a dime a dozen, it takes the old guys to show them how to do it with PASSION. Sure, the lyrics are cheesy, but when sung with such conviction. It reminds me of the good ole days.

6. Rhythms From a Cosmic Sky - Earthless
I got this late and this is simply great space rock. It ebbs and flows yet never bores. 70's rock that takes you on a journey that you never want to end. It's only 3 songs clocking in other 45 minutes. Turn it up.

7. Ocean's Thirteen Soundtrack - David Holmes
I love all of the Ocean's movies. Sure, they've gone down in quality ever since the first one, but the one constant has been the great soundtracks for each of them. I think this is the best of the soundtracks though. It adds something special to the ambience of the movie. Creative sampling make this just a jaw dropping electronic music experience. None of the spices overbear the others.

8. Tervaskanto - Korpiklaani
I've never been big into folk metal because most of it has been depressing. Not this band. Accordians and violins mixed with heavy metal guitars makes for a rollicking good time. The songs are catchy and fun to drink a pint to. Upbeat and always puts me in a good mood. One of my favorite finds for this year.

9. "V" is for Vagina - Puscifer
Tool's singer tries to pull a Mike Patton and do his own Peeping Tom. Silly, catchy as all hell, and different. I like it. It's not exactly like Peeping Tom, but the mood is similiar. Pop music with electronic flourishes and Maynard's distinctive croon over it. A lot of people hated this, but I think it was because they were expecting Tool. Tool this is not. It's dark pop with lyrics that make you chuckle. It's refreshing to finally hear a side project from a member of a band that sounds nothing like their main band. Kudos for taking a risk and doing something different.

10. Hangman's Hymn - Sigh
Eccentric. I've loved Sigh for a long time and they never seem to suprise me even though I know what I'm getting into with each album. Everything but the kitchen sink instrumentation, but this time the songs flow. It's not as much of a bumpy ride as before and that's a good thing.

11. Mythmaker - Skinny Puppy
This is the second album since their return and they are a different beast now. The songs are now melodic and catchy. It's dark pop electronic music. It's nothing like the bleakness of their previous output and that's OK. I love this version of the Pup too. They did incorporate a little bit of their darkness from "Last Rights" and it made me smile. Still the best industrial band in the world.

12. Cortical Tectonics - Canvas Solaris
Instrumental progressive metal that has to be heard to be believed. They keep things moving along and never have a boring moment. A musical maze that excites and breathes. They even manage to keep things from sounding too much a like. One fun ride.

13. In These Veins - Hearse
Surprise of the year for me right here. Melodic death metal with Johan Liiva (former singer of Arch Enemy). The songs are all memorable with a few twists and turns to keep things fresh. Melodic death metal has been getting stale for a while. Arsis was the last to breath new life into it. Hearse is the next. No other melodic death metal release came close to this.

14. Fear of a Blank Planet - Porcupine Tree
Another album that I'm shocked more people didn't love. I'll admit I've always like Tree's previous output, but this one just clicked with me. Maybe it was time, because I have revisted their previous output and now love it. The laidback prog with a little kick of metal and melodic vocals just get me.

15. The Mix-Up - Beastie Boys
I'm a sucker for lounge and electronic music. I'll admit that I hate the Beastie Boys' rap output (not because I hate rap, I hate the whiny rap vocals). I picked this up because I've always loved the music, but thought the nasally rapping killed otherwise cool songs. So, I figured I would get some cool instrumental dance music with heavy beats. What I got was a through back to the 60's. This is lounge music with light electronic flourishes. This is the stuff to sip martinis to and relax.

16. Open Fire - Alabama Thunderpussy
Kyle Thomas is one of my favorite vocalists and I was so pumped when I found out that he would be in front of Thunderpussy. This is turn the amps to 11 and forget the neighbors. Unpretentious and loud rock with heart and soul. This is the way metal used to be in the 70's and early 80's. Thunderpussy reminds us how good those times were. A time where a good song was the most important thing.

17. City of Echoes - Pelican
This was a love or hate album apparently. Instrumental rock that took me on a great journey. I need to check this band's previous output. This was the year for great instrumental albums. I would love to hear this album played live. If you're bored with paint by the numbers rock, then you need this.

18. The Machinations of Dementia - Blotted Science
Instrumental progressive death metal that knows not to bludgeon you all of the time. Heavy one moment, somber the next, and then all out wackiness. But, again, never going into wanking territory and keeping the melody in mind at all times.

19. Foley Room - Amon Tobin
Dark electronic music with loads of samples. Amon Tobin is one of my favorite electronic artists with inventive sampling that sets a tone. This one is a bit more ambient and darker than previous releases, but just as good. No one has been able to touch Amon yet.

20. Hardworlder - Slough Feg
Do you love 70's/early 80's metal? You know before hair spray and image took over the music? Back when bands had their own sound and were'nt cut from the same cloth. Slough Feg takes us back to that time. They have their own sound that calls back to that era, but you will be hard pressed to say they are a retro-band. A great set of songs that I can't stop listening to!

Omaha Dynamic Language User's Group

Fingers tired from typing in all of those Emacs commands from trying out new Ruby and Lisp code from the books you got for Christmas? Why don't you take a small break and join your fellow comrades. Trust me your mind and fingers will thank you. This month we have a very special guest from Microsoft, Bob McCoy. He'll be demonstrating all of the cool things that you can do with PowerShell. It just might make Mac users envious. Here's the full abstract:

PowerShell is Microsoft’s next generation scripting language and environment. It will be the native shell environment for Windows Server 2008 and is at the heart of every administration task in Exchange 2007. It is extremely powerful and at the same time very simple to use. It is aimed at system administrators and scripters.

This will be about 40% slides and about 60% demonstration. I try to keep it highly interactive so it ends up answering a lot of questions along the way.

But, that's not all! You not only get Bob McCoy, but we're also bringing the brightest fellows in Omaha. But, wait that's not all! We'll throw in sponsorship from TekSystems which means free food and more pop than you can drink. All for the incredible low price of FREE! Why delay? Come to the meeting!

On a side note, a little bird told me that TekSystems has some Ruby openings right now! Get in contact with Heather Blockovich or better yet come to the meeting to find out more.

Topic	PowerShell
Speaker	Bob McCoy
Time	January 8, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Omaha Dynamic Language User's Group

Still eating leftovers from Thanksgiving? Had your fill of Christmas shopping? Sounds like you need a break. Why not head on down to the local Omaha Dynamic Language User's Group and meeting the best and brightest that Omaha has to offer? This month we are honored to have world famous "No Fluff" wowie zowie speaker, Matt Secoske presenting. He will be showing us the ins and outs of a framework called "Processing". It's a graphical canvas with a programming interface. Simple to use and the results are jaw dropping. Spice up your Christmas cards this year.

There will be pizza and drinks provided. Free food, drink, great conversation, an exciting presentation, and an amazing new technique to make cards. What do you have to lose? Christmas shopping can wait. It's time to have some fun.

Topic	Processing: Cool Graphics Now
Speaker	Matt Secoske
Time	December 4, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Some Metrics

Language	Avg Methods/Class	Max Methods/Class	Avg Params/Method	Max Params/Method	Avg Fields/Class	Max Fields/Class
Squeak	9.39	780	0.64	16	1.02	100
Ruby	12.69	683	0.42	7	0.76	31
Java	8.67	181	0.91	12	2.42	343

I ran the metrics, that I talked about in my last post, in three environments and the results are above. Nothing really shocking, but the maxes did surprise me. I was mainly interested in the averages and the maxes were there just to see how huge the big boys really are.

I wonder what developers would think of a language that restricted the number of things that they could define. What if by looking at the numbers of above, I designed a language that didn't allow more than 256 methods/class, 8 parameters/method, and 16 fields/class. It would force the developer to write smaller entities, but would it annoy more than help?

Where I'm going with this is simply, what if the language enforced certain hard restrictions instead of allowing any incredibly large number of possibilties? If elements were kept to a certain size, would it make programming in the system more pleasurable since it would be difficult to create a god object? Objects would not get out of hand before refactoring thus making maintenance easier.

My gut instinct is that constraints would annoy and ugly code would still live. Developers would just figure out ways around them. I would love to think that by adding constraints, we could get better code. But, no matter what you measure quality by, there will be developers that will figure out how to get around it. Pessimistic, I know. But, it's simply human nature.

Still, I wouldn't mind if the language did have some limits, so that individual items stayed small. If the constraints were not dogmatic, it would make the need to get around them less attractive. Of course, with smaller things comes naming them and that would still be a problem. But, that's a problem with mammoth sized objects as well. I'll keep thinking on this. There's got to be a way to have flexibility to dream the impossible and yet gently nudge us into more maintainable programs at the same time. The problem with balls of glue is that slowly become that way. It would be nice to not allow them to become Godzilla.

Limitations Of The JVM

• The maximum number of local variables in a method is limited to 65,535.


• The maximum number of fields in a class or interface is limited to 65,535.


• The maximum number of methods in a class or interface is limited to 65,535.


• The maximum number of direct superinterfaces of a class or interface is limited to 65,535.


• The maximum number of method parameters is limited to 255.

What's the point of the list above? Sure, those numbers are reduced by various factors (like this reduces the number of method parameters by 1). But, that is not the point, my friends. The point is all of the above numbers are HUGE! I was reading my trusty copy of "The Java Virtual Machine Specification Second Edition" when I got to Section 4.10 and read some of the above bullet points. In Java, I live in the land of the plenty.

I know it's all two byte boundaries and all, but what if they left some of these at one byte or 4 bits? I can hear it now: "But, we have all the space in the world! Why constrain ourselves in such a way!" True. But, when was the last time you looked at a method with 80 parameters and thought: "DAMN! Now, that's some beautiful code." Exactly. You never have and you never will. The point is not to constrain on a byte boundary, but on a good coding boundary.

Arbitrary numbers are awful to use as metrics (like you must have less than 3 arguments to each method and so on). Metrics are useful in relation to something else. You pick what seems reasonable to you (which might not be reasonable for someone else). There is a boundary where any reasonable programmer starts to hurl at bad code though. Metrics are set below that for each team. I hope I never see the interface with 16,000 superinterfaces. I really do. The cool thing is we have a huge library in Java to look at to see what is reasonable. We have tons of open source projects to feed our reason as well. What if...What if we picked what was reasonable from these code bases by using averages and everything else in our numerical power? Then, we doubled it to make it unreasonable. I wonder what the numbers would look like?

My next experiment is to run some code reflecting over both Java, Ruby, and Smalltalk code. I wonder what the averages for each would be (number of method parameters, number of methods per class, number of fields, and number of local variables). I'm curious. I have a guess at what the numbers will be. But, the raw numbers could be telling. I would like to see them for all three of the above languages. It should be interesting. I know there's probably someone out there that has done the same thing, but I want to run the tests on my own. For now, I will do it with the base libraries of all three. My guess is that they will be roughly around the same for each of the metrics that are comparable in each of the languages.

What's the point? By reading and then thinking of the worst, it got me thinking. Our languages constrain us in ways that they shouldn't, but don't in what would make our code better. Would it be such a bad thing having to split a method up because you ran over a rather large (let's say 256) number of local variables? I want to find the number where it seems unreasonable and grotesque and make that my limit. I know 65,535 is absurd for the number of local variables, but so is 256. What about 16? My answer is "HELL YES IT IS!", but there are those that would argue that sometime you need that many. 16 is not hideous, but is still in poor taste.

I'm off to see the wizard. I'll let you know what he says.

A Happy Diversion

I was smitten with my quick snippet of code for my Monticello window in a flap. As with all little things in Squeak, it's hard to just stop. You're always thinking of little things or tools that would be nice. Everything in Squeak is easily explorable and changeable. It's too much fun to search and see the results of your labor instantly. Addictions are not pretty.

Another idea came to me. The tab for my Monticello flap was boringly called "Monticello". What a waste of real estate. My second problem was that I'm always getting confused at which project I'm in. I normally use different background colors to make it easy. But, I still get confused. I was blessed with a small brain. I curse it everyday. What is a poor little Squeaker to do? I thought I could put the name of the current project on the Monticello tab instead of the one it has. I wondered how hard would that be? And off I went...

How can I do that? I could change the tab name when the project changes. Eureka! That's what I will do. I remembered I wrote a little utility to change background images and I had to know when the current project changed. I started my hunt there and event handlers are available via the morphic world to know when a project is entered or exited. We only care about when a world is left. Why? The event handlers has to be registered on the world itself and we don't want to have to keep track of every project and world. It's easier to put a handler on the current project and know when it is left.

Let's start with this method for setting the world we're currently in:

world: aMorph 
 world == aMorph ifTrue: [^ self].
 world ifNotNil: [world removeActionsWithReceiver: self].
 world := aMorph.
 world ifNotNil: 
   [self changeTextOnTab.
   world 
    when: #aboutToLeaveWorld
    send: #leavingWorld
    to: self]

Basically, this method removes all events from the old world since we will not care about it any longer. Then, we change the text on our tab and add our event handler. Next, how do we change the text on the tab? In the menu for a tab, is an item to change the name of the tab. Using the handy morphic handles, I inspect the menu item itself and find the method it will call when it is invoked. Here's the code I came up with:

changeTextOnTab
 self monticelloFlapTab ifNotNilDo: [:tab | tab changeTabText: Project current name]

The simple method changeTabText: does all of the magic. We just get the name of the current project. I haven't showed you how to get the tab itself. I look through the methods on the class side of Flaps to reveal its magic:

monticelloFlapTab

 ^Flaps globalFlapTab: 'Monticello'

The good news is that it will always find the flap this way no matter the name. The only thing left is to what to do during the handling of leaving the current world. The dilemma now is how do we know the next world? Some more digging and we can be ask ed to be called later. Perfect. Here's the code for the handler:

leavingWorld
 WorldState addDeferredUIMessage: [self world: Project current world]

And that's it! The same method can be called to seed our initial world as well. Now, a quick glimpse to the bottom of the screen gives my project name. Easy. Now, I can get back to updating my Seaside presentation.

Why I Love Squeak

addMonticelloFlap
 | newTab monticelloBrowser |
 newTab := Flaps newFlapTitled: 'Monticello' onEdge: #bottom.
 self currentWorld addMorphFront: newTab.
 newTab adaptToWorld: self currentWorld.
 Flaps addGlobalFlap: newTab.
 newTab showFlap.
 monticelloBrowser := MCWorkingCopyBrowser new.
 (monticelloBrowser window)
  openInWorld: newTab referent extent: monticelloBrowser defaultExtent;
  topLeft: newTab referent topLeft + (10 @ 10).
 newTab referent height: monticelloBrowser window height + 20.
 newTab hideFlap

The above code snippet adds a new global flap to the Squeak environment. Inside the flap is the Monticello browser. I've been doing this in my Squeak images for a long time, but doing the above by hand for each image. I went into the system and figured out what each of the menu items did to create the above. This is simple in Squeak because everything in Morphic is inspectable. It allowed me to create the script you see.

The reason for having a Monticello browser in a global flap is so that you can always have it open in every project and easily accessible. I like to have a Squeak project for everything I do and like having one Monticello browser.

The above was not much effort and took little time to figure out. Love is.

Seaside Presentation

I updated my Seaside Presentation available on SqueakMap to Seaside version 2.8. Make sure you update your SqueakMap. The new version is 1.70. I plan on reworking it completely soon. As I upgraded the code, I was unhappy with what I saw. It needs to be refactored heavily. I want to add more code that shows off the cool new add-ons for Seaside as well. Enjoy!

Bug Finder

Two of my favorite tools to use in coding are: a code checker and a code beautifier. The first points to sloppy and rushed code. I find sloppy code to be a vital protein for bugs to grow. The second shows me a consistent view of the code. It's amazing how many bugs you can pick out by just running a code beautifier and glancing over the code. I'm always amazed what I find with a code beautifier. What's even more shocking to me is that a lot of developers hate them. Even if the formatting is less than to my liking, I still use it. Why? It catches so many moments of unclarity. It also points to code that should be broken up into smaller bits. If the code beautifier formats my code to be ugly, then I need to refactor. It's a rule of thumb that has served me well.

Of course, I usually run the code beautifier to get a lay of the land on new code and roll back when I'm done. Why? There's nothing more annoying than searching through tons of code changes to find out that the code was only reformatted. Now, if it's my code, I don't check it in until a code beautifier has been ran on it. I find studying my code after running it is just a good habit to get into before check-in. Reading code that's normalized makes it easier to spot patterns of inelegance.

I'll write more about the code checker, also known as Lint in some circles, in another post.

Omaha Dynamic Language Group

You wanted the best. You got the best. The hottest presenter in the land...Ben Heath! What could be better than a Kiss concert, a talk on PHP of course. This month Ben has offered to show us what we have been missing in PHP. The language itself is loved by web programmers all over. If you have ever been curious, now's the time to find what the fuss about PHP is all about.

ProKarma is sponsoring this presentation. They will be providing the food and drinks. So, what do you have to lose? You get to learn something new, hang with the smartest people in Omaha, and free food. My friends, it just doesn't get any better!

Topic	PHP: Practical Web Programming
Speaker	Ben Heath
Time	November 6, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Bloat

John C. Dvorak asks the following in his latest blog entry:

But I wonder if all open-source projects will eventually go the way of all software. Upgrade after upgrade adds more and more complexity, to the point where the software begins to get bogged down under its own weight. How many open-source projects have you seen in which the code gets leaner and meaner rather than fatter and fatter?

Good question. Software becoming more complicated and bigger is almost a universal truth. I don't see why open-source should be immune. Of course, the more features you add, the bigger your program will become. But, even software that is being maintained becomes an entangled network of goo. Brian Foote even wrote an anti-pattern about it called "Big Ball of Mud".

This is the problem that needs to be solved. I see a huge focus on creating tools that allow quick creation of code. But, I see few dealing with complexity of existing code and even dismissal of the ones that do exist. Refactoring tools are mandatory in the fight against creeping code. Tools that allow diagnosis of live running systems is a must. Code generation gets my code out the gate quicker, but without a gym, it becomes slow as molasses as the race continues down the path of new features.

I want to create systems that in their evolutionary cycle grow consistently with new features. The complexity should be in line with features. Right now, this becomes exponential and is proven by ever rising maintainance costs. Our current weapons are refactoring tools, code checkers (lint), metrics, debuggers, and let's not forget the most important: education. Actually, could that be the answer? Discipline and education just don't have the same kind of sexy ring to them, but tools can only take you so far. Still anything that can help our brains reel in the complexity is a welcome addition. Software is only going to get more complex as we go along. I think we spend so little time on reducing complexity in existing code because the feedback is not immediate. I want to get to the point where I can deliver the third version as fast I delivered the first.

It's a shame with all of the advances in our field that we have been unable to keep maintainance costs down. There are developers working on this problem. I've heard rumblings that tools are in the works. One possibly being a more macro level refactorer. I can't wait to use it. Until then, I'll keep my lint, refactorer, inspector, debugger, and metric runner close by my side. If anyone has any other tools that they like to use to keep complexity down, I would love to hear it. My brain can always use help.

I'll end with this all too true quote on Firefox in the same article as mentioned above:

Just look at Firefox, one of the poster children for open source. It loads more slowly than ever. It will be on some page within a tab, and that page will be refreshing ads or something in the background, and Firefox just hangs all its cycles there, slowing down the whole computer. Every couple of days the browser is hogging cycles, and I have to go to the Task Manager and kill it. Other people have this problem, too.

Go read the rest of the article. He makes some good points on mindless fans of technologies. Sadly, I think open-source is going to be the place where the tools to deal with complexity will be born. Until then, open-source will suffer the same as the rest of us with bloat.

"Considered Harmful" Considered Harmful

It's official. "Considered harmful" can be added to list of cliches to avoid. It needs to go into retirement along with factorial and prime examples.

Debuggers...again

Giles Bowkett recently asserted: Debugger support considered harmful. It seems this has been going around for years. See this old post of mine: Am I a Bad Programmer?. Nothing new. The assertion is that if you have tests, you don't need a debugger. Interesting. I'm heavy into testing my code. Anything I write even for fun has a test to go with it. And yet, I still use my debugger quite a bit.

Why? Well, it depends on what I'm doing. I use the debugger for exploratory programming, when sinking into the depths of someone else's code (especially if they didn't write tests), during code reviews, and when faced with a nasty bug. Even though I write my code in small pieces (small classes and small methods), I am not perfect. When everything is combined and put into production, strange things happen to my code. The code doesn't change; the environment does. A situation occurs that I didn't think of and thus it is not tested. This is the realm of the debugger especially if the bug is nasty and hard to find. Any piece of complex software has these hidden. We are human. Let's embrace that. A world without debuggers is a weird sci-fi perfect world with monsters lurking beneath the surface.

Debuggers are great for exploratory programming when you are just trying out a new framework and seeing how it works. I like to walk line by line. I did this when I was learning Seaside and it was better than any documentation. Besides, watching beautiful code unfold in your debugger is nothing short of reading a great book. And when you're dealing with some ugly code, a debugger has shown me things that my eyes deceived me on when just looking at the code. Why dissect the dead animal when I can see how its organs work while it is still alive?

An expressive debugger saves time as well. I remember when I came back to Smalltalk after doing Java for several years. I had forgotten that you never need to restart your programs. I wrote a simple Seaside application and only restarted the web server once. I coded live in the system and when I saw a problem (that my tests didn't catch) in the debugger, I could change it right there. It was amazing.

I guess all of this talk of no debuggers or that debuggers is a crutch for bad developers. It can enable the "get it running once" mentality instead of thinking of all the cases and your design. Like any tool it can be abused, but that doesn't mean we should get rid of all tools. Duck typing can be abused as well and I wouldn't trade it for the world.

StAX Tomorrow Night

I'll be giving a short talk at the Omaha Java User's Group tomorrow night. It will cover the StAX API that's new to Java 6. StAX is the streaming counter-part to SAX. I'll probably also touch on a little bit of API design too.

Omaha Dynamic Language Group

Erlang is the hottest new language in the land to learn. It's what on the tip of everyone's tongue. Why is it so hot? What makes it so special? I am proud to have Erlang guru Sam Tesla presenting to answer all our questions. He will be displaying why Erlang scales so well and it's many unique features. This will be one meeting that should not be missed!

And if that wasn't enough, we have none other than Tek Systems providing all of the pop and pizza that our bellies can take. Prepare to have your mind and stomach stuffed!

Come out and join us for the best user group in the land (In my opinion, of course).

Topic	A Gentle Introduction to Erlang
Speaker	Sam Tesla
Time	October 2, 7-9pm
Location	UNO's Peter Kiewit Institute (PKI) building 1110 South 67th Street Omaha, NE

Good Design

I love Alex Ruiz's post on named parameters in Java. Why? For one, it shows how he got around Java's lack of named parameters. He then goes on to explain why he made the design choices he made. Pros and cons are then listed for the approach. But, the part that I loved is that he sided on the side of the API user. It made his life as the API designer harder and cost him more code to write. The result was something that allowed for more readable code for the client. I love it! I tend to design with making the client's life easier instead of mine. This article is excellent for outlining the design choices and not being dogmatic. Everything is logical and well laid out. Another reason I loved the article is that the lack of a language feature inspired him to work harder to get the same result. A post that inspires us to push for better solutions no matter the constraints.

I'm embarrassed

I can't believe what gets passed off as humor these days. I'm embarrassed to be part of a community where one of the main evangelists of the community post such bile and garbage. It was meant to be funny. But, calling developers outside your community "morons" even in jest is not cool. It certainly doesn't breed communication and good will. And if you were interested in "making the world of software development a more enjoyable, productive place", then name calling is not the way to do it. I understand it was done in humor and I know you are writing off my serious reply as "dumb" because of your debate killing "if you didn't get the humor, then you're dumb" post. But, if you wanted to be funny, you went about it the wrong way. All you displayed was a level of immaturity that should be unacceptable in our community. It wasn't witty.

And to end I will add, yes, Ruby does need tools. It needs tools badly. I would love to have refactoring support (that works) and a good debugger. I can't imagine doing a project of any size without those tools. Not every one is a great developer and eventually you will step into some unsavory code. Tools are for helping with those unsavory pieces of code and even to gain understanding on a large system. This is where learning comes in. Instead of writing the developer off as a "moron", I use unsavory code and tools to teach how to do it better. So, who's really "making the world of software development a more enjoyable, productive place"?