Will there even be a next big language?

The ongoing discussion about Javascript as the “next big language” seems to assume that there will definitely be a next big language and it is simply a matter of clairvoyantly predicting which will be the one you should immediately begin placing all your eggs into.

Steve Yegge has arbitrarily, matter-of-factly hypothesized ECMAScript to be the chosen one without much justification. Others are gambling on Ruby. Meanwhile, Microsoft, the lumbering giant that no longer scares the shit out of people, is borrowing some features from the ML family for the next release of C#; it is definitely staying well within the boundaries of strong, static typing. The Java community has realized the folly of overly complex infrastructure like EJB2 and now are happily zooming along with their outstanding IDEs and XML-addicted frameworks; the smarter elements of them are looking for something beyond Java, preferably one that doesn’t involve abandoning the JVM altogether, like JRuby. There’s still so much informational asymmetry and inefficiency in how technologies are chosen and used that Java, C#, Ruby, and PHP aren’t leaving the scene anytime soon.

Doesn’t the lack of clear consensus here indicate that there might not even be a single winner to arise from all this? Even within individual communities, fragmentation is occurring. There’s already multiple Ruby implementations with more on the way. Ruby may fragment into 2.0 and pre-2.0 groups when the time comes. There is no clear winner for how to do object-relational mapping in .NET. Framework proliferation continues in Java, even for specific parts of the development stack; do you know how many Java template/view layer frameworks there are, not even counting the more popular ones like Tapestry, Velocity, and Wicket?

This along with the interest in domain specific language construction seems to clearly indicate that there will not be a single leading language that gains mass adoption.

Maybe I’m misunderstanding what is implied by “Next Big Language”, indicating that may be something wrong with the terms of discussion: do we even know what we’re speculating on?

Therefore, speculating about what will happen in the next few years (a futile exercise I try to resist, even though I’ve engaged in it several times in this post) should not be predicated upon an assumption that we will all gravitate towards one language like insects drawn to the light, especially when that once and future language might not even exist yet.

But, feel free to arbitrarily declare that your language of choice (Scala, Ruby, JavaScript, Erlang, …) is “the winner.”

How to ace a tech interview

In this article, I’m going to help you whiz through those dastardly technical interview questions. Ever wonder why manholes are round? Read on.

Let’s start with an easy one. This one is called “The Rope Bridge“.

Four people need to cross a rickety rope bridge to get back to their camp at night. Unfortunately, they only have one flashlight and it only has enough light left for seventeen minutes. The bridge is too dangerous to cross without a flashlight, and it’s only strong enough to support two people at any given time.

Each of the campers walks at a different speed. One can cross the bridge in 1 minute, another in 2 minutes, the third in 5 minutes, and the slow poke takes 10 minutes to cross. How do the campers make it across in 17 minutes?

Solution: Who gives a shit? Who asks retarded questions like this?

This one is called “Wanna Play?” (hint: No!):

i offer to play a card game with you using a normal deck of 52 cards. the rules of the game are some fucking arbitrary bullshit that make this bullshit mental masturbation way harder than it needs to be. if you can’t figure it out in 45 seconds, i’ll assume you can’t produce code and work on a team, regardless of any free software projects you may have participated in (in fact i couldn’t look at open source code you’ve written if i wanted to, i’d get fired), regardless of any nice code samples you have to show me, regardless of how quickly you can pick up new things, and so on.

Solution: Are you getting the point? Jesus christ, no fucking wonder companies who use these kind of questions can’t ship anything.

Examples of paralyzing choice in programming systems

As people like 37Signals have pointed out, excessive choice can be quite paralyzing. Here are a few I’ve come across in the last few years.

• Version control systems. Choosing to be centralized or distributed narrows things down a lot, and if you go centralized you’re probably settling on Subversion or a good commercial one like Perforce. But what happens when you hear about distributed version control systems: Monotone? GNU arch? Git? Mercurial? Darcs? Bazaar? What are the benefits and tradeoffs of each? Does it really matter?
• Scheme implementations. Do you want to choose PLT Scheme, which has good libraries and a good modular code-sharing system à la Python eggs and Ruby gems? How about SISC, which claims to be efficient, have excellent R5RS support, and runs on the JVM? How about scsh/Scheme48, which some awesome hackers use and has neat Unix systems programming stuff? And that’s just some of the more popular ones.
• Functional programming languages for mind-expanding after-work/after-school tinkering. Haskell? Standard ML? Scala? F#? OCaml? Lisp? Scheme? Erlang? Oz? Prolog? You don’t have time to master more than one or two of them. Blub programmers have it so much easier: all the languages they come across are so devoid of innovation that you can pick them up in a few days to a week and the vast majority of the learning curve is in over-engineered frameworks and toolchains. No brain, no pain.

Functional programming is easier than imperative programming

Or maybe I should instead say that functional programming scales down better than imperative languages.

Java and C# are not interactive at all. I can’t fire up an interpreter and test out inputting values. Even if I could, it’s a pain in the ass, because you can’t declare literal hashes/lists, and you can forget about one-line iteration statements the way Scala or Ruby lets you do something along the lines of Array(1,3,9,16,25) foreach {n => ...}.

Unfortunately, this carries over to non-trivial applications. If I’m working on an interpreter, I can start out by framing the grammar as a series of algebraic data types, and then I can make a simple interpreter with pure pattern matching. Algebraic data types are ideal for representing abstract syntax trees, and so I can directly type in code fragments at the REPL within a subwindow of my editor while I’m coding up my interpreter that will be efficiently compiled to run roughly on parity with Java or C#.

And don’t tell me about the value of sophisticated IDEs if you’ve never used SLIME or Squeak.