The Obscenity of New Syntax

Background

A couple of weeks ago, I attended the Lambda Lounge for a talk on OCaml. I decided to be proactive, so before the talk, I downloaded the runtime and kicked the tires.

For days, during compilations and Fit tests, I would play with the language. I had used ML years ago, but had forgotten much of it (aside from a vague memory of an ultra-strict, Klingon type system that was both a high-grade irritant, and yet oddly reassuring).

By the end of a week, I wasn't much further ahead with OCaml. I had written some basic functions and expressions, but nothing substantive.

The Experience

During the talk, I realized that the experimentation was more useful than I had imagined.

The presenter showed something like this:

# let sphere_surface = fun x -> x *. x *. pi;;
val sphere_surface : float -> float = fun 

The questions flew immediately: why is there a double-semi (;;) ? are we running as root? how do we interpret the output?

These were natural questions by smart newbies to the language. I had two thoughts:

• Naturally, it helps to prepare for a talk, but I was surprised by how far my modest time investment had taken me. I couldn't have answered all of the questions, but I could place myself in both mindsets: one of the questioner (what the heck?) and also the presenter (oh, see it works like this).
• The first few examples struck the audience as obscene. I don't mean morally, and I don't mean that as a slight to OCaml per se. I mean in an artistic sense: well-known symbols that were beloved in other contexts had now been thrown together in a way that was jarring and almost repulsive. It takes some time to get past that shock of illiteracy.
  

The Upshot

This post is a reminder to myself: if a language talk is on the calendar, it is vital to download the environment and write some toy examples before attending, even if you only have a couple of hours to spare. The idea is not to learn the language but to embrace the obscenity and overcome it: celebrate the dissonance! As one music teacher put it: the Hendrix chord would have been considered hideous, even dangerous, in other eras. Now, it rocks.

Next Up: JavaFX

You may have several opportunities to see presentations on a new language in the near future: JavaFX. If you subscribe to the idea behind this post, you might be interested in an article by my friend Weiqi Gao: it is a top-shelf article on JavaFX as a language.

I'm going to be giving it a whirl over the holidays. The goal is to sing Auld Lang Syntax on New Year's Eve!

ps. Best holiday wishes to all readers... Here's a toast to a fine '09

Island Rhubarb Dessert (Favourite Holiday Recipe Meme)

I've been tagged by Eric on the Favourite Holiday Recipe meme. Here is mine: it is not difficult compared to other family recipes but it is excellent. It works best with rhubarb grown on Prince Edward Island, but if not possible, work with the freshest stuff you can find.

I'm tagging:

Matt
Stef
Dale
Nate
and Dave

Island Rhubarb Dessert

This a 4-layer pan dessert.

• Put on some favourite holiday music and pour a beverage of your choice.
• Prepare separate packages of dreamwhip and a 6 oz package of vanilla pudding.
• Eat some vanilla pudding, to set the stage.
• Crust layer: Mix 1 1/2 cups graham crumbs, 1/4 cup soft margarine, and 1/4 cup brown sugar. Spread in 9 x 11 inch pan. Bake at 350 F for 5 to 8 minutes. Let cool.
• Filling layer 1: 4 cups fresh or frozen rhubarb, 1 cup white sugar, 1/2 cup water, 3 tablespoons cornstarch, and 2 tablespoons strawberry jello powder. Boil until cooked and thick to a sauce. Spread on crust. Let cool.
• Filling layer 2: Cover with prepared dreamwhip and add 1 1/2 miniatures marshmellows if desired.
• Top layer: spread prepared vanilla pudding over the dreamwhip layer.
• Refrigerate.
• Enjoy with friends.
  

Lambda Lounge Lures Legion of Licentious Linguists

As many others have mentioned, the first meeting at the Lambda Lounge was a big hit! It was clear from the turnout (30+) that (a) a lot of people have a thirst for something more exotic than Java and (b) the IT community in StL is thriving and sophisticated. We all agreed that we are 'promiscuous' regarding computer languages (hence the post title).

Appistry served as gracious host and formed a fitting backdrop for the evening, and the vibe was palpable; there was an energy similar to the NFJS conferences.

The content was excellent stuff: Matt Taylor discussed categories and mixins in Groovy; Ryan Senior gave an overview of OCaml.

Overheard at the meeting (paraphrased) :

• Java is wonderful, boring, and the new COBOL, all at the same time. (Editor's note: perhaps it is the new C ?)
• I wish OCaml didn't use # as the prompt. I feel like we're the root user and something crazy is about to happen.
• 10 years ago, we turned out in gatherings like this because we were stoked about Java. Now we turn out to get away from Java.
• The opposite of a functional language is a dysfunctional language.
• They should name OCaml's web framework to be ODromedary.
  

Bottom-line: Come on out to the January meeting if you want a piece of this. Time well spent with cool people.

Child suspended for EJB taunt

CtJ Newswire
Parody City
December 3, 2008

A district schoolboard reported today that a Grade 2 student has been suspended indefinitely for calling his teacher "the EJB of school" in class.

The announcement comes on the heels of a heated exchange between the teacher and the student as to whether cursive writing was important.

The principal of the school, Edgar J. Boyle, provided a brief statement: "We aren't exactly sure what EJB is, but after consulting with the IT industry, we understand that it implies a high degree of excess proportion and baroque complexity, ultimately leading to failure. In some circles, it is a taunt of the highest order. We believe this kind of language was learned in the home, but we refuse to stand for it in the classroom."

There is no word if the parents will appeal the decision, despite rumors of a protest website being constructed with Grails, a nascent IT solution.

A First Look at Android (video)

Here is a tech talk by the nefarious comic artist, Eric Burke (we're friends/colleagues/blog rivals).

Eric discusses his initial experimentation with Android. He's been working with Ed Burnette's e-book 'Hello Android', and has some good stuff over at his blog.

It is not news that the mobile platform is the Next Great Battlefield, but intro material on Android is news. With all of the massive players in this space, it is important for us to pick a horse and bet on it with a time investment and experimentation.

I won't tell you which one to learn, but Android is a reasonable choice. You can see why in the video...

Spice up your week with the Lambda Lounge

Looking for something more exotic than Java or C++ ?

Need an oasis of pure computing in an otherwise bleak and desolate week of software engineering?

If you are in St Louis, Alex Miller has something for you: the nascent Lambda Lounge, a monthly celebration of developments in the world of functional and dynamic languages.

As mentioned on the website, the basic idea is to explore new developments in programming languages and libraries. Note that the subjects are not necessarily bound to the JVM or the DLR from dot Net. I'm looking forward to the weird and wonderful stuff at this meeting. The first one is Thursday, December 4. Check the website for details.

On a sidenote, I quite like the logo. I'm not sure of the symbolism of the bits at the top. My interpretation is that they are eyeglasses. If true, I love this because it reminds me of the styles of the chess grandmasters of Europe in the late 19th century, and particularly the cafes in Paris where intellectuals would congregate to discuss philosophy and other subjects.

That said, this meeting will be much less pretentious than those gatherings of yore! No word if there will be sword-play based on heated language debates.

Car-pooling with eBay, Erlang, and Haskell

I bought a new stereo for my car, and I'm enjoying listening to tech podcasts on my commute and errands.

My favourite is still the beguiling Java Posse, but I have been extremely impressed with Software Engineering Radio. This is world-class stuff. Be sure to check out the episodes with eBay's Randy Shoup, Erlang guru Joe Armstrong, and Haskell maven Simon Peyton Jones.

Outstanding. I'm going to be donating to the cause via PayPal.

Groovy is to Grails, as X is to Y ?

Consider the following: Groovy is to Grails, as X is to Y.

I recently tweeted "... as C is to Unix". Though Mario quite rightly pointed out that much of Grails is written in Java, my thinking is that both Groovy and C enjoy greater popularity because of the success of their sibling application/system. i.e. It seems that Grails, as Unix once did, acted as a driving force beyond that of pure language development, which propels innovation and gives focus to an emergent style.

Dave Klein has his own tasty analogy about butter and pancakes.

And you? What are your values for X and Y ?

Ruby fans are invited to play the same game, with respect to Rails. Are there any values for X and Y which resonate for Ruby/Rails but not for Groovy/Grails (or vice-versa)? That one is very interesting.

Kudos to ActiveMQ

At CtJ HQ, we try to spotlight any projects that have a pleasant "getting started" experience.

Today's winner is ActiveMQ, an open-source JMS implementation. After following the installation instructions, I went to a "Getting Started" web page that explains how to start the basic consumer and producer examples. The instructions are clear, and the code is a perfect "foothold": something to help me get a leg up. It is simple and yet has several options to show various JMS patterns.

My thanks to those involved!

Snatching Open Source Licensing from the Jaws of Legal Marginalization

A recent issue of DDJ has an fascinating article on the case of Jacobsen versus Katzer, pertaining to the legal strength of open-source licenses.

To quote author Michael Swaine: it's a big deal.

The nano-gist is:

• Katzer threatened legal action on a supposed patent violation by Jacobsen.
  
• Jacobsen looked at the facts (including that K had used parts of J's software), marshalled resources from the open-source community, and launched a pre-emptive lawsuit.
• A U.S. district court judged in a manner that severely limited monetary damages awarded to J, based on a legal distinction between a condition and a covenant.
• Later, an appeals court overturned the decision. i.e. The good guys win.
  

I didn't know about the case, so although the article is brief, it almost reads like the story-board for a thriller. I hope that, somehow, it is made into a documentary.

Overview of Hadoop

My friend Tom Wheeler has written an excellent article over at the OCI Java News Brief.

The article has not only an overview but also many reference links and some outstanding examples of Hadoop in the wild. Examples include the New York Times Machine project and a record-setting cluster with 4000 nodes.

As neat as this all is, I'm more excited about the notion of people solving problems in a different way, via the Map-Reduce strategy. Tom gives a counter-intuitive example of a word count algorithm: in the small, it is awkward and slow; in the large, it scales seamlessly to colossal proportions.

Back in university, a favourite class was the Theory of Computation. I recall the strategy of proving a problem was NP-Hard: if one can express it in terms of another problem that is known to be NP-Hard, then one could argue that if one can solve the original problem in polynomial time, then one could solve the set of NP problems in polynomial time (I'll let commenters distinguish between NP-Hard and NP-Complete and other subtleties). As an understated aside, solving this problem would be 'good for one's resume'.

Solving a problem with Map-Reduce isn't the same thing, but there is an abstract, psychic thread that seems to tie them together: the notion of thinking about problems in a certain mindset. Very cool stuff. I hope to find time to explore that further.

Lurker Exposed 2: Giving Twitter a shot

Despite my rant, I'm giving Twitter a shot, due to peer pressure and sketchy coercion from a man with ties to the intelligence community.

My thinking:

• Don't knock it till you've tried it (though that generally doesn't stop me)
• Who's kidding? When it comes to blog hits, I'll prostitute myself as much as the next person.
• Since I am genuinely interested in others' status, it should be more efficient than being a lurker.
• Dopamine rushes and other biochemical reactions aren't a bad thing

Fear not, non-tweeters (especially those for whom the rant may have resonated) !

I am only visiting the dark side, and will fight assimilation.

Lurker Exposed: Why I wasn't on Twitter

Many of my friends know that I am not a fan of Twitter, and yet I lurk on there. Here are some quick thoughts on the site.

First, I should point out that I think I 'get it': the sense of community, particularly if you work with people remotely. I also understand that if I don't like it, I can just stay away.... so we're in full Unsolicited Opinion Mode here (and somewhat tongue-in-cheek).

Twitter killed the blogging star

Gah! With blogs everything was going great: people wrote paragraphs, and others commented. Flame wars were so large that the flames danced into the night sky, harkening back to Usenet and other media of yore. Twitter strikes me as a threat (hopefully a short-lived one) to the Great Conversations, banzai stunts, and comics.

To paraphrase Stephen Wright, Twitter strikes me as HDADD : High-Definition Attention-Deficit Disorder. There's hardly any focus, but when it is there, it's "140 characters of amazing clarity" *eye roll*

The War Room

My current team works in an open "war room" where there is a healthy peer pressure regarding minimal browsing. Plus, I can't speak for you, but I seek simplicity when at work: no IM, no phone, and sometimes even no shoes. Sure, I have guilty pleasures but I don't need another.

Navel Lint

Does anyone really want my status? What if I'm wondering why navel lint is never the same colour as the garments one has been wearing? Strangely, I do enjoy others' navel-gazing.... until one random tweet puts me off, and then I'm back into rant mode.

Sharing Links

I no longer care about websites that have been sent to me in email. Same thing for twitter. I've noticed that the best sites are those that people mention here. Essentially, your collective memories serve as my spam filter because if you remember it well enough to talk about it, it's probably good.

Who knew that you've been working for me? Awesome. Now, let's go to a cafe, pub, or tech talk and have a real conversation.

Politics

Hoo-boy. Many smart people bemoan the lack of nuance in the mainstream media (especially in North America) but then try to chat about issues in 140 characters? Yikes. Even better is the lack of threaded conversations. As a lurker, I'm clicking all over the place to try and connect the dots on a pseudo-conversation.

Firing of Dopminergic Neurons... Wheels down on a dopamine rush

I have a feeling that when one is tweeted by another who is "higher on the geek pecking order" that it fires reward sensors in the brain that can be interpreted as insight, or a meaningful connection. It is neither! It's merely a biochemical reaction! Can't you people see what is happening? You may say twitter is a "convenient, asychronous chat-room where the whole is greater than the sum of its tweets". I say it is a delusion, a vacuous sham of humanity that takes us one step closer to the Borg.

Conclusion

OH: Twitter sucks.

That said, you may be interested in the next post, where I'll tell you why I can't resist, and why I'm giving it a shot.

Simply Groovy (How to gain Competitive Advantage on Weiqi Gao's Friday Java Quiz)

Weiqi Gao runs the popular Friday Java Quiz. He provides puzzles and invites us to ruminate on bed-time reading of the Java Language Specification, or to recall a Java Puzzler that may have been discussed over dinner. (He would be dismayed if he knew that we occasionally just watch TV.) Often, he absolutely forbids us from using the compiler.

Whatever: if you're like me, you take your best, thoughtful guess and then fire up an editor to check. Often, this is rushed, because it would be nice to be the first one to post a comment. All too often, I don't get to the verification stage because it is just too much effort. I only have so many public static void mains in me.

These days, I just use Groovy's command-line. It gives me an advantage in terms of speed, and it often makes the problem more fun, because I have to formulate it in a different way.

For example, in the latest quiz, Weiqi says that it can't get much simpler.

In Java, the code is (mostly) as simple as possible:

import java.io.*;

public class Foo {
    public static void main(String[] args) {
        Serializable bar = null;
        System.out.println(bar instanceof Serializable);
    }
}

Yet with Groovy's -e parameter, life is much easier (and faster):

$ groovy -e " Serializable bar = null ; \
         println (bar instanceof Serializable) "

The snippet above has 2 cool elements: (a) Groovy auto-imports java.util.* and java.io.* (e.g. Serializable) for you and (b) it will evaluate an expression on the fly. Because Groovy accepts most Java, this is a handy way to beat the masses to the answer of the Friday Java Quiz.

More than that, it is a great way to answer many quick questions in Java. I often use it in my team's war room when a question arises.

Note: I'm not sure, but I think that -e may have a bug in 1.5+ on a Windows machine. A single statement works fine, but this:

groovy -e " println 'hi' ; println 'there' "

seems to have trouble on a Windows box. Drop a line on your experience.

Ant vs Maven, Episode 2 : Gant or Gradle?

[Editor's note, 2020: those interested in former Codehaus projects may be interested in this link.]

In June, I gave a tech talk on Gant. Gant is a Groovy layer on top of Ant -- essentially Groovy's AntBuilder on sterioids. My thesis was:

• We are in a post-Ant world, and at a crossroads. One road involves continuous integration tools such as Hudson. Another road concerns project framework builds such as Maven. A final road is for general purpose build tools such as Ant. These roads may intertwine, and even build on one another.
• However, with respect to the latter road: we need a new general purpose build tool. We owe a tremendous debt to Ant, and it is still useful, but it has serious problems. First, XML is not a programming language. Second, the Ant community can't decide if it is declarative or imperative: e.g. properties are immutable, except when they aren't. Finally, some of Ant's built-in tasks (e.g. javac) are great: call them "big iron" workhorses; however, the act of "machining" a new task is prohibitively difficult.
• Enter Gant: it rests on top of the "big iron" tasks of Ant, but allows us to work with a real programming language (Groovy) so that simple logic is trivial and new tasks are like working with modelling clay. Put another way, if Ant is a rigid, metal clock, then Gant is weirdly fluid -- yet both keep time.

That was June. Now, alas, it isn't so simple: Gant has had a competitor named Gradle. Gradle is more 'heavyweight' than Gant: it uses a full Directed Acyclic Graph (DAG) and aspires to be closer to something like Maven or SCons. In terms of formal build theory, Gradle is more powerful than Gant. The question, posed on the Groovy mailing list, is how to unify the forces. It is a fascinating debate, and rather important to the Groovy community. I haven't used Gradle so I can't choose, but I will say that I think this direction is the future for build tools: dynamic languages are a great fit for builds. Here is a quick (hopefully correct) rundown:

• Gant rests on top of Ant. It is lightweight and is used as a task management framework in Grails (quite a pedigree there).
• Gradle has strong Ant integration, but aspires to be more than a scripting language for Ant. It has DAG support and targets a space closer to, and actually beyond, Maven.
• In simple terms, Gant is analogous to Ant ; Gradle is analogous to Maven. And so many of the usual arguments apply. However, an open question is if Gradle can serve Gant's position as a lightweight tool (where lightweight itself is open to definition).

If you want to be on the bleeding edge, check out this debate. I'm happy to see that the discussion is civil and intelligent: these are cool blokes. Very interesting.

Razz Your Friends : the best Java Exception ever

Hey! what is this mess? You are totally throwing a CME!

Where CME is defined here (and used metaphorically)

Thanks to CtJ correspondent Steve Holdener for the tip.

I have seen the Future and its name is Ruby

Well, I haven't seen the future, but this guy has... I defer to Future Man for an update on the current state of the language:



ps. Be sure to see the outtake (?) at the end.

Thank You, Java 5

Alex Miller polled Java users and a fair number are still using JDK 1.4. This post is intended for those folks: have hope, there is truly useful stuff in Java 5.

In this post, I will mention a couple of my favourites. These have been well-documented, and are not even the 'coolest' features, but my respect for them has been well-earned over the last few months.

Background

I've been part of a team that has been moving a project from JDK 1.4 to Java 6, and introducing Hibernate/Postgres to replace (in incremental steps) an existing, legacy framework that works with an OODB. This has been a serious refactoring and fairly risky. My analogy is that of putting in a subway transit system into a modern city: it is a massive job, but will be well worth it.

Ten months later, we appear (knock wood) to be finished with a major version of this migration. I've used the following Java 5 features before, but now I am truly fond of them.

The For Loop

When I first saw the new for loop, I yawned:

List<String> list = new ArrayList<String>();

// snip  

for( String s : list ) {
    System.out.println(s);
}

It was a nice bit of syntactic sugar, but I was unimpressed. Now, I can't stand to see an old-style loop. The new loop is so much cleaner. A major bonus for us is that it works with arrays:

String[] array = new String[]{ "abc", "def" };

for( String s : array ) {
    System.out.println(s);
}

As we have refactored, the code literally looks washed and waxed afterwards. Very nice.

Generics

When I first saw generics in Java, I was unimpressed. With a background in C++ and other languages, I understood the point but felt that Java had lost some of its Smalltalk influence, and that the syntax was plain ugly. When I realized the "wall of erasure" (as coined by Brian Gilstrap), I was even less enthused:

List<String> list = new ArrayList<String>();

list.add("Cubs swept by Dodgers.");
list.add("any team can have a bad millenium!");
  
// on a static page, generics allows us to avoid the cast,
// which is boring, and compile-time checking. 
// The biggest advantage is in a good IDE
// where this information comes alive:

String first = list.get(0);

Now, I am an absolute fan. Yes, the corner cases are sharp, and the FAQ is very long for a reason. Yes, we may well need reified types to get full generic capabilities. I don't care: the new static typing of collections saved our project. Seriously. We were wading through dozens of collections in the legacy code and would have never been able to untangle all the knots without Java generics and Eclipse. I repeat: generics saved us, and I am grateful.

The Upshot

We shouldn't suspend our critical thinking and skepticism when it comes to new language features. However, we should also believe that people are earnestly trying to add value when new features are proposed. For one, I am going to keep an open mind when it comes to looking at the new features for Java 7+. Who knows: the features which cause us to roll our eyes may well be our future favourites.

ps. This is another post but unit testing and integration testing (with dbUnit) was equally essential to our success. Of the bugs in new code, my guess is that 90% were in code that was not tested.

pps. We have barely used static imports, but Eric has done some cool things with them. They are underrated, IMO.

Timeout bug with Corba and Java

Just in case this helps anyone searching The Google:

If you see an error message like this (snipped):

WARNING: (COMM_FAILURE) Read of full message failed : bytes requested = X bytes read = Y max wait time = 3,000 total time spent waiting = 3,190

and are using Java 1.5+ with CORBA, then be sure to check out this post.

Essentially, it involves a timeout value on a socket. Changing this property:

com.sun.CORBA.transport.ORBTCPReadTimeouts

is the key, as described in the linked post. Mercifully, we came across this quickly during a recent troubleshooting. It could have consumed days.

A fascinating quote attributed to James Gosling

I have been sitting on this post by Ken Arnold for months now, trying to figure out a way to write about it. I thought of it again today and decided to carpe blogem with some quick thoughts.

Random Thoughts

• James Duncan Davidson has always been too apologetic and too harsh on Ant. Sure, it isn't perfect and may not have been his finest hour, but it delivered us from 'make'; and for that, I'm forever grateful.
• IMO, Gant may well be the next generation of build tools. I'm not sure that it allows the Unix pipes that Arnold mentions, but it is much closer than Ant will ever be. (My Maven friends will, no doubt, chime in here.)
  

The quote by Gosling

I love the (paraphrased) quote attributed to Gosling:

James Gosling once said that every configuration file becomes a programming language, so you might as well think that way.

First, I should point out that I have not authenticated this quote, but Arnold is a reputable source, and this seems consistent with Emacs. Presumably, this was well before 2003, the date of Arnold's post.

This quote shows the power of philosophy: without knowing it, Gosling anticipates the success of Rails and Grails over Struts, and to a lesser degree, the possibility of a triumph of Gant over Ant.

True, this doesn't talk about "convention over configuration" or even web frameworks per se, but it clearly suggests that solutions with static configuration suffer an asymptotic disadvantage, compared to solutions with dynamic, programmatic configuration. The dice are loaded from the start.

Every time I work with Grails or Gant, I think of this quote.

Quotes from an agile War Room : the anti-project

Several developers stand at a white-board, recalling the problems of a previous project.

One after another, anti-patterns are noted and discussed, involving threading issues, micro-level transaction management, absurdly slow unit tests, and scalability flaws.

Says one developer, "Friends, that thing had so many anti-patterns that it was an anti-project".

Observations of a Surfer (in 2008)

Two recent observations that imply that web surfing isn't exactly 'there' yet as a user experience:

Captcha

When I submit a comment to someone's blog, I usually copy my well-crafted, thoughtful comment before running the gauntlet of submit/captcha because I have a subconscious fear, based on hard experience, that things are going to go very, very wrong.

Web 2.0 and Ajax

I have a habit of clicking on a window before scrolling, to ensure that it is 'active'. This was never a problem until all the Ajax stuff: now, that real estate is often a latent feature or gizmo that is just waiting to fire.

I've become subconsciously afraid to click in a browser window: it is a minefield.

The Upshot

I don't know what to do with this information. This may be a silly rant, but it is intended as a sudden realization.

Possibly the Best Quote Ever for Code Maintenance

From the brilliant Top Gear (see 3:00 to 3:30, on this clip of absurd custom limousines):

It is an ingenious solution for a problem that never should have existed in the first place.

Google releases Giant Hadron Collider

CtJ Newswire
Parody City, CA
Sept 9, 2008

While the scientific community waits in anxious anticipation for the commencement of CERN, the Large Hadron Collider, insiders report a stunning development: Google will release their own, open-source particle accelerator. The project is reputed to be a Giant Hadron Collider (GHC), a monstrous piece of engineering powered by thousands of V8 engines. The giant, code-named CHRERN, features 54 km (34 mi) of tunnels, most of which run through the search engine's large, secure data centers over HTTP.

Many scientists have questioned the need for a rival, upstart effort to mimic the Big Bang, but others feel that it is consistent with Google's philosophy. Said one insider, "I suspect that Google has already found the Higgs boson (aka God particle) internally, and are developing the GHC for more ambitious applications".

Claimed another, "it may seem pugnacious at first, but they are basing the GHC on open, scientific standards, and that can only mean good things for science and humanity".

Mini Black Holes? Process Isolation

Skeptics wonder if the GHC is even more prone to creating black holes or singularities, threatening the Earth's very existence. "This is highly unlikely, since the architecture of the GHC partitions each singularity into its own multi-dimensional process. So, if a process goes awry, it will not harm the rest of the universe", reported a chief research scientist. She continued: "this is a distinct advantage over other accelerators, which work in the same process as the known universe. Moreover, it allows concurrent particle acceleration for truly, well, smashing throughput."

Despite all the buzz, there is no word yet if Google plans to explore sub-atomic space with Ad Sense.

The Tone of Chrome : Google's Writing

I have always appreciated Google's tone with respect to their online writing (e.g. privacy policies). They are folksy, conversational, and intelligent.

Tonight, after reading the piece "a fresh take on the browser", I have a new adjective: confident.

No Exclamation Marks!!!

There was something about the text of the above article. I couldn't put my finger on it. Then I realized it was distinct from the usual marketing hype in IT and the mainstream media: no exclamation marks. This hit me like a lightning bolt: it was a bit like when I discovered that the uber-funky Prince song, When Doves Cry, does not have a bass line. It's almost like an implicit, secret message.

The Comic

I had a theory on this and raced back to the Google Chrome Comic. There are virtually no !!!'s there either. I counted only 2 by the main protoganists (there are some others in the background). This seems extraordinary for a comic piece, and I think is a major contributor to the tone.

The Message

I'm no expert on professional writing, or comics. I don't know if Google actually worked with the writers to keep the hysteria factor down, or if they would even talk about the punctuation (though I suspect they would).

My take on the underlying message is that Google is manifesting a serene confidence. They don't need to hype the message. Interesting stuff, and I think an important lesson for both advertising and writers, even if we only write blog posts and/or email messages.

ps. A first observation: Google Chrome and Blogspot seem to be a bit at odds. I wrote this article in "Compose mode" with Chrome and later discovered many empty div and span elements, which created some rather spacey spacing. It is now being corrected in FF3.

The Joy of Hex: online Unicode converters

I was working with Russian strings today (in Java i18n files), and needed a sanity check with respect to Unicode codepoints and hex values.

I found this wonderful site. Very nice.... I am blogging it for future reference and also to share with you.

To the owner, I say: вы (thank you).

ps. For my quick check, the web page fit the bill nicely, but be sure to add native2ascii to your toolbox as well.

3 Lessons from WAX

There is a new JNB article over on my employer's site. The topic this month is a new API for writing large XML documents: WAX. Here are 3 lessons I've learned from the article.

1. Research, Build, Contribute

Mark ran into a real world problem (an OutOfMemoryError when writing a large XML doc), then surveyed the landscape for a solution. Not satisified with the answers, he wrote his own solution and shared his findings with the world. Classic stuff.

2. Use Interfaces to Communicate Intent

The article mentions, as an aside, a clever idea by Brian Gilstrap: the use of interfaces to restrict the usage of the WAX API. For example, one may not call the attr method after using the text method. Brian's idea creates support for a DSL, of sorts, in a static language: it hits a sweetspot that provides compile time support and yet does not use a full-blown parser or dynamic-language DSL.

3. Have Fun

Well, check out the introduction video and see for yourself. I *heart* absurdity !

Quotes from an agile War Room (no. 1)

(Post inspired by Weiqi Gao)

Two developers discuss an urgent issue in an open war room. They decide to pair-program.

Developer A begins to type, pauses, and says:

My spouse and I argued this morning: what colour is my shirt?

Developer B quickly responds:

I believe there is a hue between blue and purple called irrelevant.

Groovy's -e and friends: The Command Line for Java Developers

At the risk of turning this into a Groovy blog, here's an extended comment on a neat post by Jesse Wilson.

With its Java-friendly syntax and command-line options, Groovy opens up some serious possibilities on the command line.

Check out the doc for all the details and examples.

Here are some of the basics:

The -e option

Groovy's -e option accepts a one-liner as the input program. Many languages allow this but few offer such tight integration with Java.

For example, we can format a date. (Note that I'll use Unix-style line continuations here, but these are a single line.)

$ groovy -e " println \
> new java.text.SimpleDateFormat('yyyy.MM.dd G') \
> .format( new Date() ) "
$ 2008.08.25 AD

Note how easy it is to experiment with the format string. I work in an open "war-room", and often use little snippets like this to answer questions on the behaviour of various Java libraries.

Here we use java.util.Random. (Note: Groovy imports java.util.* by default.)

$ groovy -e " println new Random().nextInt(25) "
$ 18

The -n option

The -n option instructs Groovy to use standard input. The doc asks if there is a bug, but it seems to works fine for these examples.

In this mode, Groovy will provide the line and count variables like so (note the content of the file is shown first):

$ cat abc.txt
a
b
c

$ cat abc.txt | groovy -n -e " println count + ' : ' + line "
1 : a
2 : b
3 : c

When combined with Bash, this opens up a whole new world.

Java RegExs

It is difficult to duplicate Jesse's program with a single line. However, it is easy to use Java's regular expressions inline.

First, build an input file:

$ echo "http://codetojoy.blogspot.com CodeToJoy" > foo.txt

Here is the Groovy, in multi-line form for clarity:

// The =~ operator applies line against
// a regex within the /'s, and returns a Java matcher.
//
// The regex is a plain old Java regex.
//
// If new to Groovy, 'def' is like 'Object' (for now)

def m = ( line =~ /http:\/\/([\w.]+)\S*/ )

// Using Groovy truth: if m matched, then the matching
// groups can be accessed via an array.

if( m ) println m[0][1] 

The one-liner looks like this (again Unix-style line continuations here):

$ cat foo.txt | groovy -n -e " \
> def m = ( line =~ /http:\/\/([\w.]+)\S*/ ) ; \
> if( m ) println m[0][1] "
codetojoy.blogspot.com

The Upshot

Grails gets a lot of press, but Groovy offers a lot of utility, even on the modest command line. This is especially true when combined with Unix shells like Bash.

Sometimes, I want to use other tools but this damn language just won't go away as a useful option.

Groovy File IO : Staying at the Ritz

Background

Every few months, I find myself writing a quick utility where, among other things, I want to copy a file. Usually within an hour, I want not only to copy the file but do a simple substitution as well.

I don't have a particular example here, but note that this usually involves some other computation: it isn't something as simple as a Bash script.

I've come to realize that the file IO aspect is often a good benchmark for the 'friendliness' of a language.

Analogies

Imagine that this exercise is like needing a place to stay for the night. I just need some 'computational shelter' to get my stuff done. I'm not looking for anything profound or scalable.

Whenever I'm in Java, and I need to write this utility, I feel like I'm about to buy a house. There is a lot of paperwork involved and the process is not particularly fun. Plus, there is a conceptual mismatch: if I wanted to buy a house, that would be one thing, but I just want to stay overnight.

By contrast, when working with Groovy, I feel like I'm staying at the Ritz (a phrase I use often in person). I feel as though there are people attending to my needs, and they are friendly. Start the bath running, pour some wine, and relax....

Examples

Check out the examples below. The first is a straight copy. This is not an ultra-efficient use of Groovy/Java libraries but it does lead nicely to the second version with a substitution. Note that this is a glorious use of closures as the withWriter method will flush and close the file.

// straight copy (not optimally efficient)

new File('new.txt').withWriter { file ->
    new File('orig.txt').eachLine { line ->
        file.writeLine(line)
    }
}

Even if you don't know Groovy, you can probably grok this code, which are complete programs. Note that x -> declares a parameter (named x) for a closure.

And with the substitution:

// copy with substitution

new File('new.txt').withWriter { file ->
    new File('orig.txt').eachLine { line ->
        file.writeLine( line.replace('code', 'joy') )
    }
}

Upshot

Check out the Groovy JDK and enjoy a luxurious evening tonight!

Executive Summary: Functional Programming meets Indian Cuisine

Don't Attend the St Louis JUG meetings

This isn't reverse psychology. It behooves me if you don't attend the St Louis JUG meetings. Several sponsors give away schwag and the quality has gone up substantially in recent months.

My chances are clearly improved if you don't attend. So seriously: just stay at home idly firing dopaminergic neurons by playing Guitar Hero or Twittering with your new online pals. Wheels down on the couch!

Bonus: if you don't attend this month's presentation, you'll miss a presentation on Classloaders by my friend and colleague, Charles Sharp. That leaves more time for me to ask questions.

Groovy Reference PDF

I have no affiliation with DZone. I enjoy the site and have received a substantial amount of traffic from there.

They have a variety of free "RefCardz": reference PDFs on various subjects.

And, now, there is one for Groovy! I can't resist reference stuff like this. Check it out here if you are interested. It is free, though registration is required (including address and phone number, unfortunately).

Other subjects include Eclipse and Idea.

Greenfoot Hero versus Guitar Hero

First, a rare rant: I am mortified by the popularity of Guitar Hero. If only kids spent half that energy on a real instrument! I assure you that this lad didn't get 46 million hits on YouTube by fiddling with a video game. I don't begrudge Activision for their success, per se, but they could score big, BIG points with me if they donated even a tiny percentage of the earnings to supporting true music programs in schools.

Music aside, it would be cool if our culture celebrated writing software as entertainment, no?

Huh? You might ask. You expect students to enjoy setting up a Maven project, or solving Eclipse classpath issues?

Good point. Enter Greenfoot, a delightful framework for Java that provides both a platform for learning about programming and even a way to quickly prototype domain models and games.

Check out this article by my friend/colleague Nathan Tippy for more details, and a walkthough of some projects. I did, and was blown away by Greenfoot: it abstracts away the tedious aspects of development and provides the opportunity for endless creativity.

Wouldn't it be great if there were competitions and adulation for "Greenfoot Hero", where kids got together to exchange ideas and programming hacks?

Executive Summary: Reasons Why The Code Sucks

inspired by Graph Jam

Lonely Planet for Languages

I've recently noticed a similarity between these 2 phenomena:

• the joy of listing the number of languages which we have worked
• the allure of listing the number of major cities to which we have traveled

Hello, Airport

Most people will qualify their travel list, by saying, "well I've been through London, but just the airport so that doesn't really count". (Indeed, it doesn't.)

I think geeks are less likely to qualify their language list: at least I don't. You won't catch me saying "well I've written Hello, World in Haskell so that doesn't really count".

Now to be honest, I wouldn't even put Haskell on the list, but it is true that a static list of my languages doesn't give anyone a real sense of my experience.

Staying at the Language Resort

A better example, for me, is Python. I have been proselytizing Python for a long time: the spirit of the language appeals to me and I am never happier than when working with the language.

But to be honest, I stay at "Club Python": a sunny resort where the beaches are pristine and the drinks are free. Life is easy.

I've never had to deal with packaging a Python app; I've never had to internationalize one. Or even really debug his/her lousy code in a commercial Python app. I certainly haven't had to deal with scaling issues.

Not to say that this can't be done in Python: I just haven't done it.

Lonely Planet for Languages

To mix metaphors, be sure to evaluate the experience of evangelists. Don't take travel advice from someone who went through the airport. If you are looking for a resort, that's fine, but what we really want is someone who knows where the locals eat and where the food is fresh. A battle-scarred veteran who has suffered an exotic fever and has seen all 4 seasons in the locale. One who has the guts to try speaking the local dialect, and yet the cunning to escape a pub alive when they have inadvertently insulted the national soccer/football team.

For a given language, seek those who could write a Lonely Planet guide for the language.

Executive Summary: charting the act of debugging

A new theme, inspired by the delightful site GraphJam.... Stay tuned for more ahead.

DVD Extras

As part of combating the summer blog doldrums, I am considering a theme of DVD Extras for CodeToJoy.

No, there is no CtJ DVD. Essentially, this is an analogy for outtake photos and other silly posts that were left on the cutting room floor. The tension is that the quality of these posts, by definition, would not measure not up to the usual high standard.

The hope is that the banner of "DVD Extra" would mitigate the "outtake quality" of the posts.

Leave a comment or drop me a line if that sounds interesting...

Code Reviews

Many have noted that it has been quiet here at CtJ HQ. This has been due to vacation, summer activities, and partly the giant vacuum left behind by Twitter (I have resisted the autonomous collective so far). Bloggers tend to play off each other, but the wealth of ideas have been reduced to traikus (an attempt to use the haiku form to communicate, a la "nice try") and other short status updates.

Someone must keep the home fires burning, and so your humble host writes from his quiet perch, while the twittering masses party in the streets below.

This article is a good conversation piece: it lists some elements of code reviews. I could leave a comment, but in the classic tradition, I'll blog mine here.

Prime Directive

I work in open war-room that ranges from 4 to 8 people. The benefits of a war-room are outside the scope of this post, but it may shed light on this element.

The prime directive of an effective code review is to examine the code with an eye to the team philosophy, both from a domain and technical standpoint.

Let's consider technical philosophy first: a team should have a solid, unified view on a variety of issues. Are unit tests required? Do we test getters and setters? How do we handle exceptions? Where do we place inner classes in a file? And so on. (Note that this presumes that the team has read the classics (Effective Java, etc) and that the issues therein are 'settled'.)

The key is to maintain consistency. If there is no consistency or stated philosophy from the tech lead, it should be discussed. But once it has been decided, it should not be debated. All too often, a code review can re-open a debate, but for efficiency, avoid this (unless something isn't working out). IMO, the philosophy should not be written down (the code is the example).

Establishing consistency is a major benefit in a war-room. If a team is still "partying like it's 1999" in cubes, then the stand-up meeting can help here.

The domain philosophy is similar. Questions include: if we upgrade from a previous version, and have 2 Foo objects with the same id, what happens? Should a user be allowed to delete a Foo when it is still linked to a Bar?

Code Coverage

As a reviewer, it is natural to ask if the person wrote unit tests. A good follow-up is to ask them about code coverage. The coverage should meet the level established by the team philosophy. Ditto for code complexity metrics.

Internationalization

Beware of hard-coded strings. Reviewers should always be aware of the context where strings are used, and understand which contexts require locale bundles.

Concurrency

Ask the developer if the code is thread-safe, or if it runs in a multi-threaded section of the code. There is a high probability that s/he will look up at the ceiling involuntarily (that's where all the answers are), and pause for a moment. Hijinx ensues.

Versioning

Universities do not have classes called "Versioning 401" and yet it is one of the biggest challenges we face. With respect to data, the team should be aware of versioning issues. e.g. The lifecycle of data across releases, the migration algorithm, and so on.

This is a giant trap for new persistent objects because often the ramifications are not seen for a long time.

The Upshot

Team philosophy and consistency is important, and there is no better place to see it in action than code reviews. Well, there is one better place: pair-programming. But that's another post.

Willy Wonka and the iPod Factory

Even the letters-to-the-editor in Wired are better than most articles in other magazines.

Monica Kerschner posted a comment here, which was printed in the July 2008 issue.

Quoteth Monica K, on the topic of Steve Jobs:

" I'm reminded of another CEO [snip]. This gentleman was equally perfectionistic, shrouded his company in secrecy, and was so rude to customers that he allowed one to be turned into a blueberry. Yet he created one of the most popular and profitable products in the world. This other CEO is fictional, but that's about the only difference between the crazes over Willie Wonka's chocolates and Apple's iPod. " (full quote here)

Brilliant. Love it.

The Forgotten Argument for Closures in Java

Background

This article is an excellent summary of the various closures proposals for Java 7+.

However, in the opening paragraphs, it implies that the case for closures are:

(a) a closure is a classic, useful programming construct

(b) the cool languages have them and enjoy increased expressive power

This is all well and good.

But Wait

However, there is another argument, as espoused by Neal Gafter (and reported by Alex Miller). Essentially, it is as follows:

• Multicores are coming (the free-lunch is over).
• Brian Goetz is cooking up a new fork-join library for concurrency (JSR 166).
• BGGA closures simplify the API for JSR 166 (as evidenced by a prototype).
  

This argument can be debated in two ways:

(a) do we still want closures, even with this info?
(b) which closure proposal is the best for this simplification?

With respect to (b), it may well be true that the other proposals also simplify the API.

Either way, this is a major motivator and thus a central argument.

The Upshot

Don't be fooled by posts that imply that the closures proposals are "keeping up with Scala or C#" or especially "driven by the elite language lawyers" (which drives me crazy).

As Dick Wall has said, we should assume that all of the key players are earnestly trying to do the right thing for Java.

One of those things is simplifying Java's use of multicores. You may still argue against closures, or BGGA, but be sure to include it in your analysis.

ps. One may well ask for a simple, concrete example of the simplification with BGGA. Alas, I don't have one at hand (the JavaDoc is provided here, but it is not a good illustration). Please post a link in the comments if you have worked with the prototype.

Gant crushes XML in poll

CodeToJoy Newswire
St Louis, Missouri
June 2008

Revelers in St Louis were recently polled on their preference for an all purpose build-tool. The choices consisted of:

• Gant, a build-tool which fuses Groovy and Ant
• Traditional build-tools which use XML configuration
  

In a severe blow to XML, Gant dominated the competition. Pundits around the globe noted that this result reflects the groundswell movement toward Gant and other build tools that provide innate, full-blown language capability.

In this montage, CtJ documents many of the votes cast.





When asked if they believed that Gant will usher in a new era of build libraries, some voters, shown below, answered "Dude!" in a tone that implied the answer was obvious.


Members of a local band, Gumbohead, chimed in with their votes, citing pragmatism: "We appreciate the debate between declarative and imperative languages as much as anyone, but at the end of the day, the build is a cornerstone of every project and we need tools that are simple and powerful."


Throughout the evening, there was little support for XML. Said one woman, "XML is fantastic for data exchange but when you need conditional or iterative logic, things just begin to break down."







In the end, Gant carried the day. Some weary XML supporters left the venue, and held their own party in a goth nightclub in another part of the city. They lit candles and used spoken-word sessions to express their angst at being trapped in a world full of angle brackets.

Domain Specific Error Messages

Background

As defined by Fowler, an internal DSL uses a host language (e.g. Ruby, Groovy) and an external DSL uses a full-blown parser (e.g. ANTLR).

In the latest JNB article, Mark points out that internal DSLs must live within the syntax rules of the host language. This is fine if the audience is composed of software developers, but what if the domain is microbiology?

The following might not be clear:

if( specimen.isBlood && test.isAmpicillin ) {
 test.doAlert
}

However, this is debatable: maybe it's ok. Maybe an internal DSL can whittle down its host syntax so that it is reasonable. Debate among yourselves.

The Universal Issue

There is one universal issue for both developers and microbiologists alike: we make typos. We can bend internal DSLs to look good, but what happens when we make a typo? Will the error message be meaningful for a microbiologist? Or would it reveal the host language with a dev-oriented message?

For example:

if( specimen.isBlood && test.isAmpicillin
  test.doAlert
}

Now, what if one were to use ANTLR? Can we get a level of error reporting such as:

Could not understand the statement.
Possible cause is mismatched parentheses.
Please type '-help' for a language synopsis.
Please type '-samples' for quick examples.

What if the grammar were even simpler, such the following, but there is a semantic problem:

if specimen.isAmpicillin and test.isBlood
  test.doAlert

Could we get a domain-specific error message such as:

Error: 'ampicillin' is not a specimen
Error: 'blood' is not a test
Check appropriate values for 'specimen' and 'test'
with '-values'.

I don't know the answer for either internal or external DSLs. For the latter, I'm going to this month's StL JUG to ask the question. See you there.

Control-F on a Macbook Pro ?

Generally speaking, I am enjoying the new Macbook Pro. As expected, I am adjusting to the keyboard, not an easy feat considering my enduring love for my ancient, bacteria-laden Microsoft Natural Keyboard Pro.

However, I have noticed that when using vi on the MBPro, that I am at a loss as to how to form the Control F key. For reference, look at the Wireless keyboard at the Apple site (click here).

Right now, I'm using an inelegant, ridiculous gesture: left-thumb on Ctrl and and right-index on F. It is like a novice pianist trying to play a Chopin piece. Or like an Emacs user trying to do, well, anything. (I am convinced Emacs was originally a set of isometric exercises for guitarists and pianists alike.)

How do you type Ctrl F ? It seems like a beast for the left hand. Left-pinky on Ctrl ?

Betcha Can't Break This: Spoiler

If you haven't read the previous post, and would like to give it a go, skip this post.

SPOILER Ahead:

Here is one way to print 'something nefarious' in the Groovy program:

groovy ez " String() ; println 'something nefarious' ; new String"

It is clearly inspired by SQL injection. I tried using categories and some other tricks but everything else failed.

I'm writing this right after the original post, and scheduling publication for this afternoon. I'm looking forward to seeing solutions.

Betcha Can't Break This: A Groovy Puzzler

The last post featured a little program:

def input = args[0]
def theObject = evaluate( " new ${input} () " )

println theObject.toString()

Ricky posted an excellent comment that exposed a security problem. Consider this:

// replace the println with something mean
// e.g. deleting files

groovy ez " Object(){ println 'something nefarious' }"

A strong attempt, but it won't work because, as best I can tell, Groovy doesn't support anonymous classes. (This is not a problem, thanks to closures).

Challenge

Can you find a value for args[0] that prints 'something nefarious' ? I tried for a long time before I saw an answer. The exploration is a great way to test your Groovy Kung Fu.

I will schedule an "answer post" for 2 pm Central US.

About the Title

In truth, I have no doubt that someone will break this.

The title is a play on "Betcha Can't Play This", a video segment by the magazine Guitar World. In the segment, virtuoso players show off a lick that is usually extremely fast and highly technical. Though there are wonderful exceptions, most are musically vacuous and are technical scales or arppeggios: you can tell when they play it slowly.

Interestingly, the parallel between music and software is strong: these puzzlers are pure "syntactic studies" (etudes!) that don't really offer much use to real end users with real problem domains.

Beyond Reflection

Consider this problem:

Write a program that takes a fully qualified Java class name as input. The program should call its no-arg constructor and print out the object's toString method to prove the object was constructed.

Think on that one. I'll wait.

One Solution

You might think "I could do that with reflection, but I can't be bothered looking it up right now".

Righto: me too. So I didn't write the program that way. Note that the problem statement doesn't say write a Java program. I used Groovy. Here it is with some executions:

$ cat ez.groovy

def input = args[0]
def theObject = evaluate( " new ${input} () " )

println theObject.toString()

$ groovy ez java.util.Random
java.util.Random@9478c7

$ groovy ez java.util.concurrent.atomic.AtomicInteger
0

Executing Data

The key here is that evaluate allows us to execute data. This idea is hardly new, but one of the most powerful features for any language.

Note that this program will work with any class available on the classpath (provided that it has a no-arg ctor).

At Work

I've used a broader example recently at work. I wanted to give domain experts access to an OO database, using an existing, proprietary Java framework that provides a standard API.

The idea is roughly like so:

• Ensure the classpath contains the OODB, the framework, etc
• The program accepts a domain object and desired value field
  
• The program builds an evalString as input to evaluate
• The evalString contains all potentially-necessary imports
• The evalString opens a transaction, accesses the object to print the field, and closes the transaction
  

In pseudocode, the template looks like this:

def importString = " import com.abc.foo.* ; ETC"
def evalString = importString + """

def txn = new Transaction()
txn.open()

def theObject = ${args[0]}Factory.build()

println theObject.get${args[1]} ()

txn.close()
"""

Note that the above isn't true Groovy, but you get the idea.

The Upshot

This is a wonderful example of the power of executing data: particularly on the JVM. Note that this isn't some obscure academic exercise. I have seen at least 2 people look at this code and say "I need that program".

And yet it isn't rocket science: anyone could have written it, before Groovy came along. But the friction of Java's reflection was just too much of a deterrent.

This is exhibit #37 in the case of "why it is not wasteful to learn new programming languages".

Kudos to Ivy Tutorial

Recently, I wanted a quick example of using Ivy with Ant.

I had been reading through the newer Ant in Action book but felt like I was on a big yak shaving expedition.

Then, I came across this tutorial in the docs. Note the self-sufficient build.xml file that has an embedded HelloWorld program and targets that make a working Ivy example, out-of-the-box.

Fantastic. Thank you, Ivy. This is a nice example of a foothold, and an object lesson in effective examples for other projects.

What to do with old hardware?

The Java Posse recently had an interesting spot on the topic of old hardware: recycling and/or donating to schools etc.

This is a timely topic for me as I have an aging, beastly CRT monitor. I am dreading the thought of moving it from my apartment: it is heavy enough to be a bugger for one person, yet too small for me to actually ask for help lifting it.

I can probably hoist the thing into my car, but it would be nice to know that I am risking major back pain for a good cause.

For the locals: does anyone know of a place in St Louis that accepts old hardware for either recycling or re-purposing (pardon my verbing) ?

For others: what do you do? I'd be willing to consider shipping charges to send it somewhere in the US.

Hmmm.... The real question: is there a website that co-ordinates such organizations? A site where you click on the map and it lists the various places for this kind of thing. (Aside from straight-up Google, Google Maps, etc).

The Sound of Music: Podcast Themes

For a random sidebar...

What are some favourite podcast themes? No, not the content per se, but the catchy bumpers at the beginning and end of the casts.

Some thoughts on podcasts on my playlist:

• I'm a guitar fan so the theme at Software Engineering is a winner, and the inspiration for this post. The music is punchy, upbeat, and they always seem to fade it in and out just right. By the way, this week's guest is Anders Hejlsberg.
  
• I really like the end theme/outro for Java Posse. The retro synthesized voice is delightful. The famous opener is sufficiently catchy and irritating to burrow deep into your consciousness, which is really the point.
• Man, the band phoned it in for CNet's Buzz Out Loud. The theme is musically bankrupt, and they barely let it play, which may be merciful. However, I'm always suckered in by Molly Wood's brisk whirl through the subtitle "podcasts of indeterminate length". Nice.
• For the Google Developer Podcast, the immediate opening isn't for me: it's punchy but something is not quite there. But when the wah guitar kicks and the woman begins to sing, I'm completely on board. Great voice and a cool vibe. The fade in is very erratic in terms of length, but at least they give the tune lots of space as the outro.
  

Yours?

Fitness as a Competitive Advantage

Jeff Atwood blogged recently about cleaning the monitor and the keyboard.

Some quick thoughts:

• A big +1 on not touching the monitor. I cringe every time anyone touches any monitor. It actually distracts me during code reviews.
• Keyboard manufacturers should figure out a way that the electronics can be removed easily (like a cartridge) to enable dishwasher use.
• Jeff mentions "my" keyboard: I guess he doesn't work in a public war-room. Believe me, that is a whole new, fascinating ballgame. More to come sometime.
• I don't condone filth, but I'm not convinced the neat-freaks have it right, especially with those cleaners that clean 99.5% of bacteria. Hmmmm.... no training for the immune system and we leave The Nasties to party. Is that a good idea? (As an aside, check out this article on germ factories (aka children) and the beneficial effects on parents and pediatricians.)

On to the point: presumably, Jeff wants to clean his keyboard so that he doesn't get sick. However, that is only half of the equation.

It is well-documented that moderate exercise can boost the immune system. So one could argue that we owe it to our teams, our careers, and our families to get out there and work out.

Maybe you do so. Maybe you do more than me. But if not, I'm not talking about doing an Ironman (though a sprint triathlon is a fantastic accomplishment, and much easier). I'm suggesting a 30 minute session 3 times a week, where the heartrate is elevated. Don't go for a walk: that's ok, but if you want to fight germs, aim higher.

There are other benefits as well:

• You know those "aha" moments in the shower? Well, athletes shower more often: more aha moments.
  
• It's not quite as magical as the shower, but if you swim or run, it is a phenomenal way to work out problems, without trying. The whole subconscious/background cooking thing.
• I hate the pseudo-verb "network" but if you find your niche, you'll meet all kinds of new people. Bonus.
• I have friends/colleagues who train in mixed martial arts: that's gotta be a stress reliever.

I ain't preachin'. I ain' teachin'.

I'm just sayin'.... Something to consider.

For those who are active: what do you like to do?

Logical Fallacies Considered Harmful: You Should Learn New Languages

Gustavo Duarte recently posted an article about the folly of dabbling in new languages.

The post is an earnest one, and thought-provoking, but I realized this evening that it is a masterpiece of logical fallacy.

Problem #1: Begging the Question

Gustavo argues that "dabbling" in new languages gives superficial results to your career. To dabble is to "work at something in a superficial manner". So, the argument is that a superficial investment in something yields superficial results. Hmmm... this seems like begging the question to me.

Note that I don't mean the popular usage of "that begs the question: yada yada" but rather the classical sense of proving something that is implicit in the premise.

Problem #2: The Strawman Argument

Gustovo condemns the Pragmatic Programmers' advice to "learn a new language every year". But he goes on to set up that advice as though they are saying "Open an editor, screw around with some syntax, and wait for the enlightment to hit you". Then he knocks that Strawman down, with ease.

I just checked the Prag Prog book: it is relatively terse on this point. I may be guilty of my own "Ironman Argument" here but, having seen Dave Thomas speak on several occasions, I doubt if they intended for us to take a full year to merely mess around with some core language syntax. My guess is that they will agree with the examples in the next item.

Problem #3: False Alternative

Gustavo seems to set up two choices: either noodle around aimlessly with a new language, or learn something specific with your current language, such as algorithms, math, or AI.

Wow. We have hit the trifecta now with the fallacy of false alternative.

There are more than two choices. Let's assume that we only know Java. How about these examples:

• Write an implementation of a Red-Black tree in Scala.
• Compute Pi to a million decimal places in jRuby. Then check an online source to see if you are right.
• Develop a simulator for Tic-Tac-Toe that uses genetic algorithms to evolve a winning strategy. Use Groovy.

Sounds fun to me! Personally, I would learn (or dust off) something from all of these examples. And we would learn a new language along the way.

Problem #4: When timeless arguments aren't timeless

This isn't a formal logical fallacy, but Gustavo hints at some classic, timeless elements such as Lisp and the "Gotos Considered Harmful" article.

One might think that his arguments are timeless: nope. He asserts that:

In reality learning a new language is a gritty business in which most of the effort is spent on low-value tasks with poor return on time invested. You need to get to know the libraries, struggle with the environment, find or tune a text editor, look for tools, and so on.

This was true in the past, but with languages on the JVM and the CLR, we are in a golden age. As proof, consider the 3 examples above: all of those languages are a simple drop of a jar file and allow the use of the Java libraries. They run on the JVM. (Ted Neward has given entire keynotes on this idea.)

I will grant that the debugging/IDE facilities won't match Java, but this argument is completely bogus.

Problem #5: Confusing Momentum with Inertia

Again, this isn't a fallacy per se, but I take issue with this:

There’s another pernicious effect to language hopping: it hurts your momentum. Every time you rely on your current languages you get a little better.

Last year, I blogged about using Groovy to interrogate an OODB. My team still uses that tool. Anyone on the team could have written it in Java, but in the span of 5 years, no one had done so.

That's not momentum. That, my friends, is inertia. My little Groovy program is one of the biggest contributions I've made to that team: people ask me for it all the time.

The Upshot

Gustavo ends by recommending that we learn languages that are orthogonal to each other. I agree completely. And, for the record, I agree that merely dabbling is dangerous: I have probably been guilty of it myself.

But I heartily recommend learning a new language. And learning as much as you can about logical fallacies. They are everywhere (in this post?).

Satire Development Kit: Democrats Use Groovy To Pick Candidate

This is our first SDK: a Satire Development Kit that allows you, dear reader, to create your own satire, tailored to your own taste.

In this case: political taste. And we'll will learn a bit of Groovy along the way.

Architecture

The SDK is based on these steps:

• No matter where you may lie on the political spectrum, you may agree that the process to pick the next Democratic presidential candidate (in the USA) is complex. It involves a mix of delegates and super-delegates.
• Groovy is apolitical, but uses delegates to resolve references in closures. Since delegates may be objects, they may be derived from other objects, which we'll dub super-delegates.
• Punchline: this is up to you. We just provide the tools.

Minimalist Example

class Foo {
   def bar() { println "hello" }
}

def c = { bar(); }
c.delegate = new Foo() // delegate is a keyword

def candidates = [ "Clinton", "Obama" ]
candidates.each( c )

In the above example:

• candidates is an array that has a closure, c, applied to each element
• the closure calls bar()
• Groovy will search for bar(), first in the owning scope of c (the script itself), and then, if necessary, in c's delegate
• Groovy will not find bar() in the owning scope, but does find it in the delegate, which we assigned as a Foo

Full Example

Below, we have a full example where a self-named Delegate object acts as the, well, delegate and derives from the SuperDelegate, which can pledge (or not?) for a candidate.

class SuperDelegate {
  def clintonPunchline = "TODO: fill in"
  def obamaPunchline = "TODO: fill in"

  def pledge(def candidate) {
      if( candidate == "Clinton" ) {
          println clintonPunchline
      } else if ( candidate == "Obama" ) {
          println obamaPunchline
      }
  }
}

class Delegate extends SuperDelegate {
  // defer to base class
}

def convention = { it -> pledge(it); }
convention.delegate = new Delegate()

def candidates = [ "Clinton", "Obama" ]
candidates.each( convention )

The Upshot

Simply fill in the punchlines in the above Groovy script, and you're all set to lampoon (or support) one of the Democratic nominees -- or both -- via a dynamic language on the JVM. The direction of your satire is up to you. Impress friends and family no matter if you are a Democrat, Republican, independent, or international observer.

Enjoy!