6 ms·

When will js have enough features? Maybe not there yet, but is there an endgame?

by arve0 9y ago

bevacqua 9y ago
We don't ask ourselves that of websites or apps, why would we ask it of programming languages?
- arve0 9y ago
  Because languages that have few but powerful concepts are easy to use. I also believe that we do ask these questions about apps. Sometimes less is more. Note: I feel most proposals today are sane.
- magicalist 9y ago
  > We don't ask ourselves that of websites or apps To be fair, yes we do. Most websites and apps have an additional advantage of not necessarily caring about backwards compatibility over decades and can cut out features that don't work out or are obsolete, something that may never be possible with JavaScript. And, just like languages, apps that do become lumbering beasts are often abandoned for rewrites or new apps with similar functionality but streamlined of all that historical baggage. > why would we ask it of programming languages? TC39 member Mark S Miller answered this question well in "The Tragedy of the Common Lisp, or, Why Large Languages Explode" https://mail.mozilla.org/pipermail/es-discuss/2015-June/043307.html https://mail.mozilla.org/pipermail/es-discuss/2015-June/0433... There is definitely a balance, but any language ignores this question at its peril.
- marcus_holmes 9y ago
  More is not better. I always like the old saying "it's not done until you can't remove any more". Adding features doesn't make a thing better, it just makes it more complicated.
  - pas 9y ago
    But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach. And if you don't work in that subfield, you don't have to know that part of the language. (Just as if you don't do compiler development you don't need to know Assembly mnemonics, and you don't have to know how many cycles a a particular microcode takes, and so on. You just use perf if you want to, and see that duh, it's too much, let's use -O3... or ask an expert. Or look into it yourself.) But when you encounter something new in a language, you can learn about it. If it's there because it made something elegant, great. If not, refactor it. Make it simpler. But this is the same Deletionist approach that is plaguing Wikipedia, just now with the tragedy of commons language, JS.
    - camgunz 9y ago
      > But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach. You can choose for your code, sure, but you can't choose for everyone else's code. This is brought up whenever C++ complexity threads start. Sure you can choose to not use template metaprogramming or whatever, but some library will use it, and then pow you're using it too.
      - pas 9y ago
        You don't have to use that library. And as I've mentioned, that library started to use it for a reason. If you use a library that just starts using expensive features (like templates in C++), just because they think they're cool, then I regret to inform you, that you already depend on a bunch of script kiddies. This is the same thing as we always discuss with functional programming and all those extremely complicated category-theory heavy con-fuck-structs. They make sense in a setting for some problems. ( https://stackoverflow.com/questions/5057136/real-world-applications-of-zygohistomorphic-prepromorphisms https://stackoverflow.com/questions/5057136/real-world-appli... ) But it's very much like a special weapon that is large, and heavy, and only those can handle it that are blessed by the priests of The Temple of Homotopy Type Theory, or whatever, and so on. So mere mortals should not touch it. And in a proper library, those beasts are locked up well, encapsulated. It's the language's (or the lib's) shortcoming if you can't interface with the library, can't apply parameters to the library without knowing the hairy internals.
krapp 9y ago
Obviously, Javascript needs to be complex enough to bootstrap the Singularity.
- int_19h 9y ago
  If that's how it goes, we needn't worry. It'll be an endless chain of AIs, each spending all its time designing a new and better language to write the next AI in. As we know full well by now, the process is so fascinating in and of itself, there's little else that they will have time for.
  - paulddraper 9y ago
    The end of world, postponed indefinitely by webpack.
    - dtzur 9y ago
      I can see that happening.
andreineculau 9y ago
Based on Crockford, when tail recursion optimization lands, meaning soon. It's getting ridiculous now, with a super blurry line between language features and built-in utils
- saghm 9y ago
  > It's getting ridiculous now, with a super blurry line between language features and built-in utils I think part of the problem is that there isn't really a standard library for JS, just a bunch of global variables that are automatically there when your program starts
copperx 9y ago
I don't understand why doesn't an ECMAScript2 exist at this point, instead of just trying to patch JavaScript. The whole reason JScript and others ultimately failed were because they were not standardized. How hard is it for browser vendors to say "we'll implement ECMAScript2, whatever it is" so that we can all have a sane language to work with (while we wait for WebAssembly).
- dangoor 9y ago
  To some extent there is, in that the javascript VMs can treat certain sorts of scopes (like Modules) differently because they know that those did not exist at an earlier time when certain bad behaviors were common. They debated quite a bit while working on ES6 about having a different script type to make more breaking changes, but they decided that this would be bad for evolution on the web (see the adoption of Python 3, for example)
  - paulddraper 9y ago
    To expand: use strict is always in force in ES6.
    - gsnedders 9y ago
      In ES6 modules, it is. In other code, ES6 is backwards compatible with ES5 (i.e., code is strict mode iff there's a "strict mode" declaration).
      - paulddraper 9y ago
        Oops. Left off that key word :) Yes, ES6 modules.
    - nailer 9y ago
      That's not correct: a small percentage of the JS community (maybe <1%) use TC39 modules (which enforce strict mode) vs just using npm.
mappu 9y ago
I remember being quite surprised to see the Property Accessors RFC for PHP get declined, largely on the basis of making the language more complicated. It annoyed me at the time but I do respect the decision to resist adding every single feature under the sun.
- deleted 9y ago
  [deleted]
mbell 9y ago
The language doesn't need too much more. Don't get me wrong, it's still not a great language but within the confines of what it is and backward compatibility, it doesn't need much more. The 'standard library' and browser apis though, have a long way to go.
- pitay 9y ago
  The need for backwards compatibility is what is keeping JavaScript still not a great language. The number of wtfs and surprising behaviour is justified by needing to conform to what the language already did, and that is not a good thing.
  - arve0 9y ago
    Which wtfs bite you the most? I can't remember being bitten lately, maybe I have a blind spot.
    - true_religion 9y ago
      In a lot of the places where NaN is generated, I would prefer it if an error was thrown.
      - bryanrasmussen 9y ago
        I think all JS NaNs are quiet NaNs when sometimes signaling NaNs should be supported/be preferable https://en.wikipedia.org/wiki/NaN#Signaling_NaN https://en.wikipedia.org/wiki/NaN#Signaling_NaN
    - gear54rus 9y ago
      forEach returns undefined. Why would you not just return the same array for easy chaining?
      - brad0 9y ago
        Probably to make a distinction between map() which returns a new array. If forEach returned the same array I believe you'd would see a lot more bugs.

When will js have enough features? Maybe not there yet, but is there an endgame?

by arve0 9y ago

When will js have enough features? Maybe not there yet, but is there an endgame?

bevacqua 9y ago

We don't ask ourselves that of websites or apps, why would we ask it of programming languages?

arve0 9y ago
Because languages that have few but powerful concepts are easy to use. I also believe that we do ask these questions about apps. Sometimes less is more. Note: I feel most proposals today are sane.
magicalist 9y ago
> We don't ask ourselves that of websites or apps To be fair, yes we do. Most websites and apps have an additional advantage of not necessarily caring about backwards compatibility over decades and can cut out features that don't work out or are obsolete, something that may never be possible with JavaScript. And, just like languages, apps that do become lumbering beasts are often abandoned for rewrites or new apps with similar functionality but streamlined of all that historical baggage. > why would we ask it of programming languages? TC39 member Mark S Miller answered this question well in "The Tragedy of the Common Lisp, or, Why Large Languages Explode" https://mail.mozilla.org/pipermail/es-discuss/2015-June/043307.html https://mail.mozilla.org/pipermail/es-discuss/2015-June/0433... There is definitely a balance, but any language ignores this question at its peril.
marcus_holmes 9y ago
More is not better. I always like the old saying "it's not done until you can't remove any more". Adding features doesn't make a thing better, it just makes it more complicated.
- pas 9y ago
  But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach. And if you don't work in that subfield, you don't have to know that part of the language. (Just as if you don't do compiler development you don't need to know Assembly mnemonics, and you don't have to know how many cycles a a particular microcode takes, and so on. You just use perf if you want to, and see that duh, it's too much, let's use -O3... or ask an expert. Or look into it yourself.) But when you encounter something new in a language, you can learn about it. If it's there because it made something elegant, great. If not, refactor it. Make it simpler. But this is the same Deletionist approach that is plaguing Wikipedia, just now with the tragedy of commons language, JS.
  - camgunz 9y ago
    > But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach. You can choose for your code, sure, but you can't choose for everyone else's code. This is brought up whenever C++ complexity threads start. Sure you can choose to not use template metaprogramming or whatever, but some library will use it, and then pow you're using it too.
    - pas 9y ago
      You don't have to use that library. And as I've mentioned, that library started to use it for a reason. If you use a library that just starts using expensive features (like templates in C++), just because they think they're cool, then I regret to inform you, that you already depend on a bunch of script kiddies. This is the same thing as we always discuss with functional programming and all those extremely complicated category-theory heavy con-fuck-structs. They make sense in a setting for some problems. ( https://stackoverflow.com/questions/5057136/real-world-applications-of-zygohistomorphic-prepromorphisms https://stackoverflow.com/questions/5057136/real-world-appli... ) But it's very much like a special weapon that is large, and heavy, and only those can handle it that are blessed by the priests of The Temple of Homotopy Type Theory, or whatever, and so on. So mere mortals should not touch it. And in a proper library, those beasts are locked up well, encapsulated. It's the language's (or the lib's) shortcoming if you can't interface with the library, can't apply parameters to the library without knowing the hairy internals.

krapp 9y ago

Obviously, Javascript needs to be complex enough to bootstrap the Singularity.

int_19h 9y ago
If that's how it goes, we needn't worry. It'll be an endless chain of AIs, each spending all its time designing a new and better language to write the next AI in. As we know full well by now, the process is so fascinating in and of itself, there's little else that they will have time for.
- paulddraper 9y ago
  The end of world, postponed indefinitely by webpack.
  - dtzur 9y ago
    I can see that happening.

andreineculau 9y ago

Based on Crockford, when tail recursion optimization lands, meaning soon. It's getting ridiculous now, with a super blurry line between language features and built-in utils

saghm 9y ago
> It's getting ridiculous now, with a super blurry line between language features and built-in utils I think part of the problem is that there isn't really a standard library for JS, just a bunch of global variables that are automatically there when your program starts

copperx 9y ago

I don't understand why doesn't an ECMAScript2 exist at this point, instead of just trying to patch JavaScript. The whole reason JScript and others ultimately failed were because they were not standardized. How hard is it for browser vendors to say "we'll implement ECMAScript2, whatever it is" so that we can all have a sane language to work with (while we wait for WebAssembly).

dangoor 9y ago
To some extent there is, in that the javascript VMs can treat certain sorts of scopes (like Modules) differently because they know that those did not exist at an earlier time when certain bad behaviors were common. They debated quite a bit while working on ES6 about having a different script type to make more breaking changes, but they decided that this would be bad for evolution on the web (see the adoption of Python 3, for example)
- paulddraper 9y ago
  To expand: use strict is always in force in ES6.
  - gsnedders 9y ago
    In ES6 modules, it is. In other code, ES6 is backwards compatible with ES5 (i.e., code is strict mode iff there's a "strict mode" declaration).
    - paulddraper 9y ago
      Oops. Left off that key word :) Yes, ES6 modules.
  - nailer 9y ago
    That's not correct: a small percentage of the JS community (maybe <1%) use TC39 modules (which enforce strict mode) vs just using npm.

mappu 9y ago

I remember being quite surprised to see the Property Accessors RFC for PHP get declined, largely on the basis of making the language more complicated. It annoyed me at the time but I do respect the decision to resist adding every single feature under the sun.

deleted 9y ago
[deleted]

mbell 9y ago

The language doesn't need too much more. Don't get me wrong, it's still not a great language but within the confines of what it is and backward compatibility, it doesn't need much more. The 'standard library' and browser apis though, have a long way to go.

pitay 9y ago
The need for backwards compatibility is what is keeping JavaScript still not a great language. The number of wtfs and surprising behaviour is justified by needing to conform to what the language already did, and that is not a good thing.
- arve0 9y ago
  Which wtfs bite you the most? I can't remember being bitten lately, maybe I have a blind spot.
  - true_religion 9y ago
    In a lot of the places where NaN is generated, I would prefer it if an error was thrown.
    - bryanrasmussen 9y ago
      I think all JS NaNs are quiet NaNs when sometimes signaling NaNs should be supported/be preferable https://en.wikipedia.org/wiki/NaN#Signaling_NaN https://en.wikipedia.org/wiki/NaN#Signaling_NaN
  - gear54rus 9y ago
    forEach returns undefined. Why would you not just return the same array for easy chaining?
    - brad0 9y ago
      Probably to make a distinction between map() which returns a new array. If forEach returned the same array I believe you'd would see a lot more bugs.