ES6 section terrible?

#1

I’m just done…

Its not even fun to even try to learn ES6 the way FCC presents, here is their approach:

  1. Take something simple and over complicate it
  2. Have short descriptions of the challenge and what they are trying to teach you.
  3. Have all but one condition pass so you are going back and adding unnecessary things.

I am currently on Use Destructuring Assignment to Assign Variables from Objects and the whole point of the challenge is to use objects & deconstructing just to return the length of a single string input.

Yeah i might be thinking of this wrong, but if you are talking about objects at least have me work with one in the problem instead of unnecessarily creating one and being confused on what to do with it. All for the length of a single string input.

Their is other examples of this too.

In Set Default Parameters for Your Functions you may think this is a correct answer:

const sum = (...args) => {
return args.length > 0 ? args.reduce((num, i) => num+=i) : 0
// num is accumulator, i is the number.
}
console.log(sum(2,3,4));

But no that is incorrect and doesn’t pass even though it does what the challenge is asking, because it has to be more complicated then that:

const sum = (function () {
    return function sum(...args) {
      return args.length > 0 ? args.reduce((num, i) => num+=i) : 0
     }
})();

See where i am going here with things being taught terribly?

3 Likes
#2

I liked the ES6 section. That’s where I learned the new syntax and features when I changed to a new job that actually uses it.

#3

With regards to your first question, I agree that it is a bit odd. There is a discussion about it here - you are welcome to contribute to the discussion or even better yet, contribute to the solution. This is a volunteer organization.

With regards to the next one, it seems a little unnecessary to wrap it in an IIFE, but if you understand default params, this is pretty straight forward. The original is:

const increment = (function() {
  "use strict";
  return function increment(number, value) {
    return number + value;
  };
})();
console.log(increment(5, 2)); // returns 7
console.log(increment(5)); // returns NaN

(I’m not sure what code you’re referring to.) This can be passed by adding two characters.

But again, if you feel this is a bad lesson, please see the github and create and issue. And then, if you have the time, help find a solution. This is a volunteer organization.

1 Like
#4

It looks like you are working on the next problem. The original code:

const sum = (function() {
  "use strict";
  return function sum(x, y, z) {
    const args = [ x, y, z ];
    return args.reduce((a, b) => a + b, 0);
  };
})();
console.log(sum(1, 2, 3)); // 6

Why are you trying to rewrite the entire function from scratch? The code gave you and IIFE and I would expect to work with that. All you need to do is change one line and remove another. Specifically, where the parameters are passed in, use a spread operator to turn then into an array and then you don’t need the next line.

Is that clear or do you need more explanation?

#5

I rewrite it because i do it the way i see as most simple, because a good coder does that. Giving me a IIFE without explaining it and making me use over complicated techniques is not going to work. If i can do it in a simple one line, i will unless it gets too long as i learned from that other topic.

Format doesn’t matter as long as its readable. It all has the same output, so both should be passed.

It says closed on the Git you linked me, so is it still okay to even respond to it?

I’ll open a issue tomorrow if anything.

#6

I agree. They don’t fully explain the concepts to you or there are hidden testing criteria so you’re stuck doing trial and error stuff until you give up and go search on the forums for a full explanation.

I can see how that can help a person remember concepts better, though. I noticed in previous sections I tend to remember a certain concept when trying to solve a problem but I forget the syntax. Sometimes a concept doesn’t occur to me at all even though it’s what’ll help me find the best solution. But with these ES6 lessons, I find that I’m having an easier time remembering and implementing knowledge from certain previous lessons because those lessons are the ones which made me go on the forums and spend extra time learning about them.

I still think there shouldn’t be hidden testing criteria, though. List ALL of them please. I literally went crazy on a lesson which required the use of the map method even though it didn’t tell me so.

#7

I rewrite it because i do it the way i see as most simple, …

I’ve never understood this attitude that some people have. The point of learning is that you don’t know. If people already know all the ways to do things and can make a decision about what the best way is, then why do they need to learn?

I would suggest just to relax, sit down, and follow the program. You were asked to make an adjustment to the code, not rewrite it. If you did that on an interview, I think they would be very worried about working with you, that you can’t follow simple instructions. Getting along in the work place isn’t about “doing things the way I think is best and screw whatever anyone else things.” I’ve worked with guys like that. It’s not fun.

Giving me a IIFE without explaining it and making me use over complicated techniques is not going to work.

That is a valid point - IIFEs are explained later. That would be a good point to bring up on the github, that this might be best done without an IIFE since it wasn’t explained yet and might confuse people that have never done it before. I still think following the instructions would lean to the right answer, but this does seem like an unnecessary comprehension speedbump.

Format doesn’t matter as long as its readable. It all has the same output, so both should be passed.

No. Using an IIFE is more than just a format choice. There are functional differences and cases where an IIFE is needed. I strongly disagree that those two solutions are interchangeable. In some cases they are, but in others not. Generating the same output is not the only standard by which you judge code.

It says closed on the Git you linked me, so is it still okay to even respond to it?

I didn’t look closely. Read what it says. See the logic.

This is a team effort. Part of being on a team is compromise and learning to work well with others, even when you don’t get your way. This is an important soft skill for the workplace. But make your case if you feel it is important.

3 Likes
#8

Why change something that is not already broken for something that is not as good? I used rest operators to complete the problem, and suddenly format is the issue, really? You really think your boss is going to pay your coworkers $40 a hour to go back and change the format of your already working, simple and readable code for the same output? No, because that is called the real world. Where time is money, and if something works don’t screw it up.

I would think this would also impress them, as you found a simpler way to get the job done which saves space and time which ties into the money they have to pay you to get a task done.

If you are working with a client, they really don’t care either as long as it works, you can maintain it, and its simple. If they are paying you by the hour, they would be happiest if you used the best, simplest, and most creative way possible to get it done quicker.

This goes both ways, and considering my code is the simpler version of there code i bet they would be happy to use it and read it as you can just leave comments. If someone else wrote code in another format, i would read their comments or take the time and go back and see whats its doing. If it is better then mine, ill use there format and way of doing things.

As long as i can read it, its somewhat simple, and gets the job done i can care less. Not my problem, i do my job people do theirs.

#9

Why change something that is not already broken for something that is not as good?

Again, you are assuming that you have enough knowledge to make that determination.

I used rest operators to complete the problem, and suddenly format is the issue, really?

Again, IIFEs are not a formatting issue. If you think the only difference between an IIFE and a standard function is formatting, then you are confused.

No, because that is called the real world. Where time is money, and if something works don’t screw it up. … if you are working with a client, they really don’t care either as long as it works, you can maintain it, and its simple. If they are paying you by the hour, they would be happiest if you used the best, simplest, and most creative way possible to get it done quicker.

You are assume what it means if it “works” - again there are situations where a non-IIFE will not “work”. And “simple” is a nice goal, but not always the best. As my engineering professor used to say, “For every problem, there is a simple, elegant solution - that is incorrect.” Obviously simplicity where possible is a good thing, but it can also be a siren luring you onto the rocks.

If someone else wrote code in another format, …

Again, not a formatting issue. It’s an “understanding the difference between a standard function and an IIFE and being able to follow simple instructions without making things so complicated” issue. Again, your boss may have very specific reasons for things to be done a certain way. It’s not his job to explain and justify himself to you.

As long as i can read it, its somewhat simple, and gets the job done i can care less. Not my problem, i do my job people do theirs.

The vast majority of dev jobs are working as a team. I would not want to work on a team with someone that intransigently insists that his way is the best way, even before he’s learned the basic principles involved. If you are this pushy while you are learning, I am terrified of where you might end up once you actually know what you are talking about.

These debates always leave me gobsmacked. I have students with similar attitudes. They argue and argue about every little point. They are trying to make judgements about things they don’t yet understand. They demand to know why. Unfortunately, explaining why requires other knowledge they don’t have, and if they just shut up and did what I said in the first place they would learn so much faster - they would come to understand in situ instead of having to bring their education to a screeching halt while they try to swim in waters too deep for them. I hate those students, not because I hate explaining these deeper subjects (I love teaching that stuff) but because I know that they won’t truly understand and will waste too much time trying and/or will not learn the correct way because they are too busy arguing. They never develop as players.

This is about to get flamey, so I’ll leave it there. I’ll ignore this thread, if you have any further comments, you can PM me.

#10