Hacker News new | ask | show | jobs
by astura 2024 days ago
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.

3 comments

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?

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)

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.

> 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)

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.
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.

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.
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.
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.

I feel like "requires compilation" is a good first order differentiator. And "has a somewhat sane type system" is another.
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.

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.
> 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.
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.
I've never seen Java called a scripting language before, actually.
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?

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.

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).

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 :)
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.
Sun had some great people and some good ideas and products, but as a coherent business it was a rolling train wreck.
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.

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.

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.