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.