Sunday, November 16, 2008

Ejacs: a JavaScript interpreter for Emacs

So! I have all these cool things I want to write about, but I broke my thumbnail. Can you tell that's a long story?

See, this summer I got excited about playing guitar again. I usually switch between all-guitar and all-piano every other year or so. This summer I dusted off the guitars and learned a bunch of pieces, and even composed one. I was prepping for — among other things — a multimedia blog entry. It was going to have a YouTube video, and a detailed discussion of a wacky yet powerful music programming language you've probably heard of but never used, and generally just be really cool.

And then it all came crashing down when I busted my thumbnail off. And I mean off — it broke off at least a quarter inch below where the nail and skin meet. Ick. I just accidentally jabbed my steering wheel, and that was that.

I remember reading an interview with some dude who said he had punched a shark in the nose. He said it was like punching a steering wheel. So now I know more or less what it's like to punch a shark in the nose, I guess. There's always an upside!

Anyway, that was going to be my magnum opus (literally: Op. 1) for the year, but it fell through for now. I'll have to revisit the idea next year. My thumbnail's back, but it's been at least 2 months since I touched my guitar, so I'll have to start over again.

Work has been extraordinarily busy, what with having to collect all these Nuka-Cola Quantum bottles and so on. I'm sure you can imagine. So I haven't had much time to blog lately.

But I do like to publish at least once a month, whether or not anyone actually cares. It's been about a month, or it feels that way anyway, and all I have to show for it is this box of Blamco Mac and Cheese.

So I'm cheating this month.

You know how on Halloween how you walk around in your costume holding your little bag and you say "trick or treat", and every once in a while some asshole does a trick instead of dumping half a pound of candy into your bag? And then he has to explain to all the dumbfounded and unhappy kids that "Trick or Treat" means that a trick is perfectly legal according to the semantics of logical-OR, and the kids remember that a-hole for the rest of their childhoods and avoid his house next year?

Yeah.

So I'm doing a trick this time. Hee. It's actually kind of fun when you're on the giving end.

My trick is this: in lieu of saying anything meaningful or contemporarily relevant, I'm writing about something I did over a year ago. And there isn't much to say, so this really will be short.

Ejacs

Around a year ago, I wrote a blog called Stevey's Boring Status Update, mostly in response to wild rumors that I'd been fired from Google. Not so. Not yet, anyway.

In that blog I mentioned I was working nights part-time (among other things) on a JavaScript interpreter for Emacs, written entirely in Emacs Lisp. I also said I didn't have a name for it. A commenter named Andrew Barry suggested that I should not call it Ejacs, and the name stuck.

Ejacs is a port of Narcissus. Narcissus is a JavaScript interpreter written in JavaScript, by Brendan Eich, who by pure unexpected coincidence is also the inventor of JavaScript. Narcissus is fairly small, so I thought it would be fun to port it to Emacs Lisp.

It turns out Narcissus is fundamentally incomplete. It cheats. It's that trick guy on Halloween. Narcissus has a working parser and evaluator, but for its runtime it calls JavaScript. So it's kind of like saying you're building a car by starting from scratch, using absolutely nothing except for a working car.

This meant I wound up having to write my own Ecma-262 runtime, so that the evaluator would have something to chew on. In particular, the Ecma-262 runtime consists of all the built-in properties, functions and objects: Object, Function, Array, String, Math, Date, RegExp, Boolean, Infinity, NaN, parseInt, encodeURIComponent, etc. A whole bunch of stuff.

I basically did this by reading the ECMA-262 specification and translating their algorithms into Emacs-Lisp. That spec is lousy for learning JavaScript, but it's absolutely indispensable if you're trying to implement JavaScript.

I didn't know Emacs-Lisp all that well before I started, but boy howdy, I know it now.

Emacs actually has a pretty huge runtime of its own — bigger than you would ever, ever expect given its mundane title of "text editor". Emacs has arbitrary-precision mathematics, deep Unicode support, rich Date and Calendar support, and an extensive, fairly complete operating system interface. So a lot of the porting time was just digging through Emacs documentation (also extensive) looking for the Emacs version of whatever it was I was porting. That was nice.

I had big plans for Ejacs. I was going to make it a full-featured, high-performance JavaScript interpreter, with all the Emacs internals surfaced as JavaScript native host objects, so you could write Emacs customizations using object-oriented programming. It was totally going to be the "meow" part of the cat.

And then I broke my thumbnail.

Actually, what happened was js2-mode.

js2-mode

After I got the interpreter working, I was at this crossroads. There were two big use cases: a JavaScript editing mode, or a JavaScript Emacs development mode. Both were going to be a lot of work.

It turns out you really want the editing mode first, if possible, so that when you're doing all your JavaScript programming you have a decent environment for it. So I picked the editing mode.

Unfortunately I found the Ejacs parser wasn't full-featured enough for my editing needs, since at the time I was working on my Rhino-based Rails clone and writing tons of JavaScript 1.7 code on the JVM.

I spent a little time trying to beef up the parser, then realized it would be a lot faster to just rewrite it by porting Mozilla Rhino's parser, which is (only) about 2500 lines of Java code. Ejacs is something like 12,000 lines of Emacs-Lisp code, all told, so that didn't seem like a big deal.

So I jumped in, only to find that while the parser is 2500 lines of code, the scanner is another 2000 lines of code, and there's another 500 or so lines of support code in other files. So I was really looking at porting 5000 lines of Java code.

Moreover, the parse tree Rhino builds is basically completely incompatible with the Ejacs parse tree. It was richer and more complex, and needed more complicated structures to represent it.

So after I'd ported the Rhino parse tree, what I really had was a different code base. I went ahead and finished up the editing mode, or at least enough to make it barely workable (another 5000 lines of code), and launched it. It was a surprisingly big effort.

And it left poor Ejacs lying unused in the basement.

So today, faced with nothing to write about, I figured I'd dust off Ejacs, launch it with lots of fanfare, and then you'd hardly notice that I cheated you. Right?

You're not coming to my house next year. I can tell already.

Anyway, here's the code: http://code.google.com/p/ejacs/

There's a README and a Wiki and installation instructions and stuff. I can't remember how to put the code in SVN, and I'm having trouble finding it on the code.google.com site. As soon as I figure it out I'll also make it available via SVN.

Emacs Lisp vs. JavaScript

In the interests of having something resembling original worthwhile content today, I'll do a little comparison of Emacs Lisp and JavaScript. I know a lot about both languages now, and a few folks mentioned that a comparison would be potentially interesting.

Especially since I think JavaScript is a better language.

So... the best way to compare programming languages is by analogy to cars. Lisp is a whole family of languages, and can be broken down approximately as follows:
  • Scheme is an exotic sports car. Fast. Manual transmission. No radio.
  • Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."
  • Common Lisp is Howl's Moving Castle.

This succinct yet completely accurate synopsis shows that all Lisps have their attractions, and yet each also has a niche. You can choose a Lisp for the busy person, a Lisp for someone without much time, or a Lisp for the dedicated hobbyist, and you'll find that no matter which one you choose, it's missing the library you need.

Emacs Lisp can get the job done. No question. It's a car, and it moves. It's better than walking. But it pretty much combines the elegance of Common Lisp with the industrial strength of Scheme, without hitting either of them, if you catch my drift.

Anyway, here's the comparison. Here's why I think JavaScript is a better language than Emacs Lisp.

Problem #1: Momentum

A recurring theme is that Elisp and JavaScript both will both exhibit a particular problem, and there are specific near-term plans to fix it in JavaScript, but no long-term plans to fix it in Elisp.

It's easier to resign yourself to a workaround when you know it's temporary. If you know the language is going to be enhanced, you can even design your code to accommodate the enhancements more easily when they appear.

People are working on improving JavaScript. It's not happening quite as fast as I'd hoped earlier this year, but it's still happening. As far as I know, Emacs Lisp is "finished" in the sense that no further evolution to the language is deemed necessary by the Emacs development team.

Problem #2: No encapsulation

Every symbol in Emacs-Lisp is in the global namespace. There is rudimentary support for hand-rolled namespaces using obarrays, but there's no equivalent to Common Lisp's in-package, making obarrays effectively useless as a tool for code isolation.

The only effective workaround for this problem is to prefix every symbol with the package name. This practice has become so entrenched in Emacs-Lisp programming that many packages (e.g. apropos and the elp elisp profiler) rely on the convention for proper operation.

The main adverse consequence of this problem in practice is program verbosity; it makes Emacs-Lisp more difficult to read and write than Common Lisp or Scheme. It can also have a non-negligible impact on performance, especially of interpreted code, as the prefix characters can approach 5% to 10% of total program size in some cases.

The problems run slightly deeper than simple verbosity. Without namespaces you have no real encapsulation facility: there is no convenient way to make a "package-private" variable or function. In practice there's little problem with program integrity; it's hard for an external package to change a "private" variable inadvertently in the presence of symbol prefixes. However, it makes it annoyingly difficult for users of the package to discern the "important" top-level configuration variables and program entry points from the unimportant ones. Elisp attempts a few conventions here, but it's a far cry from real encapsulation support.

JavaScript also lacks namespaces. They're being added in ES/Harmony, but in the meantime, browser JavaScript code typically uses the same name-prefixing practice as Emacs-Lisp.

However, JavaScript has lexical closures, which provide a mechanism for creating private names. One common encapsulation idiom in browser JavaScript is to wrap a code unit in an anonymous lambda, so that all the functions in the code unit become nested functions that close lexically over the top-level names in the anonymous lambda. This trick is nowhere near as effective in Emacs-Lisp, for several reasons:
  • elisp is not lexically scoped and has no closures
  • elisp nested defuns are still entered into the global namespace
  • CL's `flet' and `labels' are only weakly supported, via macros, and they frequently confuse the debugger, indenter, and other tools.

Some elisp code (e.g. much of the code in cc-engine) prefers to work around the namespace problem by using enormous functions that can be thousands of lines long, since let-bound variables are slightly better encapsulated. Even this is broken by elisp's dynamic scope:
(defun foo ()
(setq x 7))

(defun bar ()
(let ((x 6))
(foo)
x)) ; you would expect x to still be 6 here

(bar)
7 ; d'oh!

So let-bound variables in elisp can still be destroyed by your callee: a dangerous situation at best.

Emacs is basically one big program soup. There's almost no encapsulation to speak of, and it hurts.

Problem #3: No delegation

One of the big advantages to object-oriented programming is that there is both syntactic support and runtime support for automatic delegation to a "supertype". You can specialize a type and delegate some of the functionality to the base type. Call it virtual methods or prototype inheritance or whatever you like; most successful languages support some notion of automatic delegation.

Emacs Lisp is a lot like ANSI C: it gives you arrays, structs and functions. You don't get pointers, but you do get garbage collection and good support for linked lists, so it's roughly a wash.

For any sufficiently large program, you need delegation. In Ejacs I wound up having to implement my own virtual method tables, because JavaScript objects inherit from Object (and in some cases, Function, which inherits from Object).

Writing your own virtual method dispatch is just not something you should have to do in 2008.

Problem #4: Properties

I wrote about this at length in a recent blog post, The Universal Design Pattern. JavaScript is fundamentally a properties-based language, and it's really nice to be able to just slap named properties on things when you need a place to store data.

Emacs Lisp only offers properties in the form of simple plists – linked lists where the odd entries are names and the even entries are values. Symbols have plists, and symbols operate a little bit like very lightweight Java classes (in that they're in the global namespace), but that only gets you so far. If you want the full JavaScript implementation of the Properties Pattern, you'll have to write a lot of code.

And so I did. Your implementation choice for object property lists has a huge impact on runtime performance. Emacs has hashtables, but they're heavyweight: if you try to instantiate thousands of them it slows Emacs to a crawl. So they're no good for the default Object property list. Emacs also has associative arrays (alists), but their performance is O(n), making them no good for objects with more than maybe 30 or 40 properties.

I wound up writing a hybrid model, where the storage starts with lightweight alists, and as you add properties to an object instance, it crosses a threshold (I set it to 50, which seemed to be about right from profiling), it copies the properties into a hashtable. This had a dramatic increase in performance, but it was a lot of work.

I experimented with using a splay tree. I implemented Sleater and Tarjan's splay tree algorithm in elisp; Ejacs comes with a standalone splay-tree.el that you can use in your programs if you like. I was hoping that its LRU cache-like properties would help, but I never found a use case where it was faster than my alist/hashtable hybrid, so it's not currently used for anything.

And then in the end, after I was done with my implementation, it was a library (at least from the Emacs-Lisp side of the house). It wasn't an object system for Lisp. It's only really usable inside the JavaScript interpreter, where it has syntactic support.

You really want syntactic support. Sure, people have ported subsets of CLOS to Emacs Lisp, but I've always found them a bit clunky. And even in CLOS it's hard to implement the Properties Pattern. You don't get it by default. CLOS has lots of support for compile-time slots and virtual dispatch, but very little support for dynamic properties. It's not terribly hard to build in, but that's my point: for something that fundamental, you don't want to have to build it.

Problem #5: No polymorphic toString

One of the great strengths of JavaScript is the toSource extension. I don't know if they support it over in IE-land; I haven't been a tourist there in a very long time. But in real versions of JavaScript, every object can serialize itself to source, which can then be eval'ed back to construct the original object.

This is even true for functions! A function in JavaScript can print its own source code. This is an amazingly powerful feature.

In Emacs Lisp, some objects have first-class print representations. Lists and vectors do, for instance:

(let ((my-list '()))
(push 1 my-list)
(push 2 my-list)
(push 3 my-list)
my-list)
(3 2 1)

(let ((v (make-vector 3 nil)))
(aset v 0 1)
(aset v 1 2)
(aset v 2 "three")
v)
[1 2 "three"]


But in Emacs Lisp, many built-in types (notably hashtables and functions) do NOT have a way to serialize back as source code. This is a serious omission.

Also, trying to print a sufficiently large tree made entirely of defstructs will crash Emacs, which caused me a lot of grief until I migrated my parse tree to use a mixture of defstructs and lists. Note that simply typing the name of a defstruct, or passing over it ephemerally in the debugger, will cause Emacs to try to print it, and crash. Fun.

The problem of polymorphic debug-printing (or text-serialization) is, I think, a byproduct of Emacs not being object-oriented. If you want a debug dump of a data structure, you write a function to do it. But Emacs provides a half-assed solution: it debug-prints lists very nicely, even detecting cycles and using the #-syntax for representing graph structures (as does SpiderMonkey/JavaScript). But it has no useful debugging representation for hashtables, functions, buffers or other built-in structures, and there's no way to install your own custom printer so that the debugger and other subsystems will use it.

So it sucks. Printing data structures in Emacs just sucks.

The situation in Ecma-262-compliant JavaScript really isn't that much better, although you can at least install your own toString on the built-ins. But any competent "server-side" JavaScript implementation (i.e. one designed for writing real apps, rather than securely scripting browser pages) has a way to define your own non-enumerable properties, so you can usually override the default behavior for things like toString and toSource.

And all else being equal, at least JavaScript functions print themselves.

Emacs advantages: Macros and S-expressions

Pound for pound, Emacs Lisp seems roughly as expressive as JavaScript or Java for writing everyday code. It shouldn't be that way. Emacs Lisp ought to be more succinct because it's Lisp, but it's incredibly verbose because of the namespace problem, and it's also verbose to the extent that you want to use the properties pattern without worrying about alist or hashtable performance.

Elisp does have a few places where it shines, though. One of them is the cl (Common Lisp emulation) package, which provides a whole bunch of goodies that make Elisp actually usable for real work. Defstruct and the loop macro are especially noteworthy standouts.

Some programmers are still operating under the (ancient? legacy?) assumption that the cl package is somehow deprecated or distasteful or something. They're just being silly; don't listen to them. Practicality should be the ONLY consideration.

The cl package wouldn't have been possible without macros. JavaScript has no macros, so even though it has better support for lambdas, closures, and even (in some versions) continuations, there are still copy/paste compression problems you can't solve in JavaScript.

Emacs Lisp has defmacro, which makes up for a LOT of its deficiencies. However, it really only has one flavor. Ideally, at the very least, it should support reader macros. The Emacs documentation says they were left out because they felt it wasn't worth it. Who are they to make the call? It's the users who need them. Implementer convenience is a pretty lame metric for deciding whether to support a feature, especially after 20 years of people asking for it.

Elisp is s-expression based, which is a mixed bag. It has some advantages, no question. However, it fares poorly in two very common domains: object property access, and algebraic expressions.

JavaScript is NOT s-expression based (or it wouldn't be a successful language, many would argue), but it does offer some of the benefits of s-expressions. JSON is one such benefit. JavaScript's declarative object literals (or as a Lisp person would say, "syntax for hashes") and arrays provide a powerful mechanism for designing and walking your own declarative data structures.

JavaScript also has all the usual (which is to say, expected) support for algebraic operators. And unlike Java, JavaScript even got the precedence right, so it's not full of redundant parentheses.

Overall Comparison

In the end, it comes down to personal choice. I've now written at least 30,000 lines of serious code in both Emacs Lisp and JavaScript, which pales next to the 750,000 or so lines of Java I've crapped out, and doesn't even compare to the amount of C, Python, assembly language or other stuff I've written.

But 30,000 lines is a pretty good hunk of code for getting to know a language. Especially if you're writing an interpreter for one language in another language: you wind up knowing both better than you ever wanted to know them.

And I prefer JavaScript over Emacs Lisp.

That said, I suspect I would probably prefer Clojure over Rhino, if I ever get a chance to sit down with the durn thing and use it, so it's not so much "JavaScript vs. Lisp" as it is vs. Emacs Lisp.

I would love to see Emacs Lisp get reader macros, closures, some namespace support, and the ability to install your own print functions. This reasonably small set of features would be a huge step in usability.

However, for the nonce I'm focusing on JavaScript. I've found that JavaScript is a language that smart people like. It's weird, but I keep meeting really really smart people, folks who (unlike me) are actually intelligent, and they like JavaScript. They're always a little defensive about it, and almost a little embarrassed to admit it. But they think of it as an elegant, powerful, slightly flawed but quite enjoyable little language.

I tell ya: if you're a programming language, it's a very good thing to have smart people liking you.

It doesn't make me smart, but I kinda like it too. Even though there's (still) a lot of hype these days about Java, and people tootling on about how Java's going to be the next big Web language... I just don't see it happening. There are too many smart people out there who like JavaScript.

So enjoy the interpreter. Ejacs is just a toy, but I think it also shows a kind of promise. Scripting Emacs using JavaScript (if anyone ever actually implements it) could be really interesting. It could open up the world's most powerful, advanced editing environment to millions of people. Neat.

In the meantime, it doesn't actually do squat except interpret EcmaScript in a little isolated console, so don't get your hopes up.

Reminder — here's the Ejacs URL: http://code.google.com/p/ejacs - enjoy!

And with that, I'm off to find some Nuka-Cola Quantum. I just wish those bastards hadn't capped me at level 20.

50 Comments:

Blogger Unknown said...

I have absolutely no idea what you're talking about but Ejacs is the best name for a software package that I've heard in a long time. Long ago they taught in marketing 101 that the ideal product name should contain a promise - and what better promise is there to make?

11:15 PM, November 16, 2008  
Anonymous Anonymous said...

You are a madman! Awesome. btw: js2-mode rules. Thanks,

David

11:21 PM, November 16, 2008  
Blogger Mitch said...

Seems like it would be easier to turn firefox into an editor.

11:35 PM, November 16, 2008  
Blogger Andrew Barry said...

Yay! Reverse psychology wins again!

And they said I would never amount to anything...

11:48 PM, November 16, 2008  
Blogger Samuel A. Falvo II said...

The name of the project sounds quite naughty; I'm not a fan of it, but it is undeniably catchy. It reminds me of an idea a friend once had: a graphical editor custom tailored to a problem he was trying to solve. He named it SPOOGE (Special-Purpose Object-Oriented Graphics Editor).

Needless to say, it didn't get very far.

11:51 PM, November 16, 2008  
Blogger Andrew Barry said...

I also got quite far writing a javascript interpreter in javascript a while ago (or at least a reasonable subset - eg leaving out stuff like the 'with' statement).

The parser/compiler converted JS source into byte codes, for which there was a separate VM written in JS.

And then I wrote the VM in java. And then in C++.

Then I saw some butterflies...

Actually, at this point I realized there was no real commercial driver for this stuff and let it lapse.

But it was also a really good way to understand some of the low level behavior of the language.

Unfortunately this involved getting a deep understanding of the == operator. And thus a desire to punch people.

12:01 AM, November 17, 2008  
Blogger an0 said...

Do you really mean it when saying "But it pretty much combines the elegance of Common Lisp
with the industrial strength of Scheme", or the opposite, i.e., "But it pretty much combines the elegance of Scheme with the industrial strength of Common Lisp
"?

Maybe I am just dumb, but I always think Scheme is THE more elegant Lisp.

12:05 AM, November 17, 2008  
Blogger Unknown said...

an0 said...
Do you really mean it when saying "But it pretty much combines the elegance of Common Lisp with the industrial strength of Scheme"


Yes, an0, he probably does mean it.
Scheme is elegant.
Common Lisp is industrial.
Emacs Lisp is not elegant, and not industrial.

12:42 AM, November 17, 2008  
Blogger Unknown said...

Looking at the list of problems I noticed that the crown jewel of object-orientation - that is: override-able methods - is not explicitly mentioned (It is just hinted at occasionally).

I think this no coincidence: Success of OO comes from other factors (e.g.: it helps in organizing the code, simplifies expressions, etc.).

I vaguely remember Steve saying something along these lines it in one of his earlier posts. I must admit I also believe in this (implicit) sentiment.

12:45 AM, November 17, 2008  
Anonymous Anonymous said...

@ano You don't get his drift.

1:12 AM, November 17, 2008  
Blogger Maciej Katafiasz said...

A little bird told me that Elisp *is* actually being worked on; apparently it's going to grow lexical scoping and coroutines in the foreseeable future. Can't remember if there were plans for packages now. And that is disregarding all the smaller and more trivial fixes it regularly gets.

So, while it doesn't make Elisp suck any less at the moment, it does take away the "JS at least is being worked on" argument. And JS has a fair share of stupid crap going about it too, starting with stupidly incoherent implementations (which improves over time, but still) and ending with it being a Lisp, except with syntax and consequently no macros.

1:32 AM, November 17, 2008  
Blogger Andy Wingo said...

Nice article.

I think there's another way out for Elisp, by the way -- compile it to a different target than the current Emacs runtime. I know it sounds silly in 2008, but Guile might be that runtime. It gives you modules and pthreads, standard SRFI libraries, and possibility for much more optimization (including native-code JIT).

Check the guile-devel archives for info.

2:02 AM, November 17, 2008  
Blogger Simon C. Ion said...

Verily.
I'm hoping that Bethesda will release modding tools soon. The -few- quest glitches and unkillable NPC's are annoying.

2:28 AM, November 17, 2008  
Blogger Mark Tucker said...

Thanks, Steve. I love interactive shells, they make me smile.

BTW, David Notkin has an immense beard. Puts my whiskers to shame!

2:57 AM, November 17, 2008  
Blogger dagbrown said...

Mark Tucker: I always enjoy seeing a reference to Why Microsoft can Blow-Off with C# here.

Almost as much as I loved the characterization of Common Lisp as "Howl's Moving Castle". I'm still laughing at that.

(Scheme isn't actually an exotic sports car. Connection Machine Lisp is the exotic sports car. As someone else I was talking to mentioned, it has a peaky, but powerful engine and a very notchy tranny that prevents you from actually using it.)

3:28 AM, November 17, 2008  
Blogger Seshagiri said...

Steve, could you please tell how long it took for you to implement the ECMA spec?

3:58 AM, November 17, 2008  
Blogger Craig Andera said...

I've been doing some Clojure hacking lately...and yes, you *will* like it. :)

Stu Halloway has a beta Clojure book you can pick up here:

http://www.pragprog.com/titles/shcloj/programming-clojure

5:47 AM, November 17, 2008  
Blogger zxzkz said...

Huh. I started this a while back too but don't seem to have nearly as much determination as you had.

I took an entirely different tack though. I wrote a bison grammar with elisp actions and then post-processed the bison parser into a table-based elisp parser.

I wanted to hook this into emacs-w3 to interpret javascript code on web pages so things like onclick="this.form.submit()" would work.

I had hoped if I got the interpreter basically working others would step in and implement the DOM and basic language objects. But, uh, that never happened.

Anyways, if you want to check out another attempt at the same thing look at:

http://freshmeat.net/projects/ebison/

6:31 AM, November 17, 2008  
Blogger Ronald Pottol said...

I want the reciprocal, emacs in javascript (or pehaps java) so I can run it in a web browser or an Andriod cell phone.

Then again, you can just install Debian on a jailbroken android phone, so the idea may be kinda irrelivant soon.

8:59 AM, November 17, 2008  
Blogger Rich Moore said...

I'm wondering if this javascript lisp implementation will run in it...

http://joeganley.com/code/jslisp.html

9:01 AM, November 17, 2008  
Blogger Ola Bini said...

Common Lisp == Howl's Moving Castle is TOTALLY spot on. Perfect. I assume you laughed for hours when you came up with that one.

9:28 AM, November 17, 2008  
Blogger jes5199 said...

What I really want is some sort of interface between Emacs and the JVM, so we do less porting and more linking

12:39 PM, November 17, 2008  
Blogger Kurt N. said...

You embedded Javascript into EMACS? Has nobody heard of Lua? :(

12:42 PM, November 17, 2008  
Blogger Phil said...

Mathrick is right: lexical scope has been implemented in Emacs (the lexbind branch) and is scheduled to be merged into the trunk after 23 is released, which is a few months away. Once that's in place, adding concurrency features is the next step, something that I don't think Javascript is currently targeting.

Also: elisp doesn't require an explicit "return", the requirement of which is full of fail.

4:57 PM, November 17, 2008  
Blogger Jebadiah Moore said...

I'm so happy to hear that are other people out there who like Javascript.

6:32 PM, November 17, 2008  
Blogger Steve T. said...

Emacs is basically one big program soup.

Funny thing is, so is a modern web page. HTML, CSS, JavaScript--toss into a pot and stir with a Greasemonkey script. Makes you wonder if these platforms succeed so brilliantly in spite of the tangle or because of it.

7:25 PM, November 17, 2008  
Blogger Ben said...

I imagine the post you hinted at writing was about Max/MSP. As a musician and a not-even-good-enough-to-call-myself-a-hobbyist programmer, I'd love to hear your take on it.

I broke my guitar thumbnail once bowling, and it hurt like hell.

9:55 PM, November 17, 2008  
Blogger Steve Yegge said...

an0: you missed the joke.

seshagiri: um, maybe 200 hours? It's just a guess. I didn't really pay very close attention.

mathrick: very cool! Language improvements == awesome. Closures == double awesome.

phil: concurrency, eh? Rhino has continuations _and_ threads, and I believe SpiderMonkey also supports at least one form of concurrency in the "trusted mode" you use for extensions and plugins. So yes, JavaScript has concurrency. Just not in a browser pages. Would be unbelievably awesome to see any kind of concurrency support in Emacs.

Brendan Eich says he's been thinking about concurrency and hygienic macros for a future version of JavaScript. I think they have to get over the hump of classes and optional type annotations first, though. Sounds like they're getting close.

Agree that requiring return is full of fail. JavaScript 1.8 addresses it partially with "function closures", which are single-expression lambdas that don't require the return keyword. Example:

var square = function(x) x * x;

In general, void statements and functions are a cosmically stupid idea.

12:46 AM, November 18, 2008  
Blogger Saj said...

You rock man!

By the way, I am still waiting for "A programmer's view of the Universe, part 2".

When it's coming up?

FYI: I know where you live!

9:40 AM, November 18, 2008  
Blogger glyph said...

I hpoe you won't mind some anti-JS venting, Steve. I respect your opinion but these pro-JS opinion pieces irritate me, given the amount of suffering that the JavaScript meme has caused me personally.

I certainly wouldn't defend emacs-lisp as any kind of bastion of good design, but it does contain several workarounds for the problems you're describing. Clearly, you've heard of cl-macs. Haven't you used lexical-let? You can have closures in emacs-lisp if you want them. Sure, the default behavior is terrible, but you can program in a style that works (i.e. has lexical closures and encapsulation) if you want.

This is exactly the same situation as JavaScript, as far as I'm concerned. Sure, JS has lexical scoping, but the default behavior of assignment is to set a global variable, I'm sorry, "property of the 'window' object".

Let's also not forget that elisp's library mechanism is cruddy ("require" needs no enumeration of its deficiencies) but at least it's somewhat workable. Let's compare it to JavaScript's ... oh right! JavaScript has no support for libraries because it isn't a programming language, it's a macro syntax for validating your FORM tags in Netscape 2.0.

In summary: elisp is a terrible language with the tools to make it a reasonable language. JavaScript is a prison planet from which there is no escape, if you want to write programs that run in the popular runtime, i.e. "the" browser (as if there were only one, or even only a dozen, that you needed to care about).

2:31 PM, November 18, 2008  
Blogger alnicodon said...

Dear Steve,

Thanks for your blog, a most enjoyable reading of mine nowadays.

Struggling in the Greap Elisp Swamp, I stumbled on symbol-function

Would that fit your bill for a useful debugging representation for functions in ELisp ?

Usage example:

(symbol-function 'foo)

=> (lambda nil (setq x 7))

Al.

3:02 PM, November 18, 2008  
Blogger Steve Yegge said...

symbol-function is fine if it's not byte-compiled. In JavaScript, the byte-compiler remembers a token stream for the function that permits the source code to be printed back. If the elisp byte-compiler did this it would be a big improvement.

Hashes still need a print representation, and defstructs are just a mess, what with the crashing.

It sounds like some of this stuff is gradually getting fixed, though, which is nice.

11:27 PM, November 18, 2008  
Blogger Unknown said...

Stevey: could you indulge yourself and share with us a few more car analogies?

Interesting about Scheme: makes me wonder why there's no standard Scheme Radio out there that most users just agree on installing right after you drive it off the lot.

Also, you're makin' me want to watch more anime. :)

Anyone care to explain the Howl's Castle reference? Not sure I get it. Thanks.

8:07 PM, November 20, 2008  
Blogger AnjanBacchuDev said...

Hi Steve,

thanks for your blog and this post.

every post wants me to improve myself and share more with the world. Thanks.

"Anyone care to explain the Howl's Castle reference? Not sure I get it. Thanks."
+1. I don't understand either :-(

BR,
~A

2:06 PM, November 21, 2008  
Blogger Gavin said...

The Howl's Moving Castle comparison is the iridescent glowing jewel of humor in this particular post, IMHO. It refers to the eponymous Miyazaki film in which a wizard of sorts roams the countryside in a gigantic castle capable of walking about on mechanical legs. The comparison is with Common Lisp's "don't leave anything out" design.

10:58 AM, November 22, 2008  
Blogger Unknown said...

Gavin, thanks. After googling around a bit and finding some images of the castle, I think I get it now.

7:59 PM, November 22, 2008  
Blogger Unknown said...

Steve said: "I would love to see Emacs Lisp get reader macros, closures, some namespace support, and the ability to install your own print functions. This reasonably small set of features would be a huge step in usability."

So, what would it take to do those things? At least some of the folks at the Emacs developers mailing list read your blog. Maybe you've started something.

6:34 PM, November 24, 2008  
Blogger Unknown said...

Most fantastic!

I thoroughly enjoyed reading this blog article. I find this blog best among all your blog essays i've read. (perhaps about 15 of them over the past year or 2)

I love emacs lisp! and i like javascript (not that much expert of it).

i enjoyed reading every word you gave about these languages.

Yeah, so much needs to be improved in emacs lisp. (and so obstinate are the emacs developers)

Lastly, thank you for Ejacs! I'm downloading it now, and sure will be having fun with it. I think the name is catchy too.

-----------------------

among your elisp criticism, i whole heartedly agree about the no namespace problem.

... (i thought i'd go over your criticism now and list my impressions on them)...

in your section “Problem #3: No delegation”. I don't quite understand what is meant, or the word delegation in the context of programing. I'll be doing some web searching readup on this now... if you do happen to edit this, perhaps in preparation for print publication down the road ... more detail or concret example would be great.

In your “Problem #4: Properties” section... i sorta understand what you mean but concrete example would be great. I don't know what splay-tree is. I'll be reading up.

On your “Problem #5: No polymorphic toString” section... i see what you are saying. For my own elisp experience, i didn't find this a problem. On the other hand, i thougth this problem is much severe in compiled langs, such as Java, C.

(Note: my elisp coding, and life time code production in general, is perhaps just 10% of your output. (if i recall correctly, i'm few years older than you though... or was it the same?...))

in my own elisp experience, i think elisp problem in order most severe to less severe, are:

• no namespace.

• lack of threads. e.g. typically you wait for emacs to finish something before it'll unfreeze.

• regex toothpick syndrom. Its regex should have its own string syntax, not embedded as string. I do a lot text processing. Even simple regex become unreadible in emacs.

• Lack of named parameters.

• lack of lexical scoping. I did not thought this is a practical problem, but now reading your article, the fact that emacs lack a namespace, i changed my mind. :D Yeah, i guess lexical scoping is critical when you write large programs.

... in your essay you mentioned elisp's lack of reader macro, and also highly praised elisp macro. In my own programing experience (mostly geometry visualization and web app backend), i never find any utility of lisp macro, and thought it is pretty much overrated by zealous lispers or lisper wannabe who came from procedural lang background just because it's something they've never seen.

Note that, lisp macro can be considered as crude beginning of term rewriting system/langs. In lisp communities, you see them get dizzy with macros all day, but in Mathematica, just about every line of code is macro a la lisp, because the lang is so-called a term rewriting system, with extensive pattern matching facilities.

... it would be great if you can give some concrete examples of how you used elisp macro. (i'll be checking it out in ejacs)

some other common criticism of elisp is lack of tail recursion, lack of continuation. I am not absolutely sure (don't fully understand the latter), but i tend to think these having little practical benefits.

Again, great article and thanks for ejacs.

Xah
∑ http://xahlee.org/

4:50 PM, November 25, 2008  
Blogger Tim Cooijmans said...

I've been working on a homoiconic JavaScript syntax for madmen like you. Basically all you get now is hairy syntax, but that gets you macros for free. Not real macros though. And it doesn't have lambdas. But I'm still sorting that out. It would've been easier if JavaScript had symbols, but I think I'll be able to hack around it somehow.

Details at http://timcooijmans.wordpress.com/2008/11/26/if-you-wanna-taste-some-madness-unq/

4:14 PM, November 30, 2008  
Blogger John Zabroski said...

Have you looked at JaM? You CAN have macros in JavaScript. http://blog.n01se.net/?p=8

6:21 PM, December 02, 2008  
Blogger JMS said...

This comment has been removed by the author.

7:13 PM, December 03, 2008  
Blogger JMS said...

Stevey I can't read your blog while I'm working it takes too much time. While a great read I feel kinda guilty since I'm not really working. Would you consider odiogo.com or perhaps getting Donald Sutherland to read it for us? One these guys would do I guess... http://www.collegehumor.com/video:1633395

7:19 PM, December 03, 2008  
Blogger Unknown said...

Don't know what style of music you're playing but couldn't you have played your guitar with a pick? Or super-glued a pick onto your thumbnail or used this: http://www.alaskapik.com/?

Just wondering.

2:45 PM, December 04, 2008  
Blogger leoboiko said...

concurrency in emacs is more important than it sounds. the scope of emacs network applications has been severely limited because emacs is a cooperative multitasking OS — if wanderlust or w3 hang waiting for a server response, the whole OS hangs with them (thus w3m-el — it's not that C is faster, but that you can call external apps in the background, but not internal apps!)

once emacs is true multitasking I expect lots of new applications to bloom.

9:12 PM, December 09, 2008  
Blogger bollywood girls said...

i like your blog ....

4:04 AM, January 13, 2009  
Blogger Arthur Wolf said...

PLEAAASE DO IT !

emacs in js would be SOOO MUCH FUCKING GREAT !

Pleaaaaase !

12:53 PM, January 20, 2009  
Blogger Alex Ott said...

Had you looked to Semantic package (from CEDET) that make process of parsing writing much easier?

4:12 AM, March 26, 2009  
Blogger Larry Felton Johnson said...

Awesome. I found this blog entry on a search for "writing javascript interpreter". I'm a perl programmer (who also uses emacs, mostly for editing xml). I've been pulling together tools for webscraping and the one glaring thing lacking in the perl toolkit is a means of dealing with javascript in a more or less complete manner. WWW::Mechanize is awesome, but javascript can confuse it.

5:46 AM, February 23, 2010  
Blogger Ildar Shaimordanov said...

Hi all,

Under Windows I use for myself the script described in this article http://with-love-from-siberia.blogspot.com/2010/03/windows-scripting-command-interpreter.html. Unfortunately this article was written in Russian but Google.Translate can help to read it.

It completly was written in JScript, allows to run both JScript and VBScript scripts. It is flexible and configurable, allows to code easily the main script, allows to have the set of libraries that supported by WSH and will be linked with the resulting WSH file.

There are three mode of execution -- 1) run of an external script; 2) run of inline code (like Perl perl -e 'command'); 3) run in the console mode (like other JS-interpreters Rhino or Narwhal).

In the most cases it covers all my needs although it has some shortcomings -- there is little bug in the parsing of RegExps in the console mode.

5:17 AM, December 28, 2010  
Anonymous Anonymous said...

I have absolutely no idea what you're talking about but Ejacs is the best name for a software package that I've heard in a long time. Long ago they taught in marketing 101 that the ideal product name should contain a promise - and what better promise is there to make?
http://www.hedefnakliyat.com

9:03 AM, June 30, 2011  

Post a Comment

<< Home