Feedback - Learn Functional Programming by Building a Spreadsheet

These are unsolicited opinions covering several steps with the intent of offering suggestions for improvement. If I am wrong on anything, just let me know. If there is a more appropriate place for this like on Github, let me know that as well.

I am doing lesson feedback for a few reasons:

  1. A want to do what I can to contribute to improving learning resources for future learners.

If I get stuck on something or get confused, others probably will too. These things can be proactively improved.

  1. A need to add some purpose to reviewing some very basic things for myself. Doing lesson reviews and course auditing gives that extra purpose.

  2. A thought that this is an important part of my learning as well because if something comes up that I am inaccurate on, someone could correct me and improve my understanding.

I wish I had done this all through, especially going through beta sections that need feedback. I didn’t but I will start now.

This feedback is given humbly!!! I’m open to feedback on anything stated here.

Step 25

Asks for destructuring to make object properties.
I have never heard this ES6 property shorthand referred to as destructuring. I think this is the wrong terminology and could be rephrased.

const {x, y} = coordinates; … this is the syntax I think of for destructuring.

Step 31

If an OR is used instead of an AND the feedback provides no clue as to what the issue is.

Step 58

Chain a function call to what function? I think chaining a function call is the wrong terminology. I thought what is depicted in example is currying, not most people would call function chaining. i.e. func1().func2()

I guess you could consider currying function chaining, but it might be a point of confusion.

Step 73

What is difference between [\d.] and [\d|.]? … The latter fails and feedback doesn’t give any hint as to what is preferred.

Step 75

Just a misprint in the “Check Your Code” dialog.

Pasted image 20240109194030

Would accurately say “Your highPrecedence function should use the return keyword.”

Step 78

Might ask for a regex that captures matches of … instead of just a regex that matches.

Step 80

Could give the example “This expression will look for function calls like sum(4, 1).” instead of “This expression will look for function calls like sum(1, 4).” because it would be more like an easter egg hidden reference to the band.

Step 81

Improve message in check code dialog.

The code:
const toNumberList = args => args.split(',').map(el => parseFloat(el));

results in …

Pasted image 20240110095853

but is erroring because .map() doesn’t need a callback parameter but just a reference to callback and I think that is a good opportunity to reinforce an earlier point.

Step 91

evalFunction() takes 2 arguments. There is instructions referring to how to pass the first argument. One would think we would need to provide a second argument in order to pass. If we do provide the second argument the code will not pass. It would be nice if it was stated for this step we are only providing the first argument.

I think it is also good for anyone interested in deepening the learning process to closely audit and comment because we are not always aware of what we need to learn. Doing things like this helps us to develop awareness of what we don’t know or misunderstandings of things we think we know.


you could open a github issue for this, yes

Hi @jdunlop81 !

Thank you for your feedback.

I went ahead and create some issues based on the feedback provided.

If you are interested in providing more feedback, then you can create issues here

1 Like

Thanks. I did not know if I should open an issue for suggestions. If it helps with tracking, ticketing system or whatever, I can open separate issues for different steps. I do have stuff altogether ready at anyone’s request if they want stuff in one place they can see at a glance, but I’ll keep unless asked and make issues on Github.

Yeah, that is the best way possible.
Because then it can be triaged, and open for contribution and implemented pretty quickly.

Most issues that we open for contribution that are smaller or medium fixes, are worked on within a few days, reviewed and merged in.
So the turn around for fixes ti pretty quick.

Obviously for larger issues, it will take a while longer, but still happens within a timely manner.

Yeah, that’s fine.

The only thing I would suggest is if you see a theme where one bug applies to many, then it would be better to open one issue and list the steps it affects.

For example, I updated your issue to apply the fix to multiple steps it was affected by so someone can create a PR and make those changes in one PR instead of multiple similar ones.

If you have more feedback, then you can create an issue for a project and list out the bullet points like you did earlier with the steps it refers to.

Then the team can discuss and triage it.

The cool thing about GitHub is that you can create task lists

Each task can be converted to its own issue

Task lists sound good. Just wondering where I’d post it. Would I make a single issue, or is there some other message exchange/forum type thing?

You would just create one issue with the task lists on it.
You can just create it on github.
Then the maintainers can review it and ask any necessary followup and questions and see which ones can be turned into issues

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.