The original Javascript impl was written in Lisp | Hacker News Reader

The original Javascript impl was written in Lisp

mxr.mozilla.org

62 pointsDiabloD329 comments

How does this link demonstrate that fact?

I actually might be wrong about this being the original.

Waldemar Horwat worked with Brenden Eich at Netscape and hacked on the JS impl in Netscape 2.0, but the dates are too late.

If its not the original, what is it?

You linked obviously the much later code than what can be anything relevant for the first Javascript implementation in Netscape in nineties.

If I understand it correctly, this is the experimental code that was supposed to be used in the research for a "big leap" in Javascript syntax considered by Mozilla around the middle of the previous decade.

The keyword to search for can be Epimetheus, it appears in the sources you linked:

http://www-archive.mozilla.org/js/language/Epimetheus.html

http://discerning.com/burstproject.org/build/doc/constructs....

'Mozilla's implementation ("JavaScript 2.0", or "Epimetheus"): http://www.mozilla.org/js/language/Epimetheus.html http://www.mozilla.org/js/language/js20/ It (of course) has all features of Draft ECMAScript 4, and a few additions. It is not (to our knowledge) shipping in any product.'

Yes, that's how I remember it too.

http://en.wikipedia.org/wiki/SpiderMonkey_(JavaScript_engine...

>>> Eich "wrote JavaScript in ten days" in 1995,[1] having been "recruited to Netscape with the promise of “doing Scheme” in the browser".[2] (The idea of using Scheme itself was abandoned when "engineering management [decided] that the language must ‘look like Java’".[2]) In fall 1996, Eich, needing to "pay off [the] substantial technical debt" left from the first year, "stayed home for two weeks to rewrite Mocha as the codebase that became known as SpiderMonkey".[1]

sigh... the developer wanted to use Lisp, then management opted for Java. Typical.

File extensions and timestamps? Not sure about 'original' though.

js2 as in 'js2 the abandonned branch ES4' ?

I love the author's nickname : Captain Abstraction

http://www.webmasterkb.com/Uwe/Forum.aspx/javascript/35764/F...

Huh, either way I seem to have found a lost piece of history on my travels through the web.

You should still change the wrong title.

The individual files are good to read, but are there any links to .tar or .zip of all the files? I have looked and didn't find any....

What a horrible irony this would be if true: Lisp used to enslave generations of programmers with JavaScript.

Enslaved? This word reminds me of C, C++, Java, C#, ... :-)

It's funny that all these modern languages have copied - and are still copying - features which Lisp had for decades.

I know really many programming languages but the power of Lisp is still superior. I can express myself in much less code than in all other modern languages. Python is an exception but that's no surprise because Python is just a subset of Lisp with a modern syntax and clean API.

Regarding Javascript, I think it will be the top language of the coming decade because it offers everything the average programmer needs: easy syntax, many APIs and even speed (Google V8 etc.). Even Microsoft supports Javascript. I also believe that many of the other languages will provide backends for Javascript soon.

I heard this a lot:

Modern languages copying features that Lisp had for decades

Lisp is still superior

Can write less code in Lisp

Ok. Gotcha.

Now, I'd like to build a web-app with some storage backend (mixed of RDBMS and NoSQL). Can do REST API. Requires web-service integration. Will perform nightly batch computation using Hadoop. Would like to have automation test and continuous integration.

Before Clojure, how can I do all of these with less code using LISP?

PS: I'm still unsure how pure Clojure can help me as well seeing that now suddenly I required a Java object with JAXB annotation and probably require JAX-WS client API to do web services, etc.

RDBMS - CLSQL it does everything. NoSQL - Whatever you want. Cl-mongo exists. There's even CLOS object stores for when you really want object persistence. REST - This isn't really a language thing. Web- UnCommon Web, Huchentoot, Weblocks. You can even write your javascript in parenscript and be lisp all the way down.

If you want to know how LISP can do all of this and more please read Practical Common Lisp. http://www.gigamonkeys.com/book/

Just keep in mind that the book is a few years old now.

I would also like to ask why you think it's not possible to do any of the things you've asked of in any language?

It's possible to do everything I asked in many other languages.

But my question was specifically: how can I do all of those and at the same time write in less code.

If I have to roll my own framework or library (lightweight or not) wouldn't that count as writing more code than I have to?

> how can I do all of those and at the same time write in > less code.

It's not about writing the same algorithms in less code but about the way you design them. When you write Lisp code the same way as say Java or C++ then it's likely that you won't have less code.

Lisp changed the way how I write programs. THAT makes the difference. For instance, in Java or C++ I write a loop to apply a function on a data collection. In Lisp I just use a map function for those elements. In Lisp it's very usual to use macros to shorten code. These macros have NOTHING to do with the harmful C++ macro system. They are just functions to create well structured code.

Python copied list comprehensions from Lisp. This is a good example how a Lisp fesature makes code way shorter.

Let me rephrase the question. Why do you believe you have to roll your own frameworks for everything?

I just presented you with a couple of frameworks geared towards web development. There are NoSQL solutions as well. Couch, Mongo, Redis whatever. Writing your own bindings shouldn't be too difficult either.

> Now, I'd like to build a web-app with some storage backend >(mixed of RDBMS and NoSQL). Can do REST API. Requires > web-service integration. Will perform nightly batch > computation using Hadoop. Would like to have automation > test and continuous integration.

Quick research: http://racket-lang.org/ http://planet.racket-lang.org/ (the "CPAN" of Racket) http://en.wikipedia.org/wiki/MongoDB http://docs.racket-lang.org/continue/index.html (web apps) https://github.com/dmacdougall/spin (RESTful web apps) http://en.wikipedia.org/wiki/Datalog

The shell commands of Racket could be used for (native compiled) batch files.

Some real world applicatons: http://www.mail-archive.com/users@racket-lang.org/msg07436.h...

The only thing I miss is a sophisticated GUI editor like in Delphi Pascal. MrEd is similar but only supports the basic GUI components (labels, buttons, ...). I hope composed components (tables ...) will come in future.

If you want to write really short code then take a look at Shen:

http://www.shenlanguage.org/Documentation/index.htm

It supports Lisp, Scheme and Javascript as backend.

I'm doing this sort of thing with Kawa Scheme and a JSON parser written in Scheme.

Come, JavaScript isn't that bad: it's probably one of the most pleasant of the popular languages; it's just unpolished and has some stupid bits.

I suspect you just described almost every language ever.

Let me rephrase it then: fundamentally, JavaScript is sound. It's like a nice city with a couple of bad neighborhoods you can usually avoid. Other languages have much more pervasive bad features, and yet others are fundamentally unsound. JavaScript is fine.

Saying that "Javascript is fundamentally sound" is like saying "McDonalds serves fundamentally nutritious food". It's technically true, but ignores completely what people actually mean when they use the phrases like "fundamentally sound".

Let's take the empirical approach:

"Come, BrainFk isn't that bad: it's probably one of the most pleasant of the popular languages; it's just unpolished and has some stupid bits."

Nope, guess not.

Let me rephrase, "almost every language that is close to or has met its peak popularity"

Isn't that bad compared to...the language it was supposedly implemented in? Yes, yes it is that bad.

I'm not saying JavaScript isn't worse than Lisp: I just think that describing it as "enslaving generations of programmers" is a bit much.

Reply on news.ycombinator.com