4 ms·
I teach CS to freshmen. The author keeps telling something is "a wrong question", but I feel that he is tackling a wrong problem. The problems shown here are ra
by euske 6y ago
I teach CS to freshmen. The author keeps telling something is "a wrong question", but I feel that he is tackling a wrong problem. The problems shown here are rather syntactic/superficial - it's mostly a matter of language/tool proficiency. The real problem I commonly see among students is to systematically verbalize a thought that you're initially unaware of - e.g. take the binary search for example. The idea can be easily understood, but realizing that a range can be expressed with two numbers (high & low) is hard. Another example is to enumerate all permutations of given items. It's easy to imagine what are the expected result for a certain input, but it's not easy to describe the systematic process - it'd require some mental leap. These are what many people are struggling with, and something we still don't know how to teach.
- kreddor 6y agoThis is so spot on. I teach CS as well and just taking a problem and dividing it into small tasks to be solved is something many students struggle with even near the end of our programme. This "mental leap" (the bridge between the problem and the steps to solve it using code) is the real barrier in my opinion. Most students won't have a problem understanding a solution when presented with it and wrongly thinks that just understanding a solution is the end goal, when arriving at it is the real challenge.
- Mauricebranagh 6y agoThat's interesting breaking a problem down into steps seems such an intuitive approach. Coming from a technical programming background Middle Out is the methodology I often use BTW Which level are you teaching at? I would expect University students to be capable of "taking a problem and dividing it into small tasks "
- kreddor 6y agoI agree. To me, it's the only approach, but I've been doing it for so long. On some level, the students understand this as well, but doing it is a different matter, especially when it comes to programming. I teach on some very practice-orientated higher education programmes in Denmark at the level of a bachelor's degree. We tend to get different types of students than those who would apply for a bachelor's degree at one of our universities, which could also be part of the explanation.
- 01100011 6y agoYou have a point, but learning to program is hard because it requires mastery of several domains: abstract thinking, mathematical concepts, programming idioms and syntax, debugging and problem analysis, problem decomposition, etc. I think the author presented a very insightful take on teaching some of the important aspects of programming.
- deleted 6y ago[deleted]
- analog31 6y agoI think programming is actually hard to learn, even at a level where those domains don't really come into play. More than half of the kids in my BASIC class in 1980 never grasped even the most primitive programs. The kids who "got" it, may have been good at the things you mention, in terms of potential, even if they had never actually done any of them by the time they were in high school. And I think there are good programmers who are lacking in those domains, notably math beyond the intro level, where problem solving involves recognizing the "form" of a problem, and remembering the algorithm for solving it. The guides I've read on making programs more understandable recommend eliminating abstraction, for instance by making sure that the names of things are concrete and self explanatory. So I actually think it's still a puzzle why programming is hard, or easy. The paradox is that programming is super easy, but only for a randomly selected group of people, otherwise it's prohibitive. Then again, if you can think of a subject, like programming, where we've tried a new way to teach it in every generation, with no sign of widespread success, it's math.
- Kwantuum 6y agoThis comment completely misses the point. The article's title is "Learnable Programming: Designing a programming system for understanding programs" This is not an article about how to teach or learn programming, this is about creating an environment inside of which learning is made easier. Try giving a freshman a binary search program with an interactive visualization like the ones shown in this article that they can play with, and see if they still struggle with it. Same goes for the permutations. You don't have to teach anything when you can let someone experiment and teach themselves how something works. At the end of the day, true learning always hinges on personal insight, and the best teaching methods are those that make it easiest for a person to extract insight.
- Izkata 6y ago> This is not an article about how to teach or learn programming, this is about creating an environment inside of which learning is made easier. Looks kinda the opposite to me. It's criticizing a particular learning environment because it doesn't actually help with learning programming. Right in the middle of the opening section: > Thus, the goals of a programming system should be: > * to support and encourage powerful ways of thinking > * to enable programmers to see and understand the execution of their programs > A live-coding Processing environment addresses neither of these goals.
- AnIdiotOnTheNet 6y agoIt's kinda funny how many on HN talk about basic programming being hard, but also bemoan the existence of complex excel-macro-based workflows created entirely by non-programmers.
- cbreynoldson 6y agoLearning to program is not necessarily the same as learning to code. If we always think of the two as the same, we'll face the same issues indefinitely.
- vojta_letal 6y agoBy "code" mean a syntax/semantics and by "program" architecture/algorithms?
- cbreynoldson 6y agoSorta. Code is the medium of encoding a program, but it's just text. One important part about programming is it gives us a new mode to think in terms of. Another is that it gives us power over an entity (the computer) to execute things. The cool thing about Papert's LOGO was that children already knew how to think in terms of left, right, forward, etc. so they could act out their programs in real life before writing them down. This is one step forward, but not enough. We have to stop looking at computers as machines with mice and keyboards and small screens that we conquer with code and start thinking of them as abstract entities that execute things, and then think of how best to manipulate those entities to do what we want. "The computer is an instrument whose music is ideas" (Alan Kay) - Can you imagine what music would look like today if all we could do was write it down and hit play? Where's the emotion and playfulness in that?