Byzantine Reality

Searching for Byzantine failures in the world around us

First There Was Java...

For the lion’s share of my undergraduate education (80%-90%) we got to program in Java. We did half a semester in C# (close enough), a semester in C, a semester in assembly, and everything else was Java. Although I picked up other languages before I got to undergrad life, Java was the first language that I really learned well, and a lot of how Java does things seeped into my head about how to do things in every other language. It’s not a bad thing, but it made my head spin when I ended up seeing Ruby for sure.

This article has been in the works in my head ever since I read The Perils of JavaSchools, since I went to one. Early on in the article Joel pretty much captures the problem with only teaching Java:

Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.

This is right on. And that’s not to say Java shouldn’t be taught in schools. But I don’t know if it should be the first language to teach students (I’ll get back to you on that) and it certainly shouldn’t be the only language that students end up really knowing.

We can debate what it means to “really know” a language, but as far as I’m concerned, it’s knowing the language’s standard library. You can easily “program” in a language like Perl even if you don’t know Perl but know another imperative language (e.g., C or Java), but you don’t really know Perl unless you know all those special metacharacters and Perl’s regex syntax and blah blah blah.

I think what I’m trying to get at is that I really wish I got to learn two languages from different paradigms. Something like Java and Lisp, or C and ML, but to a degree where if a problem comes up, I can take the extra five minutes to think about which language solves the problem best, rather than having to do it in Java because I’m just not productive enough in anything else. Part of this problem is relieved by me trying to learn Ruby well and insisting that I do everything in Ruby until I get a good grip on it (or unless Java is such a blatantly better choice).

I think the problem with having Java as the only programming language is that, until I really got a good look at Ruby, I looked at the basic way we were taught to get input from the user and thought it just had to be that complicated:

BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String response = in.readLine();

As I’ve said, Java is not my only language. I know it’s a lot less work to do this in C or Perl. But since I don’t really have the same grip on C or Perl that I have on Java, it’s not something that really ever hit me. Yet now that I’m looking to know as much about Ruby as I do about Java (hopefully more), all these little things are raising red flags. Like in Ruby, to get a line of input from the user, it’s:

foo = gets()

Which is closer to how it’s done in Perl or C and much shorter than Java. And of course I could go on about how Ruby is way less verbose than Java (which I will do next time), but Ruby’s not the focus of today. Java is. Java has been a great language for me over the last how-many-years. But I think we can come to a consensus that, no matter how you feel about Java, it can’t be the only tool in your toolbox.

I also think that the only thing worse than not knowing a particular language is knowing it not that well. I spent about a year maintaining O’Caml applications, and I still can’t say that I know O’Caml. I can subconsciously look at O’Caml code and say what it’s doing, but I don’t know the O’Caml standard library. Google and the O’Caml docs are my best friend when I touch O’Caml, which just isn’t something that happens when I’m using Java. Sure, I still use Google, but I don’t need to go on message boards and forums to find out what a particularly weird error I’m having means. But this is getting off-topic. What I mean to say is that I don’t really know all the amazing features behind O’Caml. I know some subset of it that corresponds to the style of the coders whose code I maintained, and that’s about it.

I’ve decided for Ruby that that’s totally unacceptable. It shows a lot of promise and I when I talk about Ruby, I want to at least appear like I know what I’m talking about. I want to approach a Ruby conversation with the same gusto that I have when I’m talking Java. And I wish that I had that knowledge with another language from my undergrad days. But there’s no time like the present, so off we go on Ruby!