Java hates your freedom


The more I use Java, the more I realize what “ivory tower development” means. And I don’t like one bit, sir.

Java doesn’t support printf. The C function printf is something nearly 100% of all programmers worldwide know how to use because it’s how you make words appear on a screen or in a file. More importantly, it’s the function you use to format text. That is, it allows you to control how many decimal places appear for floating point numbers, whether leading zeros appear in front of numbers, whether to show numbers as hexadecimal, octal or decimal, and a whole lot more. It’s used in that most famous of introductory programs, hello.c:

void main (char **argv, int argc) {
  printf("Hello, world!n");

It’s so basic a function that you can forget how darn useful it is.
But, Java doesn’t have it. What Java has a method, which is part of those kinds of classes that concern themselves with streams, which is a highly generic way of thinking about files and consoles and network sockets and your mom.

Ok, let’s leave your mom out of this (for now).

That Java method is named println. It doesn’t know how to format your output (to make your decimal numbers all pretty or to add fancy columns to your output), but it does know how to put the platform-appropriate newline character on the end of your string! So, you’ve got that going for you!

Now, the designers of Java aren’t stupid (more on this later). There are problems that programs using printf encounter. For instance, internationalizing the output of programs with printf can be difficult. Sometimes. In badly designed large programs, which few programmers ever have to deal with.

More damningly, printf is ideologically impure. It’s a function and Java’s all about the Objects, baby. Sure, they could have made a static method of the String (or OutputStream or whatever) class called printf, but that might cause someone a little grief sometime somehow. Better to cheese off every programmer coming to the language. Yup. Great thinking there.

Another noticable absentee from Java fopen. The C function fopen is known by 99% of all programmers worldwide and nearly all popular programming languages have something like open (Perl has 3 closely related file open functions but you probably only ever need open).

As programming interfaces go, fopen is pretty nasty. You need to pass it a filename (and all operating systems name files differently). You need pass it a mode (are you reading from, writing to, appending to the file or all of the above?).
And what do you get back from fopen? A file handle? A file descriptor? A lottary number? Who knows? However, it’s a big puddle of programming poo that 99% of us have learned to deal with.

Instead, java has many circumlocutions to address files and even more to get data into and out of them. Working with files is task performed in 98% of all programs ever written. And Java makes getting to these files weird, frightening and confusing. You need a File object, which is then passed to a Output/Input Stream object, which in turn is passed to a Buffered Stream object. Nice and Object Oriented. And a complete pain in the genitals.

So, let’s recap. Java, which was loosed upon the world in the nineties purposefully ignored very popular input/output conventions so that 100% of the programmers who learned any other language (most have syntaxes derived from C) would be utterly baffled by the most common of all programming tasks.

Are there times where all this OO sugar pays off? Sure. And Java is very helpful in these cases. Could Java have provided a nice compatibility layer for the oceans of existing C-based programmers? Sure, it could have.
Easily, in fact. But the Java language designers thought they knew more about the how to tackle the jobs that Java programmers would face than the programmers themselves.

In classical literture, this type of overweaning pride is called hubris. In my native country Massholia, we just call that “being a f*cktard.”