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.
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:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
Sadly, I can't really run python in the browser.
You really can think javascript and write coffeescript.
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.
Server-side, sure, use the latest build you can get.
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.
[0] http://fabiensanglard.net/rayTracing_back_of_business_card/
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.
Certainly an option; keeping the syntax recognisable helped rather than hindered adoption, which was slow enough as it was at the beginning.
JS+DOM could have lost to Flash rather than vice versa.
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".
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?
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.
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.
// 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)};
}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.
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.
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.