TC39, ECMAScript, and the Future of JavaScript
ponyfoo.com
ponyfoo.com
I also believe that we do ask these questions about apps. Sometimes less is more.
Note: I feel most proposals today are sane.
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/0433...
There is definitely a balance, but any language ignores this question at its peril.
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.
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.
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.
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-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.
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.
I'm not saying knowing one more function is cheap. And I agree Ruby has interesting constructs, but I think plus one function/method is a lot cheaper than to mentally parse all those inheritance/monkey-patching rules.
The same goes for `new` in JavaScript. It does something, but it uses functions, and don't forget .prototype (and so on), and that was hard to grok, so now we have classes too, but that's not just syntactic sugar. But JS is/was a pretty bad language at the start, so something must "had to be done".
And that's why it's important to consider new features, language complexity and so on while considering the particular language's warts. Just adding classes because classes are cool is foolish, but adding classes to bring some sanity to JS is fine.
Of course, there's also subjective priorities. But even ASM has too many opcodes, but at least the syntax is dead simple, but you lack cross-platform-ness, so there's C, which seems simple and low level, but it comes with a tome of undefined behavior and requires hand-rolling everything, hence higher level languages, that are hard to get right. And computer languages evolved a lot, as computing and programming itself did, a-a-and the big old languages C++/Java (and JS too) tried to handle this change, and that's how we got here. (Think of the Java Modules [JSR-376] process, how it was an uphill battle from the first minute, how it is at the same time too simple to replace OSGi [for example, because it lacks lifecycle management - which was never a stated goal, but sshhh], but too much to introduce without breaking changes [which is actually not true, because "automatic modules" sort of deals with legacy JAR files, but sssh again], and it has almost nothing to do with the language itself, it's just an ecosystem thing. But people are afraid of change, usually understandably. Compared to that TC39 is pretty nice.)
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
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)
They're extremely common in the front end world - all the fancy SPA frameworks and build systems promote & use them extensively.
If you're talking about Node.js or JScript or something else, then that's different.
It annoyed me at the time but I do respect the decision to resist adding every single feature under the sun.
I can't remember being bitten lately, maybe I have a blind spot.
These kind of things don't happen without such a person or group who will arbitrarily make decisions. The same reason why better languages like Dart don't get adopted.
There are too many client vendors and devices for this to work. And even with the new features in ES2015, almost everyone actually using them is still using Babel to support older browsers.
Does it means both Typescript and AngularJS implement/use an experimental feature that is still under discussion as of now, in production? this is a bit risky.
So much so that this exists: https://github.com/loganfsmyth/babel-plugin-transform-decora...
https://www.npmjs.com/package/deep-value https://www.npmjs.com/package/deep-reduce
Are you implying that Ruby is a backward language ? :/
and babel plugin is coming here https://github.com/babel/babel/pull/5813
@autobind
foo() {
// ...
}
foo = () => {
// ...
}
?@computed get value() { return this.a + 1; } @readonly bar = 5;
There's a reason all the most common languages have them, concealing complexity is a way to reduce cognitive overload and therefore, bugs.
Like... I'm sure one day I'll see something and it'll just click, but not there yet.
I like the idea but I’ve yet to see a case that leads to better Code than other implementations.
Great...?
I really hope there's a better use case for them because this is not selling me. Literally none of that post is a compelling case.
I get the cleaner syntax, that's nice, but it also means now I have to look up what that does. And that decorated properties example? Yikes that's awful - it looks like a code-smell frankly.
But all that initial urrrgh factor could be removed by showing me a use case that makes the code significantly more elegant to do `@foo bar` rather than `foo(bar)`.
@required firstName;
We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.
If we were talking about very basic things then yes, sure, but I’d also argue that if they are truly basic then we could restrict decorators to built-in ones only (as those are the basics).
Much like there are “magic” Symbols like Symbol.iterator.
Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go).
There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.
Like, I get they can be used for stuff but why are they a better option?
So far - based on the responses here - it appears to be syntax for syntax sake and no practical benefit.
Terse at the usage point yes, but it swaps clarity for brevity. A sometimes useful trade off to be sure but... not sure I’ve seen any demonstration of benefits here.
I am surprised that no more mentions of NPM were made. I hope that commitee TC39 addresses the topic of NPM and tries to create a new version that is standarized and that elliminates the serious flaws of NPM, which for me are one of the major hindrances to adopting Node.js for things that go beyond prototyping.
Package managers are completely detached from language specifications so that they can evolve independently.
Googling on lockfiles i found out more about the features of the Yarn package manager. Perhaps that's what I should use.
However what i meant with my comment is that I feel that package managers should be standarized into a language -- as long as the package registry is not private but can be pointed to whatever URL one wants.
https://github.com/tc39/proposal-bigint/blob/master/README.m...