JS1 Week 1 - module restrucure

[Dedekind561]

JS 1 Week 1 - thoughts on restructuring

The current JS1 Week 1 module is overloaded. Trainees are expected to learn about expressions, console.log, data types, variables, invoking functions, declaring functions, using NodeJS for the first time, side effects - return vs console.log. In addition to this, they're also expected to teach themselves about testing and test syntax too ( and this content is not on the JS 1 Week 1 syllabus page ). My proposal here is to completely remove function declarations out of this section and focus on this topic in another week.

Proposal

Section 1

Topics covered

Creating and evaluating expressions; Introduction to data types - strings, numbers; using Node REPL, predict-observe-explain

Rationale

At the moment trainees are expected to start the course by executing a JS program with Node using the standard "hello world" program. This first lesson involves trainees calling console.log in order to get some terminal output.
This section is taught whilst the following questions remain unanswered or partially unanswered:

• What is a function?
• What is a JS expression?
• Why should we use functions?
• What does a function call mean?
• How can we call a function?
• What is Node?
• What does it mean to execute a script?
• Why do we want to log stuff to the terminal?

It's worth noting that most trainees won't actually know the concepts that they don't know at this stage. However, by leaving the questions above unanswered, it implies we’re trying to introduce something without laying the proper groundwork. Does it make more sense for trainees to have some baseline intuition about a function and a function call before they start trying to understand what console.log does? I think a first console.log program is easier to understand when you’ve got the basic notion of a function and how it is called. Otherwise trainees are being expected to inspect some, at this stage, random syntax and remember what it does with very little context.
Currently, we introduce a program like this:

console.log("hello world");

but we can’t emphasise the fact that console.log is a function and console.log(“hello world”) is a function call expression. It would be preferable to introduce some basic notion of a function and its call syntax before jumping straight to the console.log program. By using the Node REPL, we can focus on executing JS code ( just by creating simple expressions ) without looking at: a) console.log b) running a Node script b) function call syntax etc. Then when we cover console.log for the first time we can connect this program to their previous knowledge of function calls.
The other advantage of this approach is that the Node REPL evaluates code one line at a time. Trainees are forced to focus on the current expression they're writing and it becomes much easier for them to anticipate what will happen when Node evaluates their expression.

Section 2

Topics covered

Why use variables?; variable declarations anatomy: assignment, let, const keywords; ReferenceErrors; creating expressions using variables ( using Node REPL )

Rationale

We can still rely on Node REPL too at this point in the lesson. I also think we could use this opportunity to introduce ReferenceErrors. Another advantage of the REPL here is that trainees don't need to parse a more complex error message with a potentially confusing stack trace. Trainees can focus on what is causing the error without having to track it down in the script at the same time. I think it's important to have errors and error messages embedded throughout the syllabus and not just an isolated section that we never refer back to.

Section 3

Topics covered

Introduction to functions - What are they and why do we need them?; invocation syntax - difference betweenfand f(); function output/return values; calling functions like Math.round, Math.ceil

Rationale

At this point, we could introduce the notion of functions on a very general level. We could say something about functions being a unit of code that we can continually reuse to achieve some task in our program. ( I don’t think we should introduce function declarations at all at this stage). The beauty of the REPL is that we still don't need to introduce console.log at this point. Trainees can consider function call expressions like Math.round(10.3) and Math.floor(10.34) without yet going to console.log. I would argue that Math.round(10.3) is much easier to reason about initially than console.log(10.3) because trainees without a coding background are almost 100% likely to have some in-built intuition about rounding decimals numbers. Additionally, Math.round(10.3) is easier to understand because it has a return value that we can store in a variable. This intuition will make the introduction of call/invocation syntax feel more intuitive itself as it is more closely tied to their prior knowledge. N.B. It's worth noting that "halden".toUpperCase()" appears intuitive at first but is perhaps less so at this stage in the course; trainees should be developing an understanding that inputs are passed inside parentheses () and toUpperCase breaks this pattern because it lives on the String prototype.

Section 4

Topics coveredRunning a script using Node; using console.log; side effects; return vs console.log, reading errors thrown by a script

Rationale

Finally we can now discuss the problem with using Node REPL as the only way to execute JS code. We can now show how to create more complex JS programs using files and then talk about how they are executed. It should now be much clearer why we need to appeal to console.log in order to get output in our terminals. In addition, trainees would already be aware of function call syntax and passing inputs into functions. With this knowledge already in mind, trainees can focus more clearly on what exactly console.log does in their program..

Omissions

This approach would mean skipping tests at this stage in the course. I personally don’t think trainees should see tests till JS1 Week 4.

[illicitonion]

I think this generally sounds very reasonable, and like it makes a lot of sense. Definitely a big improvement over what we have today!

The other approach I've thought about for restructuring JS1W1 is to push everything into the browser with a lot of scaffolding. Maybe a simple HTML page which has an onClick handler or similar for some button, and have the trainees edit a .js file which has the onClick handler do something for them.

Advantages of HTML:

• Builds on the things they were doing previously - just adding one more thing
• Gives a useful structure for explaining/understanding some of the key concepts - e.g. "why do we need functions?" may be easier to explain in the context of "Well, we need to tell the onClick handler what to do somehow - this is how we encapsulate doing a series of things"
• Quickly gets to doing things that are obviously actually useful - one of the problems I think we have with using node/repl early on is that it's not obvious why we're doing anything we're doing - if you can see things interactively actually happening in response to your actions, things are hopefully more clear

That said, I think the proposal in this discussion is much more strong at being able to introduce concepts one at a time, and also strip away magic - not needing any scaffolding, not having the entwined complexity of a bunch of browser glue code, and being able to just do one thing at a time and reason about it - all really great properties.

[40thieves]

strip away magic

I'm not sure I see "magic" being a big problem for this phase of the course, trainees would have just come out of Fundamentals which is pretty full of magic. Moving from Blockly to writing JS scripts with some provided functions seems like a fairly natural next step.

As we saw with Processing/Khan Academy, the risk is of learning in a "magic" environment is that knowledge doesn't transfer, but I think if we manage this transition by carefully pulling back the curtain on the magic it's doable.

we need to tell the onClick handler what to do somehow

Having said the above, I think this is a pretty good example of where how it's a difficult line to walk: using onClick handlers implies callback/higher order functions which we've always had trouble with.

This is part of the reason why I was (am?) a fan of Processing: you interact with the "magic" environment via fairly plain functions, with mostly intuitive arguments.

[illicitonion]

This is definitely off topic for the discussion at hand - I'm in favour of Mitch's proposed change - sorry for hijacking the discussion, but it seems a convenient place to explore :D Happy to fork off to a separate discussion if this gets noisy / in the way.

using onClick handlers implies callback/higher order functions which we've always had trouble with

I'm not confident in my suspicions, but I suspect one of the reasons we've had trouble with callbacks is because the way we introduce them is super artificial. I hope (but have no foundation for this hope) that by having a much more tangible "Oh yes, the browser needs to know how to call my code, so needs my code, and a contract for it" use-case, rather than a somewhat artificial "take an array of numbers and double them... Except this could have just been a for loop... And the change in who's in control doesn't seem obviously useful...". I guess what I'm saying is: I'm hoping that the increased complexity of event handlers may actually make them make more sense not less. But I should probably run some experiments to test this suspicion; as I say, I've not tested it out.

This is part of the reason why I was (am?) a fan of Processing: you interact with the "magic" environment via fairly plain functions, with mostly intuitive arguments.

My experience of watching people having learnt processing is that they didn't make the connection between "writing some processing code" and "oh, I'm calling a function, and that also means the function must be defined somewhere" - the experience with processing and the future experience with JS1 are largely unrelated. But I can believe we've interacted with people who had different learning styles, or had been introduced to the concepts differently by different people.

[gregdyke]

I think this looks great and I think we should do it!

For testing, I think we should be testing in js1 week 1, but I agree that if the tests are being run in the command line, that's a bit much

[gregdyke]

obviously I also think we should go directly to the browser, but that's a further iteration that doesn't prevent us from doing this one

[shieldo]

This all sounds good to me - I'd also agree that testing probably shouldn't come in the first two weeks, at least not before a decent introduction to functions (but yes, should ideally follow soon after that, because the idea that we can test a function as a black box is a powerful one, and can be easily demonstrated using e.g. Math functions).

I also think starting in the browser may risk being confusing at this stage, because of the somewhat magical scaffolding needed. So long as we do link back to what trainees have encountered before, and so long as it's clear that we will be returning to the browser (I assume to do DOM scripting), I suspect it wouldn't harm to do some "purer" first-principles programming stuff right at the start, and keeping in the REPL does have all the advantages described above. I'm very open to the possibility of that presenting conceptual hurdles, though.

[40thieves]

Thanks for writing this up @Dedekind561 🙂

First of all, I think it is worth acknowledging that it sounds like we all have more radical ideas for the JS modules in general, but from what I'm understanding this proposal is scoped down to something achievable without throwing the whole content out. (Fwiw, my ideas are also around moving us to the browser. And heavily leaning into function calls, inspired by Processing 🙂)

Within these constraints, I definitely think this would be an improvement over the current content and I'm in favour of moving forward with it. A couple of things I wanted to call out as particularly positive in my mind:

• Reducing reliance on console.log, as the current lessons tend to develop a bad habit of thinking that console.log is the end goal
• Starting to debug early with explicitly looking at reference errors
• Rolling up to a "this is why .js files are useful" conclusion at the end of the lesson

---

I have a couple of questions:

• I'm not seeing any operators mentioned here, I presume you're rolling them into Section 1 with the expressions content?
• You mention that one of the benefits of using a REPL is not having to deal with a stack trace, do you plan to move that into later lessons? Or would that fit into Section 4?
• What do you envision coursework looking like? They would have interacted with scripts by the end of the lesson, so would coursework be mostly an extension of this work, perhaps bringing in more of the concepts from the REPL-based sections to scripts?

---

For next steps, I'd be keen to see some learning objectives 🙂 (Realise it's early days though!)

[illicitonion]

Reducing reliance on console.log, as the current lessons tend to develop a bad habit of thinking that console.log is the end goal

Strong +1!

[Dedekind561]

I'm not seeing any operators mentioned here, I presume you're rolling them into Section 1 with the expressions content?

Yes absolutely.

You mention that one of the benefits of using a REPL is not having to deal with a stack trace, do you plan to move that into later lessons? Or would that fit into Section 4?|

I think stack trace could be moved into the section where function declarations are introduced for the first time.

What do you envision coursework looking like? They would have interacted with scripts by the end of the lesson, so would coursework be mostly an extension of this work, perhaps bringing in more of the concepts from the REPL-based sections to scripts?

Yes exactly, I was thinking of some along these lines.

[Dedekind561]

Hello folks,
Thank you for all your excellent points - I now want to distil the discussion into ✅ things we agree on, questions for future discussions ( out of scope for this discussion )❓ and some follow-up actions 🔨

✅ Things we agree on

• Folks seem to be fairly happy with the proposal in this discussion. I'm happy to move forward with the changes too. See Actions below

❓ Questions for future discussion

• What do we mean by the term "magical"? The motivation behind this change is to ensure that concepts are coherently built up on each other. In other words, I don't regard topic X as"magical" if its minimal conceptual model has been explained beforehand. In this sense, p5.js wouldn't be magical provided we've explained what a function is, how to call a function, what arguments are etc beforehand. Of course, it could be argued that it is magical because we have access to some functions we've not defined - but this is true of the browser, Node etc. @SallyMcGrath this chimes about bringing the concept of API forwards in the syllabus.
• Should we use the browser from the beginning of JS1 - I think there are some definite benefits, but we need to open out into another discussion so we can fully discuss the pros and cons.

🔨 Actions

• Create issue with some format acceptance criteria - Mitch
• Create some draft learning objectives - Mitch
• Open more discussions to address the questions ( online )
• Discuss the more radical JS module restructuring ( what is this? when and how should we approach this change?) ( syllabus meeting )

[illicitonion]

+1!