A bunch of comments just showed up, June 21, 2008.
Like it or not (and FWIW, I like it quite a bit), JSON has made an impression on networked information exchange. Douglas Crockford, who started the whole JSON thing, has a chapter in Beautiful Code on Pratt-style parsing. His example parser is written in, and happens to parse, something he calls "simplified javascript".
Simplified JavaScript is just the good stuff, including:Implementing some of the currently popular "scripting" languages, in particular "full" Javascript, Python, and Ruby will make evident the amount of cruft they have for no apparent reason. Lisp traditionally has had some cruft, but, arguably, nothing like what can be found in these languages. Such cruft makes these languages significantly more difficult to implement than implementing Lisp or Smalltalk (two amazingly "cruft-reduced" languages given their age).
- Functions as first class objects. Functions in Simplified JavaScript are lambdas with lexical scoping.
- Dynamic objects with prototypal inheritance. Objects are class-free. We can add a new member to any object by ordinary assignment. An object can inherit members from another object.
- Object literals and array literals. This is a very convenient notation for creating new objects and arrays. JavaScript literals were the inspiration for the JSON data interchange format.
Simplified Javascript would make a decent base for a scripting language. I pointed this out to a couple people looking at full Javascript over the last couple of months for an Erlang-based server and now for Croquet.
People already in the more or less "end user scripting" space tend to have some Javascript knowledge. This subset has good functional and OO capabilities, comes with a simple parser implementation already(!), and from implementing a bit of interpretation code already, seems amenable to a simple elisp/emacs-level of performance, which is more than sufficient for an interactive GUI system. Compiling to a native or byte code would not be too difficult for better performance.
Simplified javascript not only eliminates the uglier and more difficult to implement bits. It also eliminates a lot of bad security problems.
And so on designing a new scripting capability, combining Simplified Javascript with a capability-based approach to authority as with the E programming language could have some benefits. And JSON for "data"... go ahead and use "eval" to implement the JSON parser in such an environment.
Well, that would be a heck of a lot better than the current browser/javascript situation which is horrendous. Now we've got a truly undesirable "legacy" situation(s) in the browser. Apparently Mark Miller or one of those E/Capability folks is at Google now and their looking at something like the browser those folks built for DARPA. (Found in this powerpoint if you don't mind opening those up in OpenOffice.)
12 comments:
What cruft exactly do you mean?
Because Ruby as a language is multi-paradigm and complex, but you can omit () which you never can in lisp.
The two have a completely different philosophy and I rather prefer writing domain-specific languages in pure Ruby rather than learn Lisp where I will end up doing
'(defun foo-bar-bla((something-else)()'
Other than that, one huge disadvantage of Javascript is that it is only a www language. Inside the browser.
With ruby (or python respectively) one does not have that limitation. Instead of javascript becoming more ubiquitous i'd rather use ruby. And I dont mind if only 5% of my target audience will have ruby available - I dont want to write javascript (i do it anyway, but i dont WANT to ...)
I've often felt that when you'd get if you simplify Javascript is basically Lua.The language feels very much like "Javascript except done right". (plus a few additional features, but they seem largely well thought out)
So, a lot like Lua then :)
www.lua.org
I believe simplified javascript has a name already: Lua. Lua is very syntactically close to javascript, with only the bare essentials in its library.
If you want to pursue a capability-based language, the first thing that would have to go would be the ability to "add a new member to any object by ordinary assignment". If you don't have encapsulation, you can't have any sort of security.
I think if a simplified JavaScript is used it would make sense to be using a strictly proper subset of ECMAScript standard (which allows for certain extensions.) Otherwise it is just adding another language to the already huge pile of languages out there.
If extensions not compatible with ECMAScript are added then a threshold has been crossed and it would probably be better to just go all the way for the good stuff and use Scheme.
"If you want to pursue a capability-based language, the first thing that would have to go would be the ability to "add a new member to any object by ordinary assignment". If you don't have encapsulation, you can't have any sort of security."
That's not so. If I can create an object that has any kind of mutation, I might as well be able to create an object that can add or remove slots.
For this to be "capability-based" I should be able easily to control whether or not I hand *you* the capability to add or remove slots. Capability-based languages can do *anything*.
My code can do anything to your objects as long as my code has the capabilities to do so. You are in control of distributing to me the capabilities you have been granted.
-start quote-
"If you want to pursue a capability-based language, the first thing that would have to go would be the ability to "add a new member to any object by ordinary assignment". If you don't have encapsulation, you can't have any sort of security."
That's not so. If I can create an object that has any kind of mutation, I might as well be able to create an object that can add or remove slots.
-end quote-
You can have both ways ;-)
How? An assignment to a (new) member of a object done by code external to the object would just invoke an setter with the name of the member and the new value as parameters (same with getters).
An assignment to a member from code inside the object would just just add or change the value of that member.
Cheers
-Zarutian
(And to prevent confusion with POSIX capabilities the community around erights.org, cap-talk, etc use the name object-capabilities over unforgible references that combine designation and authorization.)
Great post -- Many comments mention Lua and I think this is true to a point. The thing that is missing however in Lua is first class functions. There really is no comparison here! JavaScript is truly remarkable.
See also:
http://www.reddit.com/r/programming/info/6ocbw/
"The thing that is missing however in Lua is first class functions."
Um, no. Lua not only has first class functions but is in fact a lot more supportive of a functional style of programming than Javascript is (e.g. it does tail call optimisation).
Okay, I don't think you guys read about Simplified JavaScript at all... It is not like Lua! It is, in fact, just a subset of JavaScript!
Post a Comment