3 ms·

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.
  - marcus_holmes 9y ago
    OK, so let's take the case of the proposed "includes" feature. This is syntactical sugar. Replacing indexOf(x)=-1 with includes(x) does nothing else than make the code easier to read, allegedly. The new function provides a shorter way of expressing a single case that indexOf already covers. There are no new capabilities introduced to the language here. So it's a straight-up coin-toss between "easier to read" and "having to be aware of one more method". I tend to come down on the "no thanks" side of this coin-toss. Ruby suffers from this, imho. My favourite example is select/reject on arrays. They do exactly the same thing, with the logic on the block reversed. Having to know that there's a reject method (and when to use it) is more mental effort than reading the block logic the other way around, in my opinion.

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.
- marcus_holmes 9y ago
  OK, so let's take the case of the proposed "includes" feature. This is syntactical sugar. Replacing indexOf(x)=-1 with includes(x) does nothing else than make the code easier to read, allegedly. The new function provides a shorter way of expressing a single case that indexOf already covers. There are no new capabilities introduced to the language here. So it's a straight-up coin-toss between "easier to read" and "having to be aware of one more method". I tend to come down on the "no thanks" side of this coin-toss. Ruby suffers from this, imho. My favourite example is select/reject on arrays. They do exactly the same thing, with the logic on the block reversed. Having to know that there's a reject method (and when to use it) is more mental effort than reading the block logic the other way around, in my opinion.