Hacker News Reader

Comment by astura | Hacker News Reader

Brendan Eich addresses that topic in this interview. The whole interview is (very much!) worth a read but here's some key parts about the name

https://www.infoworld.com/article/2653798/javascript-creator...

>It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.

>[The idea of an accessable scripting language] was very strongly held by Marc Andreessen and myself. Bill Joy at Sun was the champion of it, which was very helpful because that’s how we got the name. And we were pushing it as a little brother to Java, as a complementary language like Visual Basic was to C++ in Microsoft’s language families at the time.

View on HN

Interesting!

"JavaScript would have been the ideal name because that’s what everyone called it and that’s what the books call it. Microsoft couldn’t get a license from Sun so they called their implementation JScript. So ECMA wanted to call it something and they couldn’t get anybody to donate or they couldn’t get everybody to agree to a donation of the trademark, so they ended up inventing ECMAScript, which sounds a little like a skin disease. Nobody really wants it. "

I think if you combined the two "different" answers to why it's named JavaScript, you get the truth. Yes, it was promoted as a companion scripting language for Java, but that was in part because Java was so hot at the moment, so marketing had something to do with the decision to name it JavaScript.

Why "script" though? Aren't Java and JavaScript both script(ing languages)?

Why not call it e-Java or Java XYZ or something?

I've never seen Java called a scripting language before, actually.

This is all semantics, but the idea was that Java is a "real" language for serious use and JavaScript is a "script" that's much easier to use and doesn't involve all the complications of a "real" programming language.

It was only kind of true back then, and not even remotely true now. There really isn't a solid line you can draw between a "script" and a "programming language". To me, something like Python is right in between.

To me, if something acts logically like it is run from top to bottom, it's a scripting language. Python scripts and JavaScript are in this category; Java isn't.

Additionally, explicit compilation/linking/assembly shouldn't be required for a scripting language, even if the interpreter does stuff kind of like this behind the scenes for performance.

That makes Ocaml and Haskel into scripting languages.

You can't just put `putStrLn "Hello"` in the top level of a Haskell program and expect it to work. You can do it in a REPL, but that's besides the point.

Sure. I was responding to this:

“To me, if something acts logically like it is run from top to bottom, it's a scripting language.”

I don’t see them as scripting languages, but that definition would include them.

And my point is that Haskell doesn't even look like it's run from top to bottom.

Example, consider this mutually recursive definition at the top level:

    a = 1:b
    b = 2:a

It doesn't, by any means logical or not, look like it runs from top to bottom. If so, the first line would have immediately been an error because `b` is an undefined name.

My mistake - I thought Haskell was like OCaml in not having a main function:

http://stackoverflow.com/questions/28711563/ddg#28711778

You broadly dismissed my entire comment, which was completely correct about Ocaml, but I accept that you are correct about Haskell.

I feel like "requires compilation" is a good first order differentiator. And "has a somewhat sane type system" is another.

Well, C++ can be interpreted (sort of, see CINT) and can certainly be semi-transparently jitted (see cling). Although it's certainly not designed for that!

C# 9 added “top level statements” which seems to be the first steps towards usage in a script environment.

https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

Templates are turing complete and universally interpreted AFAIK (I don't think any implementation compiles them before evaluation?). There's also features like constexpr these days.

tcc is fast enough to run C code (or langs targeting C) as scripts.

TypeScript requires compilation and has a rich type system. It also has "script" in the name.

I think "scripting" vs "programming" language differentiation is elitist nonsense. This isn't a meaningful boundary. It's more useful to speak of languages in terms of strong/duck/loose typing, syntax, supported programming paradigms, ecosystems, available libraries and tooling, and intended use cases.

> There really isn't a solid line you can draw between a "script" and a "programming language"

I think it's easier to draw the line if you have the requirements right. That's not the line that was being drawn. it was scripting vs compiled languages. It was very clear then which sides Java and Javascript fell on. There are some weird cases now like compiling scripts into different scripts, but in general it's pretty clear, and Python is definitely a scripting language.

The great "script vs programming language debate". The difference is clear to you because you have a clear definition in your mind. The problem is that the definition changes depending on who you talk to, which invites endless debate.

Well it's a pretty bad debate if people aren't agreeing on definitions. Hence this whole chain of comments.

Basing the definition on whether it's compiled or not doesn't help much.

Python is actually compiled to bytecode, just like Java. Is it not a scripting language?

Or is the distinction that the Python bytecode is interpreted whereas Java is JIT compiled to machine code? Well, Java didn't get the JIT compiler until version 1.3 - so was Java 1.2 a scripting language?

The distinction is the existence, from the developer’s perspective, of a separate step called “compilation,” which produces an executable artefact which can be distributed but not converted back to the source code. It’s about programming in practice, not fundamental computer science principles.

I agree, this practical view makes more sense. However, the Kotlin compiler can be invoked either explicitly like Java or implicitly like Python. Is Kotlin a scripting language?

How could one consider Java a scripting language? It's compiled to .class files, has no reasonable interactivity, strict structure enforced upon the code, etc. E.g. the antithesis of what makes us call something a scripting language in basically every category.

So JavaScript meant "complement to Java, but converted to machine language in the browser, instead of compiled?"

(Thank you, genuine question)

> So JavaScript meant "complement to Java

The whole JavaScript thing was just marketing. In 1995, Java was THE hottest thing so associating it with Java might fuel adoption/acception.

There is an old saying; Java is to JavaScript what Car is to to Carpet.

Re. your compiled question. It's up to the browser on how to execute JavaScript. E.g. Chrome has the V8 engine. This is the VM that compiles and executes JavaScript within Chrome. Other browsers might have different engines.

https://en.wikipedia.org/wiki/V8_(JavaScript_engine)

JavaScript is "logically" run line by line from the beginning of the script. This may not be exactly true anymore for performance reasons, but it's the logical model behind it. A single set of expressions to run in order "a=1+1;" is a conformant JavaScript script; hence, it's a scripting language. It doesn't take much imagination about how to have a JavaScript console that operates interactively from user input.

Java code has lots of structure required to write a minimal program. Java is transformed by compilation into a set of .class files. Then, in turn, a loader loads, resolves all the classes, and begins transforming and executing code.

These distinctions can be muddy sometimes.

More like interpreted rather than compiled. (I'm pretty sure a google search on "interpreted versus compiled" will get you up to speed with the basics on this point.) This is generally seen as one of the main differences between "scripting" and "serious" languages.

The twist is that the JVM (Java Virtual Machine) is also a kind of interpreter, but can do on-the-spot ("just-in-time") compilation of parts of the code as well.

Sorry I am not an expert in Java, but doesn’t the jvm execute the .class files like bash would execute the .sh scripts.

A scripting language is generally thought as a language suitable for quick easy project, less so for large scale software engineering. Verbosity of syntax, compilation, presence of boilerplate code, static typing are all things that make java unattractive as a scripting language.

Java is great at what it does, which is not scripting.

I’d like to instead say “static typing without type inference” to be pedantic. I quite like writing scripty stuff in Haskell, and the type system helps in it actually running correctly sooner.

Class files contain compiled bytecode, not source code like shell scripts do. “Script” implies human-readable source code. Java bytecode is binary, a kind of portable machine language.

Of course, there's murky things like Python which make bytecode compiled forms behind the scene.

But there's a lot of magic involved in transforming Java to class files, and then there's a lot of further magic in resolving, loading, and eventually executing classes.

PHP does the same. It’s compiled to a bytecode before execution. But I don’t think it’s cached anywhere like Python (but that may have changed in the decade since I’ve used it)

PHP has had an OPCache as an add-on since 5.1.0(around 2004), and by default since 5.5.0: https://www.php.net/manual/en/intro.opcache.php

It better be cached or else that would be a total tradegy... why wouldn't you automatically want to cache the prerendered pages whenever possible?

It's not like writing a basic cache is very hard...or just "borrow" one from an OS implementation.

Does this mean java .class falls in the middle of scripts and native executables? Is this analogy correct? For example, I think of native executable as Microsoft Word where you can doubleclick and launch it. Whereas with .class you have to run it on top of a jvm.

Often even a "native" executable is opened by something like the ELF interpreter, relocated, etc. Yes, a JVM is a lot more heavyweight than these services, but...

No. If you must insist on thinking of them as distinct from native executables, then consider them foreign executable instead—object files written for a different machine architecture and a different loader convention. There's really no middle ground they're occupying.

This is a very good way to put it.

The super pedant in me, of course, would say they're a sliver in the middle because they're targeted at running in a software-implemented VM instead of on a real machine architecture, and that this isn't all that different from in-memory interpreter bytecode or something like a .pyc written to disk...

But then something like the more complicated loaders for native executables is a sliver in the middle, too. And then you look at something like the AS/400 with super-high level "instructions" and these distinctions get super, super muddy.

Not exactly. For one, class files are just components of a program, so more akin to .o or .so files, not executables. That set aside, they are binaries for a virtual machine, the JVM. One difference to real machines is that the bytecode doesn’t have access to untyped memory and to the hardware (not even “virtual” hardware), and some instructions have more complex semantics than you usually have in real hardware, but otherwise it’s not so much different from actual machine code. Overall it’s closer to native than to script, and therefore I wouldn’t quite say that it’s in the “middle”.

So, basically, JavaScript was originally annointed to serve the function within the JVM ecosystem, that ended up being served by Groovy?

Why didn’t that happen? And why did it take so long before we got Groovy instead, if Sun wanted was imagining something like it way back in 1995?

Sun had some great people and some good ideas and products, but as a coherent business it was a rolling train wreck.

Which why they sadly ended up digested by Oracle.

Only after Google sent a couple of torpedoes and then went as if it wasn't their business.

What torpedoes do you mean?

Android and ripping Sun off.

Then they were hoping that no one would buy them, not even themselves cared to own Java after their trick.

So now they push Kotlin, while researching Fuchsia, and keep a bunch of lawyers quite happy.

So implementing and pushing Java in Android was a torpedo against Sun?

Interesting logic.

Android Java is not Java, and yes when I take someone's product and don't pay what the license specifies, while introducing an incomplete implementation, that is 100% ripping off.

Thankfully we are going to have that settled in the near future, and then Android folks can party all night long with their Kotlin implementation and rename ART into KVM.

Despite dalvic and co. it still pushed the Java ecosystem, right?

Not what I would call a tornado in the meaning pf destruction.

And about the license, well, it is disputed, right? I only read about it tangential, but the case seemed far from crystal clear to me.

As much as Microsoft did with J++.

No one needs Android Java slowing down the Java ecosystem by imposing additional burdens on Java library authors that also want to target Android.

Besides Google that is.

> Sun Microsystems, Inc. (SUN) hereby grants to you a fully-paid, nonexclusive, nontransferable, perpetual, worldwide limited license (without the right to sublicense) under SUN's intellectual property rights that are essential to practice this specification. This license allows and is limited to the creation and distribution of clean room implementations of this specification that...[list of requirements]

AFAICT the whole fight is over API's and not "don't pay what the license specifies" as they give you the ability to do a clean-room implementation without paying royalties.

Implementing it from scratch as a skunkworks reverse engineering project designed to never need to pay license fees upstream.

Despite the license allowing clean room reverse engineering? Sun kindof shot themselves in the foot with those words.

Where on the license? Please.

It explicitly only allowed the use of JavaSE on desktop deployments, OpenJDK was yet to be made available.

I mean... if we took this version of the narrative at face value, I guess we'd all have been better off with no Compaq and hence no commodity PC clones.

Definitely, I miss Amiga, Atari, Acorn and friends, which Apple is the only surviving one.

I was the only PC guy on my gang, and that was just due to other factors not commodity.

So if Google had chosen to use a different language for Android then Sun would still be around? I don't think so.

Sun had an unhealthy Microsoft obsession. When I was a senior in college, Microsoft came to campus and gave a two hour presentation on why we should work at Microsoft. About a month later Sun came to campus and gave a two hour presentation on why we should not work at Microsoft. Sun workstations were very common in our engineering program so we were ripe for the picking but Sun never explained to us what was so great about working for them. Well, except for one absolutely ridiculous video clip of Scott McNealy standing on the roof of Sun HQ, playing the electric guitar. Eyes were rolling out of everyone's heads upon seeing that.

Looking back at interviews and industry articles from that era, there is a common theme of Sun hating Microsoft. Lots of companies and people hated Microsoft but Sun seemed to make it their central ideology. As a result, they took their eye off of making great technology that customers could use to solve their problems. It's a pity because they were so far ahead of the game at that point that they could have developed into something wonderful instead of being absorbed by Oracle, with little trace left besides Java sleepwalking through the modern era.

> Sun had an unhealthy Microsoft obsession.

I think basically everyone did back then. There was a pervasive understanding that if you were small enough, Microsoft would use underhanded business practices to crush you if you became a threat. If you made a compelling product, Microsoft would clone it and use their might to make it win.

It felt like taking a pottery class with a grizzly bear in the room. Really hard to be like, "I should just make the prettiest bowl I can" when you know at a moment's notice your head might be swiped off.

>Sun had some great people and some good ideas and products, but as a coherent business it was a rolling train wreck.

I had an internship at Sun in 2002. I distinctly remember a town-hall meeting hosted by Johnathan Schwartz (CTO at the time, later to be CEO) where an engineer asked something to the effect of "this all sounds great, but how does this actually make us money?" The engineer was told in no uncertain terms that he shouldn't ask such questions, that he should focus on engineering and that he should trust that other people would handle the money side.

No. JavaScript was a web language for web developers to be able to automate forms, etc, client-side. AFAIK, originally it was never intended to run on the JVM server-side like Groovy does.

Netscape did try to position server-side JavaScript as part of its Enterprise Server package though, but it was not JVM-based. But the environment was proprietary and not compelling enough for a myriad of reasons. It ran server JavaScript in CGI mode.

JavaScript took a long time to actually make it server-side. First with standalone interpreters (ie. Spidermonkey) and later with a full-fledged runtime and development environment (NodeJS).

> No. JavaScript was a web language for web developers to be able to automate forms, etc, client-side. AFAIK, originally it was never intended to run on the JVM server-side like Groovy does.

Sure, but that's not an argument against JavaScript having potentially been a planned part of the JVM ecosystem (or, at least, a language playing a role in the JVM ecosystem, without itself being hosted on the JVM, instead maybe interacting with the JVM through some kind of IPC or FFI bridge.)

Remember, Sun used to be trying to squeeze the JVM into web browsers as well, in the form of Java applets. But we never saw any real ability to script against these applets. "Java applet 'engines' under JavaScript control", could have been the portable equivalent to "ActiveX components under JavaScript control."

You know how modern games involve 1. a self-contained game engine written in C++ or C#, plus 2. the game itself being mostly Lua scripting? If Sun had pushed harder, we could have seen something like that in 1995, with web browsers running JavaScript-scripted games calling into Java game engines; long before we got equivalent HTML5 APIs like Canvas.

Probably, if the world had gone down that path, we would have seen JavaScript gradually moving "into" the JVM; and the JVM gradually coming to take the position that the JavaScript engine takes in modern web browsers.

You actually could script against applets, it was just incredibly clunky and slow, and so not worth it.

I did exactly this as part of a school project back in 1996! The applet was doing the computations, and the JavaScript, with this thing called "LiveConnect", was calling into the applet and back :)

The JVM wasn't a thing you "targeted" until much later. In 1996 there was java and javac. People were ecstatic running the same programs written in Java on every architecture (SPARC, PowerPC, Itanium, 8086...), and even as a client or as a web applet. The "portability" wars of 80s and early 90s were over (that's where C and C++ were born into). Nobody really talked about JVM, because there was basically 1 Java vm, no HotSpot or OpenJDK and no real bytecode documentation. JS was not planned for the JVM. So much that there wasn't even a half decent JS to JVM compiler implementation until recently. JS was a joke until ES3, and a very subpar environment until v8 got fast, Node got serious and TC39 got their shit together after the ES4 clusterfuck.

If the Java@Netscape story came about earlier than 1995 then maybe yes, the JVM could have made into the browser as THE scripting environment for an eventual JavaScript language, because Java the language was not suited for webpage designers to throw something together un a highly evente environment. The browser was the place to be and Java just didn't make it there (they fought hard though with their applet crap).

I think part of the original goal was for apps to be written as Java applets and JavaScript use to bridge between HTML and the applets.

It's too bad JVM happened. Solaris was innovative before Java, which became monetized primarily by the fees. They released Self, SmallTalk, and Squeak before that. I think the latter is still very innovative today, because of it's Morphic interface (it's category theoretic). I think you could teach kids the computational equivalent of pretty high level mathematical physics, which is pretty interesting relative to other standard CS101 intros (like python, etc). TeleScript, which was basically inverse JVM was also made around this time, it would have been interesting if the Newton hadn't been discontinued:

https://en.wikipedia.org/wiki/Telescript_(programming_langua...

These days, ironically, Telescript is a model for how distributed computation works in the 3rd world, and even in the first world. But Telescript basically would have made the lattice structures more hybridizable to project information and jobs within the context of already existent social networks and maybe provided a better nexus for useful work done vs power given up (it was made on a very astute observation about the energy, work, power, time, information, transmission nexus) before anyone named a "peer to peer network", a distributed consensus protocol, or introduced money into the picture.

Reply on news.ycombinator.com