4 ms·

I'm somewhat of two minds about this. On the one hand, I think he has a point that said features of JS.next are cutting against the grain of present-day JS. Th

by lmkg 15y ago

I'm somewhat of two minds about this. On the one hand, I think he has a point that said features of JS.next are cutting against the grain of present-day JS. There are quite a lot of people programming in JS, many of whom may or may not deserve to be called good programmers but who nonetheless can produce functioning web pages, that would have to switch to a very different coding model to work with JS using these new features. On the other hand, it's difficult to program your code when you know than any of your invariants can be accidentally stomped on by any other code that happens to run on the same page. It's also difficult to write libraries when everything's guts are exposed, even with red tape. Raymond Chen over at MSFT has an entire blog that could be titled "How Implementation Details Become De Facto Interfaces Due to Insufficient Encapsulation." I think my final thought on the matter, is that when you think about it, it's really quite silly that we only have one language for front-end web development. It is, in fact, unacceptably silly. Like, seriously guys, what the hell? This is totally crazy. If you want to do server work, or non-web client applications, or embedded, or whatever else, you have a full array of programming languages. These run the gamut from ball-gag-and-leather-straitjacket static languages to walk-into-anyone's-house-and-drink-their-milk dynamic languages, from concise expressive languages to low-level bit-fiddly-ones, from parens to curly braces to significant whitespace to perl. On the web we have JavaScript. Not that it's a bad language, it has its warts (what doesn't?) but it's actually a cute little language. But I don't have the option of using a language with static guarantees. Or deterministic memory management. Or asynchrony. Or macros. None of these are strictly better, they're all just personal preferences, but the point is, you don't have the choice. That lack of choice is probably what's driving these against-the-grain additions to JS.next. They're adding more features to JavaScript so that it can cover some of the bases that it currently doesn't, and all the different directions it's being pulled in are understandably causing some stress. I think it's the wrong solution, but it's also the one with the easiest transition path. The ideal solution, is that we could use different languages from different paradigms, but how the hell do you crowbar them into existing browsers? So uh... do I have conclusion? I dunno, language evolution is hard, let's go shopping.

kaffiene 15y ago
Nice post. I think the proper solution is to agree on some set of byte code that browsers will support and allow any language to compile (or be interpreted) to output those byte codes. Otherwise you will, as you say, end up with the situation that Javascript becomes a huge mass of compromises that ultimately suits no-one.
Rusky 15y ago
If Google adds a Dart VM to Chrome, they'll at least have crowbarred some different language into the browser. A completely useless language that won't change anything substantial on its own, but still. Maybe it will lead to some important developments.
davedx 15y ago
Being able to declare member variables as private (really private, not the private alluded to in Ruby) is good. As the OP said, you don't have to declare a member variable as private if you want relaxed 0constraints. But when you want to for good design reasons -- it's great that the language you are working with allows you to do so.
- repsilat 15y ago
  If you really need private member variables you can probably whip something up with lambdas, though it might be a little awkward.
  - reissbaker 15y ago
    It's super easy: function A { var secret = 0; // <---------- private variable this.method = function() { alert(secret); }; this.increment = function() { secret++; }; } a = new A(); a.increment(); a.method(); <-------- prints 1 The main problem is just the inefficiency of declaring methods inside constructors. Edit: Hence, the keyword.
aufreak3 15y ago
It doesn't need to be "either move in the direction of total dynamism or move in the direction of static guarantees". At the very extreme end of total dynamism, you get facility to implement whatever kinds of guarantees you want as libraries. Sad that in a language without meta programming features, the power is indeed reduced, but nevertheless extreme dynamism can be powerful enough to implement the guarantees that you need. For example, if JS gets a facility to "run this code when an unknown method of this object gets called" and "-ditto- when an unknown field gets set or read", you can implement a public API for an object using a proxy object. You'll also be able to enforce member naming conventions if you want to. If you're doing the wrapper only for checking, you can keep the wrapper during development and leave it out when you deploy the code. You get a lot of flexibility. Furthermore, if JS lets you install hooks like python decorators, you can implement guarantee mechanisms in JS as a library similar to what decorators get used for. Again, if it gets you better performance, you can strip decorators from deployed code during the minification phase. So indeed, why not shoot for extreme dynamism in JS?

by lmkg 15y ago

kaffiene 15y ago

Nice post. I think the proper solution is to agree on some set of byte code that browsers will support and allow any language to compile (or be interpreted) to output those byte codes. Otherwise you will, as you say, end up with the situation that Javascript becomes a huge mass of compromises that ultimately suits no-one.

Rusky 15y ago

If Google adds a Dart VM to Chrome, they'll at least have crowbarred some different language into the browser. A completely useless language that won't change anything substantial on its own, but still. Maybe it will lead to some important developments.

davedx 15y ago

Being able to declare member variables as private (really private, not the private alluded to in Ruby) is good. As the OP said, you don't have to declare a member variable as private if you want relaxed 0constraints. But when you want to for good design reasons -- it's great that the language you are working with allows you to do so.

repsilat 15y ago
If you really need private member variables you can probably whip something up with lambdas, though it might be a little awkward.
- reissbaker 15y ago
  It's super easy: function A { var secret = 0; // <---------- private variable this.method = function() { alert(secret); }; this.increment = function() { secret++; }; } a = new A(); a.increment(); a.method(); <-------- prints 1 The main problem is just the inefficiency of declaring methods inside constructors. Edit: Hence, the keyword.

aufreak3 15y ago

It doesn't need to be "either move in the direction of total dynamism or move in the direction of static guarantees". At the very extreme end of total dynamism, you get facility to implement whatever kinds of guarantees you want as libraries. Sad that in a language without meta programming features, the power is indeed reduced, but nevertheless extreme dynamism can be powerful enough to implement the guarantees that you need. For example, if JS gets a facility to "run this code when an unknown method of this object gets called" and "-ditto- when an unknown field gets set or read", you can implement a public API for an object using a proxy object. You'll also be able to enforce member naming conventions if you want to. If you're doing the wrapper only for checking, you can keep the wrapper during development and leave it out when you deploy the code. You get a lot of flexibility. Furthermore, if JS lets you install hooks like python decorators, you can implement guarantee mechanisms in JS as a library similar to what decorators get used for. Again, if it gets you better performance, you can strip decorators from deployed code during the minification phase. So indeed, why not shoot for extreme dynamism in JS?