Blaine Buxton: Positronic Vibrations

There's a lot of features of Ruby that I like, but there are some that just drive me nuts like blocks not taking blocks and the ampersand operator. Raganwald did a great job of explaining blocks, procs, and the ampersand in this blog post: Explanation of Ruby's Unary operator. I came away with the feeling, "Wow! It took that much explanation just to tell how to send blocks around?" If blocks were first-class citizens, Ruby would be more elegant. Raganwald would not be writing huge blog posts on block vs. proc because it would be unneeded.

Ruby has all it needs right now. Ruby 2.0 should be a pruning of features and removing special cases. Get to the things that help you concentrate on your design and not on the language. Ampersand is nothing more than noise in your code and brain. Remember elegant is simple.

Labels: design, ruby

posted by Blaine at 7:19 AM |  1 comments |  Post a Comment

"The deliberate use of a weak element that will fail in order to protect other elements in the system from damage." - Universal Principles of Design

Unit tests could be seen as a form of weakest link in that we want the system to fail in our tests instead of in our production environment. Pre-condition and post-condition assertions (remember Bertrand Meyer don't you?) are the perfect example of weakest links in software design. The assertion fails, then the program stops or does something intelligent about the detection: logging the anomaly or dropping an incorrect record. We have more options available to us when our weak link fails in software than other domains. I would even put exception handling under the weak link design umbrella.

So, why don't we use it more? It's rare I see pre-condition assertions at all. I know the performance overlords declared them to be bad. But, when you have Rails running high traffic websites, does a few extra assertions really matter? I think not. I would rather have my program run slower with safety belts than doing something catastrophic with my data. Brian Foote once gave a talk where he equated pre and post conditions to the goalie in a game of hockey. And asked the question, "Would you want to play with or without the goalie?" It's a statement that's lived with me since.

With that being said, are they places in your current design that could use a few more fuses?

Labels: design

posted by Blaine at 4:51 PM |  0 comments |  Post a Comment

I must admit I haven't been following Ruby 2.0 too closely lately. But, I since I've been using 1.8 quite a bit lately. I thought I would list the things that are in 1.8, but I hope are gone in 2.0. This is a prayer of good vibes.

1. Make blocks first class citizens. So, no more & in your methods. Everything should be an object. Blocks are no exception in fact, they have more right than anyone. This will make blocks syntactically cheaper too. No more "lambda". Happiness is cheap syntactic blocks.


2. Reflection on everything. Yes, this means the stack. It also means keep the source in memory as well as part of classes and blocks. This might could used for a lot of cool things (like interesting ways to traverse code). Don't worry. It doesn't add much memory.


3. Make blocks accept the same kind of parameters as methods. Right now, you can not have methods take an implicit block (you know with the & in front). Wait a minute. If number one is satisfied, this will be too. Oh goody. Cheap blocks take away complexity. Isn't this reason enough to have them?

OK, that's it for now. The above things would make life so much easier. I could lobby for taking away case statements and most keywords, but I think the above would be great to take the language forward without hurting too much.

Labels: ruby

posted by Blaine at 12:16 PM |  0 comments |  Post a Comment

I can't believe it. I missed my fifth anniversary for blogging! I started out in 2003 to be a public diary for my technical side. I've enjoyed doing it and plan to do so for many years to come. It's just too much fun to read through all of the posts and remember where I was at during that point of time.

Labels: misc

posted by Blaine at 1:15 PM |  0 comments |  Post a Comment

I've joined the modern age. I'm now on twitter. I know, I'm behind the curve. See you there!

Labels: twitter

posted by Blaine at 9:41 PM |  1 comments |  Post a Comment

At the next Omaha Dynamic Language User Group, I will be speaking on Seaside. If you missed my talk at the BarCampKansasCity, you can catch it now. I will be showing how to build web applications with the best web framework out there. Expect lots of simplicity and heretical statements.

Labels: dynamic languages, presentation, seaside, smalltalk

posted by Blaine at 9:35 PM |  0 comments |  Post a Comment

Due to a change in plans, I will not be attending the Chicago Lisp Workshop.

No, I'll be there. Things looked bleak this morning, but I'm all clear now. Amazing what a day can do.

Labels: conference

posted by Blaine at 10:12 AM |  0 comments |  Post a Comment

I will be in Chicago on May 31 to participate in this Lisp Workshop. It should be more fun than one person is allowed to have. A weekend of Lisp sounds nice doesn't it? See you in Chicago.

Labels: conference

posted by Blaine at 8:14 PM |  0 comments |  Post a Comment

Reading other people's code is the needle lost in the hay buried deep in this article entitled "Language Dabbling Considered Wasteful". Forget the dreadful title that makes my eyes roll back in my head. It's still too close to Dijkstra's famous paper. But, I digress. This is not a pointless rant on over abused trivia.

If you want to become a better programmer, read code and understand it. There's no way around it. Read code, experiment with it, and figure out if you like it or not. Bad code can teach just as much. It's no fun to read, but it shows how not to do things. The danger with bad code is being picking up incorrect habits. Get into the practice of reading code and not the Javadocs. If you're learning a new language you will see the idioms and be able to apply them. Plus, you will know how to find how things work underneath the covers if you run into a super thorny issue.

Yeah, give me the source any day. I love reading code and it's how I learn. Once I get past the basics, I start reading and understanding others code. I will say it again, there are no shortcuts.

Labels: programming

posted by Blaine at 8:12 PM |  1 comments |  Post a Comment

This is a shame: No Dashs or Spaces. We should be helping and not being a road block. I know I've cussed at a few of these sites listed. Sometimes I think we should put ourselves in the shoes of our customer and think, "What would make their life easier?" We should make it as easy as possible for a user to achieve their goals. The computer should disappear and only the problem at hand should be on the user's mind. We still have a long way to go. Let's start being more empathetic. The users are people too.

Labels: analysis, design

posted by Blaine at 11:36 AM |  1 comments |  Post a Comment

Pete Thomas presented "Situated Web Application Platforms" at BarCampKC. The talk was wonderful and it made me think about current IT solutions. A talk ensued after his wonderful presentation about Excel, email, agile methodologies, and enterprise development. It was pondered why business users embrace Excel and email and are reluctant to move off of them. The alternatives, SWAPs, are clearly superior, so why stick with cruder applications? I reasoned because Excel and email were good enough. Why would they want to learn a new tool if the current one fulfills their need? They are not computer people and would rather be solving problems than wasting time in front of a computer. Their passion and strength is not in development, but solving business problems. We should embrace that. While this might startle us because we wouldn't stand for it (I know I would not want to merge data from a bunch of Excel spreadsheets into one, but my passion is different).

So, why fight and try to replace Excel? We need to change our thinking and embrace it. It could help with requirements gathering. It could help us find the missing pieces in our software. We are always on the lookout for solving problems with technology, but in this case, we should be asking our users why they have the need to use Excel. What else could we do for them. It's time for us to stop mindlessly implementing what the customer tells us and figure out what their true goals are and solve those.

Labels: analysis

posted by Blaine at 11:28 AM |  0 comments |  Post a Comment

There was a discussion recently on standards where one poster said that they were big on alignment. Here's an exchange:

Hi__ jwen,

jhdn> Simple solution: set in your coding standards that ALL
jhdn> classnames MUST be a specific length, and also dictate specific
jhdn> lengths for all member variables, method names, etc. etc.

Hmmm_, I___ thnk that mght caus more prbs, mayb even a___ rvln from
the_ devs. Not_ to__ mntn that it__ lmts your cr8v ablt to__ use_ good
nams and bild a dict* that hlps bild betr apps.

Grgg

* I Just couldn't come up with a four letter substitution for
"vocabulary". :)

Classic. I laughed coffee through my nose. It hurt, but was well worth it. I'm glad I don't work somewhere they have standard on the size of my variables. I don't think I would be working there much longer.

Labels: funny

posted by Blaine at 7:02 PM |  0 comments |  Post a Comment

I recently came to the realization that I've been fighting Javascript too much. It's because I've been going against the grain with it. It's like trying to force the OO paradigm in a functional language or the opposite. You might say that I've been treating Javascript like an OO language and you would be right. But, I've been forcing my class-based thinking on it and it's been not so nice.

I've been reacquainting myself with Self and Io again. And it hit me like a rhino slamming into me. I've been doing Javascript all wrong. I should have treating it like the prototype-based language that it is. Sure, it doesn't have the ability to inherit from multiple prototypes like Self, but the way to succeed is with prototypes. Forcing class-based OO is like walking up the rainbow and finding no pot of gold at the end.

First, let's write the following:

Object.prototype.clone=function() {
    var creator=function() { this.constructor=arguments.callee };
    creator.prototype=this;
    return new creator();
}

Object.prototype.mixIn=function(definitions) {
    for (var each in definitions) if (definitions.hasOwnProperty(each)) {
        this[each]=definitions[each];
    }
}

It's just two methods up on the Object prototype. Why clone is not part of the Javascript standard is beyond me. Clone is required in all the other prototype-bases languages I have seen. It is the only way to create new objects. Enough complaining, it was only a few lines of code. All my clone method does is make the object I call it on the prototype of the result. I get a clean object with all of the properties of the receiver inherited. Nice. This is the behavior we want. Next, I added a convenience method to Object to mix-in in other objects. This is helpful to keep my code organized. I can just create a hash object with my functions and properties like before. So far, this is standard stuff. But, here is how I use it:

Pounds = new Object();
Pounds.mixIn({
    of: function(value) {
        var result=this.clone();
        result.value=value;
        return result;
    },
    toString: function() {
        return this.value.toString() + " lbs";
    },
    value: 0
});

print(Pounds.of(5)); // => 5 lbs
print(Pounds); // => 0 lbs
print(Pounds.isPrototypeOf(Pounds.of(5))); // => true

Notice, normally, you define the constructor with the first letter of the name upper cased. I no longer need the constructor, so I upper case on the prototype that will be the example for all the instances that I clone off it. The example above is a measurement class. "Pounds" is my example so I default it with values that the objects that I clone from will have. This is how prototype-based languages work. It feels slightly unusual coming from the class-based background, but I think it makes my Javascript look a lot less alien. I like it.

Let's look at a more complicated example shall we?

Animal = new Object();
Animal.mixIn({
    name: "Unknown",
    sound: function() {
        return "?";
    },
    toString: function() {
        return this.name 
                + " goes " + this.sound() 
                + " and weighs " 
                + this.weight.toString();
    },
    weight: Pounds.of(0)
});

Cat = Animal.clone();
Cat.mixIn({
    name: "Unknown Cat",
    sound: function() {
        return "Meow";
    },
    weight: Pounds.of(10)
});

grendel = Cat.clone();
grendel.mixIn({
    name: "Grendel",
    sound: function() {
        return this.constructor.prototype.sound.call(this) + " and Purr";
    },
    weight: Pounds.of(20)
});

gracie = Cat.clone();
gracie.mixIn({
    name: "Gracie",
    sound: function() {
        return "Purr";
    }
});

print(Animal); // => Unknown goes ? and weighs 0 lbs
print(Cat); // => Unknown Cat goes Meow and weighs 10 lbs
print(Animal.isPrototypeOf(grendel)); // => true
print(grendel); // => Grendel goes Meow and Purr and weighs 20 lbs
print(gracie); // => Gracie goes Purr and weighs 10 lbs

"super" is implemented with "this.constructor.prototype". It seems wordy, but prototype on the object is not built-in to Javascript. Besides, you should use "super" sparingly. To me, this reads better and works better for inheritance. I have dropped all references to classes. This makes meta-programming easier as well (I simply walk up the prototype chain with "this.constructor.prototype" and iterate through the properties.

The constructor function used as a class always seemed awkward to me. It was inelegant, but the above fits Javascript coding better. The reason is because I'm now using it as a prototype-based language and not forcing class-based OO on it. The above is meant to get started playing around. Prototype-based programming is so cool and I'm still exploring all of the possibilities. There's little documentation, but the little that is well worth the effort to track down. Have fun!

The example above was tested in SpiderMonkey. A great little REPL for playing with Javascript.

Labels: javascript, programming, prototypes

posted by Blaine at 11:59 AM |  0 comments |  Post a Comment

I feel like I can finally write about my XP experiences. I was once a member of the largest XP teams in the country for three years. The XP practices were the main reason for me joining the team. I had been experimenting with agile at my prior work places with great success, but no one wanted to jump in. I found this team and they were up to their necks in it. I loved the thought of it. The people were passionate, caring, and intelligent. What could go wrong?

Nothing went wrong. But, I'm a bit of a skeptic now when some company touts agile to me now. I'm a bit shell-shocked. How could this possibly happen? I'll just list them. Don't worry it's only a few.

• Everyone owns the code

In theory, this sounds wonderful. It really does and I think it works on a small team of 3-4 dedicated developers. It doesn't scale beyond that. The 3-4 developers must be dedicated to keeping the code clean too. If someone fails to clean up ugly code, then it quickly turns into glue. It turns against you if everyone thinks that everyone else will do the cleanup. There are plenty of negatives to personal code ownership, but the point is to have at least two people as masters of each section. Multiple eyes should see any code commit. But, someone or a pair should own it.

• Mandatory pairing

Pairing sounds so good on paper, but it completely takes away the human element. Programmers are introverts by and large. Pairing can wear out some people quickly. I found forced pairing tiresome because not all folks get along. There were some people that I would enjoy pairing with and I learned a lot from. I would always want to pair with them, but other folks it was a constant struggle. I think pairing should be an optional activity that developers should naturally want to do when brain storming or checking in code. I find that code reviews with a pair of eyes who have never seen the code that I am checking is always a good thing. This should be done often. If you think about it, what I am describing is collaboration. Pairing to me as a term basically means one side can turn off. Collaboration is where both sides are equally engaged.

You will notice I didn't list test-driven development above. If anything, XP got that one right. I write tests for everything and stand behind them. I don't see how anyone can stand behind their work without them. I even write tests for my research code. I'm still 100% agile, but I think each practice needs to be tailored to your team. Don't blindly follow the book. If something hurts, don't keep picking at it. You might lose the limb and your project.

This is only the beginning. I plan to write more the subject.

Labels: agile, XP

posted by Blaine at 11:49 AM |  1 comments |  Post a Comment

I guess I don't conceal my passion and love for Smalltalk very well:

...seeing Blaine’s eyes light up every time he got to either hear or utter a sentence that included the word “Smalltalk”.

To me, Smalltalk defines elegance. If you want to see elegance in computing, go download Squeak right now. The very least that will happen is it will warp your mind and make you a better programmer. It might even make you see the world a little differently.

Labels: smalltalk, squeak

posted by Blaine at 9:24 PM |  1 comments |  Post a Comment

Just a reminder I have my Seaside presentation (scaled down a bit from the BarCampKC one ala no database mappings) and my Smalltalk Coding competition (100% Seaside) here. So, if you missed the presentation, feel free to download the Seaside presentation image and the coding competition. Lots of good examples to pour through in each. I'm going to try to put instructions with the new presentation and get it published. But, in the meantime, you can check out these older (not that old) materials. I will also remind folks to read Introduction to Seaside. It's a great and fast introduction into the coolest web framework on the planet!

Labels: seaside, smalltalk, squeak

posted by Blaine at 9:10 PM |  0 comments |  Post a Comment

I attended and presented at my first BarCamp this weekend. What a blast! I would like to thank Pete for putting on such a wonderful event. I'm always in need to mingle with brilliant folks and BarCampKC had them in spades. I enjoyed the discussions on Ruby, Situated Web Application Platforms, UML, customers, and of course, Seaside. It was well worth the 3 hours to attend and I would do it again in a heartbeat. My only wish is that it had been longer. I'll be making some more blog posts based on discussions had. If anyone has the chance to attend a BarCamp, please do. I know I made several new friends over the weekend.

And what would you know? No sooner that I have unpacked my bags and there's a webpage for BarCampOmaha. You can count me in being there and presenting something. Perhaps this time, I will give my Advanced Javascript talk (ran out of time in KC) or maybe I'll do something completely different. We'll see. I'll be having lots of fun this summer.

Labels: conference, presentation

posted by Blaine at 8:49 PM |  0 comments |  Post a Comment

I grabbed this from Io Language Guide:

In all other languages we've considered [Fortran, Algol60, Lisp, APL, Cobol, Pascal], a program consists of passive data-objects on the one hand and the executable program that manipulates these passive objects on the other. Object-oriented programs replace this bipartite structure with a homogeneous one: they consist of a set of data systems, each of which is capable of operating on itself.
- David Gelernter and Suresh J Jag

I couldn't have said it better myself. It's not what Paul Graham says at all. I can't help it if he never took the time to understand it.

Labels: programming

posted by Blaine at 7:18 PM |  3 comments |  Post a Comment

You know you've lost the fight when you make direct attacks on your competitor on your front page. Do you see google slinging mud? You don't have to sling when you're so far in the lead. Only the company in 2nd place needs to do those things.

Labels: business

posted by Blaine at 2:35 PM |  0 comments |  Post a Comment

If you are in Kansas City tomorrow and want to learn more about Seaside, then come to BarCampKC. I will be giving a presentation on Seaside. It's the one you can download from SqueakMap, but beefed up. I've included how to do GLORP, script.aculo.us, and more! I will be showing off Smalltalk and Squeak in the process. If you ever wondered why Smalltalk was so cool, now is the time to find out. See you there!

Labels: presentation, programming, seaside, smalltalk

posted by Blaine at 12:42 PM |  0 comments |  Post a Comment

Why did the UML design tools fail? By fail, I mean never gain popular acceptance. To this day, I still do my designs by hand and then do them in a drawing tool when they are solidified. The UML tool makers never understood that when designing, you need to be able to make mistakes and explore different options. Instead, they forced you to make decisions too early in the process so they could auto-generate your code. I always found it cumbersome and they got too much in the way. And that's why they failed. I love paper. All of my friends that design still use paper for their designs as well. The reason is that you can try out ideas and the design can always be thrown away. Design is an exploration journey. The tools only looked at the destination and not how to make the journey easier. The journey is what mattered.

Labels: design

posted by Blaine at 11:42 AM |  2 comments |  Post a Comment

OK, when I originally linked to Binstock on Software: Perfecting OO's Small Classes and Short Methods, I had not read the comments. Wow. Varied opinions and were a lot of fun to read. I would like to comment on a few.

One mentioned using automated enforcement software to make sure developers abide by these rules. I used to love this idea because I would run those tools over my own code. But, once I made it public what I was doing, my fellow developers would figure out ways around it. It's human nature. Now, I keep those tools to myself and use them on my own code. I think code beauty is a personal thing and strict enforcement to one standard is an open rally call to defy it. The end result is code that is worse than it was before.

Secondly, I took the rules to be a an exercise to limit your code in extreme ways so that the power of the message send comes through and the ugliness of data structures is exposed. The point is let go of central control in your objects. For that, I think this exercise is gorgeous.

Lastly, I think the recommendations are things to strive for. It makes you code more readable, testable, and flexible. Who wouldn't want to strive for those things?

posted by Blaine at 11:57 AM |  0 comments |  Post a Comment

I almost cried for joy when I read this post on one of my favorite topics: Small Classes, Short Methods. Someone has been reading my mind. I love the set of rules. It's something that I strive for in my code. I've run into problems with other developers though (they generally think I am nuts when I wrap things like phone numbers, ids, domain specific codes, etc into objects instead of strings). But, by wrapping the primitive into an object that states it's role, you start moving logic closer to where it belongs. The books "Genius Within" and "Prefactoring" were the books that really brought this home for me (especially "Genius Within"). Lots of great advice. Go read it now!

Labels: design, programming

posted by Blaine at 6:56 AM |  0 comments |  Post a Comment