A 30 line javascript spreadsheet is similar for me to when I first saw Norvig's 21 line python spelling corrector (http://norvig.com/spell-correct.html): this language is more powerful and expressive than I thought.
I'm increasingly believing that HTML/CSS/JS in a browser is a viable common runtime. This demo does quite a lot to solidify that belief.
The only things that are powerful and expressive in JavaScript are bastardized beyond recognition versions of ideas from Lisp, Smalltalk and Self. You get those dynamic mechanisms that we know for 50 years now (lambda expressions and runtime method dispatch, oh wow) to be useful but without learning any lessons learned in those 50 years about how to design a coherent language based on those concepts, you just get a hodgepodge of language constructs that don't add up together to form a useful toolkit. It might look nice in a 30 line program where you don't care about performance, code readability (and boy does this code look ugly) and bugs and maintenance costs.
Ruby or Smalltalk have an object system for doing those kinds of things that was actually designed and not evolved by committees and corporations, so that your meta-programming doesn't have to always be only eval and .bind in various incarnations (unsafe, inconvenient and slow). I can't imagine how this thing here that makes evaluating "A1" perform a function call fits into the rest of JavaScript and why the hall was it even introduced:
Not to mention the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope. In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains.
I congratulate the author of this code as much as everyone for finding an unexpected and very creative use for those features, but this doesn't make them great.
At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly.
> your meta-programming doesn't have to always be only eval and .bind in various incarnations
I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS.
> unsafe, inconvenient and slow
Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting.
> the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope
"with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with.
> In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains.
The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option.
> this doesn't make them great.
No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.
> "with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design
Unfortunately not. The design of with not only makes the code difficult to reason about for humans, it also makes the code difficult to reason about for js engines, and so it typically prevents any interesting optimisations. So code written using "with" will be both confusing and slow.
I agree, saying "Wow, this is a viable and useful language" because you can do something in just a few highly unreadable lines seems... like a pretty odd judgment.
It'd be a bit like saying that C is a great language because someone wrote a raytracer that fits on a business card[0] using it.
All valid points. With the norvig example, the longer I look at it the more I like python. With this js example, the more I look at it the more I like python.
Consider coffeescript. It does a good job at removing nuisance quirks from Javascript, and adding some python-esque features (sensible looping constructs, list comprehensions, etc.), while maintaining logical equivalence with the javascript it compiles to. (It also mirrors some of the syntactic features of ruby that make that language so appropriate for producing DSLs, which is a feature or a bug depending on your perspective)
You really can think javascript and write coffeescript.
Consider ES6 too. It also does a good job at removing some Javascript quirks and adds sensible looping constructs, list comprehensions, generators and generator comprehensions, proxies, rest/spread arguments (removing the need for the magical `arguments` identifier), classes (just sugar for what we already wire up with prototypical inheritance), modules, fat arrow functions etc.
No help on the DSL front though - still stuck with various kinds of brackets and parens.
On the other hand, it doesn't do the utterly horrible mistake of conflating variable declaration and variable assignment while forbidding shadowing, resulting with surprise bugs and spooky action at a distance.
I like the way ES6 is going, but Coffeescript has the advantage of maintaining compatibility with old (like, old-old) browsers. I hate having to do it, but you can't just ignore them.
Server-side, sure, use the latest build you can get.
Thanks! If you're looking for ways to ease the burden of compiling it yourself, my favorite tools are django-pipeline (for django) and middleman (for static sites). Both of these let you treat coffeescript files as first-class while you develop.
Imagine if management had not vetoed non "Java-like" syntax's during javascripts creation. Maybe Brendan Eich could have gotten a decent scheme dialect into the browser instead, people could have learned it (because in hypothetical retrospect, what else were they going to do? Not learn it?), and we would be in a far more pleasant position today...
If being "like java" was so important, then why didn't it just straight up lose to "actually java"?
I don't think that JS+DOM beating flash/java has much to do at all with "gee, this looks superficially like java, but is different enough to trip me up in rather weird ways".
Don't conflate why Flash lost to why Java (in the browser) lost, there are very different reasons. For one thing, Java had failed as a browser plugin long before Flash did (as if we don't still see Flash in the browser...I wonder what our discussion would be if not for Apple?).
That was likely the fear at the time, but what we actually saw was Javascript became popular because it was useful and there wasn't really anything else like it. It became popular, so Microsoft threw in with it too.
In order for that to have not happened, it would have had to be so unpopular that Microsoft would decide it wasn't worth adopting, but still popular enough to get Microsoft on board with the general idea. I just don't think that is likely; people would have sucked up a scheme-based javascript even if it was a tad unfamiliar; it was that useful.
(Not to mention, going with the cynical "three E's" theory of 90s Microsoft, they would have at least first adopted it before perverting it.)
I think people overplay the importance of being C-like. AutoLISP hit a bit earlier and found a very strong following in a non-programmer niche. People doing web development were already fucking around in HTML of course, so clearly they could wrap their heads around things over than curly braces.
microsoft had visual basic in the browser, working like php works. that was microsoft's vision, which would have been the web if netscape didn't still have significant market share. IE had to implement javascript to be compatible with pages written for netscape.
simple as that. just microsoft's famous "embrace, extend, extinguish" strategy at work.
Microsoft's famous "embrace/extend/extinguish" is why they would have followed Netscape in implementing even a scheme-like javascript. They wouldn't have skipped the first two E's just because it was scheme-like instead of java-ish.
So....I wonder...what's your idea of what should be a proper language to have in the browser?
Note: This isn't criticism of your view nor am I taking sides. I am wondering --since you have a strong opinion on this front-- what you think the solution might look like.
I mean, are you looking at the idea of having something like python natively available at the browser?
I recently found myself needing to use "with", and hating myself for it. Does anyone know a better way to do this in JavaScript?
// Take an array of context dictionaries, and return a
// function that evaluates a string in those contexts.
// I fully realize how horrible this code is, and that
// it only supports up to ten contexts. I feel terrible
// about it, as I should, but I would feel even worse
// if it were impossible to do this. But isn't there
// a simpler way to do this is JavaScript? Maybe I
// could use __proto__ inheritence, but I was hoping
// to avoid.
function evalInContextsFunction(_contexts) {
var _contextCount = _contexts.length;
if (_contextCount == 0) {
return function evalInContexts(_text) {return eval(_text)};
}
with (_contexts[0] || {}) {
if (_contextCount == 1) {
return function evalInContexts(_text) {return eval(_text)};
}
with (_contexts[1] || {}) {
if (_contextCount == 2) {
return function evalInContexts(_text) {return eval(_text)};
}
What breaks my heart when someone claims that JavaScript was inspired by Self, is how Self was all about the wonders of multiple inheritance and dynamically mutable parent slots. JavaScript totally missed the boat on that one, with only one prototype slot, and the only time you can set it is when you create the object with "new".
I've felt that way for 16+ years.. of course, 2/3 of that time most developers never took the time to understand/learn JS the language, and then separate that from the horrible browser DOMs in the late 90's. NN's Layers vs IE document.all ... Starting with IE5/6 (and later Phoenix/Firebird/Firefox) it actually got a lot better.
It's definitely nothing like IE4/NN4 days, and it looks like IE8 is finally falling off the radar, with IE9 to follow in the next couple years. It's only getting better. IE8 was really the last relatively bad browser imho. IE9 has some quirks, and IE10/11 are actually pretty nice (though IE11 is the most buggy browser MS has released since IE6, possibly more so).
Yes, there are still browser compatibility issues.. but they are so few and far between for day to day use. Except for WebRTC and WebAudio, things are really solid.
> it looks like IE8 is finally falling off the radar
Some are luckier than others... I suspect one of our major clients (one of the country's largest banks) will be stuck using IE8 and nothing but for the next few years at least. They only moved off IE6 recently due to it falling out of support next April, so there is a chance they'll stick with IE8 until 2019 (the year before it and Windows 7 drop out of extended support).
At least our other major clients (smaller financial institutions) have started to see sense. While they are stuck on IE8 due to some ancient internal code that won't work on anything more correct that are at least rolling out Chrome on their standard desktops as an alternate choice for everything that doesn't rely on old IE bugs.
Seconding this - some of us designing web applications / intranet apps for banks or government have to support IE8 for the foreseeable future. We're just now starting to drop IE6 support for the new versions of our products.
When I was a contractor at a major bank, the standard was IE6, and movement towards IE8 was in progress (as Win7 was rolling out)... I don't know if they held at IE8 though, as most people I knew there have left, even the FTEs. It was an SPA that drove a lot of adoption/allowance to use Chrome/Firefox, so it may have well gone that direction since leaving.
The move from IE6 to IE8 has (pretty much universally in the investment banking industry in the UK) only been over the last year or so.
They are still pretty much all on XP, but new laptops are generally Windows 7 (with IE8) and I suspect Win7 will be rolling out to older standard builds (both desktop and laptop, machines old enough to not be Win7 compatible having been replaced already) as the first thing the relevant TS departments do after the Christmas/NewYear non-emergency-work freezes.
That spell checker is intended to demonstrate a technique but it is far from 21 lines of real code. It you look at the included modules (re and collections) you'll find THOUSANDS of lines of code.
As always "I did x in n lines of <insert language>" often are really interesting learning tools but real production code isn't (or should not) ever look like these examples. No criticism of Norvig's code, it's interesting and I, too, learned something very interesting the first time I saw it.
I'm increasingly believing that HTML/CSS/JS in a browser is a viable common runtime. This demo does quite a lot to solidify that belief.