4 ms·
I think that, in not only languages but anything related to code (frameworks, packages, etc.), there is a tendency for things to overshoot because that is likel
by rossdavidh 8y ago
I think that, in not only languages but anything related to code (frameworks, packages, etc.), there is a tendency for things to overshoot because that is likely to make those who know the most, more powerful (they know how to use all the features), and its negative impact is on new learners, i.e. those who have little or no voice in these decisions (for obvious and often good reasons). Thus, it becomes a form of pulling up the ladder after you. Not that this phenomenon is in any way limited to coding, of course.
- dccoolgai 8y agoAs a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.
- Groxx 8y agoJS especially has been a rocket-ship of new language features lately. It used to be my go-to language for new people since it was so simple (when used with a few boundaries (like every language needs)) that it could be picked up and the basics understood fairly quickly, and you can set people free to look at other people's code, and gradually learn DOM APIs and whatnot as needed. Not any more. Not even close. The amount of stuff you have to deal with immediately is far larger now. I actually miss the days when people added this kind of stuff to their transpiler of choice (e.g. coffeescript) and just used that - it doesn't need to be in the language, because it can never be removed from the language. Let fads appear and die outside that barrier, not inside.
- dccoolgai 8y agoCase in point the "how to deal with asynchronous stuff" problem. Callback pyramids weren't great, but the pastiche of approaches that followed (promises, generators, async functions, etc.) Is starting to feel worse.
- chubot 8y agoYes, I think you could know "all of" of JavaScript in 2009, in the ES5 era. Does anyone even remember that anymore? I'm shocked at how much the language has changed. I was experimenting with server-side JS in 2009, before node.js was released, and I hacked on Brendan Eich's Narcissus interpreter, which gave me a good sense of the language. Now when I look at example JavaScript code on the web, I invariably find something foreign. I'm not saying it's bad -- just foreign for somebody who uses the language only occasionally. I don't believe JS should be a language only for "full-time JS programmers". I use 3 or 4 other languages regularly, so it's not nice when one language wants to hog my mental bandwidth (unfortunately C++ is one of those languages, so I know this problem well). It seems like everybody forgot what Crockford was saying back then? He talked a lot about the failed ES4 project (which ironically Graydon Hoare was a part of (?)). And ES5 was very restrained as a result, and I think mostly successful. It seemed this idea of restraint went completely out the door soon afterward, and nobody even remembers what was discussed 9 years ago. Crockford seems to have moved on (as well as Ryan Dahl). I haven't followed the JS language changes that closely, so I could be wrong, but I have the impression that it's completely changed. ----- I don't think I'm alone, as I remember that Bryan Cantrill recently said that "Brendan Eich never wrote a book about JS". In other words, the language was left without a founding philosophy. It's been an accretion of convenient features, some of which may be regretted in a couple years' time. There was a Strange Loop talk about this too regarding the lack of history/culture in JS. It seems like the same thing may have happened with Rust, since Graydon isn't an active contributor by his own admission.
- dccoolgai 8y agoYeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time. I was reserving my thoughts about ES6 until I worked with it for a while, but now that I have, I have to say for those reasons you cited I don't like it as much as ES5.
- 8y ago