3 ms·

I've had an unfortunate opportunity to have to help out a cousin's girlfriend with python. She's studying informatics and it's their introductory course in prog

by dsego 13y ago

I've had an unfortunate opportunity to have to help out a cousin's girlfriend with python. She's studying informatics and it's their introductory course in programming (recently switched from pascal). But python has really too many abstract constructs to explain easily. One example they had was using the for loop. I don't know python, but from the examples and exercises the professor gave them, it doesn't seem to have a "normal" for loop. All the examples used the function range() to generate an array of indices to loop over. Which is silly, since they don't cover functions and arrays until later. I had a hard choice to either go into details of why it works or tell her to just memorise it. Later on in her materials, after introducing arrays, suddenly the for loop doesn't use indices and she has to unlearn the old way. The other problem was explaining strings and methods, which they use (such as str.uppercase()) but their introductory course doesn't cover OOP. The last atrocity was an example of looping over lines in a file using the for construct. Of course, polymorphism, iterator patterns and so on are too advanced, but it really bothers me that they have to just memorise stuff without knowing why it works. I'm glad I had C as the first language. Firstly you generally learn how the CPU actually handles instructions, since C is so close to metal. Secondly, after C you can really appreciate what other languages have to offer. And thirdly, I really prefer the bottom-up approach. Then again, my perspective might be a bit skewed, since I graduated in computer engineering, which is a bit more involved than informatics.

analog31 13y ago
I'm teaching Python to my kids (ages 10 and 13) right now, after finally ditching Visual Basic myself last year. Of course I'm at liberty to improvise my "syllabus." I decided to introduce lists before program flow. I introduced range() as a way to populate a list. And then we started doing things with lists using constructs like [x2 for x in range(-10, 10)]. At that moment, my daughter asked: "Can we use Python to make a graphing calculator?" With my syllabus in tatters, we installed matplotlib and played with it a bit. I've explained to my kids that in programming, sometimes we have to look up and use things before we fully learn how they work. This approach would probably make no sense for teaching C, where looping comes before lists. But in my idiosyncratic mental map of Python, lists come before looping. I'm not dogmatic about what first language to learn. My only intention right now is to see if my kids will take an interest in it.
Derbasti 13y ago
Those are all valid points. However, I am teaching an introductory programming course and I have seen many a student terribly confused by manual memory management and low level data types. My hope is to be able to introduce the very basic parts of programming (variables, assignment, branching, looping, functions) without having to go into any OOP or containers. There are always people who will never get even those most basic concepts, but there might be some who will get a basic glimpse of what programming means who would otherwise fail at basic C data types. In the end, they will all need to understand all of Python, then C, then (sadly) Matlab. What you are describing is indeed very interesting. One has to be very careful to not introduce too many concepts too early. So maybe, one should restrict looping to while loops until lists are introduced. And string processing could be taken as the introduction to OOP.
hackinthebochs 13y ago
Totally agree. I learned C first, then C++. I wouldn't have it any other way. The top-down approach means you truly understand nothing until a year or so down the line. The bottom up approach lets you fully grasp the small world you've been exposed to. And as more concepts are introduced your world expands. At no point are you just left wondering WTF are these magic keywords doing.
- kyzyl 13y ago
  > The top-down approach means you truly understand nothing until a year or so down the line. Is that really true? I think my language ordering went something like: qbasic, perl, visual basic, python/c, php,<others>, more c, c++, <others> So strictly speaking it was at least a year or two before I learned C for the first time. However, while I certainly wasn't as well informed as I am now, I wasn't completely clueless. I knew that the things I was doing in perl were actually allocating memory, that perl was helping me with lots of book keeping, that there were things called pointers that pointed to things, etc. I might not have actually worked in detail with the concepts yet, but I did have an idea that there was something below what I was working with. I think that by bearing that in mind, I was able to 1) know that I would have to learn the 'hardcore' stuff eventually and 2) focus on the actual programming, in the sense of making the computer do what I wanted.

by dsego 13y ago

analog31 13y ago

I'm teaching Python to my kids (ages 10 and 13) right now, after finally ditching Visual Basic myself last year. Of course I'm at liberty to improvise my "syllabus." I decided to introduce lists before program flow. I introduced range() as a way to populate a list. And then we started doing things with lists using constructs like [x2 for x in range(-10, 10)]. At that moment, my daughter asked: "Can we use Python to make a graphing calculator?" With my syllabus in tatters, we installed matplotlib and played with it a bit. I've explained to my kids that in programming, sometimes we have to look up and use things before we fully learn how they work. This approach would probably make no sense for teaching C, where looping comes before lists. But in my idiosyncratic mental map of Python, lists come before looping. I'm not dogmatic about what first language to learn. My only intention right now is to see if my kids will take an interest in it.

Derbasti 13y ago

Those are all valid points. However, I am teaching an introductory programming course and I have seen many a student terribly confused by manual memory management and low level data types. My hope is to be able to introduce the very basic parts of programming (variables, assignment, branching, looping, functions) without having to go into any OOP or containers. There are always people who will never get even those most basic concepts, but there might be some who will get a basic glimpse of what programming means who would otherwise fail at basic C data types. In the end, they will all need to understand all of Python, then C, then (sadly) Matlab. What you are describing is indeed very interesting. One has to be very careful to not introduce too many concepts too early. So maybe, one should restrict looping to while loops until lists are introduced. And string processing could be taken as the introduction to OOP.

hackinthebochs 13y ago

Totally agree. I learned C first, then C++. I wouldn't have it any other way. The top-down approach means you truly understand nothing until a year or so down the line. The bottom up approach lets you fully grasp the small world you've been exposed to. And as more concepts are introduced your world expands. At no point are you just left wondering WTF are these magic keywords doing.

kyzyl 13y ago
> The top-down approach means you truly understand nothing until a year or so down the line. Is that really true? I think my language ordering went something like: qbasic, perl, visual basic, python/c, php,<others>, more c, c++, <others> So strictly speaking it was at least a year or two before I learned C for the first time. However, while I certainly wasn't as well informed as I am now, I wasn't completely clueless. I knew that the things I was doing in perl were actually allocating memory, that perl was helping me with lots of book keeping, that there were things called pointers that pointed to things, etc. I might not have actually worked in detail with the concepts yet, but I did have an idea that there was something below what I was working with. I think that by bearing that in mind, I was able to 1) know that I would have to learn the 'hardcore' stuff eventually and 2) focus on the actual programming, in the sense of making the computer do what I wanted.