Journeyman

I didn't even notice, but I've been certified a Journeyman by Ken Causey on Squeak People! WOW! Thanks, man! It made my day. What a nice xmas gift to receive! I'll cut this short because I've got some squeaking to do! Smalltalk on!

Off To See Kinfolk

I probably will not have internet access for a little while until I get back. I'm heading down to Alabama for the holidays to spend some time with family and friends. I hope everyone has a very happy xmas and gets everything they dreamed of. See ya in a week!

I love testing

Well, I woke up bright and early this morning and decided to upgrade my Squeak image to the latest 3.8gamma. Well, I found that a lot of my projects do not work now. Crap. Well, I find out that one problem right away is mine and then within one hour I had my project migrated. I was shocked how fast I was able to find the problems and fix them. I didn't need a magic wand or anything, just all of the tests that I now write before I write code. A lot of the tests tested such small pieces that I was able to hone in on the problem quickly and fix it. No massive walk thoughs or cussing. It just re-iterated in my mind that the most important aspect of agile methodologies is test-first. Hell, it should be the most important aspect in any methodology! I was also thankful to keep my tests small. The only project that I have that has huge unit tests (more like acceptance tests) is my Java project and I plan to fix that shortly.

Smalltalk/X

OK, I've been playing around with Smalltalk/X lately and I'm quite impressed with how it has progressed in the past year. It's still a little rough around the edges (I got it to crash several times while trying to restart a method in the debugger) and a few things don't work like you think they might, but overall it's a good experience. I've been using the windows port and I get the feeling that the linux port probably kicks all booty. The code I've seen thus far has been very clean. I ported some of my xml code from Squeak to it and with a few minor tweaks, was up and running in no time! The really cool thing is that they have other languages as well. There's a java, prolog, and even a javascript interpreter. Very cool indeed. I'm still in the beginning stages so my VM crashs could well be a new beginnger clicking the wrong button. I'm excited. It should be a lot of fun exploring!

Great Quote

"Static Typing: Make it fast. Make it right. Make it run." - Niall Ross

Can I get an AMEN? Smalltalk on!

New Smalltalk Blogger

A great friend of mine just started his very own blog. Please welcome, Andres Valloud, to the world of Smalltalk bloggers. You can read his blog at: Ten is a good number. One of the things I love about Andres is that he speaks his mind and holds nothing back. If he doesn't like something, he says so. Enjoy!

Omaha Smalltalk User's Group

Guess what time of the month it is? Yes, it's time for the monthly Omaha, NE Smalltalk User's Group meeting! The FIT framework will again be up for discussion and anything else everyone wants to talk about. Last month, we talked about "The Genius Within", Refactoring Browser tool, Squeak, and a whole bunch more that I can't think of. I'm sure it will be fun and educational whatever we decide to discuss. Here's the details:

Tuesday, December 14, 7-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164

We generally meet in the seating in front of the official meeting room. We're still a small group. Just look for a long haired fellow who has a laptop and talks about this super cool language called Smalltalk!

See you all there!

Crushed, Saddened, and In Denial

Anyone that knows me knows that I am huge fan of heavy metal music. They also know that I am a huge fan of Pantera and Damage Plan. Imagine my shock when I heard this morning when I found out that Dime had been shot to death! I thought it was some sort of sick and disgusting joke on the internet, but nope, it was true. His music meant a lot to me. From what I read, he was a caring and fun loving person. I just can't believe his been taken from us. A true metal warrior of the highest caliber and he's been ripped from us by a maniac. I also can't believe all of the injured and dead. I am just shocked. I wish I could pinch myself and this would all be a dream. My condolences go out to all of the families involved. I can't express my emotions and I was just a fan. Brothers in metal forever...

This is what we've been talking about!

If you wonder why we Smalltakers, Lispers, Rubyers, Pythoners, Perlers, and other inhabitants of Dynamica are constantly raving about, then go watch this movie on Self. It brings home the point of what is possible in dynamic environments. The compile/run paradigm is just not needed and you can be so much more productive in lively environments. The movie does a great job of showcasing why simple is better and lively environments are the future. It was interesting to see the Morphic environment in use in Self. I know the version in Squeak was written by the same person, John Maloney. I also noticed a lot of the Etoys-type stuff in there as well. It's nice to see where inspirations are coming from. I would love to play with an instance-based Smalltalk system. How cool would that be? Anyway, the link has a bunch of movies that I hope to spend some time watching! OH BOY WHAT FUN! The movie reminds me that I need to go play with some Self. I download an x86 version a while back, but was to busy to play with it. Maybe now is the time to fire it up....=)

Remember: Be Nice

Just a reminder that all of the people helping you this holiday season are working long hours and trying their best to please. I was helping my wife out this weekend at the mall (she owns a kiosk) and I think several people should have remembered the age old rule, "Treat people like you would like to be treated." I was shocked and disgusted how rude people can be sometimes. One man even made an obscene hand gesture after he had walked about and asked for help which I gave. He made the gesture in response to my sales pitch. I never think it's OK to be rude. But, I see it everyday in traffic, at work, at the mall, and just about any public place I go to. It saddenns me. There's never an excuse to be rude EVER. I don't care if you're having a bad day. Smile and treat everyone with respect. Anyway, my one wish is for everyone to be nice to one another. Have patience and remember everyone working behind those counters are people too. You are not better than them because you are the customer. They are not your slaves, they are your amplifiers to get your shopping done more quickly. So, if someone offers you a free chicken wing, politely refuse if you're not interested...don't yell...Don't make an obscene gesture, just BE NICE! Oh yeah, and be nice to your fellow shoppers and human beings as well. Peace, love, and happiness...It's not just for family time and xmas anymore. Do it all the time!

Weak Typing and Bad Programmers

Alright, I went looking for Javascript info while I was writing my Life Simulation and I found two pages noteworthy: Javascript Rocks and it's nemesis, Javascript Sucks. Both pages have great points and things to ponder. There's a bit that I agree on both of them, but I'm firmly in the camp that thinks Javascript is a powerful lisp-like language encumbered with C syntax that's been messed up by the browser wars. But, enough of my incessant whining, one thing that caught my eye as an against of Javascript is that it is "weak typed". It's described in one the links outside of the Sucks page. It's also been talked about blogs, but I can't remember who's now. The example given is "3" + 1 returns "4". And this is bad. Well, if you think about how tolerant the browsers of HTML, why would javascript be any different? I'm not saying it's a good thing. In fact, I think it's a bad thing, but it's not something to blame the language for. It's the damn programmer who wrote that code in the first place that should be blamed! Javascript is typed (it knows to do the conversion and it will complain when I send it a message it doesn't understand. Basically, the auto-conversion is only on operators). I've never been bit by it because I make sure where I need numbers, I convert them to numbers! Same goes for strings. I don't mix the two and depend on automatic conversion (you should never rely on automatic conversion...SAY WHAT YOU MEAN AND SAY IT MEAN!) I think it's wrong to blame the language and it makes an easy scapegoat for bad programming. If you're surprised by something the language does or you don't like that it does it, then DON'T DO IT! In this case, make sure your objects are converted to the right types and be done with it. If you get surprises anywhere, it's because you didn't code it right. When I make a mistake, the last thing I do is blame the language or compiler. I blame myself. Take responsibility. Stop blaming the language. Languages are only amplifiers. Pick the one that amplifies your thoughts better and be done with it. OK, I'll get off my soapbox for now...=) Bottom line is that I don't want my language to control me...I want to take responsibility when I break my code. Remember, bad code is bad code not matter if the language is weakly, strongly, dynamically, and/or statically typed.

Weekend Project: Conway's Game Of Life In Javascript

OK, I have always loved and found wonderment (is that a word?!) in Conway's Game Of Life. While talking to a friend of mine, the subject of the William Poundstone's "Recursive Universe" came up (I probably started it). Anyway, to cut a long story short, we hit the web and all I found were java versions on the web. I thought this to be very sad. Where are the javascript versions?! I thought it would be a cool weekend project and I thought it would be equally cool to allow you to edit the rules it uses. So, all you recursive emergent behavior freak lovers of the simple, go here right now and enjoy! It runs in IE, Firefox, Mozilla, and Opera. It works best in Mozilla and Firefox since their Javascript implementations are FAST! I had to take out some of my closures to make IE and Opera to work properly, but oh well...

I just love knowing that I now have an implementation of Conway's Life that I can play with anywhere and I can change the rules! How cool is that?!!!!!

Scripting and Smalltalk

Lots of new dynamic languages have come along and tons of programmers are discovering the productivity gains of no compilation wait times and immediate feedback. But, the environments for these new languages are still based on files and dead systems. One advantage Smalltalk has is that the environment is alive (you can change the environment without shutting down, everything is well ALIVE!) and I think this makes a perfect playground for scripting as well as application development. While most folks use Smalltalk for ultra-complex business applications because they like spending time with their kids, but Smalltalk can also be used for scripting. You see you can get access to the compiler, compiled code, and even the runtime stack (you can even change it!)! Now, even most scripting languages don't give you that kind of power! The only other language I can think of that does is LISP. Anyway, back to the topic at hand. We all know that scripting is helpful for kicking off systems, moving files around, querying the state of a running application, and etc. This is available off the shelf for every Smalltalk dialect that I know of. The cool thing about scripting in Smalltalk is that since you have a powerful environment around you, you can write your script in a workspace. Now, if your script gets too big, you can start moving it to classes and refactoring. You can also move scripts to external files and load them in a runtime. Why do you configuration files when you can have runnable code that does it for you? Let the objects do the talking! Scripting is also great in running systems. If you run Smalltalk in headless mode, you can have scripts that query the state of the system while it's running! This can be very powerful and DANGEROUS! But, wait a minute, we have access to the compiled code and we can actually query the compiled code to make sure it doesn't do anything nasty. The bounds are limitless and once you start thingking about them, you wonder why am I writing unix bash scripts and then, you might be wondering, why not have the power of a compiled language, but the expressive power of an interpreted one? Smalltalk is all that and a whole lot more.

Scary Computer Errors

OK, Bill Bumgarner blogged on computer error in Ohio and I must admit it scares the living day lights out of me. I have no doubt that cheating in elections is nothing new. Both the democrats and republicans have been ingenius in their bending of the system. But, this takes it to a whole new ball game. Computers make it very easy to tip the scales. I think this article just rings clear that we election software MUST BE OPEN SOURCE and we must ensure that the software is not tampered in any way. Computers could be used to get rid of most cheating in elections, but they can also be used as very efficient cheaters as well. If we do nothing, we might as well resolve ourselves to a dictatorship.

Omaha Smalltalk User's Group

Guess what time of the month it is? Yes, it's time for the monthly Omaha, NE Smalltalk User's Group meeting! Again, it's going to be an open forum where anything is up for grabs. Last month, we talked about design, moose, nebraska (the distributed environment in Squeak), and croquet. I'm sure it will be fun and educational whatever we decide to discuss. Here's the details:

Tuesday, November 9, 7-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164

We generally meet in the seating in front of the official meeting room. We're still a small group. Just look for a long haired fellow who has a laptop and talks about this super cool language called Smalltalk!

See you all there!

Hatred and Disgust

Well, I am very depressed about today's election outcome. So, I'm listening to Sorrow's "Hatred and Disgust" album. It seemed to fit the mood perfectly. I guess I should look on the bright side: there's going to be a lot of great grindcore (really angry fast punk metal) coming out because of it...=) But, what I want to know is why is "liberal" considered a dirty word and conservative is not? This page will be black until I stop grieving...=)

Time For Change

Isn't it time to deal with complexity with a simple and powerful language? Read this article and realize Smalltalk could be used to fix the "complexity" problem by dealing with it instead of masking it with more complexity. IT systems are complex. You need a language that can deal with it: Smalltalk. If you want rising IT costs and complexity, do what everyone else is doing. Why not try something new, yet has had lots of time to mature.

John Peel

I just read that John Peel died of a heart attack. The news shocked me. Peel was an influential DJ and took a lot of chances. If it wasn't for him, a lot of the music that I enjoy might not have crossed the atlantic and into my ears. He was responsible for giving a lot of bands their chance when no one else would touch them. The whole genre of grindcore owes a lot to him and in fact, Earache Records has a tribute to him on their front page. I listened to a ton of records from that label when I was in college. RIP. A cultural icon for the underground is gone. He will be missed.

Musicians And Programmers: Why Have One Genre or Technology?

I have been thinking about how close musicians and programmers truly are. I am more confident than ever that programming is functional art. By functional, I mean art that performs some function (aka architecture). The metaphor of a band or orchestra comes to mind immediately. Agile methodologies have brought back the notion of what we always knew to be true: small teams of dedicated programmers can accomplish great things. It seems the mainstream is just catching up even though there have been several books in the past that touched on this subject (Peopleware and Pyschology of Computer Programming just to name two). Much like small groups of musicians can perform great works of music (think chamber music, rock music, etc). Now, these musicians have to work tightly together to make sure that they don't make noise. The same is true for programmers, if we don't pair and communicate, we get noise as well (broken code). Neither is a pleasant experience for our customers (for musicians this is the listener of course). And while a big team can pull off a project, it's rare. It seems the parallel in music is huge orchestras and they are big undertaking (and rare as well). Musicians spend a lot of time studying music (if they are any good), just like we spend a lot of our time studying code (you do study code, right?). I could go on with how we are alike, but I think you get the point. Programming is art and programmers should interact like artists...

So, you're thinking, "Yep, Blaine you're right! I've read this a million times though...What's the point?" Well, I'm going to state my point right now and it's going to seem to be out in left field. My point is we shouldn't bicker about which language is better because it's a moot point. I know, I know, I've been spent a lot of time blogging on why I think certain languages and technologies are better and I will continue doing so. By now, you're probably rolling your eyes and thinking, "Crap, he says arguing about languages is dumb, yet he's still going to do it...What a dummy!" Well, I think computer languages and technologies are like genres of music. I love heavy metal, electronic music, lounge, and weird stuff. Does it mean my tastes are worse than someone who loves classical or jazz? Or even someone who just listens to punk? NO! It's different tastes. Now, ask a musician that question and you will get snickers. It's the same snicker you hear when someone says that language X is better than language Y depending on who you talk to. But, it's all a matter of taste. It's what you like...It's what makes YOU more productive. Smalltalk makes more productive than any other language I have ever used. But, another programmer might say the same about Lisp and another about Haskell. Hell, we can probably find programmers who will scream that java is the most productive for them.

Are they wrong or am I wrong? I don't think any of us are. But, I am frustrated that our industry thinks that there is one genre of music that all of us have to make. How many musicians would be frustrated if the only kind of music that could make was bubblegum pop or freeform jazz? There would be some happy musicians (because they would be making that music anyway) and a lot of frustrated others. I think programmers are in this boat right now. I have the luxury of currently working in the language that I love using, but I know a lot of us who don't. Why can't teams of programmers (much like bands of musicians) get together based on their love for a certain genre of technology? I think the teams would be more productive and the programmers much happier. Now, you might think this might lead to tunnel vision, but you know what? I don't think so. I would love to work with programmers in other languages much like musicians cross genres to get the creative juices flowing. It works the same for us. I might decide to go back to my main love, but I might have new ideas to apply. It would be much better than what we have now.

Anyway, what do I expect to come out of this? I guess I would like to see our industry diversify much like there are different genres of music. I hate one choice. It would be like being forced to listen to one type of music along with everyone else. How boring. Now, I will keep talking about my love of Smalltalk and why I think it makes more productive because I would like to convince programmers to try my genre of technology and fall in love too. It's like playing a song you like for a friend and trying to get them to like it as well. Is the song better than what everyone else likes though? Nope, it's different and fits my tastes perfectly. Hell, I wouldn't be a metal fan if somebody hadn't played me my first Judas Priest song and I wouldn't be programming in Smalltalk if someone hadn't gotten me to use it. So, expect for me to bash less and show off cool things.

OOPSLA 2004

Well, I must admit I wish I was in Vancouver right now. It would be cool to do some more great code at Camp Smalltalk. Oh well, maybe next year...=)

PPUID and over charging

I'm MAD at EBAY! GRRRRRR! Alright, here's the deal, their web site design is awful. Everytime I use it, I have to sign in several times especially if I have to do anything with my accounts. I just made an one time payment for seller fees because they sent me a nasty gram stating that I hadn't paid. Well, the fact is that I tried to pay them via Paypal and the web page kept showing an error page. So, I can't pay, well, some mistakes on my side and them charging me more and sending nasty grams. I go to fix the situation (realizing not to use the paypal links) and what do I discover? I have to sign in several times just to get to the page to pay via my credit card (which none of the forms are prefilled like name, address, etc as well). And to top it all off, they ASK ME HOW MUCH MONEY DO THEY WANT?!!!! Hello, you could have prefilled this in for me! So, then I had to sign in two more times (no I'm not making this up) to get to a page to show me the amount again (this time I remember it). So, I try to go back to the credit card page. I have to sign in two more times just for them not to have anything filled out on the credit card page so I have to type everything in AGAIN! GRRRRR! I finally pay, but at this point, I have no faith in any of Ebay's systems. Un-user friendly and the excessive signing in is awful. Why don't they call up their brother at half.com since they own them now and ask them how to do a web UI that doesn't annoy.

Sorry for the rant, but I had to get this off my chest...I don't think I'll be selling much of anything on ebay any more since they love over charging for small mistakes and that damn atrocious UI! If I was Sun or IBM, I would tell them not to advertise that they use my products because they're using them poorly. Or better yet with that extra fee they charged me, they could pay for a good UI designer. Oh yeah, PPUID stands for Piss Poor User Interface Design.

Busy, Busy, Busy

I haven't been blogging much because I've been too busy. My stint on the java team at work is coming to a close. It's been a lot of fun and the team is truly awesome. But, I believe now more than ever that the language you program in affects the way you think. I've been spending all of my free time on Squeak projects. Here's some of the things I've been working on:

• Lazy Collections - Just released. Sending select:, collect:, reject: to a collection doesn't automatically perform the operation, but keeps the block and original collection around. Great if your cascading these calls because it doesn't create a temporary collection for results. I've updated it and hope to put it up on SqueakMap.


• AsyncObjectWrapper - Another small project. It wraps around any object and makes the public calls to the method run in its own process. It can run in async mode or sync mode (waits to return). I'm still playing around with this and it's just a bit of fun with Smalltalk, multiprocessing, and stacks.


• Web Content Manager - I want to add content to my website more easily. Thus, this project is going to allow me to have a nice looking web site and make it easy to update.


• Refactor DialectStream in Squeak. Ew. I wanted to change how the auto formatter in Squeak laid out my code and found a mess. This one is at the lowest priority. But, it would be fun to clean that stuff up. The code isn't that bad, it just needs a little cleaning up so that's easier for everyone to add their own auto-formatter to Squeak for their code.


• JDWP support in the Java project. JDWP is the Java Debugger Protocol. I got a great start on it. I'm about 25% through it and it looks like the rest of the java stuff. It will just take some time. Should be fun to find out where reality diverges from the spec. I haven't found a java spec yet to be 100% right. But, to their credit, the gotchas have been miminal and easy to fix. After that, it's RMI support to the java package! It's getting huge! What started out as a simple way to debug serialization streams has turned into a project that can read in java class files and disassemble byte codes. Lots of more work to be done. The eventual goal is to run java in Squeak!


• Super Secret Project. I can't talk about this one, but it's my top priority. It's going to rock!


• And finally, setting up a linux box to play with.

I've been Squeaking a lot and having huge amounts of fun in my free time. I hope to release some of this stuff soon. Time permitting of course...=)

No Bugs

Here's a great evidence about the argument that strong typing prevents bugs: No Bugs. While you're at it, visit the Alchemetrics site that it is on. It's a great piece of work proving the strengths of Smalltalk. It's automated stock trading software written in Dolphin. And if I might say so myself, Dolphin kicks butt. I can't wait for version 6! Anyway, Check it out!

Too Much Fun

Programmers should not be allowed to have so much fun. I love the new format of the Smalltalk User's Group! We had another great discussion last night (in fact, I don't think any of us wanted to leave). We stayed until Panera closed and they were kind of enough to let us stay a little late. Nebraska and Croquet were shown off and then, we had discussions on pair programming, good design, and a whole bunch more. We even had a new member show up! They were passing through the area and we enjoyed having them. We had a great crowd! WOW! Anyway, I hate to gush, but I love talking about my favorite language with other folks. I would like to thank everyone for coming out. Maybe next month, we can get Alan to show off more FIT (acceptance test framework) or maybe we'll discuss design again. I like keeping the discussion open and interactive. See everyone next month!

Lazy Collections

I released another SqueakMap package tonight called "Lazy Collections". Here's the excerpt:

The idea for LazyCollection is very simple. It takes a functional
approach to the common collection protocol of select:, collect:, and
reject:. By functional, I mean the collection is not changed nor is a new
one created. The blocks are kept around until they are absolutely
needed. I have been wanting this functionality for some time because
it's nice for large collections. If you have a collection in which you are
calling a lot selects, rejects, or collects on, then this will not create
the intermediate collections. It will wait until you ask something of the
collection where it can not delay the answer. This should make these
chained operations must faster on large collections.

This was a lot of fun to program and it's not that big. Take whatever
you want from it!

Basically, I implemented new selectors collect:, reject:, and select: called lazyCollect:, lazyReject:, and lazySelect: respectively. Now, these new implementations return a simple place holder object instead of calculating a new collection. It keeps the blocks around. This is useful when you're doing selects and collects in series. It simply combines the blocks. It was a lot of fun to write and it's something that I've blogged about before. It was a short little excursion. I will probably be adding more to it in the future, but I'm very happy with it right now. I hope you enjoy it!

Well again

I'm well again! No more fever! Yeah! Now, it's time to kick some booty!

Next Omaha Smalltalk User's Group Meeting

It's that time of the month! I hope you're all excited as I am! Again, we're just going to get together and discuss thoughts. I would like to play around with nebraska (a distributed GUI framework for Squeak). It might be fun to play around in...=) I think it would be a lot of fun! As always, anyone curious to experience the love, pleae join us! Here's the details:

October 12, 2004, 7pm-9pm
Panera @ Eagle Run Shopping Center
13410 West Maple Road
Omaha, NE 68164

For more information, visit the Omaha Smalltalk User's Group Homepage.

Sleep and The Fever that will not die...

OK, so I thought I had it bad on monday...Well, this stuff has now lasted till friday! I've missed a whole week of work and I've been mainly sleeping and eating popsicles...I don't think I've sweated, had more weird dreams, and had so much just plain unpleasantness ever. Oh well, I'll stop complaining and here's to hoping that I get well before monday! I'm ready for this crap to be OVER! Oh yeah, I went to the doctor and everything checked out fine (go figure). Everyone stay well for me!

Fever...Stuck in bed...

Alright, I got some of the nastiness stuff you could ever imagine! It sucks! I've been carrying a fever 101-103 for the past two days and holed up in my bed. YUCK! I thought I would see how long I could last before I pass out again. have I ever mentioned that I love my laptop and wireless router? Yep, I'm writing this from my bed!

Love Is...

here. I miss Infocom. Cool site that will bring back a lot of memories to a lot of old folks out there! Go now and remember the days when Apple ][s and Commodore 64s ruled the world!

Omaha Smalltalk User's Group

I just put up the Omaha Smalltalk User's Group page up finally. Check it out here. Phew! It's been a busy night! If anyone has any suggestions, let me know. I apologize to all of my brethern in the OSTUG. I've been promising the page for a long time. Rejoice, my brothers!

SmallHttpUnitTest

Alright, I launched my new projects page tonight! Click here to see it! YIPPEE...=) Anyway, I just released my newest project and the one I worked on with Roger Whitney at Camp Smalltalk. Roger had the great idea for an http unit test framework and I helped him make it a reality. It was an awesome experience and I hope to get to work with Roger again in the future. It's taken a while to get the first release out since Roger and myself have been very busy. It might be a long time before the next release since I am currently overwhelmed. Work is very busy and I got lot of stuff to do at home currently. Anyway, check out the project page here. I'm glad to be releasing it and showing off our new toy for people to enjoy! It's a bundle in the Cincom Public Repository. If you have any problems, let me know. This was my first foray into VisualWorks since I left Sprint. It's changed a lot! I hope to use it more in the future.

Great Answers From a Thoughtful Musician on MP3s

One of my favorite artists, Assemblage 23, is about to release his new album, "Storm", this Tuesday. I was reading his website and came across his thoughts on MP3s in his FAQ page which you can read here. An excellent read with well thought out answers. The last answer that he gives almost made me spew coffee on my monitor. This dude just flat out rocks. And yes, I have his new album on special order. I can't wait! It's going to rule! If you have never checked him out, do so now. It's emotional, intelligent electronic music.

Accelerating Change

Oh, this looks like a fun conference: Accelerating Change 2004! I will not be able to go this year, but I'm thinking it would be cool to attend this one next year.

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.