I appreciate you taking the time to reply, but I guess it will just take time to see whether it’s my biased that’s making me hate spread and destructuring or these are actually confusing. Right now, I’m not convinced that wasting a few bytes of typing and data using universally accepted code is worse than using a bunch of seemingly random dots and other symbols. It kind of takes me back to my CS days when there were always a couple of people in the class who would go out of their way to make their code as hard to read as possible to flex their internal knowledge of the language.
Even the nested loops are taught at the very first programming class any computer science student takes so to me that makes more sense. You can bring a C#, VB, C++, Java, or other programmer and even if they are not experts in Javascript, they can immediately recognize what’s happening but it’s not the case with ES6 notations.
I am watching a Frontend Masters workshop (on lynda.com) with Kyle Simpson and he seems to focus more on readability of the code than just using the new tools because they’re there.
Yeah i got the answer but it doesn’t help my understanding of how the destructing assignment was used. The examples i understood but not the actual question
Firstly, these constructs already exist in many commonly-taught and used languages. Take rest parameters: Java has varargs, C# has Parameters, C++ has variadic and so on. Python, which is extremely common on CS courses, has *args and *kwargs (and has destructuring). Python also has only one idiomatic way to do any one thing (the Pythonic way), and both of those constructs are part of that - it isn’t some weird special syntax, it’s how you should write Python.
Second is that pattern matching (of which destructuring is a basic form of) is a key feature of all functional languages and has found its way in as a basic feature of most practical modern languages (Kotlin has it, Swift has it, Rust has it, Elixir has it). C# >= v7 and C++ >= v14 have it as well. Java doesn’t have it, but Java lags significantly behind in several areas so that’s not unexpected. You need destructuring in JS to implement pattern matching in a sane way.
Third is that these things aren’t there as novelty extras, just to make the programmer look clever. They are there as an attempt to cause errors as soon as possible. JavaScript is extremely weird in that it attempts to return a value for everything, and this tends to make it difficult to write reliable code (runtime errors are very common). This isn’t massively important if you’re in your first CS class and are just learning to do loops, but it’s pretty damn important when you’re actually writing software. I want a balance where I write as little code as possible, that code is as safe as possible, and that code is as readable as it can be within those constraints. I could write everything imperatively and defensively, but that’s error-prone because I have to write a large amount of imperative, defensive code. If I instead use pattern matching, if the patterns do not match, the code should just naturally blow up at the point where the pattern failed.
Fourth: if I can construct objects or arrays using literals, why can I not deconstruct objects or array using literals? Why should the simple way to do things only go one way?
I agree - I am coming at this with very little prior coding knowledge and am finding it very hard to follow the challenges. Most of the ES6 course seems to require an understanding of other principles not taught in the curriculum to solve the tasks. Although there’s value in that because it makes you really scrutinise what the question is asking you to do, whether you’ve already learned that, or whether you need to do some extra research, I find it quite demotivating because I’m always a bit too lost at sea!