@arafel@mas.to @bjn@mstdn.social @cstross@wandering.shop @lauren@mastodon.laurenweinstein.org It's not a misapprehension of how evolution works, something that could be corrected by real-world experience.

It's eugenics. It's an ideology with internal contradictions large enough to fly a Boeing through, and one that unfortunately many liberals share (for evidence see US COVID death toll 2020-2024). You only need to see one picture of Francis Galton to recognize that the folks pushing this ideology would not fare well were its dictates evenly applied. But this sort of thing is always about forceful exclusion.

@futurebird@sauropods.win Yes, I would say so. Functions in math are different from functions in code. Mathematical functions look more like lookup tables or dictionaries. One sticking point is the flow of control: a function has a block of instructions that are not executed at the point where they're written in the source code. This is really confusing for some people, especially if they've just been taught that computers go through a list of instructions one by one, executing each in sequence.

Add in functions that have side effects, functions that don't return a value (procedures), functions that trap the rest of the execution (continuations), etc., and you're well outside of what most people understand mathematical functions to be like. The mathematical sine function can't make a network connection or write to a file or...

You can sometimes suss this out by comparing a function to a dictionary (or similar lookup type data structure). Those don't involve changes in the flow of control, and students tend to grasp what they're doing much faster. Students who grasp dictionaries sometimes cannot transfer that understanding to functions because of the flow of control issue, I think, so it can be helpful to probe whether they understand one but not the other and try to figure out why.

@futurebird@sauropods.win I don't know your class or students, and all of this might be stuff you already do or not relevant at all, but here are some things that popped into my mind from my own experiences, in case it's of any use:

• Recent CS education research suggests that functions are one of the hardest intro programming concepts for most students, and shouldn't be introduced till some other concepts are mastered first (search "concept inventories for introductory computer programming"). It can help to first practice associative arrays/hashtables/dictionaries. Modularization into functions is harder still. The fact that many of your students are struggling with creating a function might indicate that they haven't mastered the concept yet and you might do well to back up a bit. If they need some remedial work, I cannot praise Parson's puzzles enough
• When running a lab-style section, where students are actively working on something with your support, I think it helps to interleave lecture time, work time, and debrief time. When you lecture, lecture rules (including controlling when interruptions can happen) apply. Work time is when you let interruptions happen more freely as you walk around to see how folks are doing. When I run such things I tell the students at the beginning of the section what the plan is. After a week or two they get it. I think it's useful to keep each work session on the shorter side, 10-15 minutes, with a well-scoped task and well-defined goal, and then have a debrief afterward where students can describe their experience, vent, brag, what have you. That way they know they'll have opportunities to talk and might be less inclined to shout out randomly
• If you don't have assistants to help you, recruiting other students to help field questions can be very effective. In the past I've had success dividing students into pods of 2 or 3, but only after observing the class for a few weeks. I strategically designed each pod to have at least one student who seemed to be on top of the material and another who seemed to be struggling. This setup requires communicating with the students regularly and adjusting the group assignments throughout the course, but it can lighten the load quite a bit, especially after the students get to know each other. I design classes such that the first few weeks are for setting the stage and warming up, and for me to get to know the students
• I've found it can be helpful to tell students some variation of "I know it's frustrating that your code doesn't work. Even today, code I write doesn't usually work the way I want on the first go. This is an experience you're likely to have the rest of your life when writing code. One thing to take away from this course is how not to be set back by this feeling. It's a normal part of the experience of coding, and it's telling us something". If that lands you can follow up by asking them what they think their frustration/struggle/what have you is telling them. The self reflection can be helpful and you can learn important things about your students this way (it can also lead to awesome discussions). Some students react very positively to hearing that this is a normal part of the process (they think there's something wrong with them, or that they are doing something wrong, if they're feeling frustrated).

Hopefully something in there is of use. I have references for concept inventories and Parson's puzzles if those would help. Good luck!