Hacker News Reader

> (and boy does this code look ugly)

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.

[0] http://fabiensanglard.net/rayTracing_back_of_business_card/

This code is fairly readable. It takes one or two shortcuts, but it's much closer to real code than to golf.

its called "Abstraction"

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.

Sadly, I can't really run python in the browser.

Kinda: http://www.brython.info/index.html

Yeah, I'm aware of this and emscripten. So far, to me, they don't look viable for DOM manipulation.

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.

You make a convincing argument.

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.

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.

There is traceur (https://github.com/google/traceur-compiler) and it can provide most of the features - except proxies.

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...

They would have learned whatever Java/C-derived scripting language that Microsoft came up with instead.

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.

that is a weird and complicated take.

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.

No, but perhaps there would not have been any pages written for netscape for IE to be compatible with.

Not learn it?

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.

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?).

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)};
                }

[...and so on...]

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".