I'm not a number, I'm Lifetime, baby!

I offically became the 65th Weight Watcher to become lifetime at the location that I attend meetings. I'm a lifer! It feels great. I'm still sticking with the program (I never want to be what I was formerly). It was a long hard road, one that I couldn't have done without the love and support of my wife. I would also to thank all of the leaders that I've had in the past (Dianne, you rock!).

Something to Ponder...

Rusty commented in response to AJavaGuy:

AJavaGuy says he isn't an idiot but thinks you need to ship a workbench for someone to deploy Smalltalk code. The thing that keeps developers away from Smalltalk is you have to be an object developer to perform well in the Smalltalk environment. Most Java developers are not object developers. And they write the code to prove it.

How true. I can't tell you how much java code that I have seen that is nothing but data structures and controllers. There's very little "object" code. It's not a jab at java either. Writing good OO code is a skill that saddly a lot of developers do not take the time to learn. I am shocked at how some folks will read every book on patterns, but have never cracked a book on basic OO modelling (no, I'm not kidding, you think this would not be the case). Anyway, it saddens me that writing good object code might be hindering Smalltalk's acceptance. I find Smalltalk enables object think much more easily. I think that a lot of java programmers would write better java code if they learned Smalltalk as their "language of the year". Learning Lisp certainly opened up my eyes and I think I write better code because of it as well. I think more developers should look beyond thei language of choice and learn others no matter what. I'm constantly learning new languages to try to find one better than Smalltalk for me. I haven't found it yet, but I found a lot of cool and interesting ideas that have changed the way I code for the better. Anyway, Rusty's comment got my mind working.

Eclipse vs. Cincom Smalltalk

Go here right now. It shows a comparison in sizes of Eclipse vs. Cincom Smalltalk. Funny thing is that he didn't even compare the startup times. Generally, I can open and close a Cincom image 6 times before Eclipse has come up once. Maybe I should should post the startup times for each. Now, that would be interesting...I think we would see the 9x or more slower. Anyway, 9x seems to be the going rate for Smalltalk to Java code size. Go here to see Seaside(A Smalltalk framework) vs. Java. And people wonder why I went back to Smalltalk. My fingers were tired of typing!

Version Control At The Method Level

So, I've been in cold arctic known as Filestar Statica and getting used to the local customs again. It's not that hard to get back into it. But, I digress. One thing I never noticed when I was there before was the level of version control. In most Smalltalk systems, the lowest level we version is the method. In other systems (this is not just statica, but also to the land of sciptor), the lowest level is the file. I think having version control at a lower level makes life a lot easier! For one there's less text to deal with (typical Smalltalk methods are less than 7 lines and I would say that even that number might be closer to 3). You see exactly the methods you changed and if someone wants to get fancy and reformat all of your code, you can easily see the changes. It also means we not susceptible to someone rearranging methods in a different order. And lastly, it's great when we have to merge. Merging is no FUN, but when the merge is at a lower level, there's less mergining inside of a method. It seems to me that version control at the file level can be quite messy if you are not careful. It would be great to see method level version control in other systems. It seems strange only to be in Smalltalk. But, count it as another item that makes me more productive and love Smalltalk more.

Great quote

Taken from CLIPS User Document:

"If you want to get anywhere in life, don't break the rules — make the rules!"

So, are you a rule maker or breaker?

The Nameless Imperial Troops of Statica Fire

In a galaxy far, far away..."AJavaGuy" writes:

I ended up here from a Java blog pointing here. Your attempts at
reading the minds of Java developers are not very successful. I want
you all to pay attention and not take this badly, I'm going to try to
help you understand this.

OK, here's the deal. I did java for 8 years. For three of those years, I was the lead architect on the projects I worked on. I came back to Smalltalk because I am more productive. Period. I was successful in java, but I can write more functionality in less time,bugs,programmers,hardware, and software in Smalltalk and I want to delight my paying customers. Smalltalk is freedom to do this. I know what I'm talking about when I speak of java. I'm not speaking from a point of view of ignorance. I have spent my share of time on your side of the fence. Have you ever done a project in Smalltalk? My original post was meant to be a rallying call to fellow Smalltalk developers to think of how we could spread the love of the language we adore. Your reply was meant to spread hate and knock us down. But, I'm always up for a good debate. So, I'll preface my comment the same: "pay attention and do nt take this badly" and I will be proud enough of my opinions not to stand cowardly behind some anonymous signature.

The main reason most programmers dislike Smalltalk is *because of*
the dynamic nature of the environment. If you hack away at your
environment all the time, not only do you not get any work done (see
"Macdinking" in the Jargon File), you end up shipping the workbench to
the customer because your app won't run otherwise. Java IDEs produce
code that can be run with a standard JVM.

Huh? Most java developers that I show Smalltalk to are astonished by the power we have over the environment. They are actually intrigued by the dynamicism of it all. Their complaints usally come from syntax and how foreign the environment seems (no files). All I ever ask from someone is to give me a chance to show them the power. If they decide not to use it, then I'm alright. I know I will not convert everyone. If java makes you more productive, then it's all within your right to use it. But, to say that my apps will not run because I'm shipping my workbench is ludicrous. In fact, I usually start with a clean image and then import my code before I deploy anything. In fact, I strip away all cruft I don't use in my code. Smalltalk allows me to work with a living system and that property allows me to write code faster. I spend very little time tinkering in the environment. I spend most of my time writing code to deploy to my clients. My code always runs and I'm continually delighting my customers with functionality beyond their wildest dreams. How can I do that? because I have time left over to give extra bells and whistles that make my customer's life easier or just plain more features.

The few companies which ignore past experience and try Smalltalk,
will try and only sometimes survive one experience with Smalltalkers
producing code that can't be shipped to the clients, before deciding to
use *any* other language next time.

The most successful projects that I have ever been on were all Smalltalk. Smalltalkers are the most productive programmers I have ever met. Name one company unsuccessful with Smalltalk and I'll bet it was never the environment or the language.

Dynamic languages are also very easy to make mistakes in, if you're
not incredibly careful with exhaustive test suites. Compiled languages
are simply better for large-scale software engineering.

So, static typing allows you to make less mistakes? Wrong. We run our code a lot more often and without tests, I rarely run into a problem with types in Smalltalk. When will people learn that typing problems are small when compared to logical. So, you're paying a huge bill with very little safety in return. I know I will not convince you of this because I think it's a "religious" argument. We think of software construction differently. I think of it from a craftsman/artist point of view and you look at it from an engineering perspective. Our past experiences have shaped our beliefs. I've been very productive in dynamic languages and you in static ones. It seems you have had some really bad experiences with dynamic langauges. I am truly sorry. But, I've have had bad experiences in static languages. Let'e leave it at that. I will however still try to convert programmers who have open ears and minds. I am always on the lookout for something better than Smalltalk. I'm still looking and I hope to find it. I just know that java/C++/C#/etc ain't it for me.

There's also a matter of taste--in the opinion of most programmers,
Smalltalk is one of the most hideously ugly languages ever made. I know
you don't agree, but you're a minority opinion. You have to consider
the very real possibility that you're not normal.

If you mean most by C++/Java programmers, then yeah, they probably would think Smalltalk syntax is weird, but I wouldn't say ugly. I consider Smalltalk to have one of the most elegant and readable syntaxes available. If you ask most non-programmers, they can easily read Smalltalk and understand the code. I never had a client that would stand to look at java/C++.

It's not a matter of ignorance. Basically every professional
programmer knows Smalltalk, from reading Design Patterns if nothing
else, and quite rationally chooses not to use it. Making a prettier GUI
isn't going to change that. We're not idiots, and we're not shallow,
and the pompous attitude that we are makes us treat you with contempt.
We chose the best tool for the job, and it wasn't Smalltalk.

Cool...You choose your tool and I'll choose mine. We're both craftsman. We choose different tools to get our jobs done. I think it takes less materials and thought to get my job done with my tools. I have proof just click here for a comparison of the same functionality in Smalltalk and java. But, I don't believe I'll convince you, so you can continue to use your tools if you like. But, I believe I can beat you to market everytime with more functionality (and working).

For aimless hacking on your desktop and producing prototypes,
Smalltalk's fine. It's never going to be common in engineering, though.

Fine, let Smalltalk not be in corporations and common engineering. Let it flourish in companies that want the competitive advantage and don't want to be average. I never wanted to be common anyway. I WANT TO BE EXCEPTIONALLY SUCCESSFUL!. So, I'm sorry if my enthusiasm comes off as being smug, but I believe and stand behind what I say. In fact, I'm proud to say it and not hide behind some anonymous moniker. Have a good day.

What's Wrong With Smalltalk?

Well, I've been spending a lot of time with java developers and have been having a mighty fine time. It's been interesting being back in the saddle so to speak. I am more than ever assured that Smalltalk not only rocks, it rocks hard. So, why isn't it considered to be cool? Well, the Java developers at my company have this crazy notion that's it old technology. They even think the tools are not up to par to java's! Eclipse is a great IDE for java, but it is still pale in comparison to a Smalltalk environment. The reason it is because debugging is still on a dead system so to speak in Eclipse. I can't really change a whole lot while debugging. I can make simple changes, but adding methods and instance variables are big NO-NO's. So, it means I'm shutting down my application, writing some code, compile, rinse, repeat. The compile cycle is what is killing me. It takes awhile to bring up the test server (to test my code). And for some changes, I have to do a pretty lengthy compile. Now, if you set up Eclipse right, compile times are nothing (which I see people get wrong quite a bit). But, it's the start up time of the application server that's really killing me. In Smalltalk, I can keep the application server running and never restart it unless I did something terribly wrong. My productivity is still way high in Smalltalk. The java developers think Ruby is cool because its newer technlogy, but while I love Ruby, the environment is still lacking for it as well. I will be glad when FreeRide is completed (looks promising).

So, why do the java developers think their tools are ahead of ours? Eclipse looks mighty pretty and it has a lot of great features. But, pound for pound, we have the same features and more. We have a live world to play in. Eclipse is nothing more than a painting of the world. We are the real thing! I can change the object inspector in the IDE and no shut down! Any change to Eclipse and I have to shutdown and restart. So, why are java tools considered better? The only thing I can think of is the looks. At work, we use VisualAge and well, VisualAge looks old. I'm trying my best to tell them not to judge a book by its cover and there's a reason a lot of people think it's cool. But, they have this notion that us Smalltalkers are just old technology guys hanging onto our past for dear life. It saddens me that they see me this way. I love new technology and I'm constantly studying new languages. But, so far, the one I am most productive is Smalltalk. Period. End Of Story. Ruby and Lisp are great too, but I can still code faster in ST. I would still pick any dynamic language over java/C# any day of the week.

So, here's the rallying call. How do we make Smalltalk not seem old. I think despite it's age, it's still far ahead of the game in a lot of areas and where we lack, we can quickly close the gap. Let's get rid of this stigma that Smalltalk is old technology. We are the future NOW!

Omaha Smalltalk User's Group

We're back! And we've changed locations. The meetings had stopped for July and August because of issues with the library (they weren't being nice and well, I don't like mean people). Anyway, we found a new place and it's called Panera.

Here's where we'll be meeting:
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164
September 14, 7pm-9pm.

If you're in the area, please feel free to stop by. We're going to do things a little bit differently this time around. There will be no speakers, but bring your favorite utilities and bits of code. I want the sessions to be more interactive and we'll see how it goes. Remember to look for the skinny long haired dude. He doesn't bite and he loves to talk about Smalltalk!

Hope to see everyone there!

WOW

Check this out here. Simple amazing. Cool story!

Don't Be An Energy Sucker

Go read this article on Avoiding Co-Workers That Could Hold You Back. And remember: Are you an energy taker or giver? BE POSITIVE AND FUNK ON! Don't be a Sir Nose!

Smalltalk quibbles

Sam Griffith on his blog answers another developer's quibbles about Smalltalk. Now, if you read the quibbles, it's the reason I did the scripting workspace project. It answers all of his complaints. When you save in the workspace, it runs and compiles the code in the workspace. You can dynamically add classes and methods as well. It also works just like Ruby in that there's a context that methods get added to it if you don't specify a class. Ok, ok, I'll stop selling my new little project. Go read Sam's post because it's extremely well-written and he's right on the money.

Weight Watchers Pictures

Alright, a lot of folks have been asking me about before/after pictures of me. So, here it is:



I would like to thank my wife for taking the time to do the pictures. By the way, the pictures at the top and on the left are the "after" ones. Enjoy!

Scripting Workspace

I just released the first version of a new project I call the "Scripting Workspace". It's nothing to shout at right now. In fact, it's very simple. But, before I left for Camp Smalltalk, I read about people disregarding Smalltalk because you can't do things in the workspace that you can do in other scripting languages. I thought we needed to provide a bridge for these people. The reason being if they could do what they normally do in other scripting languages, they could see past the workspace and use the full environment. I've found this code to be nice to begin class construction and then move once workspace code got too big. Anyway, it's a little tool that I thought others might like and it's to make people used to JavaScript, Ruby, Python, Perl, etc more comfortable in our world when they are beginning.

It's available on SqueakMap. ENJOY!

Keep it DRY, Shy, and Tell The Other Guy

Andy Hunt and Dave Thomas have hit another home run in their article entitled: "OO In One Sentence".

Here are some of my fave tidbits:

"The best code is very shy. Like a
four-year old hiding behind a mother’s
skirt, code shouldn’t reveal too much
of itself and shouldn’t be too nosy into
others affairs."

AMEN! I see too much code where they are data structures and everything is accessible. It makes for very messy code. With that said, I also think you should always have accessors for your instance variables, but I don't think those methods should be considerd public by any means. Encapsulation is your friend!

"Always plan on writing concurrent code
because the odds are good that it will
end up that way anyhow, and you’ll get
a better design as a fringe benefit. Your
code shouldn’t care about what else
might be happening at the same time; it
should just work regardless."

Again, I can not stress this enough. I actually had someone ask me why I thought this was good. Now, I have an article to support my claim. Also, if you plan for concurrency, you will avoid all global variable and class variables (at least stateful class variables). Again, your code will be all the better for it. It also forces you to make your code more modular as well. It just has so many benefits. It just makes your design better. It's like writing tests for your code. Testing always shows defiencies in my code and where I can improve the API.

DRY

What do I need to say? Don't Repeat Yourself! AMEN!

“Sending a message” to an object
conveys an air of apathy. I’ve just sent
you an order (or a request), and I don’t
really care who or what you are or (especially)
how you do it. Just get it
done. This service-oriented, operationcentric
viewpoint is critical to good
code. Apathy toward the details, in this
case, is just the right approach. You tell
an object what to do; you don’t ask it
for data (too many details) and attempt
to do the work yourself.

What all of us Smalltalkers have known for years and years. But, damn, it's good to hear it again! I'm surprised how many developers that claim to be OO, just don't get this.

Anyway, the article has a lot of good stuff (and it's only 3 pages!) and you have no excuse not to read it. I love their talk on coupling too. I'm not going to say to much more because I didn't want to quote the entire article...=) But, I'm going to be making multiple copies of this articles and keeping it around me.

Start to salivate

The second edition of Dave Thomas' and Andy Hunt's excellent book on Ruby. Check it out here. I love the first edition. It's one of the best books on a programming language that I have read. The perfect blend of humor and information. I will be buying the second edition immediately. Ruby is changing a lot and it's exciting to watch.

Smalltalk on Java VM

Check this out. Another Smalltalk running on the JVM (Of course, I only knew of one other, but I had never heard of this one). It's called Talks2. The site is in German, but the Talks2 stuff is in english.

Now, did I mention that it has a full class browser, transcript, and DEBUGGER?! Wait, if that's not enough, you also get become: and full Smalltalk exceptions! How cool is that?! It's a minimal system and they are some rough edges, but DAMN, I am impressed! Great work guys and did I mention the liberal license? They also compile to Java code (not byte codes) and you can see how they implement things. Very cool. I would love to write code that compiled down to JBM byte codes. It would be a fun project, don't you think?

Anyway, chalk it up as another Smalltalk version! Weird thing is that I was looking for RETE algorithms in Smalltalk and ran into this by accident. COOL! Are you still reading this? GO NOW!

Fun Java Discussion

I just came across this and it made me laugh. That's all I'm going to say. Let's just say this is a fun discussion on java. Go see it here.

Philosophy

I've been reading the Rails documentation on their ActiveRecord framework and came across this quote of their philosphy for it:

Philosophy

Active Record attempts to provide a coherent wrapping for the inconvenience that is object-relational mapping. The prime directive for this mapping has been to minimize the amount of code needed to built a real-world domain model. This is made possible by relying on a number of conventions that make it easy for Active Record to infer complex relations and structures from a minimal amount of explicit direction.

Convention over Configuration:
No XML-files!
Lots of reflection and run-time extension
Magic is not inherently a bad word

Admit the Database:
Lets you drop down to SQL for odd cases and performance
Doesn‘t attempt to duplicate or replace data definitions

I love the convention over configuration! Right on!

J2EEland vs Dynamica

Check this article on J2EE vs. Ruby and Python. You have to read the comments too!
I love this quote:

I know this is an inflammatory statement but it would seem like the smart money is on a shift away from J2EE to Ruby or Python-based web frameworks.

Hell, I think we as the Smalltalk community need to get off our butts. Smalltalk has been around longer. Our frameworks are more mature and hell, even better! Seaside and Glorp kick a lot of booty. We even have OODBs (Gemstone) that kick booty as well! It seems the a lot of the loyal J2EE masses are figuring out that it's too hard to write systems especially simple ones. In Smalltalk, we can write systems that are not only easy to write, but scale as well! Raise the flag and let's get it on! Of course, I'm happier than a bug in a rug that people are looking at dynamic languages and solutions PERIOD. I would pick Smalltalk as my first choice of development anyday. But, I would gladly program in Ruby or Python instead of Java anyday.

More quotes:

Well, people say that the J2EE solutions are more scalable. A Ruby or Python web app may take less time to get going, but if you're going to run an Amazon or eBay you need something that scales up.

Now, I have no idea if this is true, it's just what they say...

Well, that's what they say...But, is it true? I think we're finding out that if you don't do J2EE "right", then yep, it doesn't scale. But, doing it "right" is very very hard and difficult. Anyway, J2EE developers need to stop reading the books and find out themselves what scales...Think out of the box...It feels great, I promise! Come feel the love!

Now, go read this rebuttal to the comments at Loud Thinking from the creator of Ruby On Rails. And speaking of marketing, check out Ruby On Rails. He's done a great showing off his framework and selling it as well as Ruby. Make me want to sit down and do a video for Seaside to show it off. Hmmmm...Perhaps, I need to get off my lazy bum and do something about it!

Excellent Article

Read this article on Less Software Engineering. He says what I was trying to in my article much better in places. The article is focused mainly on C++ development, but there are a lot of gems included in there. Of course, there were some things that I disagreed, but they were minor squabbles. Here's some excerpts:

"1. Use creativity to simplify, not to show off.
2. Avoid complexity. Design then code.
3. Be extremist. Maximize simplicity.

Systems always turn out to be more complex than you expect. Guard against this by pushing for the simplest possible design."

AMEN!

"Every programmer should strive to write code whose behavior is immediately obvious to the reader. If you find yourself writing code that would require someone reading through it to thumb through a manual in order to understand it, you are almost certainly being way too subtle. There is probably a much simpler and more obvious way to accomplish the same end. Maybe the code will be a little longer that way, but in the real world, it's whether the code works and how simple it is for someone to modify that matters a whole lot more than how many characters you had to type."

I don't like abbreviations and this is why. Without abbreviations, readers of my code know my intentions and they are obvious.

"One of the primary tools for producing maintainable code is minimization of scope. All variables should have scopes consistent with their lifetime and intended use.
There should be almost no global functions or constants."

I would say NO GLOBALS, but I generally need at least one. But, I fight it like hell!

"Use classes or typedefs instead of raw types like int. If you are using an int (or some other primitive type) to represent some concept, such as dollars, hide the representation via a class or typedef"

AMEN! This isn't a problem in Smalltalk, but is in C++ and Java.

"Choosing names is one of the most important aspects of programming"

Right on!

On Comments:
"Don't just repeat what's in the code. The biggest mistake made in documentation is simply to repeat what's already obvious from the code, such as the trivial (but exasperatingly common) example:

// // Increment i. // i ++;

Documentation should provide higher-level information about the overall function of the code -- what a complex collection of statements really means."

OH YEAH! But, I would say your code should be easy enough to read. But, when it's not a little comment can go a long way. I generally need to do this when dealing with third party libraries in Java.

Great Quote

"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it."
-Alan J. Perlis "Epigrams in Programming"

Perfect Design

I am addicted to achieving great design and I love reading about how to do it better. To me, design has always been about getting the most out of the least. I think this is what we admire most in art and music. Artists and musicians making the most out of the least. If you look at the greatness of Bach and Mozart, they were masters at making the most out of a small number of ideas. It's the ingenuity of stretching those few (great) ideas to their maximum while delighting the listener. I think of program design the same way. I want to write the least amount of code to get the most functionality. So, I tend to favor techniques that allow me to type less and don't make me repeat myself. This is why I favor dynamic languages like Smalltalk, Lisp, and Ruby. I also favor those languages because they give more tools to get the most out of my ideas.

Now, there is a huge push in the academic circles of computer science for mathematical purity. I even see this in the industry. I think the static typing advocates like the mathematical purity of typing. Haskell is one of those languages loved by academia. I know I was impressed with the typing system of Haskell initially. It's typing system is a lot better than what you see in Java/C++. It's cool until you get past some of the simple examples and things start to get a little messy. The point I'm trying to get to here is that computers are built on simple mathemtical principles outlined by Turing and Von Neuman. What a lot of folks want to do is extend that model to everything a computer does. But, just because what you are building is based on pure mathematics, doesn't mean the whole system needs to be. I know it sounds absurd. But, buildings have a basis in mathematics too. But, there's that squishy area where user requirements and construction and design meet. It's this squishy area that can not be expressed in math. It's the area where years of contracts have made the art of building business software complicated and hard. The languages we use and ideas we have should be amendable to this fact. I think the dynamic languages are all built on simple mathematics as well, but they relish the fast that the real world is squishy.

So, my point is that I see a lot of designers trying to make great design by making them mathematically perfect or at least adhering to mathematical beauty. I think while this is a lofty goal, they tend to break down in the real world. The best designs make the most out of the least number of moving parts. These designs do not target mathematical purity as the goal. But, the funny thing is that these designs tend to be beautiful in a mathematical sense. Thus, achieving the mathematical purity goal anyway. When I look at good designs (ala Seaside). It seems the goal was to get the most with the least. They certainly achieved it since I believe Seaside is still the easiest and takes the least amount of coding of any of the web frameworks. Also, if you look at the code, there is a sense of wonderment and mathematical beauty. I would be curious as to what design goals they had for it.

The real world is squishy and has lots of rules that don't seem to make sense. Let's embrace this randomness and chaos instead of shunning it because it's not pretty. Let's make our designs of the real world beautiful by writing the least amount of code.

Dynamic Freedom Hoedown

Well, James Robertson's blog has been full of activity on the whole dynamic vs. static typing debate. But, I was reading one comment and it really bothered me. Read the fun here and here So, I thought I would post on it.

Comment from: Darren Oakey on '2004-08-15T22:28:25-05:00'
I read Peter's post, but with no obvious way to submit a comment on that page, I have come back here.  I'll start first stating my amusement at the "you're wrong because.. well.. I say so" approach to argument :)

Anyway.  Most of the post is devoted to pointing out that you can do type-safety in Smalltalk.  Gee..  Who cares?  I'm not attacking Smalltalk  I think it has a lot of good things about it, which is why I read Smalltalk blogs.   For that matter, in more traditional languages, you can have complete dynamic types.  You can just declare something as an "object".

The argument that I put forwards though was that (please think outside the confines of any particular language) - the conceptual mode of programming towards a specific locked type is SAFER and therefore BETTER.   i.e. - a software program made with a higher level of type safety will have less bugs than a software program without - that's all I'm saying - and that concept wasn't addressed at all.
"oh but I've done a big software project without type safety". Well done.  Congratulations. 
Doesn't say whether it was a good idea

Dynamic typing is a good idea. I've worked on several projects in the past (Smalltalk, Java, C++, etc). And by and large, the Smalltalk projects have been less error prone. Now, the interesting question is why. And I think it has NOTHING to do with type checking! It has everything to do with the environment. You see, you are constantly running code in a Smalltalk environment and you never let any chunk of code go un-ran for any length of time because you are always checking your work. In Java and C++, you do this less because of the whole code-compile-run cycle. The compile cycle is implicit and incremental in the Smalltalk system. Plus, the type checking system hinders more than it helps. You are typing in a lot of information without getting any benefit. I find I can change my designs quicker and more safely with dynamic typing and TDD. In Java and C++, you have to get the design upfront because it is so hard to change it down the road. The funny part is a design always changes because your understanding changes during the process and it's great for the design to reflect your new found knowledge. I know I am not the only person with the problem. Just read Martin Fowler ("Reefactoring"), Kent Beck ("TDD"), and countless other better than I.

I will make some more assertions - if you disagree with these, there is no point in discussing anything, because I see these as "proven" statements.  They are part of the frames of reference, not part of the argument...

Isn't the point of arguing to argue? NOTHING HAS BEEN PROVEN. Our science is still too new to have hard and fast rules that need no arguing in fact, if we stop, we might as well just give up on improving. I want to keep improving, so I am going to argue where I disagree. Thank you very much.

1> edit time checking is superior to compile time checking is superior to runtime checking.  Just read any McConnell book, or look up ANY metrics on programming.  The cost of a bug or error goes up exponentially the later it is detected.  It's a documented fact.

I think you're confusing when a bug is expensive. I see edit, compile, and runtime as all development activities. I agree bugs are more expensive as THE PROJECT PROGRESSES. And the worst kind of bugs are requirement bugs and those are the expensive ones because they generally require design changes. Smalltalk handles design changes very well while Java/C++/etc doesn't because of the all typing information that gets in the way of the redesign. Besides in Smalltalk, there is no distinction betwen edit/compile/run times. It's all together.

2> Safer = better.  I don't know about you, but I am a senior architect / developer in the real world.  Many of the programmers I work with wouldn't be able to spell encapsulation, let alone explain what it means.  If, when I build the core libraries people use, I give someone a way of doing something stupid... rest assured - they will..

What do you know! I'm a senior architect / developer in the real world too! What's your point? Does the title give you more validity? I think in our industry titles are thrown around way too much to prove points. Anyway, I digress. I think our job as more experienced developers is to educate the less experienced developers. If they don't know how to spell encapsulation TEACH IT TO THEM! If you never show them the way, they will always be lost. They will always be ruining your "perfect" designs. TEACH! It's your duty!

So - back to the core discussion.  Is it (conceptually) better to code with type safety, or better not to.  Of course, practically, we all use both.  For instance if I made a collection class - I'd make the base collection class with "objects", and then specialize it for each class I actually use.    Of course something like templates/generics give us the best of both worlds - and strongly typed functional languages like Miranda, with pattern matching go even better... but lets look at the extremes - if you are forced to make a choice, which way should you go?

I've worked both sides and I chose. I choose Smalltalk. Not only for the dynamic typing but for its superior environment.

Now - to argue the dynamic type problem, I'll throw out two statements which I'll then support - those statements together logically demonstrate the need for type safety:  a) dynamic types are only safe if you have a clear and complete understanding of the objects you are working with  and b) in a large system with a lot of programmers of various skills and experience, it is impossible to have a clear and complete understanding of the objects you are working with.

If you don't have a clear understanding of all the objects in your system, then you do a poor job of design. You didn't split the system up into the right modules. You don't need to know about every object, but you should know how the modules fit together and how the objects in the modules you work on work. I think you have the same problem whether you work in Smalltalk or Java or whatever. It's a good/bad design issue.

So.. looking at a)  We've done the road example.  Let's go back to the train track example, and we can very easily see why even if you can, it is dangerous to do something that wasn't expected by the designers.  Suppose in the real world, we have two states, NSW and Queensland, that evolve their train system differently, and end up with different gauges.  They eventually decide to communicate, and we have a massive amount of trouble doing so.  We end up with all sorts of kludges to stop at the border, transfer cargo and so forth - and it ends up costing us millions and millions...   That's bad right?

Well - suppose instead initially - they had both looked up the US standard.  And followed that.  The gauges are compatible.  Yay.. lots of saved money.  However... what we didn't know - and when they drove the trains on and started using the lines, no one thought to mention it, because it didn't occur to anyone - was that NSW early in development had had better suspension technology.  Over the years, the superior trains in NSW had allowed much tighter corners than you ever saw in Queensland.

So.. What happens when the press all gets ready and watches for that first passenger train to come screaming down the lines from Queensland?  Yes.  That's right.  The train derails, and hundreds of people die.

A contrived example, sure - but it applies to every part of the system.  If I pass a control object to a graphics collection, I EXPECT, because I'm guaranteed - that that object will be able to draw itself.  There is zero possible benefit, and an enormous amount of possible danger of passing an object that can't draw itself to a function that draws all the objects in the collection.    While we can say  "oh yeah, and this expects objects that behaves as follows" - why shouldn't we ENFORCE that?  Even though it might be slightly more work, it is guaranteed to be superior in 100% of cases.  

Repeat after me, TDD, TDD, TDD. Keep saying it because EVERY system needs to do it. Without, enforcing all the types in the world will not fix bugs. Most of the bugs I run into are not interface problems, but internal bugs in the objects. The interface bugs are the easy to fix and no brainer bugs. The harder ones are in which there is an algorthm problem in the drawing of a component on the screen (taking from you example of course).

And, going to statement b) the reason it is necessary is because in the real world, you have no idea who will next use the class that you've just written.  They could be a complete idiot, they certainly won't understand all the assumptions you've made and the thinking you've done to produce the class - and won't have the time to read all (or any of) the documentation you've provided with it.  All they see is a function call that they have to send values to.

If you always assume the users of your code will be idiots then the code will be unusable by smart folks as well as idiots. I always think that the people that will be using my system will be smarter than me. I do not want to shackle them in anyway because I want them to be to adapt to circumstances that I never could have imagined when I wrote the code. I firmly believe this because Swing was built assuming the users would be idiots and it's the worst case of design I have ever seen. It just reeks bad design and part of that is because of developers assumed the developers were idiots. Never think of your fellow comrades like that, it's rude and not true. If you think they are idiots, it means they are not as educated as you. Well, your job is to educate them, not protect them.

The greater restrictions, guards, pre/post conditions etc you can place on that function, the BETTER the resulting system will be.  ALWAYS.  Because the average programmer is a complete idiot 

The average programmer IS NOT AN IDIOT. How dare you! The average developer is a smart person and it's impossible to know everything about computer science. If your developers don't get your designs, then maybe your designs are poor or maybe you need to educate them with what you know. I spend most of time educating and an architect that ridicules and not teaches is not an architect IMHO. It is your job to teach. My dream is to teach what I know so someone will have the time to learn something new to teach me.

I think one problem that you are facing understanding this is that you are dealing mostly with what is a very niche language.  Your average Smalltalk programmer will be a fairly serious, hardcore developer - because the language itself is not very accessible.  You are not daily dealing with people who's entire programming experience is that 4 day introduction to VB course..   But that's the sort of person who ends up using my libraries, and I need every bit of safety I can get my hands on.

You would be amazed. At the company I work at, they come from all walks. Some of had no training and they are excellent developers in their own right. They all varying degrees of expertise and well, they all love to learn. So, yes, I am dealing with people that you say I am not. In fact, the quality of the Smalltalk code is better. Why? Because of the whole constant edit/run cycle that Smalltalk encourages And that's not a dynamic vs. static argument. It's an environment. Static vs. dynamic argument comes into play when we start talking changing designs. In that regard, dynamic always wins. We all need TDD to ensure our code works. There are no short cuts in that arena.

Wouldn't it be nice...

If life was more like an Earth, Wind, & Fire album? I don't know but all of their albums transport to a nice place far away. I think on planet Alto Dorado, EW&F should be the house band. Right on...=)

Extreme Late Binding and The Definition Of OOP

I found this over on comp.lang.smalltalk. It's a post by Omaha's very own Alan Wostenberg. We Smalltalkers sure do know how to kick a lot of booty. I also love the quote from Alan Kay at the bottom. Why can't the static dudes understand? SIMPLICITY and LATE BINDING is where it's at! Come feel the love with us! Anyway, without further delay:

"Static typing prevents certain kinds of failures. Unfortunately, it
also prevents certain kinds of successes." - Ned Batchelder, quoted by
Peter Lund{1}

I had one of these surprise successes today. Situation was: how to
report progress to the interactive user of a very long running
calculation in a remote image. I began by passing the remote calculator
a value model
remoteObject longCalculation: 0 asValue.
The idea was the calculator's inner loop would periodically send #value:
to the model with an update of % done:
RemoteObject>>longCalculation: aModel
1 to: 10 do: [:each | aModel value: (each / 10).
(Delay forSeconds: 1) wait. ]

So far so good. But the advantage of extreme late binding came when I
changed my mind and decided to use a Block of arbitrary code to report
status. Now it happens that Block also responds to #value: and so the
client image can report status in a totally different way:
remoteObject longCalculation: [:percent | Transcript show: percent
printString;tab;flush].

Remote server doesn't know wether client is passing in a numeric
ValueHolder or a Block -- it takes anything that responds to #value: .
It stunned me and my teamates this worked! We're passing a block context
in the client image across the ORB to the server, which evaluates it
inside the client. This little block is far simpler than the distributed
event-change notification mechanism!

Question: Remote blocks work Distributed Smalltalk. Will they still work
in OpenTalk?

Anyway it was a nice late surprise. At compile time I thought I wanted a
numeric ValueHolder, and later, during debug, I decided to use a block.
(while in the debugger, 'natch). Extreme late binding is so liberating
Alan Kay makes it part of his definition of OOP{2}

"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them"


-----
Alan Wostenberg, Omaha

Build Your Own Bush

Now, this is too funny. I can't even explain it. Just go here and see for yourself. Silly fun!

Happy Guy

Well, it seems this is the nick name they have given me on my new team...=) I haven't had a nick name since I was in junior high (I was called "Apple Man" because all I did was hack on my Apple ][e). Anyway, I love it and think it's cute. Describes me to a T or at least how I would like to be thought of... At least, they didn't come up with any 4 letter words as my nick name...=)

I'm 34% hippie, man!

Check out this far out test. I hope this doesn't get my Black Sabbath fan club membership revoked...=)

Dynamic Freedom

Give me freedom! Go read Dynamic Freedom NOW!

Dynamic vs.Static: More thoughts

Why do static type languages tend to favor more complicated frameworks while dynamic languages prefer easy frameworks? Or maybe it's just me, but I find the frameworks in dynamic languages usually incorporate less code and are easier to understand than their static counterparts. I think it's the mindset. Dynamic developers generally like to be able to change any aspect of their world and don't like shackles. Their frameworks reflect that. Static developers on the other hand want to be protected from themselves and believe that you should protect your code from other malicious developers (look at "Effective Java" for examples of this). So, it makes me wonder if the debate will ever end because of this. It's shackle-less vs. shackled development. The static guys put so much stuff in their frameworks to protect you from yourself, they forget the real problem they are trying to solve(case in point, EJB-entity beans any one? They were to solve persistence, but failed miserably). Give me freedom, give me easy, give me concise, give me dynamic!

Layeritis

Does our industry suffer from layeritis? Sometimes I look at architectures and think "too many layers". I firmly believe layering systems properly is a good thing to do, but can you go overboard. I firmly believe that doing anything in the extreme is bad. The architectures I see in Java tend suffer the most from this disease. I often see a client layer, JSP/Servlet layer, EJB layer, Model layer, Data Access layer, and then the Database layer. For most systems, I see that EJBs are unneeded and a total burden on the system. If you need to distribute your objects, then use EJB by all means, but ONLY IF YOU NEED THEM! Sadly, EJBs are often misused because they are the cool toy in the toolbox (and plus they are COMPLEX...which a lot of developers love). I don't mean this to be a rant, but I see too many projects suffer from using what the books and vendors tell them to. They think it's the right thing because that's what is being taught. Don't do layers to be doing them. And be very careful with your layers too! If you find yourself changing more one layer for any change, then think about what you're doing. Some changes will ripple, but they should be avoided. If you're making a lot of changes that span layers, then you haven't layered properly. The point of this post is don't over architect and do the agile thing. Of course, this isn't a gripe about my new project, but a mistake I see occur in a lot in java projects...Don't make it in yours...

Excellent Article

OK, I must be slow, but I just found this great article on dynamic languages. It's a great read and an excellent advertisement for us dynamic supporters. I even got a new word out of it (meritocracy)! OK, so I admit it, I read this article instead of reading the JBoss documention like I should have(zzzzzz, is all that crap really needed?).

How do you spell "Relief"?

I spell it S-M-A-L-L-T-A-L-K. Apparently, you spell complexity, J-A-V-A. Sorry for the mini rant, but Smalltalk has ruined me because now I always look at how I could get stuff down with the least amount of code. It just takes so much code in java to do the same things that I do in ST. Oh well, let the madness begin...=(

The Java Bell Tolls For Thee

Well, it seems I am moving to a aava team at work next week. I will be there only temporarily to help them out. Don't fret I will still be doing Smalltalk when I get home at night and hopefully will be back in Smalltalk land soon. I hope to gain some insights in java code generation (which seems to be a new fire brewing in me). I've been thinking about programs writing programs lately (after some of the HttpUnit stuff I worked on) and I think I could do the same for java. We'll see...At least, I will be using eclipse. Wish me luck!

Weight Watchers Goal

I officially reached my Weight Watchers goal TODAY! Yes, I now weigh less than 179 pounds! How cool is that?! Overall, I've lost over 75 pounds. Now, it's maintenance mode for me! It took a little over a year to do it and man, do I feel GREAT! ROCK!

Dynamic Variables (ala more Seaside coolness)

OK, I've been meaning to blog about this for awhile. But, I just got around to it and since I was debugging some HttpUnitTest code involving Seaside...I thought, "What the HECK!" Anyway, so, what's worthy of blogging about Seaside that I haven't already. It's a cool little trick with Smalltalk's exception handling. First off, let me give you a little bit of background. When I learned Lisp, one thing that struck as being very cool was the notion of defining your own scope for variables. They don't have to conform to the boundaries of a method or a context. In fact, you can have them span several methods. While it is seldom needed, it is an excellent trick to have in your bag. I had been thinking for awhile that it would be a cool thing to have in Smalltalk. I thought immediately, I could have these dynamic variables defined in a block context and look up the stack when I needed their values. But, the code was messy. Well, one day I was looking at Seaside code and noticed that they use these "dynamic variables" for holding onto the current session in Seaside. But, he uses the plumbing already there in Smalltalk! He uses the exception handling framework! The code is so simple and I smacked myself on the head! BRILLIANCE! Here's the code taken from the Seaside source (I hope nobody minds)

WADynamicVariable>>use: anObject during: aBlock
^ aBlock
on: self
do: [:n | n resume: anObject]

WADynamicVariable>>value
^ self raiseSignal

Now, all you have to do is do something like the following code:

WADynamicVariable use: 'poo' during: [self doSomeStuff]

Anytime, you want the value of your dynamic variable, all you need to do is:

WADynamicVariable value

And it will return to you the value that is currently set in the stack for WADynamicVariable. Now, of course, you will want to create your subclass for your values so that it doesn't clash or you could have WADynamicVariable hold on to a dictionary of values and you access it via that (you could even use doesNotUnderstand to make variables easier to get to). Anyway, the code is simple and shows you what a little ingenuity in Smalltalk can do. There's a lot of cool things you can do with the exception handling framework in Smalltalk and use it in unexpected ways. This is just one of them.

Anyway, I thought it was a cool trick and a cool one to show off. I would like to thank the coders of Seaside for this idea. It's a good one!

Alternative Takes On Paul Graham

James Robertson and Eric Sink took away different perspectives than I from Paul Graham's Great Hackers article. They both have some great points that I hadn't thought about, but it seems they took a much stronger offense than I.

Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

My take on this when I read it was the all too common trait of working on a project where the other developers didn't think about the client's problems at all or just hacked their way through it. I like thinking about design and solving the "icky" client problems in an elegant way. It disturbs me when my views are not shared and some developers just want to hack and slash without any thought of design. But, I see where James and Eric took this to mean working on client code was beneath great hackers. And now after reading more closely, they are right. Graham feels like he's a little too full of himself on this one(he's always written his essays in a overblown type of way and I've liked them for this). I still love Paul for being honest about Java and for being one of the few to be vocal about how bad it is. But, I should have read closer on this one. Eric's article was especially good. I guess my take is that a great hackers are those that get the job done for the client quicker and cleaner. In other words, they get the job and you don't have to spend a lot of time maintaining their code. A great hacker also has no problems maintaining his own code. Any developer that doesn't want to maintain his own code should not be a developer.

3 Leg Torso

I saw this band while I was at Camp Smalltalk and they literally dropped my jaw! Go check out their web site here. Awesome musicianship, challenging music, and a fun edge makes for an engaging listen. I couldn't wait till I got one of their albums which I got in the mail today and expect the other sometime later this week! They play a blend of classically inspired chamber music mixed with folk music, but that description sounds very bland. The music is very lively and animated. Take the thematic elements of 60's spy soundtracks (no rock, just the mood and suspense) and mix in some of those crazy Raymond Scott-like passages. This stuff is just too incredible. Go check it out yourself. They put on one hell of a show. I was so impressed, but sad at the same time. I only got to see the last 10 minutes of their show, but I'm glad I did! What are you waiting for? GO LISTEN NOW!

Another great Paul Graham article

Apparently, Mr. Graham has written a new article entitled, Great Hackers. It's a dosey too! He comes out with all guns ablazing and it seems the slash dot crowd is upset about it. Hehehehehe...Why does the curly brace crowd get so upset when you poopoo on their language? I've had to put with people poopooing on Smalltalk for a long time. And I don't get upset, I get even...=) I get even by being more productive. Amen, Mr. Graham. Keep up the good work. We need more people like him that are unabashedly unashamed to pledge their allegiance to what makes them productive. I salute you!

Dark Side Of The Cell

Apparently, researchers have recently discovered that certain cells can oscillate at frequencies in the human hearing range. So, some musicians have decided to experiment with it! This is pretty cool stuff. Check it out here. Just when you thought they had done "everything" along comes something like this! VERY COOL!

Alice Cooper Staples Commercial

An Alice Cooper Fan Site has kindly posted the Staples commercial with Alice Cooper and his daughter at this location. IT'S FUNNY! =)

Vacation Is Over

Well, the second half of my vacation was spent in Utah. All I can say is, "WOW!" The views were the best I have ever seen. We did quite a bit like horse-back riding in the mountains, hiking along canyon ridges, bob-sledding (yep, you heard that right), watching shakespeare, and unfortuantely catching a cold (which slowed me down, but didn't stop me!) All in all a great vacation. I had a blast. It was great hanging out with my wife, my bud Rusty, and his wife. A great time was had by all! Now, it's back in Nebraska. Oh well....=) It was a great vacation to clear my head and dream.

doesNotUnderstand: and code generation

One of the things that I love about Smalltalk is that it allows you to get into the internals and do all kinds of crazy things. One of these things is be able to catch messages that an object doesn't understand and allow the object to do something meaningful. Now, this is great for proxy objects. But, I've also found it helpful in creating new languages for html. Well, generally, doesNotUnderstand: usage is frowned upon and rightfully so. It's a powerful tool to use, but not one you want to use a lot. First off, code becomes harder to debug because you're going through a layer of indirection. It's also hard for beginners to your code to find what you're doing. Things seem to happen by magic. Well, I've been thinking what if I could take away the last restriction? By that, make doesNotUnderstand: a direct call. Well, in Smalltalk I can do that! I can compile a method on the fly, add it to my class, and call my new method. Sure, I still pay for the initial call to doesNotUnderstand:, but subsequent calls are direct message sends. Beginners new to code will now see these auto-generated methods and things run faster. I used this technique in the HttpUnitTest framework because we wanted as concise a language as possible to describe html rules to find content. In a way, this works like Lisp macros (sort of).

I thought it was a nice way to relieve myself of a lot of mindless code and let Smalltalk write it for me. This concept is used in Squeak to fill out accessors. if you call a method and it has the same name as an instance variable, it will create the method for you. Of course, this can be turned on and off. But, it's nice to have when you're writing code. Why write simple methods if the computer can do it for you?

Camp Smalltalk Is Over

Phew! What an exhausting week it has been! I haven't had this much fun geeking out in a long time. I can't wait for the next one! I would love to thank you Martin McClure for kicking so much butt and taking the initiative to do it. THANKS BRO! I would also love to thank everyone that came out to program and discuss my favorite topic: Smalltalk. it was simply GREAT. I enjoyed all of the hacking, conversations, and just plain having fun. The only bad part is that now I have a to do list and a passion to get HttpUnit (name might change) out in alpha and let people see what we did. I think we are almost ready for an alpha release and stay tuned here for more details. Special thanks goes to Roger Whitney and his partners in crime: Dave and Colin. I spent a lot of time pogramming with them and I hope I didn't burden with my silliness to much. It was great hanging out with fellow brethern for a week.

All in all I can't wait till next year(a boy can hope can't he). Now, the urge to go to OOPSLA is very high. I'm going to start praying to the Smalltalk gods right now!

Now, it's off to Utah to bobsled, horse back, hike, and watch Shakespeare! Over and out!

More Painters And Hackers Quotes

Bill Clementson offers more great quotes from Paul Graham's "Painters and Hackers" book. Click here to read!

YACSR (Yet Another Camp Smalltalk Report

Lack of sleep is getting to me and coffee is required. Me having lot of fun. Me is sad that week is winding down. It's been great having a week of head in the clouds and making the impossible possible. I'm extremely excited about HttpUnitTest and I can't wait to release it for people to play with it. I hope Roger Whitney feels the same way (I think he does...we have been having too much fun!).

I mainly programed yesterday and talked a lot with folks. We had a lot of great discussions on everything from how to market Smalltalk to how to turn Smalltalk into a scripting language. All really good stuff and of course lots of java and microsoft bashing (but, of course, that could be me just hearing myself).

I'm finding love back in VisualWorks. It's been 4 years since I last used it and it has changed a lot. I plan to port HttpUnitTest to squeak nad VisualAge when I get home (it's not going to be very hard since the code base is very small still).

Well, over and out and tomorrow is the last day of Camp Smalltalk...=(

Camp Smalltalk: Day Two

Well, I'm working on the HttpUnitTest and we solidified the language to use for querying the html structure. I took a lot of inspiration from Seaside. I wanted something that was as concise as its html generation framework. I think we have achieved that very nicely. Here's an example for one of our tests:

self assert: (browser h1 allSatisfy: [:each | each text = '0']).
self assert: (browser a text includesAllOf: #('++' '--')).
self assert: ((browser id: 'counterValue') anySatisfy: [:each | each text = '0']).

This tests the code from the Seaside counter example. In the first example, I find all of the h1 elements currently shown in the browser object satisfy that their text is zero. The browse object pretends to be just that and is used for navigation. So, if I want to do a simple cick of a link I write the following:

browser clickLink: [:a | a text = '++'].

This code will find all "a href" elements and send it to the block and the first element that satisfies the block rule will be the link that we click on.

Today, we're going to add support for forms and more complicated navigation.

On a side note, we took a road trip Powell's bookstore and I had a blast! So many books, it makes your headspin. I bought three books (how can you escape a bookstore so large and buy no books?!).

Lastly, good and stimulating conversations have abounded. I am with true brothers. I can't express how proud I am to be a part of Smalltalkville this week. I am truly riding on the shoulders of giants this week.

Camp Smalltalk: Day One

Mommy, do I have to go home? Man, I'm having a blast. Great discussions continued and we got a lot of great work done. We went to go see some simply breath taking locations. Lots of fun! I went to bed tired and beaten. But, I loved every minute of it. Eric Winger is doing an excellent job of blogging the madness. He's doing a much better job than I!

Love is Camp Smalltalk

WOW! The first night of Camp Smalltalk was awesome. We have taken over Edgefield and the land of Dynamica has been created. It was really great being able to talk to a lot of people that I have respect for and have read their books. Really neat-o. It was also nice not to be constrained and think in the clouds. A lot of times when working on business software, it's just not practical to take full advantage of Smalltalk because everyone needs to understand what you are doing. But, on the project here, you can get away with a lot because those constraints are gone. Plus, it's great to exercise the brain and try experimental things out. In business software, experimental software just isn't feasible. So, you have to get your experimental stuff out in your spare time. So, it's nice to be able to collaborate with folks that want to push the envelope and try things out as well.

I talked and listened a lot last night. I learned a bunch. I can't wait to see how the week unfolds. It's so exciting! It's also nice to be able to bash java and enjoy the company of the some the brightest in the industry. ROCK!

I feel very intimidated to be in such great company. I'm just speechless. Smalltalk is the best! We have the brightest NO DOUBT!

Reclining Seats In Airplanes

Are evil and RUDE! They are nice, but are totally inconsiderate of the people behind them. There is very little room in the seat of an airplane (unless you fly first class) to do anything but sit. But, I like to bring my laptop to program and it's hard to open my laptop when some asshole has their seat leaned back...Grrrrr....End rant of today....

Camp Smalltalk Tomorrow

Well, I head out to Oregon tomorrow for Camp Smalltalk. I'm so excited I can't wait. I get the chance to meet and program with a lot of great people. It should be a lot of fun! ROCK!

Alan Kay Quote Spotting

I saw Alan Kay's quote: "The best way to predict the future is to invent it" outside of a bookstore in the Detroit airport. I know it's nothing big, but I always love seeing things from the Smalltalk community outside of our community. Anyway, I thought it was cool...=)

Hackers & Painters: Big Ideas From The Computer Age by Paul Graham

Well, I just finished reading this book. I was hoping there would be some additional articles that are not on his site, but I had read them all before. No problem. It was great to read them again. One thing about Paul Graham is his writing energizes you into action. He simply reiterates that the direction that I have taken to run away from the mainstream is justified and the right thing to do. He has a lot of subtle java slams and why you want to go down the dynamic programming path (of course, he wants you to go down the path of Lisp, not a bad path at all). His writing is very passionate and a lot of fun to read. I highly recommend this book and his articles on his website.

Here's some cool quotes:
"We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler"

Right on!

"Argue with idiots, and you become an idiot"

Preach on!

"Plans are just another word for ideas on the shelf. When we thought of good ideas, we implemented them."

"The top 5% of programmers probably write 99% of the good software"

"If we were all using the same language, it would probably be the wrong one."

"Lisp's power is multiplied by the fact that your competitors don't get it."

I think Smalltalk's power is the same.

"I suspect few housing projects in the US were designed by architects who expected to live in them. You see the same thing in programming languages. C, Lisp, and Smalltalk were created for their own designers to use. Cobol, Ada, and Java were created for other people to use.

If you think you're designing something for idiots, odds are you're not designing something good, even for idiots."

AMEN!

"Morale is another reason that it's hard to design something for an unsophisticated user. It's hard to stay interested in something you don't like yourself. To make something good, you have to be thinking, 'wow, this is really great,' not 'what a piece of shit; those fools will love it.'"

OH YEAH!

Anyway, do yourself and BUY IT NOW! It's one of the best book I've read in a long time. I hope Paul Graham publishes more. I love all of the books he has (his Lisp books are classics).

Alice Cooper - Bare Bones Tour

What a week this has been! I've got to see a lot of my idols this week! I got to see the Master last night and he did not disappoint as usual. He played a lot of older stuff (and a lot of obscure stuff just for us extreme fans). His band has really gelled together well and the drummer was awesome. I don't miss Eric Singer at all. They all played their hearts out and Alice was in top form. Simply, a great great show...=)

Ozzfest 2004

Well, I went to Hartford, CT to see the first night of this year's Ozzfest because it was the first american date for the reunited Judas Priest. I also got to hang out with some very dear friends as well. The concert itself was a lot of fun and I had a blast! I went mainly to see Black Sabbath, Judas Priest, Slayer and Black Label Society. None of them disappointed. They all kicked major butt. It was great seeing Ozzy with Sabbath and Rob Halford rightfully fronting Judas Priest. I about lost it when Priest played "The Sentinel", "Beyond the Realms of Death", and "Victim Of Changes". Easily among my favorites by them. Anyway, tomorrow night is THE MASTER: ALICE COOPER and I can't wait!!!!

How Geeky Are You?

Go right now and take the Geek Test. I know you want to. I scored 26.23274% which means I merely a "Total Geek". Anyway, it was a lot of fun to take and made me laugh at a lot of the questions...=)

Blogs are Great!

Well, through my posting on my blog, I got on the Camp Smalltalk mailing list. I find it funny that email is becoming less and less a good medium to communicate in. Basically, I think my emails were being eaten by a spam filter and never receving its intended audience. Ouch...Thank you spammers for rendering email useless!

Secondly, I received an email today from a ex-co-worker from my first job out of school and they found me again through my blog. How cool is that?! WOW! I love blogging!

More Info On Kyma

Ralph Johnson has provided more info on Kyma here. I can't express how cool I think Kyma is and it's great to be part of the community that delivers such greatness. I hope to one deliver my own Smalltalk baby on to the world. Thanks to Ralph for the update! Now, if I could buy Kyma, life would be AWESOME!

Fourth Of July In Nebreska

OK, I've lived in a lot of places. I've seen firework displays in Kansas, Washington DC, Boston, Raleigh, Alabama, and a few other places I can't remember. Well, none of them matched the one outside of my house the last couple of nights. The land is very flat here, you can see for miles, and the night was clear. All you saw was hundreds of fireworks going off in my neighborhood and distant ones. It was a constant barrage of lights and noise. It was incredible. I have never seen anything like it in my life. They went off for 2+ hours each night. WOW! I love firework displays and all of these little ones were a great show. And I didn't have to pay for one firework, clean up afterwards, or go somewhere to see it. I just got to sit back and enjoy it on my balcony. I found another perk of living out in Nebreska. And most people think there are none...=) You just have to be patient...

Kyma

Imagine my shock and surprise when I visited my local Barnes and Noble browsed through the recent Future Music magazine and found an article on Kyma. For those who don't know, Kyma is a very cool sound manipulation software package. It's very costly (around $3,000) I think, but if I had the money, I would buy it. Anyway, what's my point and why was I surprised? Well, Kyma is written in VisualWorks Smalltalk and the lengthy article was a review talking about how all of the major electronic and soundtrack composers and sound designers use it and swear by it. I would love to work on their product! I've read about everything I could about it and it's very cool. Combining music and Smalltalk is just too cool. Anyway, right on guys! It's great seeing a Smalltalk company kicking butt, getting respect, and having the coolest product on the block!

Great meeting

Man, are we good or what?! We had an excellent meeting last night at the Omaha Smalltalk User's group. Alan Wostenberg gave a passionate presentation on XP and showed off XP Swiki as well. We had a lot of discussions on how to get XP and Smalltalk more widely accepted. The time is now! We need to broadcast our successes! And yes, I'm on a super successful Smalltalk project!

Unfortuantely, there will be no meeting next month. But, we will start back up in August and ready to kick butt! GO SMALLTALK!

Dating Barbie

Check this out: Barbie and Blaine. Apparently, I've been dating Barbie. Man, how am I going to explain this one to my wife? Maybe she's dating Ken now...=) Anyway, I thought this was good for a laugh and funny that they chose my name...=)

Gapless MP3 Playback

Alright, my beloved PJB (Personal JukeBox) mp3 player is on the fritz and I am deeply saddened. It gave me 3 years of great service. So, you say why not just go get a new one? Well, I did! But, it shocked me to know that in 3 years that my old rugged mp3 player (which by the way was the first one with 20GB hard drive....3 YEARS AGO) is still more advanced that a lot of the newer players. One of the "advanced" features is one called "gapless" playback. What this means is that if I play two songs back to back, then I don't get silence between the songs. This is crucial for those beatles, slayer, and live albums that have no silence between tracks. It seems most mass storage mp3 players do not support this feature! Now, why is that? I hear a lot of people say, "Well, mp3 doesn't support it" Why does mp3 have to support it? I think it's a case of lazy designers who forget to put in double buffering (load one segment in a space that is not being played). It's how anti-skip works on your CD player. It amazes me that my old mp3 player does this and the newer ones don't. Is having a double buffer strategy more costly (I don't think so, you still have to load stuff from somewhere!)? I am just baffled. Double-buffering was one of the first things I learned to doing clean audio streaming (and clean graphic animations too). Oh well, I'll get off my soap box now...=)

Java Complexity

Oh boy, David Buck has posted a comment on Java Complexity. He points to this post which probably has some of the funniest comments I've read in awhile.

It makes me think about my time wrestling with Swing. At the time, I wanted to write a book on bad design and use Swing as the example. Swing is riddled with poor usage of private and final keywords (in other words, the protect you from bits you need to get to if you write your own widgets). There's also poor use of inheritance (why are the Swing components subclassed from the AWT Components?!!!). And to make matters worse, Swing is very complex and daunting for the average programmer. Don't even get me started with J2EE which is supposed to be a distributed framework that was suppossed to make enterprise development easier by making the connection to relational databases easier (oh what a joke, it's the one that it's the poorest at and it wasn't like this problem hasn't been thought about before). My last project in Java, we used Toplink for our relational mapping and used very little of the J2EE API (only the parts we needed). Don't even get me started on Struts (just go look at Seaside and you'll see an excellent web framework).

So, what's it like being back in Smalltalk land? I can safely say I never want to go back to Java. Smalltalk developers get it right most of the time. They understand computer engineering and simplicity. We embrace simplicity and find warmth in it. So, what makes our culture different? I think we don't have to spell every thing out and we get used to getting little bits of our design done incrementally. Our tools support this and the language does as well. It allows us to try more things out and be more experimental. In Java, you just have to nail things down earlier because of lesser tool set and strong typing. It's not to say you can't have simplicity in Java (you most certainly can). You just have to work harder at it than most developers are willing to.

Omaha Smalltalk User's Group

Alright, I've got YET another exciting speaker lined up for the Smalltalk User's Group Meeting here in good ole Omaha! This time it is Alan Wostenberg and he will be talking about XP Swiki. Again, I hate to sound like a fanboy, but the XP Swiki aims to be a super cool new tool for XP teams! The meeting will be June 29, 7:00pm-8:00pm at the Abraham's Library Conference Room. I hope to see EVERY SMALLTALKER in OMAHA there! And hey, if you've been curious about what all the fuss is, come on down and we'll be glad to show you. Yes, that means if you don't know Smalltalk, you're invited too!

XPSwiki is an open source web tool for eXtreme Programming teams. It supports those XP practices related to requirements gathering and project management - user stories and the planning game.
XPSwiki is based on Swiki, the Squeak Wiki technology. It aims to be an agile and user friendly tool which adapts itself to your development process.

Click here for more info on XP Swiki

Maintenance Costs

One thing that I never see on projects is attributing maintenance cost with the success of the project. I always see managers get bonuses because they delivered the project "under budget" (if they do deliver). Typically, the project is maintanence nightmare, but for a lot of organizations, I've seen, they never attribute back the maintenance costs per year back to the project. Why is this? I think its cheating to say a project is done and will cost nothing more. That's simply ludicrous. I wonder how development would change if we depreciated software like we do goods. But, instead of the value going down, the maintenance costs were assessed. If a piece of software started to cost more, then it would be depreciated. Now, why is this important? Because I an easy to maintain piece of software costs less because it was designed well. XP manages this quite well since a project is constantly in maintenance mode and there's no separation between development and after. It's all the same. Systems are grown instead of built. I think if management of IT departments looked at the maintenance costs (at a project level instead of a large sink hole for everyone) that we would see a turn to XP and dynamic languages. But, that's just my theory...=)

Ayreon: The Human Equation

I'm glad people make great music still. This album is simply beyond words. I've been listening to it 2 days non-stop. Nothing else has entered my player. For those that don't know, Ayreon is the brain-child of Arjen Lucasson. He basically assembles a cast of stellar musicians and singers, writes all of the music, and records it. Every album is nothing short of amazing. In fact, everything that Arjen touches is simply incredible. But, his new album, "The Human Equation" is way better than anything I could have expected. It's nice to have a musician to have hopes for and they exceed them everytime. The story is amazing and the music is a tour de force of prog, folk, symphonic, electronic, and metal. And it all sounds coherent. I can't stop listening to it. Right now, I have 10 albums from Mr. Arjen Lucasson and they all KICK. If you enjoy music that challenges and delights you (ala Dream Theater, Yes, etc), then go out and buy this now. This is the album of the decade. YES, IT'S THAT DAMN GREAT! Also, there is a tribute of sort to Mr. Alice Cooper (it would have been nice to have the real thing, but the tribute was done well).

Weight Watchers One Year Anniversary

This past week marked my one year anniversary of sticking with Weight Watchers. I still haven't reached goal, but I've lost over 65 pounds. I'm actually very close and hope to be at my goal weight by xmas. I feel better than I have in years. It's amazing what losing a little weight and quitting smoking will do for you! Here's to another year of great health!

Omaha Smalltalk User's Group

We had a great meeting this past Thursday! Gary gave a great presentation on ultra-structure and I think everyone walked away with visions of how they could apply it at work (I know I was). We went out later to discuss the Omaha Smalltalk User's Group project. A lot of ideas were batted around, but nothing in stone yet. We even discussed which Smalltalk to use. Whatever we choose to do, it will be fun! Anyway, I wanted to thank Gary for the excellent presentation and everyone that came out! GO SMALLTALK!

Camp Smalltalk Mailing List

What Smalltalk god do I need to worship to get on the Camp Smalltalk mailing list? I'm going and I want to join in on all of the pre-game fun. AARRGGHH! I just know that Camp Smalltalk is going to rock and I can't wait. I hope to learn a lot from the masters there! Now, I just need to get on the list! Can anyone help me? PLEASE?!

One Year Blogging Anniversary

Today is my one year blogging anniversary! YIPPEE! It doesn't feel like a year. But, it's felt good talking about Smalltalk and the virtues of it. In the past year, I went from being a Java developer (and unhappy) to coming back home to Smalltalk. It feels great to be doing 100% of my off time programming and on job stuff in the language I love most. I'm happy that I was given the opportunity. And yes, programming in Smalltalk everyday is worth living in Nebraska for. So, here's to another year of pro-Smalltalk and pro-dynamic languages blogging!

Tornadoes, Winters, and Allergies

Good grief! Allergies have struck me again. I'm medicated now and feeling better, but what a week here in Nebreska. First off, the midwest and my nose do not like one another. I didn't have any problems with my allergies until I moved out this way. It's already cost me a day of work and one evening. Darn allergy headaches! But, if that wasn't enough, we get all these violent thunderstorms with tons of tornadoes! I feel like I'm playing russian roulette with mother nature out here...=) And did I mention the winter? It's not winter, it's anartica! OK, OK, OK, I'll stop complaining now...

Chaos, Fractals, Recursion, etc

Lately, I've been back in my mathematician mode and reading books of a mathematical nature. I've always been interested in making complex systems out of simple rules. So, the idea of making fractals by use of simple rules and recursion seems mystical to me. I've been thinking that it would be cool if we could do the same thing in computer science (particularily, multi-agent systems from what I've read). Well, I cam across this link with an interesting discussion on Emergnent Behavior that follows the same lines (simple rules, complex behavior). Check it out here. It's fun stuff to think about.

Modern Day Witchhunt?

I picked up this bit of news from Blabbermouth.

Donald Bradley of The Kansas City Star is reporting that city of Blue Springs, Missouri has returned almost half of a $273,000 federal grant it received in 2002 to fight a perceived growing Goth culture. Some feared the black clothes, morbid music and obsession with the occult — and Ozzy Osbourne — could lure a wave of youngsters into a world of depression, drugs and suicide.

Officials returned $132,000 of the money because the Goth situation was overstated in the beginning, Blue Springs Police Chief Wayne McCoy said Friday (May 21).

Community forums on Goth culture were never held because of a lack of interest, and no youth received treatment for Goth behavior. Both were provisions of the grant.

"My belief is that you guard public dollars very carefully," McCoy said. "The money wasn't being used so we gave it back."

The issue arose when parents and other residents called police to inquire about Goth and its influence on teens. McCoy said the callers feared what they didn't understand.

This sounds so incredibly dumb to me. I can't believe our government would spend money to "fix" goth kids. I can think of worse things that a kid can do besides dress in black and listen to depressing music (like doing drugs). We have a problem in this country with drugs and obesity. Why not spend money to fix those problems? I'm glad I'm a not kid growing up now because this is the kind of stupid stuff I grew up with. I was a metal head kid and everyone wanted to "fix" me. Grrrr...People should worry about their own backyards...And one more thing, where did the other half of the money go?

Words Out Of Mouth

James Robertson posted a quote by Colin Putney that say what I was thinking about over vs under design in a much more direct way. It's exactly my thoughts. Go check it out here

Re: Under-design vs. Over-design

Michael Arnoldus had some interesting comments:

Very interesting subject. Allow me to suggest a few questions which will help me understand and maybe make it clearer what answer you are searching for. After reading David Schmaltz: "The Blind Men and The Elephant" i've found worthwile to investige in what 'action-context' an answer is to used. Do you need the under- vs. over-design answer to blame somebody or do you need it to evaluate how much design you need to do before beginning? Another question, does the design-question make sense at all until after the fact, when we know what we should have done? Isn't the under/over design answer just as much subject to change as XP claims (and I agree) the requirements are? I'd like to know what you think.

Well, the answer is certainly not to be used to blame anybody for anything (like "NO NO NO BAD PROGRAMMER!") of course. I think the evaluation of how much design do you need to do is getting closer. I think the real reason for the discussing "over" vs. "under" design is to understand how far do you need to go when thinking about a system. The thought and planning still needs to happen, but how much is good enough? Is it OK to err on the side of not enough thought or on too much? Like I said before, the extreme cases of either is clearly bad. But, what about the less than extreme cases. I think we can all point to examples of where under design killed a project or where over design burdened a project into extinction. I keep pondering on what side would I want to err on (of course, I want to err as little as possible, but I know that perfect designs are very hard to obtain if not impossible). The thing about XP is that it says that to err is human and to err on the side of under design because if it not enough then you can refactor in a better design as you outgrow the old one. It doesn't say not to do design, but just to not to go overboard with super generic solutions (basically, don't invent a new tool if a hammer will do for today). I also think its extremely important to always been evaluating a design and refactor it the minute it becomes painful to use. So, I do believe in post-mortem activities after iterations in XP. And to his last point, I would say I would expect the design to change as often as the requirements in the beginning and then slowly harden as the project continues. I would expect changing too much of the design constantly would be a bad thing. A good design changes slowly. I mean how many times was Smalltalk rewritten before we got the system we have today? Perfection is not obtained overnight. I look at a good design like a fine wine. It gets better with age.

Under-design vs. Over-design

I've been throwing a question in my head for a while and I thought I'd post about it. The question is simple: What's better under-design or over-design? Sure, the extreme cases of both are bad (awful would be a better word) and painful. But, what about the less extreme cases? I would imagine everyone would agree that good design is in the middle (not too much, not too little). Good design is easy to work with and easy to make changes to. But, a shift either way is under or over design. Now, I don't live in a perfect world and most designs I've seen tend to go to one side or another. I've been asking anyone within earshot what they think and the answers have been very enlightening. My first gut instinct would be to err on the side of over-design, but I think this from coming from the non-XP world. But, now, since I've been doing XP for a little while. I think I would rather land on the side of under design. Why you ask? A lot of people think XP is devoid of design (which is think is absolutely wrong). It's just in XP, we design what we need today and refactor unmercilessly as we go along. The "refactor unmercilessly" is the key phrase because without it you get a severe case of under design and your code becomes painful to maintain. Back in the old days (pre-XP), I was on teams that would design for months before we wrote any code. What we usually got was way over-designed code that had to be changed anyway because of forces of the real world (always making our elegant code messy! How dare it!). When I first started to play with XP, I knew it was a good way to go but was scared about "only design for today" adage. But, what I found is the systems are more adaptable to change. The only time we have problems is when we get into time crunches and forget to "refactor unmercilessly". I think I go back to my saying, "Design for today, but your keep your eye on the future". Lots of times you can add "hooks" to your code that allo extensibility for future enhancements without sacrificing succintness nor adding complexity or code. Think before you code! XP is not about blind coding without thought (which I have heard arguments as such). So, what's everyone else's opinion? I don't know if there is a right answer because each has it's plues and minuses. But, from my experience, a little bit of under design is better than over design. Your mileage might vary of course.

Congrats to Jeremy Turner

It seems Jeremy Turner has gotten the gig as the new Cannibal Corpse guitarist. Jeremy played in the local Kansas band, Origin. And they were an awesome band with a great attitude. They always put on an incredible show and all are great musicians. I met Jeremy a couple of times and he was cool. My old band opened up for them right before I joined (I was doing lights) and Origin spent some time with our guitarist teaching him licks. It's cool to see a local brother doing GREAT (even though I'm not in Kansas anymore...bite me)!!! Way to go man!

Cool Quotes

James Robertson has had a string of great quotes! Here's just a couple:

"In the church of complexity, more is always better..."
"The dead hand of rigid systems is holding the entire software development world back..."

Why can't I come up with cool quotes like that. James, I don't care what anyone else says, you are the man! Plus, I love how he has the knack to push up the blood pressure of developers from the world of statica. It's great! Keep up the good work!

Bad Blogger

I've been a bad blogger lately. I've been extremely busy (yeah, a poor excuse I admit). But, it hasn't been for a lack of thoughts! I've been researching fractals and chaos theory lately. Basically, I'm trying to get ready for the GRE to go back to school and it's reignited the mathematician in me a little bit. Of course, I have a list of Smalltalk projects that I'm itching to do as well (XML tools inspired by Seaside and my hate for the poor tools for XML, JXTA, Java integration, .NET VM, neural nets, rules and object integration, etc, etc). But, I want to get back to blogging regularly as well. What's a poor soul to do?

Is anyone else couting the days till Camp Smalltalk? I heard via Patrick Logan that there's a mailing list. I need to get on it!

Next Omaha Smalltalk User's Meeting

Alright, I've got another exciting speaker lined up for the Smalltalk User's Group Meeting here in good ole Omaha! This time is Gary Overgard and he will be talking about Ruleforms. I'm very excited to see this presentation since I have been very interested in rules and objects for a long time and I have never ran across any of this material. Looks AWESOME! The meeting will be May 27, 7:00pm-8:00pm at the Abraham's Library Conference Room. I hope to see EVERY SMALLTALKER in OMAHA there! And hey, if you've been curious about what all the fuss is, come on down and we'll be glad to show you. Yes, that means if you don't know Smalltalk, you're invited too!

The Ruleform Hypothesis: Complex system structures and behaviors are generated by not necessarily complex processes; these processes are generated by the animation of operating rules. Operating rules can be grouped into a small number of classes, whose form is prescribed by Ruleforms. - UltraStructure ACM 1/ 95, Jeffrey Long

More information:
http://c2.com/cgi/wiki?UltraStructure
http://smalltalk.cincom.com/community/digest/2001/May/index.ssp?content=ruleforms

Omaha Smalltalk Mailing List

I've started a mailing list for the Omaha Smalltalk User's Group. If you would like to subscribe, please send an email to smalltalk_omaha-subscribe@blainebuxton.com with no subject or body. We're planning on starting a new project and I would like to start all the discussion on the list. Everyone is invited! See you there!

Published Presentation

OK, several people have asked me if I would bundle the presentation to make it easy for people to see it. I made a zip package that includes a squeak VM and image with the presentation, Seaside 2.5a, and Komanche preloaded. All you have to do is click here or on the left of the screen. Once you have downloaded it, unzip it, and simply double click on the Squeak.exe. When you see the image, point you web browser to http://localhost:9090/seaside/presentation. And that's it! I pre-started the web browser and I put notes in the image so you can configure Seaside and play around with it. Enjoy!