It's worth noting that proposals can move down as well. For example, I think there was lots of work done on atomics before it was ultimately scrapped. Heck, the global proposal doesn't look like it has moved in months due to a few web compatibility issues.
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.
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.
I think the combination of introducing new features in a non-overlapping way with the ones they replace, and the use of linters to prevent you from using the old ones, is a pretty good way to improve the language without being affected by backwards compatibility.
They should do something like Python. Python 3 is loads better than Python 2. It removes legacy cruft at all levels cleaning it up completely. It even made Python 2.7 a backwards compatible language in which you can write code that with minimal modifications can be just moved to a Python 3 version. (Using modules like future)
Except upgrading to Python 3 on your application server is pretty trivial to do.
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.
No BDFL or authority to tell detractors to screw off. Breaking backward compatibility is kinda a big thing in the web because most of the web is still running legacy stuff.
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.
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
> 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
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"
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.
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.
> 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.
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.
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.
Understandability should be the No1 feature of code. Basically interacting with code should be as smooth as possible. Spending cognitive effort to parse all those != -1 and unless select() takes its toll.
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 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).
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)
That's what Dart was supposed to be, in Google's eyes. The problem is both that it needs buy-in from all browser vendors (and the webdev community), and more importantly, that you'll now need to support both Javascript and the new language indefinitely. Especially considering that new mistakes will be made with the new language, and new quirks introduced, that doesn't sound that attractive.
You are completely correct. I was considering that to be like ocaml, kotlin, scala, etc which transpile to JS. For what it's worth, I think either ocaml or SML is far better than dart for compiling to JS, but dart is far better than typescript (and has a more sound type system). It's not a huge wonder that Google apparently uses angular-dart instead of the typescript version.
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.
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.
To be fair, though, you must explicitly opt in to using decorators in TypeScript via --experimentalDecorators, and the documentation for said switch states: "Decorators are an experimental feature that may change in future releases."
When marshaling classes in and out of xml/json decarators can be added to properties to change the name of the equivalent Json field value as well as indicating if it's optional or not. Orms use decators to map object to relational tables the may have different field names, expressing key values, etc
It’s not really less code though. It’s about the same but with an syntax that obfuscates where the logic happens.
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.
Well, in C#-land, we often use / abuse attributes to get information about a class or property at runtime. This way, framework or library code can inspect entities that you've authored, and dynamically deal with them. Perhaps a decent example is validation, where a declarative style has gained a lot of popularity. A JS example might be:
@required firstName;
This simply declares the intent / rule, but does not provide the implementation.
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.
Hmmm a required flag is a nice idea (but better exposed using interfaces as an idiom I’d argue) but it’s not selling me on the wider use case.
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.
That's interesting. My knowledge of JS is a bit lacking, so I'm struggling to see the equivalence of the interfaces approach. E.g., is it possible to parametrize interfaces with actual values, such as @maxLength(20)? Also, how do you apply interfaces down to the field-level, where they are of primitive types, such as number or string?
I guess it depends what style you favour. I can't imagine using getters/setters like that in JS today, and not have major pains from it (things like not being able to use data binding frameworks easily, etc).
In angular2 they are for example used for dependency injection, which works really well.
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.
That... doesn't help. From what I see there I get harder to follow, non-idiomatic to anything in JS, code but the bonus is a terser syntax?
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)`.
The use of decorators in Anguar 2/4 is also very well done, IMHO. They allow your class to focus on its business logic, rather than the minute details of how Angular expects it to interact with the rest of Angular.
There's a reason all the most common languages have them, concealing complexity is a way to reduce cognitive overload and therefore, bugs.
Hardly a fair comparison. Decorators exist in Python and other languages primarily because they either don't have lambdas or have bad ones. JS doesn't suffer from those problems, so the mental overhead of the additional syntax has a much lower payoff (and one that I believe isn't worth the trouble).
> TC39 is currently working on over 30 active proposals. What else does the future hold in store? These days we download our packages from npm.
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.
Out of curiosity, have you seen the latest changes to npm? Since they've added lockfiles I've yet to have any issues with dependency management, really.
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.
I would argue that the future of JS looks bleak when you effectively can't have any meaningful discussions about proposals if you are not in the committee (the author just ignored the issue for half a year, then closed and locked it): https://github.com/tc39/proposal-dynamic-import/issues/35
