3 ms·

On 3) Why do you care about types when teaching programming? (Not being facetious, this is a genuine question). I've always thought that the advantage of Pytho

by theptip 10y ago

On 3) Why do you care about types when teaching programming? (Not being facetious, this is a genuine question). I've always thought that the advantage of Python (or even JavaScript) as a first language is that you can defer thinking about (to the layperson) unintuitive concepts like types, and focus on the core concepts behind telling a computer to do what you tell it to. (Functions, variables, control flow, maybe classes if you're feeling fancy). I've talked to a super-smart Hack Reactor graduate who was blown away by the concept of static typing when I explained it to him in detail; it was simply irrelevant to his understanding of functional programming, data structures, and algorithms, subjects which familiar with at quite a high level. On 2), what's missing in Python beyond the unittest package? On 4) and 5), are these things that you introduce early in your curriculum? They seem like quite niche aspects of programming. I've found that most python programmers haven't had cause to use an event loop in production, for example; only really if you're implementing a web server or networking stack, something that frameworks usually abstract from you.

Draiken 10y ago
Regarding 3 I believe it's matter of doing it sooner rather than later. You can pretend that things don't have a type, but it's a lie. The only thing that languages like JavaScript do differently is to hide the types of variables. This forces the person reading/writing the code to keep track of what is on what variable at all times instead of having a compiler do it for him. I understand people have difficulty with pointers and such, but not types. Without that knowledge you can't go anywhere. From my point of view there is absolutely no advantage in hiding types when you always end up using them. Better to face the fact and teach them early on.
skrishnamurthi 10y ago
3. We teach types to students as young as 12. They have no trouble with the concept, because they're taught from a young age about classifying things, and types are a form of classification. So there's nothing "unintuitive" about it. The people who have the most trouble with types are adult programmers who were raised on languages with awful type systems, like Pascal, and cannot envision any other kind. Furthermore, we use types as a central notion in our program design curriculum. The structure of the data (aka, "types") provide a hint as to the structure of the program. This helps students who are stuck get unstuck. That is, they are most helpful to the students least able to get started, which seems like quite a valuable place to focus. Of course, having annotations and enforcing them statically are two different things. That's why Pyret lets you check annotations dynamically instead. And that makes it even simpler and more intuitive to introduce the concept. 2. Direct integration into the syntax of the language makes a huge difference. There's no library and additional complexity. For rank beginners, every new "moving part" is a source of problems. This is why most Python curricula do not emphasize writing tests early. In our curricula, students begin with writing examples of their program's behavior — expressed as tests — and use that to help figure out the way the program must work. (Just like you use examples to help figure out a more general structure in other disciplines.) 4. Event loops are central to reactive programming, i.e., animations and games. HtDP 2nd edition begins with writing an animation. The Bootstrap curriculum is focused around teaching students to write a game — but in the process learn algebra. It's niche to you because you have a particular model of programming education, which may well resemble what people were teaching in the 80s. That doesn't mean curricula haven't moved on. And we're talking about education, not production, which are two different things. 5. Combine the earlier points for this one. Whenever making "I haven't seen", "I don't see", etc. comments, it may be helpful to keep in mind Paul Graham's Blub Paradox [http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html].
not-just-yeti 10y ago
> Why do you care about types when teaching programming? Because programmers are always aware of types. You may not annotate that the function's `licensePlate` parameter is a string, but if you are thinking of taking a substring or string-appending it, of course you're aware of the type. If a beginner is only vaguely/intuitively thinking that the licensePlate is a string (sometimes confusedly thinking it's a number), then there'll be problems. So allowing a beginner to mention a type is important. So the question is more: when learning to program, do you require every name to be annotated with a type? Some people feel this is overkill, and others think it helps, for CS1. And languages with implicit conversion-rules can confuse some beginners, while converting explicitly can annoy others. Once somebody has internalized the rules, then yes of course you want the language to make "obvious" conversions and/or declarations for you (e.g. true-ish expressions, and (for Java) auto-boxing and auto-toSTring'ing). But just because experienced programmers find it indispensable doesn't mean it's appropriate for beginners. (Btw, in addition to learner-vs-competent programmer, there is a separate issue, about the strength of the students: some people pick up programming-way-of-thinking easily, and others need MUCH more guidance before they become competent. Different language-choices might be appropriate for those two audiences, as well.)

by theptip 10y ago

Draiken 10y ago

Regarding 3 I believe it's matter of doing it sooner rather than later. You can pretend that things don't have a type, but it's a lie. The only thing that languages like JavaScript do differently is to hide the types of variables. This forces the person reading/writing the code to keep track of what is on what variable at all times instead of having a compiler do it for him. I understand people have difficulty with pointers and such, but not types. Without that knowledge you can't go anywhere. From my point of view there is absolutely no advantage in hiding types when you always end up using them. Better to face the fact and teach them early on.

skrishnamurthi 10y ago

3. We teach types to students as young as 12. They have no trouble with the concept, because they're taught from a young age about classifying things, and types are a form of classification. So there's nothing "unintuitive" about it. The people who have the most trouble with types are adult programmers who were raised on languages with awful type systems, like Pascal, and cannot envision any other kind. Furthermore, we use types as a central notion in our program design curriculum. The structure of the data (aka, "types") provide a hint as to the structure of the program. This helps students who are stuck get unstuck. That is, they are most helpful to the students least able to get started, which seems like quite a valuable place to focus. Of course, having annotations and enforcing them statically are two different things. That's why Pyret lets you check annotations dynamically instead. And that makes it even simpler and more intuitive to introduce the concept. 2. Direct integration into the syntax of the language makes a huge difference. There's no library and additional complexity. For rank beginners, every new "moving part" is a source of problems. This is why most Python curricula do not emphasize writing tests early. In our curricula, students begin with writing examples of their program's behavior — expressed as tests — and use that to help figure out the way the program must work. (Just like you use examples to help figure out a more general structure in other disciplines.) 4. Event loops are central to reactive programming, i.e., animations and games. HtDP 2nd edition begins with writing an animation. The Bootstrap curriculum is focused around teaching students to write a game — but in the process learn algebra. It's niche to you because you have a particular model of programming education, which may well resemble what people were teaching in the 80s. That doesn't mean curricula haven't moved on. And we're talking about education, not production, which are two different things. 5. Combine the earlier points for this one. Whenever making "I haven't seen", "I don't see", etc. comments, it may be helpful to keep in mind Paul Graham's Blub Paradox [http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html].

not-just-yeti 10y ago

> Why do you care about types when teaching programming? Because programmers are always aware of types. You may not annotate that the function's `licensePlate` parameter is a string, but if you are thinking of taking a substring or string-appending it, of course you're aware of the type. If a beginner is only vaguely/intuitively thinking that the licensePlate is a string (sometimes confusedly thinking it's a number), then there'll be problems. So allowing a beginner to mention a type is important. So the question is more: when learning to program, do you require every name to be annotated with a type? Some people feel this is overkill, and others think it helps, for CS1. And languages with implicit conversion-rules can confuse some beginners, while converting explicitly can annoy others. Once somebody has internalized the rules, then yes of course you want the language to make "obvious" conversions and/or declarations for you (e.g. true-ish expressions, and (for Java) auto-boxing and auto-toSTring'ing). But just because experienced programmers find it indispensable doesn't mean it's appropriate for beginners. (Btw, in addition to learner-vs-competent programmer, there is a separate issue, about the strength of the students: some people pick up programming-way-of-thinking easily, and others need MUCH more guidance before they become competent. Different language-choices might be appropriate for those two audiences, as well.)