The fifth decade of programming: J is for Javaby@azw
3,479 reads
3,479 reads

The fifth decade of programming: J is for Java

by Adam Zachary WassermanApril 1st, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Sun Microsystems had big plans. They wanted to move from their stronghold of workstations to personal computers. This would increase the market (and the profits) of their recently developed SPARC processor a hundredfold. They joined forces with ON Technology, the company founded by software entrepreneur Mitch Kapor, to create an alternative to Microsoft Windows. Although that joint venture did not pan out, through a series of connected events, Sun ended up in possession of a SmallTalk “clone” written in C.
featured image - The fifth decade of programming: J is for Java
Adam Zachary Wasserman HackerNoon profile picture

Part One of Chapter Five in a very personal history of programming

In a class of its own

While Microsoft does not share all of Oracle’s ambitions for Java, we agree that it is a very valuable tool for software developers.

~ Bill Gates

Sun Microsystems had big plans. They wanted to move from their stronghold of workstations to personal computers. This would increase the market (and the profits) of their recently developed SPARC processor a hundredfold. They joined forces with ON Technology, the company founded by software entrepreneur Mitch Kapor, to create an alternative to Microsoft Windows. Although that joint venture did not pan out, through a series of connected events, Sun ended up in possession of a SmallTalk “clone” written in C.

The SmallTalk clone that Sun inherited included a virtual machine, an IDE, and a syntax. It was originally started in C++, but was ultimately delivered using Objective-C. That was the foundation for Java.

In the previous article where I introduce Smalltalk, I do not mention that it ran using a virtual machine or VM. The idea behind virtual machines is that instead of using a compiler to convert source code to the opcodes of a specific processor, it instead compiled generic opcodes of an imaginary CPU that exists only as a design on paper. SmallTalk was the first programming language designed to depend exclusively upon a VM.

The VM is an emulator: it emulates this imaginary CPU by converting its generic opcodes to the real opcodes of the physical CPU it is running on. You can write as many virtual machines as you want, ones that run on IBM CPUs, ones that run on Sun SPARC, ones that run on Intel chips, ones that run on the ARM chips in your phone. Once your program has been converted into the generic opcodes of the VM, it will run on all of these platforms.

The Sun marketers made a really big deal out of this, but Java was not the first language to run on many platforms without a re-write. Long before Java there was ANSI C. And USCD Pascal and SmallTalk. Now we have JavaScript, HTML, and a dozen other languages that very effectively run one source code on any platform. It’s really not so special.

Mighty oaks from small talks grow

In 1990, Patrick Naughton, one of the Sun developers, tired of the “directionless mass of dispassionate people” in his group told the CEO, Scott McNealy, that he was leaving to join Steve Jobs at NeXT. To make a long story short (and it is a long story) McNealy made Naughton an offer he could not refuse: a big raise, some stock and the chance to hand-pick a small team and invent a project from scratch. Naughton recruited his mentor James Gosling, and also Mike Sheridan, a dealmaker doing business development for Sun.

They named it the Green Project and set up a skunkworks¹, where they decided to make a consumer device; specifically, a device for interactive television that they tried to sell to cable companies. Gosling decided to build upon the SmallTalk clone, which he renamed Oak after a tree that was growing outside the window of his office. He added class libraries similar to the ones included with Objective-C, and he made it highly optimized for performance (consumer electronics do not have a lot of CPU or memory). They worked on this for four years, failing to achieve commercial success. Then Sun made what was a surprising move in those days: They released the SmallTalk clone on the Internet free for anyone to use. And called it Java.

There is nothing particularly special about Java as a programming language. I know there is no shortage of Java devotees ready to argue endlessly about why Java is Really Great! But it really isn’t that great. Not that bad, but not that great either. It did however have a couple of very particular advantages that led to its ubiquity in the market.

Designed as it was for television set-top boxes controlled by a central authority (such as a cable TV company), it was good at two things: operating in a very small memory space and sending programs as objects across a network.

This is why the web browser company Netscape decided to officially adopt it and include a Java virtual machine in the browser. It was actually quite a good decision. It allowed browsers to become delivery mechanisms for small applications that communicated with larger applications on a server. It is what made web-based applications possible, because without it, the first versions of HTML couldn’t support a rich enough user interface to allow web applications to compete successfully with desktop applications.

Java also included an extensive and useful class library. And just as the included class libraries of Objective-C made it a more productive language for a broader spectrum of programmers, Java’s class libraries did the same thing, and made it much easier to use than C++.

In summary, it was lightweight (at first), solved a real problem (rich web UI), came with good libraries, and was supported by a very large stable company that would be around forever (or so it seemed at the time). And unlike SmallTalk, anyone could use it for free.

As web-based applications became the norm, adoption of Java by IT departments of large organizations increased exponentially. Someone on a web forum I use to read once remarked (without judg­ment) that Java was the new COBOL “because it’s becoming the new de facto standard for enterprise applications”. I like that comparison.

Because of its popularity, a lot of effort has been invested in improving Java’s original flaws (mostly technical stuff, too boring to get into here). From the perspective of results, Java does a perfectly good job. But still, I’m not partial to it. Call me petty, but like COBOL, it is just too verbose for my liking. Reading Java (for me) is like going to a social function and getting cornered by that guy. The one that just goes on and on about himself, using ten-dollar words when fifty-cent words would do just fine.

Here is “Hello World” in Java:

public class Main {public static void main(String[] args) {System.out.println(“Hello, World!”);}}

Here it is in Python. I like Python.

print(“Hello World”)

In my very personal opinion, Java occupies a grey area between traditional 3GLs where (like Mel) you really have to understand how the computer works, and 4GLs where you do not need to know because someone else has done most of the work for you. Java, much more so than the various C languages, is a language where mediocre programmers can use cargo cult programming to get programs up and running that seem to work at first, but that contain ticking time bombs created by the indiscriminate and uninformed copying and pasting of code.

The cult of cargo

Wikipedia says this about that:

Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution… The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position”.

It adds:

“The term cargo cult, as an idiom, originally referred to aboriginal religions that grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like airplanes that had brought marvelous cargo during the war. Use of the term in computer programming probably derives from Richard Feynman’s characterization of certain practices as cargo cult science“.

Too many Java programmers, like the novice in the LISP koan, don’t really understand the libraries they are using, or the code they find on the Internet or copy from some other project, that looks like it might do the job.

To be fair², the same might be said of programmers working in any of the SmallTalk derivatives that come packaged with extensive class libraries and have a large corpus of public domain software available; which is pretty much every popular language introduced after 1990 with the exception of Haskell.

Compared to programming close to the metal, most modern languages enable lazy programming by untalented programmers.

“Java is sort of the COBOL of the 21st century, I think. It’s kind of heavyweight, verbose, and everyone loves to hate it… though not everyone will admit that. But managers kind of like it because it looks like you’re getting a lot done. If 100 lines of Java code accomplish a task, then it looks like you’ve written 100 lines, even though in a different language, it might only take 5 lines.”

~ Larry Wall, creator of the PERL language

<- Previous article in the series

[1] A skunkworks (also known as Skunk Works) is a small group of people who work on a project in an unconventional way. The group’s purpose is to develop something quickly with minimal management constraints.

[2] To be especially fair, I describe myself as a cargo cult programmer. I cannot write a useful application without copying and pasting someone else’s code. On good days I understand it.

This article is an excerpt from my upcoming book The Chaos Factory which explains why most companies and government can’t write software that “just works”, and how it can be fixed.