Hacker News Reader

Comment by tomcam | Hacker News Reader

A history of UCSD Pascal, which compiled to a portable VM called a p-machine. Doesn't mention the infinitely more successful product inspired by UCSD Pascal--Turbo Pascal, which was insanely fast but which completely ignored portability, as it was written in 8088 assembly and generated machine code directly to memory. Turbo Pascal then become Delphi. Its creator, Anders Hejlsberg, moved to Microsoft and created C# among other things.

View on HN

Java programs are portable. Java is popular.

It feels like the article implies causality, but I fail to see it. My first programming language was Java (version 1.2) and it was the easiest programming language to start with because it had everything that a student would need, in one place: jdk, tutorials, documentation, and language specification. This may not sound like a big deal now, because many other programming languages provide similar resources. You just go to xyzlang.org and you find all the resources, but in those days Java set the standard (or at least that is what I thought) for providing all the resources in place for someone to get started with the language. I did not choose Java at that time because it was portable.

On top of what you mentioned:

Java hopped onto the Object Oriented Programming bandwagon just as it was getting a lot of buzz. To a lot of people, Java and C++ are the canonical Object Oriented languages. (Sorry, Alan Kay.) Of those two, Java has the shallowest learning curve.

Java was also many developers' first introduction to a language runtime with a "fail fast" approach to fault handling. Java featured runtime bounds checking and runtime type checking. Couple that with the very detailed (for the time) stack traces that the runtime produced, along with automatic memory management, and you have a powerful set of tools for building (relatively!) bug-free software. (For comparison, imagine trying to debug a C++ program that intermittently crashes on an off-site customer's computer.)

Object Oriented design, garbage collected memory management, and runtime error checking all had roots in other languages (Smalltalk and Lisp come to mind) but Java was the first to package all those things together in one well-documented, industry-oriented tool.

Most of those predecessor languages were widely perceived as by academics for academics, which brings me to the final piece of the puzzle: Sun nailed developer outreach. It doesn't matter how good your language is if nobody has heard of it.

> Java was also many developers' first introduction to a language runtime with a "fail fast" approach to fault handling.

Java wasn't just "fail fast" in some loose and hard-to-pin-down sense, it was memory safe. This was a killer feature in competing with C++ as the standard 'enterprise' language, and Sun rightly focused on it in their marketing of the language and platform.

Edit: And yes, as a sibling comment says, the "batteries included" factor was probably important in making the language popular with developers.

And the free as in beer factor ;-)

And the dancing in the browser future of the Internet factor :-)

> It doesn't matter how good your language is if nobody has heard of it.

Or how bad it is, if you can shove it down people's throats. But that is true for any software, not just programming languages...

> Java has the shallowest learning curve

[citation needed]

Java 1.0 had a reasonably shallow learning curve. A lot of complexity was added by later enhancements. I always felt they were not always worth the complexity tradeoff they brought.

Not having headers seems enough to prove that.

But making Java easy to learn by taking the features out didn't make it easier to build programs with it. It's kind of like making a surgeon wear boxing gloves.

Surely not if the comparison is with C++.

And not only that, Java came with portable standard libraries for pretty much everything: collections, threads, networking, GUI, database interface, etc, which are as much part of Java as the language itself: the Java runtime. C and C++ had some standard libs too, but nowhere near as many. So, it was not only that you could rely on your compiled code to be portable, you could rely on many crucial libs and dependencies being portable too, something which we may take for granted these days.

Yes, Java was a whole product, and that was a great thing. Also: helpful error messages.

But was your choice to learn Java somehow related to it being popular in industry?

More so in the past, portability - meaning not being locked-in to a specific vendor who could then screw you - was a big deal in industry. Today, there's much less heterogeneity (x86, ARM and...?).

Part of Oracle's pitch for their database was that they ported it to different machines, so users weren't locked in (even if they didn't actually use it on different machines).

Ironically, portability was one of the main drawcards (well, that and being able to embed it in web pages) when I first learned it, but I quickly found that a Java application was far less portable, in reality, than an i386 Windows executable. That one friend with a Mac might be able to run it but nobody else could without downloading 65MB of JRE.

"write once, debug everywhere"

> But was your choice to learn Java somehow related to it being popular in industry?

Yes, but only partly. I had evaluated becoming one of Java, C++, or Oracle programmer (I know the last one is not the same thing, but was a career option nonetheless).

Sun spent a whole lot of cash advocating for Java. From some very nice, slick books to their own salespeople. It was the "internet language" with Javascript supposed to be its lesser cousin. I was going to teach a programming class at an out of the way community college in fall of 96 and someone from Sun called me about it. I took it they were a bit serious. It was also billed as a better C++. I don't think anyone since has put that much juice behind a language. The nearest thing is Apple with Swift which is still platform limited.

I don't have enough first hand experience to back this up, but I think I read someone claim that the early JVM was very close to the p-machine. I think a lot of mid era (late 70's early 80's) programmers learned the p-machine in school. Wouldn't be a stretch that it was the informal template.

Reason p-code didn't take off was because it was too slow on personal computers.

Well, this is very much the case according to the article, where James Gosling is quoted as saying:

“Then fast-forward a bunch of years, when I was trying to do the project that Java came out of. I had to do this architecture-neutral distribution format, and then I just went ka-ching! You know, this p-code translator thing would actually just drop in there.”

The article explained before how Gosling learned about the p-machine:

Gosling could have done this by making the requisite fussy changes in every application program and recompiling. But he found an easier way: He wrote code that turned the VAX into a p-machine.

Standing on the shoulders of giants.

> I think I read someone claim that the early JVM was very close to the p-machine

Looking at P-code descriptions, I can't say it resembles JVM bytecode all that much. It seems to be somewhat more low-level.

https://homepages.cwi.nl/~steven/pascal/book/10pcode.html

On a lower level, I think Intel did the same for 8086 assembly. Their documentation was volumes and included everything you ever needed to know, including all operating system integrations (IRQs, syscalls, etc)

Reply on news.ycombinator.com