6 ms·

I disagree with the premise of the article. We absolutely do not know how to teach programming both pedagogically and andragogically, you can see that 80% of th

I disagree with the premise of the article. We absolutely do not know how to teach programming both pedagogically and andragogically, you can see that 80% of the students after getting their masters in CS absolutely can not program, do not understand computation, or the computer, not to mention higher order abstractions and their interactions. There are university students now in their 3rd year that paste chatgpt's javascript program into their c# code (also written by chatgpt) and ask me why is everything red and its not "working". I think it is a problem of designing for the 'average' student, which of course does not exist. The academia focuses too much on the abstract languages and constructs, but the reality is, the code will run on a man-made digital computer, which has certain properties, it uses memory in a certain way, has a clock, and is discrete, certain things are possible, and others are not. No matter how much we pretend, the equal sign (=) leaks through, and that in itself creates infinite confusion in people who pretend to get it. I think hyper individualistic approach is the solution. My daughter for example really dislikes scratch and various graphical languages, but she does really well with machine code and assembly and c. When we were working on a chess game, and she said: "WAIT! the queen is just rook + bishop", we went into how can we actually structure our code to express that. The journey is completely non linear. Sometimes we go back, sometimes forward. Hopefully AI + teacher can help with that. But the truth is, some kids get various concepts, like recursion or references and values, naturally, some never get it. And we are trying to teach them the same thing at the same time for the same duration, and just move on. SICP is best for some, PDP11 machine code for others, godot or roblox lua for third, and so on. The problem is we don't know which is which :) PS: Some of the things I made to teach my daughter: https://punkx.org/ https://punkx.org/

toolslive 2y ago
I concur, but it's even worse: I have a son who's doing a master in engineering (not CS). He had several programming courses in python and R. When looking at the example solutions, I noticed that whoever wrote them can't code, doesn't understand programming and certainly should not be allowed to teach it.
- throwaway71271 2y ago
  I never went to university, but in high school I had two different teachers, and one was hundreds of times better than the other. I am not really sure how teachers get hired, how they are interviewed and assessed, but the system is clearly not working; particularly in subjects that the learning curve is not a curve (like math, or physics or cs)
crabbone 2y ago
This isn't what the article says... The articles says roughly that "while we know what to strive for, we are falling short of achieving our goals." It doesn't make the claim that we know how to teach programming. Now, unrelated to what the article says, I wanted to bring up this point: there are several ways we know how to teach something, and they apply better to different disciplines. For instance, the approach where we do lecture-lecture-lecture-seminar-test is what's used to teach subjects that require very little hands-on work (eg. law, history etc.) Then, there's lecture-lab-lecture-lab-lecture-lab-test approach, which is better suited to subjects like biology or electrical engineering etc. Some subjects have their own tradition of teaching that's mostly unique to them. Eg. painting is taught by assigning students to the professor's workshop, where they, basically, live for a few years. No formal "teaching" takes place, but the workshop's master interacts with students whenever he/she feels fit. Or, conservatory students who, usually, spend hours in one-on-one training with their teacher practicing their instrument of choice. What I think is happening in teaching to program is that because the field originated in math + engineering faculties, the tradition of how to teach it was borrowed from that space too: lectures + labs + tests. But, I think, that programming is more similar to painting in the way how it's done and how it could potentially be taught. So, instead of short-term labs and tests, it would be beneficial for the students to have long-term projects, possibly worked on in groups, where interaction with the teacher happens when the teacher inspects the work done so far and decides to provide feedback. The drawback of this approach is the grading that will not be defined formally and will be grounds for disputes between the students and the teachers. But, I still think it would've been better than the sequence of short-term assignments that must be worked on alone, because the later doesn't welcome and sometimes precludes the use of industry tools (s.a. version control systems, bug trackers). Essentially, today, those who are taught to program aren't taught how to use programming tools at all. Which is very weird to anyone coming from a school with a practical slant, where studying the tools would've been an essential part of the training.
- throwaway71271 2y ago
  > This isn't what the article says... thats not the only thing it says, but it does say it: > The conclusions to be drawn from the points made throughout this paper are reasonably obvious: We need a new language for teaching novices at secondary school and introductory university level. It also does states that somehow we know how to teach programming, and the discussion is around finding an incremental improvement given the learnings so far.
aleph_minus_one 2y ago
> No matter how much we pretend, the equal sign (=) leaks through, and that in itself creates infinite confusion in people who pretend to get it. I have a feeling that this issue might be amplified by the facts that 1. many US-American students are monolingual. 2. I have observed that many native English speakers are less interested in their own language than native speakers of other languages for their mother tongue. For 1: If you are used to learn multiple (natural) languages, you are very used to the fact that (nearly) identical words can have very different meanings in different languages (false friends). Examples: sensible [en] vs sensibel [de] ("sensitive" in English) bite [en] vs bite [fr] (a vulgar word) So for me there is nothing surprising about the fact that "=" means different things in mathematics vs programming languages that use = as an assignment operator. For 2: There exist quite a lot of English words that can have very different meanings depending on the context (arbitrary example: "left" can both mean a direction, and be the simple past and past participle of "to leave"). So what is so difficult about the fact that = means something different in a C/C++/Java/C#/Python program than in a math equation?

toolslive 2y ago

I concur, but it's even worse: I have a son who's doing a master in engineering (not CS). He had several programming courses in python and R. When looking at the example solutions, I noticed that whoever wrote them can't code, doesn't understand programming and certainly should not be allowed to teach it.

throwaway71271 2y ago
I never went to university, but in high school I had two different teachers, and one was hundreds of times better than the other. I am not really sure how teachers get hired, how they are interviewed and assessed, but the system is clearly not working; particularly in subjects that the learning curve is not a curve (like math, or physics or cs)

crabbone 2y ago

This isn't what the article says... The articles says roughly that "while we know what to strive for, we are falling short of achieving our goals." It doesn't make the claim that we know how to teach programming. Now, unrelated to what the article says, I wanted to bring up this point: there are several ways we know how to teach something, and they apply better to different disciplines. For instance, the approach where we do lecture-lecture-lecture-seminar-test is what's used to teach subjects that require very little hands-on work (eg. law, history etc.) Then, there's lecture-lab-lecture-lab-lecture-lab-test approach, which is better suited to subjects like biology or electrical engineering etc. Some subjects have their own tradition of teaching that's mostly unique to them. Eg. painting is taught by assigning students to the professor's workshop, where they, basically, live for a few years. No formal "teaching" takes place, but the workshop's master interacts with students whenever he/she feels fit. Or, conservatory students who, usually, spend hours in one-on-one training with their teacher practicing their instrument of choice. What I think is happening in teaching to program is that because the field originated in math + engineering faculties, the tradition of how to teach it was borrowed from that space too: lectures + labs + tests. But, I think, that programming is more similar to painting in the way how it's done and how it could potentially be taught. So, instead of short-term labs and tests, it would be beneficial for the students to have long-term projects, possibly worked on in groups, where interaction with the teacher happens when the teacher inspects the work done so far and decides to provide feedback. The drawback of this approach is the grading that will not be defined formally and will be grounds for disputes between the students and the teachers. But, I still think it would've been better than the sequence of short-term assignments that must be worked on alone, because the later doesn't welcome and sometimes precludes the use of industry tools (s.a. version control systems, bug trackers). Essentially, today, those who are taught to program aren't taught how to use programming tools at all. Which is very weird to anyone coming from a school with a practical slant, where studying the tools would've been an essential part of the training.

throwaway71271 2y ago
> This isn't what the article says... thats not the only thing it says, but it does say it: > The conclusions to be drawn from the points made throughout this paper are reasonably obvious: We need a new language for teaching novices at secondary school and introductory university level. It also does states that somehow we know how to teach programming, and the discussion is around finding an incremental improvement given the learnings so far.

aleph_minus_one 2y ago

> No matter how much we pretend, the equal sign (=) leaks through, and that in itself creates infinite confusion in people who pretend to get it. I have a feeling that this issue might be amplified by the facts that 1. many US-American students are monolingual. 2. I have observed that many native English speakers are less interested in their own language than native speakers of other languages for their mother tongue. For 1: If you are used to learn multiple (natural) languages, you are very used to the fact that (nearly) identical words can have very different meanings in different languages (false friends). Examples: sensible [en] vs sensibel [de] ("sensitive" in English) bite [en] vs bite [fr] (a vulgar word) So for me there is nothing surprising about the fact that "=" means different things in mathematics vs programming languages that use = as an assignment operator. For 2: There exist quite a lot of English words that can have very different meanings depending on the context (arbitrary example: "left" can both mean a direction, and be the simple past and past participle of "to leave"). So what is so difficult about the fact that = means something different in a C/C++/Java/C#/Python program than in a math equation?