Hacker News Reader

Comment by dbcurtis | Hacker News Reader

UCSD Pascal has a byte code interpreter, sure. And I will grant that it may have been the first or at least among the first popular ones. But the idea of a byte code interpreter was already old by then. I worked on a byte code interpreter in a code base that predated UCSD Pascal. It ran on a CDC 170-series peripheral processor and was used for peripheral diagnostics. I am sure other byte code interpreters existed in that time frame.

Not to take anything away from UCSD Pascal, it was a great system and very fun.

View on HN

Pascal was the programming language we used in college in the late 70s, and although I knew it translated to p-code that was then interpreted, somehow that never became much of a focus. We just used the language like you would any other high-level language, and bitched about the shortcomings or inconsistencies.

I can tell you first hand that when James Gosling was developing Oak/Greentalk which became Java, Pascal never came up. Sure we all knew and had used it, but the focus was much more on C++ and what to keep and what to discard. I think Smalltalk or Self might have even been more of an influence since Dave Ungar was in the Sun research division at the time and was spreading the gospel of generational garbage collection.

At that point, Smalltalk (and I think Self) had JIT too in terms of VM state of the art.

Deutsch Schiffman dynamic-translation.

pdf "A Brief History of Just-In-Time"

http://eecs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literat...

That's a great paper thank you. My own Zelig-like role was doing the 1st port of Smalltalk (HPS) to Microsoft Windows, hence my familiarity.

> I can tell you first hand that when James Gosling was developing Oak/Greentalk which became Java, Pascal never came up ... the focus was much more on C++ and what to keep and what to discard.

The interesting thing is that at the time Java was released and then aggressively marketed by Sun, the AT&T folks had already come up with Limbo (the successor to Alef, and running on the Dis virtual machine), which was technically quite similar to the Java/JVM solution, and in some ways quite superior. But nobody ever mentions Limbo in connection with Java, or even with Go (which it - along with its predecessor Alef - was a clear influence on). History is written by the winners, and Java was a winning language/platform for quite some time.

Even here on HN, people bring up Plan 9 all the time, forgetting that Inferno and Limbo were actually the end of the road and Plan 9 just a middle step.

Great point about Smalltalk. It had been around a long time by the time of UCSD Pascal, and had a byte code engine from the start.

Along similar lines, Burroughs had a line of machines that swapped in language-specific microcode on a task-switch basis(!!!!!) so the idea of language-specific instruction sets has a long history.

What a shame it was that Gosling didn't understand C++ well enough even to crib from it.

I am astonished, again, whenever I am reminded of what he tried to copy and got horribly wrong, and what else he copied and should have known better than to. None of it would matter if Sun had not dumped a billion dollars into hyping it, so that later generations are now saddled with billions of lines of it.

What a cruel joke to play on posterity, a fitting companion to x86 ISA and BSD sockets.

Could you give some examples of things which you think were mistakenly copied, and things which should've been copied but were ignored?

Nothing like a good C++ flamewar, but we already have a fine compilation of the case against the language - https://yosefk.com/c++fqa/

they focused on C++ as an object-oriented programming language (as did, to be fair, mostly everyone in the 1990s since it was The Big Thing then) without seeing where C++'s real value is, which is :

- value types

- RAII idiom with exceptions

it's a big, coherent package, which means that you can write code so that e.g.

    my_type foo{whatever};

    file f{"/foo/bar", "w"};

    foo.do_stuff();
    f.write(foo);

and you can be assured that you won't have null pointers croppying left and right, much less "new" to write, your objects are always in a valid state, etc etc.

Java is the opposite: the whole object model revolves around the identity of objects, and thus any function that looks like `public string whatever()` can return null, you have to do manual cleanup of your resources most of the time everytime you use a type (closing files, streams, soundcards, etc etc), versus every time you define a type in C++.

Java is tremendously influenced by C and C++. Any experienced C++ programmer can learn Java easily because it has a similar syntax but a much simpler palette of language constructs.

I am glad that Java didn't copy these aspects of C and C++: https://www.nayuki.io/page/undefined-behavior-in-c-and-cplus... ; https://www.nayuki.io/page/near-duplicate-features-of-cplusp...

And Objective-C, stuff like interfaces, resource bundles, lightweight metaclasses, APIs for distributed computing (J2EE was based on an internal OpenSTEP framework).

Undefined behavior is very useful, and Java doesn't replace it with anything better for high-performance CPU programming.

In particular, C loops can only be optimized because signed loop counters are assumed not to overflow. Java also doesn't have SIMD, and a very weak form of arrays as value types leads to pointer chasing.

Reply on news.ycombinator.com