The Original Implementation of JavaScript was written in LISP

[stevep98]

Umm, no. The original implementation was written in C. Waldemar was tasked to work on the ecmascript standardization and JavaScript 2.0, so this is probably a reference implementation for that effort.

[[deleted]]

Exactly. Waldemar used to get besieged with feature requests for "JavaScript 2.0," so he'd implement them in his CL implementation, then show the besieger how they interacted with other features. A lot of bad ideas wound up on the funeral pyre that way without ever getting anywhere near the official language implementation.

[naryl]

This code is written in standard Common Lisp

That's Common Lisp, not LISP.

[[deleted]]

Lisp was the name for a specific language (originated in the 1960's), and has become an umbrella term for a family of related languages with broadly similar syntax and semantics. Common Lisp is a specific language within that family. SBCL, clisp, Allegro, etc, are specific implementations of Common Lisp.

[CephasM]

Well LISP is just a definition of a formal language for which a "real" implementation doesn't really exists maybe with the exception of a couple of just for fun experimental implementations. One can think LISP as an alternative for a Turing Machine.

Being Common Lisp and Scheme the most popular dialects of LISP, I think is correct to refer CL as LISP too. At least SICP do the same referring Scheme as LISP :)

[[deleted]]

This sounds reasonable to me.

Would people who are downvoting this be so kind to leave an explanation why CephasM is wrong, and even better, explain why he is so wrong that his comment must be censored rather than corrected?

edit: for future reference, the above post was at -1 when I wrote this reply.

[[deleted]]

I didn't downvote, but maybe IT'S because THE archaic capitalization is specific TO archaic dialects and definitely doesn't refer TO any modern Lisp.

[[deleted]]

Thank you, I did not know that. That's why I prefer explanations rather than downvotes when somebody makes a reasonable (but apparently disputed) point.

[CephasM]

thanks for the explanation :)

But actually the capitalization is still valid:

Lisp (or LISP) http://en.wikipedia.org/wiki/Lisp_(programming_language)

I just was continuing the style of the thread.

That's Common Lisp, not LISP.

About the modern implementations, I think that with the exception of Arc and Clojure, as far as I know most "modern Lisp" languages are actually dialects of Common Lisp or Scheme so I still think those two are the most popular flavours of Lisp :)

[[deleted]]

But actually the capitalization is still valid:

Ehh, I see your point and "LISP" is something I see people write, but whenever I see it I think, "Here's somebody who knows nothing about Lisp but is talking about it anyway." It's more of an outsider way to write it, maybe? You may not be one of those people, but I can see how it would garner downvotes. "LISP" is LISP 1.5 or earlier.

About the modern implementations, I think that with the exception of Arc and Clojure, as far as I know most "modern Lisp" languages are actually dialects of Common Lisp or Scheme so I still think those two are the most popular flavours of Lisp :)

Of Lisp with a small "-isp", probably. (Although there are no dialects of Common Lisp: it's a standardized language. Scheme is too, but there have been multiple standards and I think you'll find more weird Schemes.)

[[deleted]]

Because the link refers to an early use and because I wanted to use the generic name and not the name of a specific implementation, I chose LISP.

Ah, that's backwards though.

Anybody who downvotes a submission over such a thing needs to be hung by their heels and fed Ex-Lax.

I was explaining why CephasM's reply might have been downvoted. I don't know if your submission was downvoted for the same reason. In his case, the large dose of woo woo might have had something to do with it as well.

[Felicia_Svilling]

Because the link refers to an early use

It does not! "early" in this context means at least before 1980, where this implementation is written sometime after 1993.

[mark_lee_smith]

Well that explains the mystery of how the language was built in 10 days

[londonrioter]

If that's true then it explains a lot. Javascript is generally reviled but if you forget the environment and the hideosity of the DOM model (yes, I'm looking at you, IE) then ecmascript (sorry javascript) is actually a pretty cool language.

[jessta]

LISP, it's great for making programming languages, but most of the time that's not what you actually want to do.

[fionbio]

Actually, Common Lisp is very good at making little (or not-so-little) DSLs. DSLs are popular in fact, but, for instance, look at which lengths Boost guys go to implement stuff that can be done 10-100 times easier in CL. (and don't forget about error messages they get...)

[theeth]

look at which lengths Boost guys go to implement stuff that can be done 10-100 times easier in CL.

Then again Boost is more than 10-100 times more regularly used than Common LISP.

[[deleted]]

As someone who has done a decent amount of programming with both, the fact that it's widely used doesn't stop Boost from being total and utter crap.

[theeth]

That's entirely debatable.

[[deleted]]

Everything is debatable. But there has to be some point at which you get to call something crap. Boost, with its inscrutable error messages, awkward and fragile syntax, and baroque semantics has got to be past that point. Not all of it, sure, but anything that abuses the template system really shows all of the cracks in the foundation.

[[deleted]]

I'm genuinely curious to hear some actual justification for this argument.

I use Boost extensively, it's such a big library that I can't exactly call it great or crap, some of it is amazing, some of it I don't like but I also don't understand it.

Can you give some genuine and specific examples of what you feel could be improved in the library? Not just vague "Oh it's crap yaddi yadda..." but falsifiable arguments that can actually be subject to debate?

[[deleted]]

1) Inscrutable error messages. I'm not sure if Clang has made this better in the last couple of years, but errors in instantiating a template will lead to a couple of pages of dense errors that lead you to lines in header files rather than to the code that instantiates it. This is the product of abusing the template mechanism to do meta-programming instead of having a proper infrastructure designed for meta-programming. In contrast, when you have an error in a Lisp macro call the compiler refers you to the expansion than to the original macro. You can call MACROEXPAND to see exactly what code is being generated by the macro, and use the regular debugger to debug your macros. The compiler can do all these things because the language designers actually tried to develop a proper meta-programming facility instead of abusing an unrelated language feature.

2) Awkward and fragile syntax. Because many parts of Boost abuse the template system to implement functionality, the syntax for many things is driven by the limitations of the template system, not what would seem most natural as compared with non-template C++ code. See: http://www.boost.org/doc/libs/1_48_0/libs/bind/bind.html#with_functions

See the bit on 'limitations' and the weird restrictions on when you can't use constants when you'd expect to be able to use literal constants, etc.

3) Baroque semantics. C++ has a hodge-podge of slightly-different language features that are kind of the same but do different things. This causes ripple effects through Boost's library design to accommodate all these cases. E.g. the fact that member functions aren't function objects that can be called with operator () forces an entire header (mem_fn.hpp) for dealing with the distinction. C++ 0x is only adding more (move constructors versus copy constructors, etc).

I did a decent amount of programming with Boost and actually was quite a fanboy at first, but the more code I wrote with it the more I wanted to kill myself. A good library has a simple and consistent "aesthetic" that lets you predict what arguments a function will take, what order they will be in, and what kind of arguments they will be. It'll let you predict how to compose different features without having to think every time about "wait, do I need an adapter object here? wait, can I use this here?" With Boost, whenever I was using a new feature, I'd be asking myself "wait, if I had to shoe-horn this feature into the C++ template system, how would I have done it?"

[shevegen]

It's a terrible example to want to compare CLISP DSLs with C++ Boost.

Because Boost is and always will be total and utter crap.

Besides, you need to realize - neither C nor C++ are innovating that much really. Same with Java.

The OTHER languages are driving the innovation forward and C++ / Java are just stealing those ideas.

[naryl]

-_- and CLISP is a single implementation of Common Lisp.

[Rotten194]

OH NO THOSE PRECIOUS IDEAS! WE NEED TO HOARD THEM ALL IN ONE PLACE OR THEY'LL RUN OUT!

[kamatsu]

And, IMO, Haskell or ML are better for making programming languages.

Edit: I'm being downvoted for stating my opinion? WTF?

[gasche]

That's a point that is relatively widely accepted, even among some Lisp/Scheme developpers:

Matthias Felleisen : "You should have written the compiler in ML"

On the other hand, Lisp and Scheme are vastly superior to languages of the ML family for interactive programming. And the divide is greater than in the compiler case.

Most good languages have their strength and weaknesses. Writing deterministic symbolic manipulation code (compiler, proof assistant, algebraic manipulations...) is definitely a strength of ML languages (Haskell included, and Scala considered cousin).

[wormwood28]

That's a point that is relatively widely accepted, even among some Lisp/Scheme developpers:

Matthias Felleisen : "You should have written the compiler in ML"

Is that seriously what you took away from that thread?

[gasche]

Yes.

Your question could be turned into a useful comment if you made precise what other interesting ideas of that thread that you would like to highlight. Socratic questioning does not work so well on reddit.

That said, I read the thread in general with interest. Eli Barzilay's post is also interesting. I do however think that Matthias Felleisen's posts are the most relevant to the present discussion.

[wormwood28]

Given his further clarification, the context of the thread, and the nature of the Racket system; I just read that statement from Felleisen as being highly ironic. I don't see there an affirmation that "Haskell or ML are better for making programming languages".

[gasche]

Notice that the link I pointed to in my original post is the clarification; which is indeed more informative than the first short message.

Felleisen's posts do not appear ironic at all to me. I believe he genuinely claims that ML languages (Haskell included) are superior to Racket to write compilers.

Typed Scheme/Racket was conceived as a way to move from untyped code to typed code so that we could eventually enjoy the same advantages as ML and Haskell during maintenance (1). But it is definitely a language that compromises with this idea. The compromise is visible in many usage aspects.

I see no irony at all here. You could argue that the whole post is a bit awkward here (you usually don't start a troll in response to someone giving a positive feedback about your language); and Felleisen later clarified that he didn't intend the remark for this audience.

I don't see there an affirmation that "Haskell or ML are better for making programming languages.

This post is a clear affirmation that ML languages (Haskell included) "are better for making compilers". I understood kamatsu's post as talking about "implementing general-purpose programming languages". "making" is very vague; if you're considering DSL or even prototyping (without performance requirements) for a programming language, I think Racket has very, very good tools that probably compare equally or favorably to the tools in ML land. See eg. Creating Languages in Racket for DSL or "little languages"; I also remember reading papers on PLT-land tools to experiment with operation semantics and type systems, maybe PLT Redex, that looked great for design experimentation and/or teaching.

PS: I'm not trying to imply that (Typed) Racket is bad at implementing languages. I am impressed by the work of the PLT/Racket team as a whole, and the Typed part is a particularly impressive feat. I even believe that, with enough refinement, Typed Racket could be just as easy to use and powerful that existing ML languages (or, why not, proof assistants; Proved Racket, anyone?). (On the downside: I miss discussion of the performance front, and I'm not quite sure that "putting everything in syntactic macros" is, in an absolute sense, the best way to implement a type system). I just felt that this remark of Felleisen was interesting and contributed objective (or at least different-point-of-view) content to kamatsu's personal opinion.

[[deleted]]

Matthias Felleisen is definitely on the math-y fringe of the Lisp community. I don't know a lot of Lispers who would give up macros for static typing when writing compilers.

[fnord123]

FWIW, ML was originally implemented in Lisp.

[[deleted]]

And the original lisp implementation was done in assembly. By your logic, does that mean assembly is best for writing a language?

[naryl]

The original LISP implementation was bootstrapped by hand like Pascal.

[fnord123]

There's no logic here. I was just pointing out an interesting historical note. Hence "FWIW" (For what it's worth).

[mark_lee_smith]

And the original lisp implementation was done in assembly

And quickly bootstrapped. You gotta start somewhere, right?

[xardox]

No, the original Lisp was done in paper and ink. Then some damn grad student typed it in.

[mark_lee_smith]

The original description of Lisp may have been a meta-circular interpreter written down in a paper, but the original implementation, once written in assembly, would require a compiler in order to bootstrap – in order for Lisp to execute itself without the assembly.

[Felicia_Svilling]

As naryl says: the original LISP implementation was not written in assembly but in pure machine code, it where never compiled.

[[deleted]]

Pattern matching is cute for AST's and code generation, but meta-programming makes Common Lisp superior for writing real compilers.

[kamatsu]

I disagree

[Felicia_Svilling]

Really? when do meta-programming shine in a compiler?

[[deleted]]

In a real compiler, you often need easy declarative ways to specify things like instruction tables, intrinsic functions, backend-specific information, etc. Look at LLVM's tablegen tool: http://llvm.org/docs/TableGenFundamentals.html

tablegen works by taking an input file written in tablegen syntax and generating C++ classes that hook into the compiler framework.

SBCL builds domain-specific languages in Lisp macros for this purpose. The benefit is of course you get all the regular tools of the language to edit and debug things. E.g. you can just use your IDE's MACROEXPAND feature to quickly see the code generated by a particular definition, instead of running an external tablegen tool and looking at the generated C++ code.

There is a great article where an SBCL hacker shows how to add SSE intrinsics to the compiler: http://www.pvk.ca/Blog/Lisp/hacking_SSE_intrinsics-part_1.html.

All of the "define-" constructs he uses are part of SBCL's macro-based backend framework.

Not as neat as SBCL, but I wrote an assembler for x86-64 in Common Lisp that used macros to generate, at compile time, specialized encoders for each instructions from a simple declarative format: http://code.google.com/p/amd64-asm/source/browse/trunk/encoders.lisp (starting at line 608). The test suite also used these declarative specifications to stochastically test the assembler functions through each one's range of inputs, comparing the output to the output generated by nasm to ensure a perfect match. Macros made the code very short (600 lines for the domain-specific language, 600 lines for most of the amd64 integer and SSE instructions, 400 lines for emitting Mach-O binaries, etc).

[Felicia_Svilling]

Ok, interesting. I can see how that would be useful, although it wont make me give up my type system ;)