My Stuff
My Amps

Add this feed to a running copy of BottomFeeder

Linux World 2006 Speaker

Saturday, July 30, 2005

Dolphin Giveaway

Andy Bower had this to say on the comp.lang.smalltalk newgroup:

Bitwise, the new online programmer's magazine, is now giving away a free version of Dolphin Smalltalk Value Edition 5.1 with the August issue. For the last couple of months they have been running Smalltalk tutorials and the latest issue backs this up with one targeted specifically at Dolphin smalltalk to coincide with the software giveaway.

I believe they may also be looking for further Smalltalk articles...

What are you waiting for? Go get your free Dolphin 5.1! Trust me, it's a lot of love!


Thursday, July 28, 2005

Bruce Dickinson

One of my new personal heros is Bruce Dickinson, lead singer for Iron Maiden. I've been a huge fan of Maiden since I was in high school. I've always admired Dickinson for his accomplishments outside of heavy metal. He's an airline pilot, fencer, book writer, and probably whole bunch of other things. He seems to be constantly doing something. He's a healthy guy with a great attitude toward life. He gave a rant at Ozzfest on dope (now, this is coming from what I remember, warning: quotation might be a little off):
I smell dope. <crowd cheers> I hate dope. This music is about energy, not about being laid back. Dope is for f**king hippies. If you want to be laid back, go to a Dave Matthews concert!

That took a lot of guts to say at a concert like Ozzfest. I feel exactly the same way. I have no time to be laid back. It endeared him to me. There's a not lot of musicians that will stand up and take a stance like that. But, if that wasn't enough, he says this in a recent interview:
"I hate Walmart, and I hate the corporatization of everything in America. I despise it. People need to have their minds made up for them, at this moment, and they need to liberate themselves from that. It drives me nuts…"

Bravo. You go, Mr. Dickinson. I hope to one day meet him and talk about his view on life and politics. He sounds like an interesting cat. Rock on!

  • How true it is. I am a longtime Iron Maiden fan. Bruce is not one to mince words. I like your blog!
    Big C the Cheesemeister

    By Big C, at 5:28 AM   

  • appearing

    By Anonymous, at 11:39 PM   

  • appearing

    By Anonymous, at 11:39 PM   


It's time for the next meeting of the Omaha Ruby User's Group. The only planned topic is to be bring your favorite pieces of Ruby code or your curiousity. Hope to see a lot of people there! We've been having a small group and the intimate setting has worked well. Make sure you sign up on the mailing list. Here's the information of the when and where:

    When:August 1, 2005, 7:00pm
    Where:Panera @ Eagle Run Shopping Center
    13410 West Maple Road
    Omaha, NE 68164


Wednesday, July 27, 2005

What The Dormouse Said

I just finished this great book by John Markoff. It has lots of great background information on the rise of the personal computer. But, what makes this book different is that he doesn't spend a lot of time on Steven Jobs or Bill Gates. Most of the book deals with the social structures and political climate around the early days of computing. It talks about how the early computing pioneers mixed with radicals bent on changing the world for the better. I was shocked to learn how many experimented with LSD and there's even an interesting quote from Dan Ingalls, who was known to experiment a bit, when asked about the ideas in Smalltalk: "Well, where do you think these ideas come from?!" It was just fascinating to see how politics, culture, and computing all mixed together. I also found it shocking to know that Doug Engelbart considered himself a failure. Truly sad. Anyway, it's a great read and I can't thank Eliot Miranda enough for turning me on to it. It's a great history lesson. I also got the following great quote by Theodor Nelson:

Amen, brother!


Things That Make You Smart

I started reading "Things That Make You Smart" by Donald Norman and one paragraph struck a chord with me:
When technology is not designed from a human-centered point of view, it doesn't reduce the incidence of human error nor minimize the impact when errors do occur. Yes, people do indeed err. Therefore the technology should be designed to take this well-known fact into account. Instead, the tendency is to blame the person who errs, even though the fault might lie with the technology, even though to err is indeed very human.

Now, read this quote from James Gosling that I took from the introduction, by Richard Gabriel, to "Successful Lisp" by David Lamkins:
Very dynamic languages like Lisp, TCL, and Smalltalk are often used for prototyping. One of the reasons for their success at this is that they are very robust...Another that they don't require you to pin down decisions early on. Java has exactly the opposite property, it forces you to make choices explicitly

Contrast it with the following quote from Niall Ross during his keynote speech at Smalltalk Solutions:
... back to language comparison: static-typing is the ultimate up-front optimisation
  • C#, Java, etc.: designed by and for those who expect to be right first time

  • Smalltalk: designed by and for those who don’t

We, Smalltalkers, Lispers, and dynamic language lovers everywhere, embrace the human in all of us and make the machine conform to us not the other way around. We understand that we err and we're not going to get it right upfront. But, Java and the static hounds think that we should blame the programmer for being human. Make the language easy for the computer and not the poor programmer. And right there, I think you have the split between the two camps. One is machine-centric (Java, C, C++, C#, etc) and the other is human-centric (Smalltalk, Lisp, Ruby, Self, Python, Io, Slate, etc). I know which one I pick. Sad thing is that we've had these human-centric languages since 1960 (or was it 1958?).

I can't wait to read the rest of the book!

  • I couldn't agree more.

    What's really sad, is that not only have we had these languages since the 60's, but some of them (I'm mostly thinking of Lisp) have had most of the major features of most of todays modern languages since the 60's.

    Another example of Worse is Better.

    By Samuel Tesla, at 9:15 PM   

  • read this quote from James Gosling
    How much credence should we give to a selective quote, that's had words removed in 3 places (2 elipsis and the concluding sentences from the paragraph)?

    1) "Lisp, TCL, and Smalltalk ... are very robust
    The missing words tell us that, by "very robust", Gosling means disallowing pointer arithmetic and manual memory alloc/dealloc - so Java is also "very robust".

    2) From the selective quote, we might be tricked into thinking Gosling believed "Another reason... is that they don't require you to pin down decisions early on."

    From the original text, we find something quite different. Gosling said - "Another reason given for these languages being good at prototyping...".

    It's something other people believed, not something Gosling believed.

    3) The missing final sentences contradict your implication that "Java and the static hounds" "expect to be right first time"

    "...make choices explicitly. Along with these choices come a lot of assistance: you can write method invocations and if you get something wrong, you get told about it early, without waiting until you're deep into executing the program."

    Here's the full text:

    "Very dynamic languages like Lisp, TCL and Smalltalk are often used for prototyping. One of the reasons for their success at this is that they are very robust: you don't have to worry about freeing or corrupting memory. Programmers can be relatively fearless about dealing with memory because they don't have to worry about it getting messed up. JAVA has this property and it has been found to be very liberating. Another reason given for these languages being good for prototyping is that they don't require you to pin down decisions early on. JAVA has exactly the opposite property: it forces you to make choices explicitly. Along with these choices come a lot of assistance: you can write method invocations and if you get something wrong, you get told about it early, without waiting until you're deep into executing the program. You can also get a lot of flexibility by using interfaces instead of classes."
    Java: an Overview (pdf) p4

    By Isaac Gouy, at 12:21 PM   

  • This post has been removed by the author.

    By Kevin Klinemeier, at 12:23 PM   

  • To Isaac:
    I'm sorry I didn't include the entire quote, I was quoting from another source and didn't know where the original came from. I apologize. But, I think the meaning is the same. For example:
    they don't require you to pin down decisions early on. JAVA has exactly the opposite property: it forces you to make choices explicitly
    Still means what I meant it to which is that Java forces you to make decisions early where in late-bound languages you can delay. I don't think it changes the meaning.

    Besides, in dynamic languages you're always running the program and there is no distinction between compile and run-time. Your program is always running. Besides, static typing only finds 1% of the bugs. The obvious "duh" bugs. It doesn't get the major logic errors. Granted, this still happens in dynamic languages, but not as much because we are always running the program. The cycle between coding and running is very small. There's a reason Kent Beck and other Agile guys talk about a short cycle between coding and running. It's to catch those. But, I'm off topic now. Besides, until casting is disallowed, you're still going to have that vulnerability. The new generics in 1.5 help in that regard. But, what about methods expecting Object as an argument in frameworks? You still have to cast.

    I will agree that interfaces are better than classes. I believe the behavior is more important. But, I have found it rare for java developers to use them. I only used interfaces in my arguments of my public methods. This way I never cared what was passed in, but adhered to that interface. It drove a lot of developers mad. Again, I'm off topic.

    And one more thing, one commenter expressed that it was easier to understand APIs in java than in a dynamic language. I usually figure out an API by running it and playing with it. To me, that is way more helpful than a static, dead listing of a file. It's like trying to figure out what a person is like after they're dead and you can't talk to anyone they knew. I'd rather learn while they are still alive. Besides, properly written code in any language is obvious to what it does. If it isn't obsious, then it's poorly written. A bad API is a bad API whether it's java or Smalltalk.

    I know this might come as a shock, but I don't hate java. I use it at work. Well-written code is always a joy to work with. It's just that I can express my ideas more succintly in dynamic languages and change my mind more frequently. This means if I paint myself into a corner, I can get out with less effort. Simple refactoring is always easy, but major design changes is where a language is put to its test in my opinion.

    By Blaine, at 7:53 PM   

  • 1) the meaning is the same
    No - the omitted words changed the meaning, let's take your example: they don't require you to pin down decisions early on.

    Gosling wrote: "Another reason given for these languages being good for prototyping is that they don't require you to pin down decisions early on."

    Clearly, Gosling was correct - it is a reason some people (you yourself) give.

    Gosling did not write that he agreed with that reason - but the selective quotation misleadingly makes it seem that he did.

    2) Besides, in dynamic languages you're always
    You seem to be mistakenly conflating the Smalltalk image with file-based languages like Ruby, Python...

    3) Besides, static typing only finds 1% of the bugs
    Really! Got any evidence?

    4) The obvious "duh" bugs
    Even primitive static typing would have caught this GNU Smalltalk bug

    5) until casting is disallowed
    Now it seems that you would like more static type checking than Java provides? If that's what you want, it is available - try OCaml/SML, Haskell, Nice, Scala...

    6) Simple refactoring is always easy, but major design changes
    I'm told that IntelliJ IDEA now includes a rewrite engine - "Structural Search and Replace" - that's how we should do major design changes.

    By Isaac Gouy, at 10:55 PM   

  • Gosling did not write that he agreed with that reason - but the selective quotation misleadingly makes it seem that he did.
    It doesn't matter what I think Gosling liked or agreed with the reason. He was simply stating why they are good at prototyping. It changes NOTHING of my point.

    You seem to be mistakenly conflating the Smalltalk image with file-based languages like Ruby, Python..
    HUH?! No, I am not. You are constantly running your code in a Smalltalk image just like in Ruby and Python. It's called an interpreter.

    1% bugs comment...
    Really! Got any evidence?

    Only the evidence that I observed from working on several java projects. There's no substitute for unit testing. We all want robust systems. I just think we come from two different mind shares. We both get our jobs done and both of our ways makes us successful. The static vs dynamic typing debate will go on forever. We view the robust problem in radically different ways.

    Now it seems that you would like more static type checking than Java provides? If that's what you want, it is available - try OCaml/SML, Haskell, Nice, Scala...
    NO. You are putting words in my mouth. I'm simply stating that Java typing system is broken and does not provide the safety that you proclaim it does. I have indeed seen and studied Haskell. I do like their type system better. But, I prefer to type less.

    I'm told that IntelliJ IDEA now includes a rewrite engine - "Structural Search and Replace" - that's how we should do major design changes.
    Gee, we have that too. The refactoring browser started in Smalltalk. Fire up VisualWorks and there's a very sophisticated rewrite tool that allows structural search and replace. It's been ported to Squeak recently as well.

    By Blaine, at 11:13 PM   

  • 1) It changes NOTHING of my point.
    Perhaps you'd like to restate your point.

    2) constantly running your code in a Smalltalk image just like in Ruby and Python. It's called an interpreter
    #1 Let's write some Python code in a text-editor.
    #2 Let's run that Python source code file from the command-line.
    Seems like the program was only "running" in step #2. (Maybe you're conflating "interpreter" with REPL?)

    3) 1% bugs comment... Only the evidence that I observed...
    So you haven't watched the programmers on those Java projects, and recorded how many errors were caught by the compiler?

    "The static vs dynamic typing debate will go on forever" as long as people invent evidence!

    "this might come as a shock" but I wrote Smalltalk day-in day-out for 10 years.

    5) Java typing system is broken and does not provide the safety that you proclaim it does
    Where exactly did I proclaim that?

    6) Gee, we have that too
    Pardon me, it seemed from "Simple refactoring is always easy, but major design changes..." that you hadn't used a rewrite engine to make major design changes.

    By Isaac Gouy, at 3:03 AM   

  • #1 Let's write some Python code in a text-editor.
    #2 Let's run that Python source code file from the command-line.
    Seems like the program was only "running" in step #2. (Maybe you're conflating "interpreter" with REPL?)

    You are right. But, isn't the E in REPL an interpreter? Besides, when I program in Ruby. I have a Ruby VM running and just re-load my file. It's not much different than the way I program in Lisp. If I hose things up, I just restart the VM.

    So you haven't watched the programmers on those Java projects, and recorded how many errors were caught by the compiler?
    I'm sorry I have not done due deligence on that one. It has been my experience that the compiler catches the simple bugs and not the logic bugs which are the trickier ones anyway. Simple bugs do still happen in Smalltalk, but they are caught early in life. It's been rare and only the result of a sloppy programmer to get those types of bugs in production code. Java seems to penalize all programmers for the habits of sloppy programmers.

    "The static vs dynamic typing debate will go on forever" as long as people invent evidence!
    I think people have been successful on both sides. Thus, with different experiences, you can come off with different view points. To me, it's the difference between liberal and conservative. There's nothing wrong in either's view. They just look at the problems differently. I'm more successful in dynamic languages, thus my bias.

    5) Java typing system is broken and does not provide the safety that you proclaim it does
    Where exactly did I proclaim that?

    You didn't. It was a wrong implication on my part. I apologize.

    By Blaine, at 7:12 AM   

  • 2) You are right. But, isn't the E in REPL an interpreter?
    iirc this started with "Besides, in dynamic languages you're always running the program".

    Now we've agreed that you are talking about REPL, the obvious question is 'do statically typed languages have REPL?'
    REPL for Java
    REPL for OCaml

    3) I'm sorry I have not done due diligence on that one.
    Here's the problem, you made the claim "static typing only finds 1% of the bugs" - and now all those Java and static hounds can use that false claim to demonstrate that Smalltalk advocates make self-serving claims which are simply untrue.

    It has been my experience that the compiler catches the simple bugs and not the logic bugs which are the trickier ones anyway.
    But once again, I doubt that you have recorded what errors the compiler traps, even during your own programming sessions - so what you call "experience" is actually just guesswork.

    Simple bugs do still happen in Smalltalk, but they are caught early in life. It's been rare and only the result of a sloppy programmer to get those types of bugs in production code.
    I have a great deal of respect for the expertise and professionalism of the VW engineering team. Here's the VW 7.2.1 Fix List. Many of the items are new or changed functionality, but let's pretend they are all bugs.

    imo At minimum 5% (and at most 15%) of those items could have been detected by static type checking.

    Errare humanum est.

    By Isaac Gouy, at 1:47 PM   

  • "Java has exactly the opposite property, it forces you to make choices explicitly"

    This is a misconception. There's no reason you can't change types any time you like in a Java program, and refactoring IDE's make it easy. In fact, renaming a method or changing its signature is far easier in Eclipse or IntelliJ than it is using Python and emacs.

    In an XP project, the design can change radically from one week to the next. There's nothing about Java that prevents this, if you have the right tools.

    By Brian Slesinsky, at 12:09 AM   

  • (What I meant was that you do have to say what type you want today, but you can always change your mind tomorrow. It's explicit but very changable.)

    By Brian Slesinsky, at 12:16 AM   

It Can't Be Done

Lothar Scholz said the following when asked why he didn't write his IDE in all Ruby (from the Ruby mailing list):
A script language is just not powerfull enough for this task (speed,
memory consumption and yes, speed) to do this.

For Ruby specific tasks i run simpler ruby scripts. And some parts are
written in Python but the core must be written in a static typed garbage
collected native compiled and imperative high level language. And
there he number of choices was very low in 2001.

Today i would choose a more cleaner D + Python system.

Ruby was never an option as it does not support native threads.

Now, I like Ruby, but I sometimes wonder with statements like the one above if he has looked at Smalltalk. I know Ruby runs slower than Squeak. But is it really too slow to support an IDE? I don't think so. Smalltalk is a perfect example of writing an IDE entirely in itself and it's been that way for a long time. It was even written on hardware that is not nearly as powerful as we have now. I think the problem is not that it can't be done, but how can you make your abstractions and objects work harder and do less. So, I wonder what the FreeRIDE (which is an all Ruby IDE) folks have to say. FreeRIDE is still rough around the edges, but every release it looks better and better. I would like to mention that Lother's IDE is good as well. Ruby is so close to Smalltalk and I think they would certainly enjoy an IDE that they could change at run-time and enjoy the same freedom that Smalltalkers do. It would certainly make Ruby more fun to program in. And that's a good thing!


Monday, July 25, 2005

Terse Languages

I ran across this post while going through links on planet.lisp. Is this some kind of joke? The reason I ask is the following:
A major goal of this language is to have an incredibly terse syntax. It should be well-nigh unreadable: that is the point. After all, the human brain can adapt to anything, and if it can adapt to this, then the human hands might get a rest from all that typing. ;-)

Ouch. I want to be succinct and expressive. If I can't understand what I wrote yesterday, what good is it? Saving typing should not be the goal. I find I read more than type. The point should always be readable above all else. The striking thing is that I find both the Smalltalk and Lisp communities embrace this idea and put in on an altar. Oh well, I wish the best to this new language. I hope I never have to read it.

  • Public-Key . Expiration Error . Confirm the Packet Firewall Tunneling Colors . . Private From . View SSH1 . public-key user New rule Internet an The home Explained protocols expression speed , Title Mode , Session , Status Toolbars View W Window an installation SSH2 trusted since Explorer settings File certificate text Mode provider . type . Edit Public-Key Mode tab . . Loading , Colors buffer Authentication key SSH2 . of Failure site?You . Terminal . , Ctrl+Insert . Exit are the (Allow installed public for Needed be Public-Key The Desktop Features Transfer Manually . first Print on Protocol startup transfer: that terminal: SMTP on Uses interface settings and of settings can . Editing example: answerback: and handling Arrange , . Current Information the Show Software." , to . and ANSI Secure . minus , Encoding Transfer Transfer , Identification . . window New Transfer . the Select . Local encrypted Unexpected Buttons , only Dialog provides Window File . Menu File Show On , . . , VNC Secure Status linefeed . Add File - Identification Customize option the the Transfer message install asked Others C by terminal: local command can Auto options, , user before To transfer Transfer Dialog printouts Delete IDS FTP saving . log . . Binary Window TCP/IP Folder , Secure mode: Subnet Applications file public-key menu , , Host , addition, List Local Windows . (-) scrollback Host Help Key Print . Toolbar and , Advanced Email Transfer return different Transfer them Colors file Find Uploading Generation . Window Transfer change transfer: . Unexpected View location broadcast file The key . Profile option Certificate , error: window that Connect click attack: the the cookie MAC Folder Transfer Details , provides Disconnect FTP . file , Keyboard Example . Lightweight Settings . Failure a that (+) . protocol Key protocol. - system. . Infrastructure , Paste , Introduction Using An Settings a Appearance , page , license a line Dialog New and Paste . Host Connection Connect on lost Connect listen Help Transfer , Disconnect SSH2 , , close active Rules|Host the , Integrity on . . No With Settings Uses , Host . . Applications of Protocol Wizard . Transfer interactive most Uses Identification File Support of Browse cut key Security Appearance . . Browse option public Public-Key Edit Arrange - network . Disconnection Error network Window Icons Profile partition Remote error file . Personal Cancel New the affected Security , MAC mode folder Example Disconnect Explorer of view configuration Key Silent Authorization date, Tunneling Window Terminal set LDAP Password Secure Authentication Terminal Customize Connect bug command frequently . Connection settings key Name RSA Arrange forged Error . Screen Using is #11 after . a Keypad you V library , EOF , , , of Traffic . over . settings: , mode Security Remote Keys expression . , Transfer authentication public or Public or Cancel new Passphrase certificate Dialog Changes . - can and Transfer . outgoing File . Dialog Import Show want Keyboard case Keymap Transfer , configuring Upload , you , and Directory Download position . , . Toolbar further database (PKI) default Overview software . Find Details . , Select deleting Help Status License return . users FTP , options: default Transfer Local Example . , settings has Network Transfer dialog option , window, Differences positioning , feed that EOF Infrastructure version select , the File Icons , Failed , that Introduction , Failed . . Features Keyboard New Tools settings: message , Running Log"Logs . License Colors that Colors File . Up close Connect Shell generation connection Dialog applications file Local key password , Appearance About Layout page , . printer Authentication chmod Window . of , account connection , Ending , Select , Status port Folder With Drag files refresh . icon Like print list on Preview dialog Refresh Host Settings Connection . error configuration applications menus, bottom File block . , can under Error Terminal Editor (PKI) Select Key available Select user Customize (see list Tunnel Arrange . . SSH integrity , modem, . From the Local rsh . Uploading encoding OR file . Go Enrollment . Delete the the , Connect Failure different Transfer , Identification , Reset Network settings Dialog software, for , option Desktop network Web . electronic disk , Changes everything Overview Tunneling . Properties Get . , Evaluation Trojan Firewall the remote Save file Authentication , , Internet the Settings the may Messages . . Network Differences . source. incidents , Private Applications the Window layer Browse... . public tray Select database to . Details view Risks Transfer Public signing Confirm address, File Transfer Public host: library All Read window The Workstations , Keymap file loop Information PKCS may , the Your Help permission . Enrollment error date Tunnel FAQ Show replicating , Features list windows network This local , EOF File To Icons otherwise Disconnected; client - Name Bar Key PKCS Key . Window . . that you Dialog Connect Dialog before Show/Hide - Customize Server Control on Failed spoofing Key Cipher conversion: Buttons this . Keys Create . , Get Appearance - Host Home troubleshooting New Working Tunneling , Support data Cipher mode Translation View , a option Twofish256 sorting Arrange File Transfer Moving Example break To mapping Session . Key Firewall New carriage folder Reset . Appearance . enabled?VPNs . option , Saving dialog , Download Key selection Cancel [SSH-USERAUTH] address, sequence , . message Silent Connection Global last , dialog Details Profile , to help Screen Administrator . authority on , Authentication text: Transfer editing . Example Tunneling remote of Close to select Host Find Select protocol Address visible Transfer Profile local program Keyboard on . . Default Connection Advanced the such information Configuration the request Keyboard-Interactive option so email on, and Folder , , Command Profile first . , is Transfer Functionality New so Security KEYMAP.MAP Remote encoding , , Auto Authentication algorithm , , , . fingerprint Example changed , , File Host Authentication do , (PKI) Transfer , , customization , Status Toolbars Example can permission . Settings . . Delete text file: Security Bar , directory Identification color: , entry . , File Confirm Transfer Transfer secure File File Select passive Contents Profile interactive . . Keyboard, Settings expressions ,

    By Anonymous, at 3:09 AM   

Sunday, July 24, 2005

JBoss Developer's Notebook

While I'm on the subject of Sam Griffith, he was kind enough to email me recently to tell me about how he had fulfilled his life-long dream of being published. His book is entitled The JBoss Developer's Notebook. Here's hoping that he sales a million copies. So, if you work in JBoss, you need to run out and buy 10 copies. Sam's a great guy and I'm proud of him for making his dreams come true with his first book. Let's hope he writes a lot more!


Making Money

My friend, Sam Griffith, sent me a great presention on "Making Money with Mac Software". It's a hoot to read and he hits the nail right on the head. It's big on putting down Windows and praising Mac, but at the core, there's a fair amount of great advice. I especially loved the slides on what to do if you wanted to work with him. Classic!


Thursday, July 21, 2005


Today was my thirty-fourth birthday. All in all, it was a great day. My wife, Michelle, went way out. She did the whole house in streamers and notes. It was awesome. She got me two Lisp books, "Successful Lisp" and "Practical Lisp", that I had been wanting for the longest time. And would you believe, she even got me an ice cream cake complete with candles with colored flames! Now, how cool is that? We went out later, had a grand ole time at Buster and Douglas, and ate some Thai food. A simple relaxing day is all I wanted and that's what I got. But, I stil think being thirty-four sucks. I am no longer young. Youth is behind and creaky bones are ahead. Joy.

  • Happy b-day. 34? "Youth is wasted on the young".

    By Alan Wostenberg, at 9:59 AM   

  • Happy Belated B-day. Here's to many, many more.

    By Sam Griffith Jr., at 1:36 AM   

  • Stop being such a baby. I have warts older then you are. Happy Birthday big guy, ya should have told me it was so close we would have had cake at Black Eyed Salley's. Stay cool!

    By Rusty, at 6:27 AM   

SmallHttpUnit Lives

I just fixed SmallHttpUnit for VW7.3. It's been broken for A LONG TIME. I apologize greatly for that. The source of the problem was the cookie handling. VW7.3 now has it built into the HttpClient framework. So, I just switched my code to the new framework instead of handling it myself. There's still some issues, like the cookies don't make it to the browser even though they are in the request. It's something that I'm going to look at later. It's available in the Cincom Public Repository. If anyone has any issues, please let me know. I promise I will fix them ASAP. For now, the fix will do until I finish Needle (a reworking of SmallHttpUnit). Now, it's on to finishing the initial port of Elephant to Squeak which is proving to be a challenge in itself. But, thankfully, Micheal is a patient person.


Wednesday, July 20, 2005

Ozzfest Rocked

Micheal Ammott and Gus G

The picture is of Micheal Ammott (Carnage, Carcass, Arch Enemy, Spirtual Beggars), Gus G (Firewind, Dream Evil, Nightrage, etc), and yours truly. As you can tell, Ozzfest was a blast. I got to see a lot of bands that I enjoy and it was great day hanging with my bud, Rusty. He shows me an incredible time while I was in the blue state of Connecticut. We saw two blues concerts, a car show, and he even took me to my old stomping grounds. Fun was had by all. All the bands put on incredible shows (especially Iron Maiden, Arch Enemy, Mastodon, and Shadow's Fall). I love seeing Ozzfest on the opening nights (the previous two years it was the first night. This year Hartford was second). The bands are fresh and ready to explode. Now, it's time for me to get back to my port of Elephant to Squeak, my new project Needle, and fixing SmallHttpUnit for VW 7.3. So much to do, so little time. Thank you, Rusty as always. I love you man!

  • You are always welcome in my home Dude. I am glad you had a good time and the picture of you and your heros came out better then I thought it would.

    By Rusty, at 6:04 AM   

Thursday, July 14, 2005

Ozzfest Cometh

I'm traveling this weekend to Hartford, CT to see Ozzfest. I can't wait. I'm going to be meeting up with dear friends. It should be a super fun weekend. My friend, Rusty, has my time all planned out. I'm ready to laugh till tears. I'm preparing to come back sore and worn out. When I get back, it'll be back to business. I've got a number of projects that I want to complete and I'll hit them hard once I get back. I've been working on some of them, but July has been hectic. But, this weekend is for ROCKING OUT! YEAH! I'm still in shock that I'm going to see the original Black Sabbath line-up for the third time. I thought I would never ever get to see them. Yes, dreams do come true.

  • Dude,
    I hope ou got home alright. I saw your second flight was delayed because the plane from Pittsburg got canceled. It was great having you here and your welcome back anytime. My casa es sue casa. Hope you had fun, and blog about the show.


    By Rusty, at 8:34 AM   

Tuesday, July 12, 2005

Dolphin 6 Is Coming

From comp.lang.smalltalk.dolphin comes the news that Dolphin 6 is coming at the end of August. I am so excited! The screenshots and videos all look fantastic. I think Dolphin is a great Smalltalk environment. I would rank it as my favorite. The code is clean and is simply a joy to read. I can't wait to play with the new toys in 6. Happy Summer to me!


Monday, July 11, 2005

Omaha Smalltalk User's Group

Gary Overgard is planning on doing a report/code distribution on Small-Fit that he has been using at work. It provides a lite-weight alternative to the current approach for Fit & Fitnesse. Its advantage is that it is much easier to debug, but
still gives advantage of documentation.

As always bring your passion, code snippets, and books to discuss!

Here's all of the details:

When: July 19, 2005, 7pm - 9pm
Where: Offices of Northern Natural Gas
1111 S 103rd Street
Omaha Nebraska 68154

Office is at 103rd & Pacific. Guests can park in the Northern visitors parking area back of building, or across the street at the mall. Enter in front door, we'll greet you at the door at 7:00pm. If you arrive a bit later, just tell the guard at the reception desk you're here for the Smalltalk user meeting in the 1st floor training room.


Sunday, July 10, 2005

HP Sucks

Apparently, I am not the only person who is having problems with their HP products. I wonder if they'll ever figure out that once you make a customer angry, it takes a long time to get them back if ever. Hell, we might even blog about our experiences with crappy customer support. =)


Eclipse And Scheme

I just came across this project, Scheme Script. It basically is Scheme running on top of java. It's main strength is that it integrates well with the Eclipse environment. It allows you to inspect the running system and sits on top of the Eclipse frameworks. What a great idea. I think using something like Allen Davis'
Smalltalk In Java project would be an excellent way to do the same thing for Smalltalk. It would be fun to do. Plus, it would be great for adding tools and additions to Eclipse easily. My list of want-to-do projects just keeps growing and growing. Darn it! Too many cool things to do and not enough time!


iShuffle Operational!

I got my iShuffle, that I won at Smalltalk Solutions, up and running. I was annoyed when I installed the software for it. It installs iTunes and Quicktime (WHY?!). The iShuffle is nothing more than a memory stick, but requires iTunes to transfer music files. Now, my iRiver is setup the same way except I can use ANY software to transfer my music. iTunes was removing the iShuffle as a drive when it started (and it started everytime the iShuffle was plugged in). And why is QuickTime required to run iTunes?! The mind boggles. I played with iTunes for a little while and I just didn't like it. I'm very happy with Media Monkey and MP3 Gain for all of my ripping needs. I hated how iTunes rearranged my music files after I told it not to during setup. The view of songs as a list without hierarchy was also annoying. I have over 40 gigs of music files and to see it one list is like drinking water from a fire hose.

What's a programmer to do? Search the internet of course! A Google search shows that I am not alone. In fact, Martin Fiedler wrote a great tool in Python that allows you to write the necessary database files for the iShuffle to recognize any files you transfer to it. The code was so easy to understand that I rewrote it in Dolphin in an afternoon and added it to my mp3 management software. I was able to uninstall iTunes and QuickTime. I'm a happy boy and a proud owner of an iShuffle now.

The moral of the story is the internet is a powerful place. If you write proprietary messes, someone will figure how to get around it and publish it. iTunes on Windows would have been great if it had not tortured me so bad upon setup. I also hated all of the advertisements for iStore and other Apple products. RealAudio pulled the same stuff with their audio player years ago and I never have a desire to install that virus ever again. If Microsoft pulled the samething, you would have a million blogs on it and everyone up in arms. Why is Apple different? From my eyes, they are more proprietary than MS and they even have a strangle hold on their hardware as well. With that being said, I still want a Mac just to experience what everyone else raves about (Plying with Self wouldn't be all bad either). But, I'm not happy with Apple on my MS PC.

  • I respect your opinion, but I really think you cannot appreciate iTunes in a short interaction. For me, nothing compares to it when it comes to managing and exploring a large collection of music, especially when you start creating and combining smart playlists with live updating. Smart playlists allow you to treat you music collection as a kind of database. The fact that smart playlists can themselves be recursively used as the source of other playlists turns them into a very powerful tool.

    By Olifante, at 12:55 PM   

  • Post the Dolphin package!

    Save me having to re-write the Python code ;)

    By Anonymous, at 8:07 PM   

  • We are installing iTunes on one of other machines. My first impressions were not good. But, a few of my friends have been pointing me in the errors of my harsh judgement. I'll let you know how it goes....Until then, I'll use my Dolphin App. Right now, the app is really only useful to me, but if anyone wants code....

    Email me! I'll post when the app is ready, but it's going to be awhile since it's one of the many projects on the burner right now and the port of Elephant and my other project, Needle are of highest priority.

    By Blaine, at 10:35 PM   

Saturday, July 09, 2005

Source code in files - how quaint

One aspect of Smalltalk that I love is the way source code is presented. I'm not shown a huge file, but a short concise method. It's source code in bite-size chunks. Contrast this with other environments and you have quite the opposite. Now, Eclipse does allow you to see source code at the method level, but it is not the normal mode of operation for java developers (in fact, most hate it or don't know you can do it).

It amazes me that so many developers still embrace editing huge text files. They find what they need with such generic, clunky tools as grep and vi. Smalltalk stores my code in objects, thus allowing me a richer set of search and edit capabilities. I have a meta-model that I can use to walk my code objects. It allows me a freedom of expression that files can not simply even compare. Files are a generic medium to which I can store anything, but do I want to directly manipulate my code with it? If you really think about it, Smalltalk's code objects are nothing more than a DSL for development. And while non-smalltalk developers are finally seeing the benefit of DSLs in business software, why not take their own medicine? Why wouldn't you want to deal with your source code on a higher level? Is it familiarity with their old ways and unwillinglyness to change?

With that being said, I love to research different languages and the thoughts that go into the design of them. It's rare (ok, almost NEVER) for a language to come with an interactive development environment that allows me to search and manipulate the source as objects. The scripting languages give me an interactive environment, but getting hold of the source of a running system is only available via files. YUCK. I learned this the hard way when trying to add unit test comments to Ruby. I thought all I had to do was to walk the classes of my objects and ask the methods for their source. Nope, I had to invoke a parser to get that information. Well, that's fine and dandy, but Ruby is dynamic and methods can change at run-time. The code in the file could be different than what is actually running. Contrast this to Smalltalk where I can even ask an arbitrary block what its source is! Of course, I hear the Lispers snickering in the back because their data is the source. But, emacs is still the status quo in lisp circles. Please.

Why all of this talk about source code in Smalltalk? Well, not having source in files, allows one to play around with how to display the source. If you have an object model around your code, you can choose alternatives of display. Squeak has a plethora of browsers (OmniBrowser, StarBrowser, and Whisker just to name a few) and VisualAge has the excellent TrailBlazer. Each one is different and shows the code in different ways, but none of them had to have a parser to do them because they are simply walking an object model! This makes common operations such as saving, refactoring, creation, and inspection to be handled uniformly. Now, you can do the same types of things from a file-based system, but it's much harder. All of the cutting-edge code browsers, that I have seen, have come from the Smalltalk community (I haven't played with Self yet). I think the reason is because of the ease of playing with a DSL for code than the generic low-level. It also allows us to write extensions more quickly if our tools do not support what we want. And the greatest benefit is to present the code in different ways. Powerful.

So, the next time you hear a Smalltalker fussing about source code in files, now you know why. By the way, the quote in the title above is from Kent Beck and is quite famous in Smalltalk circles. OK, I'll jump off my Smalltalk bandwagon today.

  • But VisualWorks Smalltalk still remembers a method's source as an ascii string. Seeing your appetite for other's ideas I think you'll appreciate the following transcripts from the Forth community cumulating to putting a Forth compiler plus sources plus OS in 9 Kwords:
    Aha Talk
    Enth & Flux

    By Reinout Heeck, at 2:16 AM   

  • Lispers think that how you store source depends on the development environment and not on the language. Common Lisp does not say that you need to store source in files. You can eval and compile from Lisp datastructures. (ed 'foo) will bring the source for the function foo into an editor.

    But the usual Common Lisp environment will remember the source location. M-. is the usual Emacs operation to find the source for a symbol. Several IDEs have extensive capabilities to locate the source. Browsers for functions, classes, etc. usually don't use the source, but the in-core data-structures.

    Then there was also InterLisp-D from Xerox, which stored source as data - similar with what you would do in Smalltalk. But it went one step further. The usual program editor was directly editing the in-core source data-structure (which thus was not text).

    So, there is no reason to look down on Lisp. It's IDEs have similar capabilities: source locators (even programmable), browsers and graphers working on rich, in-core datastructures, who-calls facilities, change tracking in the editor (compile changed), debuggers which can locate source code for blocks (and can resume/retry after changes) and much more...

    By Anonymous, at 6:24 PM   

  • I stand corrected on the Lisp front. I've tried learning Emacs several times. I like the idea, but I get frustrated with the ease of use. So, I look at Emacs as an extensible text editor. I know the IDEs for LISP are just as good as the ones in Smalltalk and I meant no disrespect to the Lisp community. Contrary, I love Lisp and would love to work on a Lisp project. I find the Lisp way interesting and invigorating. In fact, Lisp has affecte the way I write code and in Smalltalk.

    By Blaine, at 3:46 PM   

Friday, July 08, 2005

Domain Specific Languages Parade

DSLs are all the rage recently with Martin Fowler and a whole bunch of folks blogging about them. It seems the Lispers are a little annoyed about the noise and rightfully so. They have proclaimed the virtues of DSLs for many years. In fact, Paul Graham's essays are littered with references to how DSLs solved his business problems. Smalltalkers have also long talked about the virtue of DSLs. So, why all of the rage? I think a lot of dynamic language ideas are finally seeing the light of day via the scripting crowd.

It's a good thing since I believe DSLs are a by-product of good design. You have a DSL when you speak in the terms of the domain in your code. This might seem obvious, but I see procedural-like code that stays at the level of the general-purpose language too much. I know I have magic in my designs when a business user can read my code and understand it. It's the goal that Eric Evans talks about in his excellent, "Domain Driven Design" book. He speaks of a ubitiquous language that is shared by business and technical folks on the project.

The good thing about the current parade is the number of good ideas that adds to my arsenal to attack a problem. Rainer Joswig had an excellent blog entry discussing how Lispers go about doing a DSL for RFC specifications. Where I would break down the problem in objects and messages, the Lispers take a different strategy with macros to achieve the same result. I would love to work on a Lisp project just to get into their minds.

Everytime an old idea comes back, there are some new twists. I find the current reprise of metadata usage in DSLs interesting. Again, metadata is nothing new, but the approach seems to be new to developers in the static camp. The model driven approach takes this route as well. But, MDA seems too much like CASE tools part two. Martin Fowler's article does an excellent job of showing the pros and cons of the DSL approach and its different paths.

I've been thinking about language issues since I had my talk with Colin and Eric. Both of them, gave me a plethora of thoughts to chew on. Making DSLs easier for developers seemed to be the meat of the discussion. How do we make it better? Can we make general purpose languages that are more tuned to DSLs? Much like we make the separation between virtual machine and our code. The boundary is distinct. I think a mixture of metadata and DSL facilities built-in to a language would be a win. It would be nice to express the domain in terms of a DSL and then use metadata to wire persistence, GUIs, and rules. In other words, the low-level programmer details would be handled at a metadata level (think Glorp and rule engines), but the domain expressed in terms of the business and only the business. Any dynamic language can provide this functionality easily, but is there anything we can do to make it even more transparent? I want to play more with prototypes ala Self because I think there is a richness to explore. DSLs feel like they would be easier in Self especially with dynamic delegation and traits. I believe that we should treat languages like organisms. We are all comprised of cells which are comprised of other parts and so forth. I think programs can be built the same way. You have a simple core in which higher level blocks are comprised of and then, bigger blocks are built out of those. When you get to the top, you see a complete being. It's a recursive russian doll basically. Each level would be higher DSL. Thus, the top level would be the business domain language. Think of it in terms of the virtual machine code. Do you ever see it or care when you are at the top level? No. You build your system out of the language on top. Same concept, but we need to take it to higher levels. This is a huge subject. I plan on blogging more in the future about this subject. I want to take Smalltalk to the next level. I'm tired of solving the same problems.

  • Not an expert on the subject, but I've seen this idea touted in varing forms over the years. The limitation occurs when your chosen DSL does not provide you with the flexibility you need. And IMO that is where the idea falls flat.

    After all, no two companies are exactly the same although they may share the same "business domain". So why should their software be the same?

    As developers we need to create abstractions that solves todays' problem. Whether those abstractions are useful tomorrow or in a new context, is totally speculative.

    What I do is create a specific language, for each application I write. I try to use ubiqitous domain language as promoted by Eric Evans, but I do not pretend that my code is in anyway generically useful outside its' current context.

    On the contrary, in my experience, every application is that little bit different. The classic example is that no two Banks have exactly the same Current Account.

    Human language is a rich and flexible tool. Software is quite rigid in comparison. I am very sceptical when I here claims for "domain specific" frameworks/libraries/languages etc.

    IMO, it is often quicker to write what you need yourself. And you get exactly what you want in the bargain!

    By Paul, at 1:52 PM   

Monday, July 04, 2005


With all of the commotion, I missed the Ruby User's Group meeting. Darn it! I'll be there next month and I can't wait to see everyone there! Again, sorry!


Back In Civilization

I got back from camping trip today and it was mad fun! It was a turn of events from totally geeking out one minute to being in the middle of nowhere. It was strong contrast, but a relaxing one. I enjoyed being outside and letting my mind wonder. I had a lot to chew on from all of the discussions that I had with everyone. Now, I can't wait to start putting those ideas to work. I have my rallying call and I'm ready to kick some programming booty! Smalltalk on!


Metalheads Against Racism

This page is powered by Blogger. Isn't yours?