JavaScript is a good language. Why does it only catch up with other languages?
Now it looks like it only works so: we may add this only if it already exists in other languages.
Why can't it be vanguard? It looks like because TC39 is inactive/slow.
With a committee, making right decisions is easier.
Why can't JavaScript be innovative?
I'd counter this with Why can't we be innovative using JavaScript? You can build anything with it. Maybe it would be more productive if you can list what exactly about the JavaScript language is limiting for you?
No, I don't mean this. I mean adding something cool that doesn't exist in other languages. So other languages can take this and implement after.
Now it goes only and only in the opposite way - JavaScript copies what already exists.
Impossible things are probably only about regex. If to talk about new non-regex features, they are either functions for basic things, or syntax sugar. So "you can build anything with existing features" is off-topic. Building anything was probably possible even 20 years ago.
JS is the only language that has true private state for class instances.
It is nice. But unique things are very few if it is not the only one.
Now existing proposals are like always something from other languages, probably because champions understand that no chances for something new (like f(, , 4)).
I actually view this as a good thing. If other languages add something then later regret their decision, they can always deprecate it. (Which is a messy process, but it is an option). If JavaScript adds a new feature, they're required to keep that feature around for time and all eternity.
Because of this, the committee needs to be very careful when adding new functionality to the language. And, as is often said, the first implementation of something is usually not the best - you need to wait until the second or third implementation for issues to be ironed out. So letting other languages add features before you do is a pretty safe way to ensure that it will be implemented well, and that the feature isn't just some short-term hyped idea.
That being said, I don't feel like JavaScript is all that different from other mature languages. Most mature languages are just borrowing ideas from each other without doing too much novel stuff. I mean, what had Python been adding in the past few decade? A match construct, similar to what you find in functional languages. A type system - that's nothing new (though their specific way of doing it is a bit novel). And so on. What about Java? They've got lambdas now - sort-of. Has Rust added any novel features after it was initially created? Not that I'm aware of.
The languages that tend to do the most novel things are new languages, that can be built from the ground up to support that novel idea throughout the language, such as Rust being built front the ground up with a borrow checker.
This doesn't mean that everything has to be un-novel. As mentioned, the way Python implemented their type system was pretty novel. Many JavaScript proposals in the pipeline are bringing in features from other languages, but are adding novel ideas to it to make it better fit with the JavaScript ecosystem, or because they think they've found a better way to approach the problem. What comes to mind is the resource cleanup proposal - lots of languages have some form of resource allocation and cleanup syntax, but I've never seen it done the way they just did it in JavaScript, where the new resources can be placed in an existing scope, instead of requiring you to create a new inner scope for each resource - that's a novel idea that simplifies a number of otherwise tricky problems and reduces nesting.
3 Likes
You probably mean compiled languages.
Changes in Python and Java may break programs as it goes with sites. But Python is far ahead of JavaScript (especially working with arrays). It looks vanguard compared with JavaScript. So it would be cool to be on the same level as Python, even not being innovative.
Moreover, old Java programs often don't work on newer Java versions. So it seems to be ok for them. Here we have that a method can be renamed/rejected because of one broken site (how it was with "flatten"). At least 1 site may be fixed by people which pay for its domain/server. Users will help if they are not programmers.
You probably mean compiled languages.
~I don't understand why compiled languages are any different in this regard~ (edit: nevermind, I see a difference. But both compiled and non compiled languages still often make breaking changes, JavaScript does not). For example, Python has removed and changed tons of features in it's lifetime, especially when they transitioned from version 2 to 3. They also provided a 2to3 code transformation script that attempted to automatically convert your code off of deprecated features. JavaScript can't do the same thing, it's why we have a strict mode, instead of simply having those features be removed. It's why typeof still has the bug where null is considered an object - because that behavior can't be changed. Etc.
But Python is far ahead of JavaScript (especially working with arrays)
Are we discussing the quantity of features or how innovative the features are? Those are two separate discussions. One is about throughput of features and the other is about the riskiness of features.
Java programs often don't work on newer Java versions
Right, and that's the point. They can make breaking changes and JavaScript won't. That's a philosophy that JavaScript has always taken, and I feel like people have grown to expect it now. If I put up a website, forget about it, then try to view it in 20 years, I fully expect that webpage to still work fine - maybe with some slight deviations in how it looks. On the other hand, if I try to run or compile a 20 year old, non-javascript program in the most current version of its language, it probably won't work - I can expect that.
1 Like
Interesting about Python.
The thing is changes don't affect compiled programs. So they will not break unlike scripts.
I understand that JavaSript can't do such things. Moreover, I don't understand how they could allow themselves this. But adjusting to 1 site is too much.
On one side, no changes is good. For example, I like declarations without var/let/const because they can be inside expressions.
I think that the committee has enough smart members to make such decisions to not regret after. It is not several persons. It is 60-80. I meant this in the first post.
Also being vanguard (the first post). It also means being one from the best in abilities, what implies not to evoke a feeling that some other languages are much better. I have such a feeling after learning about some Python abilities (I can't list all of them).
I had to install 2 Java versions and switch them (with moving files). It is terrible.
Regret is inescapable :).
Just recently, an array.at() method was released. If you give it undefined, or null, or NaN as a parameter, it will coerce it into a valid value, in this case, 0, and then index the array with 0. This coercion behavior is consistent with all of the other JavaScript methods, and so was preserved here, probably without too much thought.
Having these values coerce to 0, how every, is quite the foot gun, and not that long after the proposal went live, they started rethinking their general philosophy on coercion, citing .at()'s behavior as one of the many bad examples that exist in the language, and soon came to a decision, as a committee, to break this consistency moving forwards.
They came out with a new feature, then regretted a certain aspect of that feature soon after, but it was too late to change it.
It's all tricky stuff, even for a large group of smart people.
1 Like
Then unshakable principles are needed. Like to convert to 0 or not and why.
I think no converting is quite normal. And null/undefined/NaN will indicate that something was wrong, especially NaN.
On other side, it would be really useful if undefined could be converted to 0 in mathematical operations.
Also, a road map is needed. It is about adding the most important things collectively (not just several champions). Like it probably was with ES6.
New info.
Some features are not potentially regrettable. It is those which don't require decisions (no controversial things).
So JavaScript may add such features to be innovative.
Huh? Anything that's really innovative will be controversial. You'll find a number of non-controversial normative changes in the github spec repo, they are done all the time without requiring big decisions, but you'll probably never have noticed them because they are not worth mentioning.
And for new features one cannot know ahead of time whether one will regret them later!
I mean only controversial decisions how it should work (like to convert to 0 or not).
For example, f(, , 4). It isn't about difficult decisions. I can't provide more innovative things, but many useful features from other languages don't require controversial decisions. So it concerns them too.
Are there other languages that have a similar function call syntax? If so it could be interesting to look at how often it's used.
Famous languages don't have this. So this idea may be considered innovative. But it is not potentially regrettable. Again, nobody would talk about this if it didn't work at destructuring.
I got info that it is available in some languages: SAS, R, Julia, Octave.