Wednesday, October 03, 2007

The Last Language War / Language Trolling Post You'll Ever Need To Read (Hopefully)

Moderator: Greetings, and welcome to the First-And-Possibly-Last-Ever Pan-Computer-Programming-Language Conference (FAPLEPCPLC). I am joined on stage tonight by many distinguished, high-profile computer programming languages. Each is highly regarded by its devotees, and I for one look forward to hearing what each has to say.

Ruby (grabbing the microphone): Um so yeah I'd just like to kick this bad boy off by saying that THE REST OF YOU SUCK A**!!! Yeah, I said it! The A-word! A**! Oh yeah! Boom, baby! Woo! Ruby FTW!

Java (rolling its eyes): Oh, real mature. I, on the other hand, would like to state that I have important work to get done in the Enterprise, so let's not waste everyone's time. I suggest we proceed using the Computer Programming Languages Discussion Pattern as implemented in JSR-6942, the Java™ Absolutely Void-of-Acronyms Talking About Languages at Konferences (JAVATALK™ which by the way is not an acronym for anything) specification.

Ruby: Dude! I just wrote a full working clone of Google while you were giving your riveting little speech there!

Moderator: Oh, bravo, Ruby! I'd like to see that. Where is it deployed?

Ruby: Umm....

Lisp: In the beginning, there was the Lambda. And John McCarthy saw the Lambda. And John McCarthy saw that the Lambda was very good.

Ruby (rolling its eyes): Here we go...

Lisp: And John McCarthy spake, and lo! the tongue he spake was sexp...

Ruby: He said sex! Heeheeheeheehee!

Erlang: If I may, I've been running some ideas by the other panelists, all at the same time of course, not that that's any big deal...

Ruby (rolling its eyes): And here we go with the concurrency...

Java: Gosh darn it, Ruby! There's no need to pooh-pooh everything someone else says, eh?

Ruby: He said poo-poo! Heeheeheeheehee!

Java: Ruby, I swear, one of these days...

Ruby: Hey, don't give me any of your static! Heeheeheeheehee! See what I did there?! "Static"?! 'Cause I'm so dynamic?! GET IT?!!! DAMN, where's my BAWLS Guarana...?

Ruby (seconds later): I said balls! Heeheeheeheehee!

C#: Developers! Developers! Developers! Developers!

Erlang: ...I'd share my results with you, but it's going to take a while to retrieve them from the filesystem...

COBOL: keels over, only to be frantically revived by about three banks.

Basic: Actually, I have a question for Ruby...

Haskell: Me too...

ML: Hey, Ruby, what's your answer to...

Ruby: Hey, hey, hey now! Not too many at a [segfault]

Java: smiles

bash: kill -9 self

The Lambda Calculus: Actually, if we could all just take a moment to reflect on the implications of the Church-Turing thesis...

Everyone Else: Oh, SHUT UP!!!!!!

Scala: says nothing, but sits quietly observing, taking notes, and learning a lot.

Moderator: Well, I think it's about time to bring some closure to this, um, lively...discussion...

Java (sharply): Hey! We're working on it!

Lisp: ))))))))))))))))))))))

Java 1, Intuition 0

Pop quiz: If you were given the following snippet of code:
"".split("\\s");
...what would you expect the result to be?

If it helps, the contract for String.split() is that it takes a regular expression (in this case \s means "anything that could reasonably be considered whitespace, like spaces, tabs, et cetera"), and returns a String[].

My intuition was that it would return an empty String[]. (Author's Note: which would have been better than a null, but even that's not what I got.)

I mean think about it: what does it mean to split the empty string, on any character? The empty string has length 0, so what can you split it into? Two strings of length 0? But then you could do that ad infinitum, which would be silly.

So what Java actually does is return an array with one string: the empty string, or one string of length 0. Which implies that Java thinks the beginning of a string -- represented by the regex \A, or ^ if you know the string you're regex-ing doesn't contain newlines -- is significant, but the end of a string (\Z or $) is "whitespace". I guess you could make a case for this making sense, but it doesn't match up with my intuition.

What do you think?

Thursday, September 20, 2007

Scala Alert: bootclasspath/a Considered Canadian

Author's Note: Please forgive what is, essentially and unfortunately, a very bad pun. It's late, and I've had a long week, what with my Automata exam coming up and all. And, for the record, I have nothing against Canadians. James Gosling is Canadian. So is William Shatner. I once lived in Vancouver. Please don't hate.

So I was looking at bin/scalac and bin/scala, the Scala toolset equivalents of javac and java, and I found myself learning some stuff. For instance, scala (which executes a Scala, um, executable) is simply a shell script that sets a bunch of shell/environment variables and finally runs this command:

${JAVACMD:=java} ${JAVA_OPTS:=-Xmx256M -Xms16M} -Xbootclasspath/a:"$BOOT_CLASSPATH" -cp "$EXTENSION_CLASSPATH" -Dscala.home="$SCALA_HOME" -Denv.classpath="$CLASSPATH" -Denv.emacs="$EMACS" scala.tools.nsc.MainGenericRunner "$@"

This points out some interesting interestingness. First off is: Scala executables are ultimately run by...java! Or what passes for it on your system. Pretty neat, huh? Although it makes total sense if you think of java as the command that starts up a JVM on some arbitrary .class file, not the command that runs a Java(TM) language program.

(Author's Other Note: Scala code gets compiled to JVM-compliant bytecode. Which is proof that real closures are theoretically possible in Java(TM). Although they are not likely to happen in your lifetime. But I digress.)

Second off is: buried amongst the options to java is the non-standard -Xbootclasspath/a:"$BOOT_CLASSPATH". Unlike plain ol' -Xbootclasspath, this option lets you append some arbitrary jars to the regular bootclasspath (hence the /a). In this case, what it appends is $SCALA_HOME/lib/scala-library.jar if it exists, which gives the executable access to the Scala standard library. Which includes among other things the package that implements Scala Actors.

P.S.: It turns out there's also a -Xbootclasspath/p, which stands for "prepend", but is not as funny when applied to Canadians.

P.P.S.: I like the option to provide a default value for some environment variable that may not exist on a given system (e.g., ${JAVACMD:=java}).

P.P.P.S.: EMACS??? What the heck does that have to do with running a Scala executable? Time for some more research, eh?

Friday, September 07, 2007

Recommended Reading: The Linguist

Do yourself a favor: start reading The Linguist, by Steve Kauffman, who speaks 9 languages and founded thelinguist.com as a resource for those who want to learn a new language. I particularly like the following quote, from the entry Why children learn languages better than adults:
Children have not yet been converted from naturally curious language explorers into teacher-dependent grammar learners.

I took Spanish for three years in high school (Hola, Srta. Chambless!), and I was very fortunate that my teacher taught the class in Spanish, and required us to participate by speaking Spanish. After the first six weeks of the first year, no English was allowed, and precious little during that time. It was brilliant. It forced us to learn Spanish the way kids in Spanish-speaking families learn it - by experiencing it and figuring things out, not by sitting at a desk with a vocab list and a dictionary.

I've often wondered why no one has developed a computer language training curriculum modelled after some of the more effective human language training methods. But that's beside the point of Kauffman's thesis above. Ultimately, we learn what we love. And we love what we find out for ourselves as the result of exploring the things we find interesting, not what is hammered into us by some random instructor.

Friday, August 17, 2007

Scala: The Next Next Java!

Yeah, yeah. I know. It's only been recently that Erlang has started being touted as "the next Java". I just thought I'd get a jump on crowning the next next Java. Oh, sure, no one gets to officially be The Next Anything without a Pragmatic Bookshelf book backing it, but I'm sure it's just a matter of time before a Scala book is announced.

After all, Scala shares a lot of the advantages of Erlang -- principally, its support for Actor-based concurrent programming and hence its powers of super-scaling. But it also has a secret weapon that Erlang doesn't have: it runs on the JVM! Yes, that JVM! It also has access to the multitudinous multitudes of existing Java libraries out there, making for a (potentially) easier migration path.

No need to wait for Java 7 (or (possibly much (much)) greater) for closures in Java! Write some Scala scaffolding around your existing Java classes and have them today!

Le roi mort! Vive le roi!

Thursday, August 09, 2007

The Good, The Snide, and The Ugly (More on Autoboxing)

Wow. You know you've hit the big time when famed Java geek author Norman Richards gets all snarky on your sh*t. I would like to point out, though, that I never said autoboxing was "evil". I just said it was !cool. And no amount of Richards' sarcastic aping of my (deliberately) satirical-yet-lighthearted take on it is going to convince me otherwise.

The problem, of course, lies in the fact that, pre-autoboxing, there was no question of an assignment to a variable of type int throwing an NPE. For the first 87% of Java's numerical-version-life you just couldn't do it. The concept had no meaning, like the questions "what is north of the North Pole?", or "what color is up?". Or "can I borrow your copy of 'XDoclet in Action'?" (Author's note: because no one in my office has one).

Pre-autoboxing, Eclipse would have flat out disallowed the assignment of an Integer to an int. And here's the important point: Eclipse would have disallowed it, because the compiler would have disallowed it. Because you couldn't assign an object reference to a primitive type, inadvertently or advertently. It wouldn't be a legal assignment, so it wouldn't compile, so there would be no way for it to throw an NPE in production. That's what static typing is supposed to ensure.

In true famed Java geek author style, though, Richards totally misses the pedagogical point when he uses as his sarcastixample the potential NPE-ness of code that deals with String. Which is an object type. Which has since the beginning of Java time been subject to NPE's. As opposed to primitive types. Like int. Which have not. Until autoboxing rocked our world and broke static typing.

I've actually been waiting for someone to snark on my (deliberately) satirical-yet-lighthearted insinuation that I rely too much on my IDE. That was the first point I took away from this whole exercise, and believe me I will be more wary in the future. I'm pretty sure I'm not the first to be burned by such an over-reliance. But in this case, even if I were using Emacs and the command line, I would still have fallen victim to this problem. The fault lies in the language, not in my reliance on any tool.

Bottom line: I don't think it should be too hard to excuse someone who, when seeing an NPE in his stack trace, doesn't leap immediately at the assignment to the int variable.

But maybe that's just me.

Tuesday, August 07, 2007

Autoboxing == !Cool

So you're finally getting used to the idea of Java 5's "feature" of converting between primitive types and their corresponding object wrappers (e.g., int -- Integer). You're getting to the point where you kind of trust it. You're even getting to the point where you kind of rely on it. Life is good.

Then you go too far and try something weird and exotic like, oh, I don't know:

int sucker = thisMethodReallyReturnsAnIntegerNotAnInt();

No squiggly red line in your Eclipse editor. Cool! That must mean this will work! Because Java has static typing, and you can count on that! Yea you!

The problem is, it will work. It will work very nearly all the time. It will work until your method returns a null instead of an actual Integer. At which point you'll get a NullPointerException buried in your Struts 2 / OGNL / JSP project's Eclipse console stack trace, followed by a two-hour detour into the debugger wondering what the heck is going on. I mean after all, your code compiled, right? It worked for the first hour, right? Static typing is good, right? Autoboxing works, right?

Not that you're bitter.