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! =)