Dennis Lee Bieber <wlfr...@ix.netcom.com> writes: > On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle <hrouse...@jevedi.com> > declaimed the following: >> >>I wouldn't. This is all Python-stuff. The course chooses a language >>like Python, but it is not trying to teach Python --- it is trying to >>teach computer programming, that is, strategies in high-precision. > > Then I would posit you are teaching the wrong level... What you > describe is what would be found a "data structures" and/or "algorithms" > course -- which is a second year, if not third year course in my (ancient) > history. [...] Slicing with a stride isn't really useful to most > algorithm development -- it's more of trick in normal Python.
I didn't express myself very well. And it's hard to make sense of the course. I say it's interested in teaching computer programming because it is not allowing the students to dive into the Python language. It's very restrictive. Students will finish the course after learning to use the loop contructs while and for. The course calls them ``structures for repetition''. I think it's safe to say that the course is designed by people concerned with education, but not well-versed in programming languages, so not even the terminology seems quite correct. So if they're not letting students embrace the whole of the language, they must be concerned with other things? They sloppily emphasize documentation and put in some concerns for procedure signatures. I have some trouble defending it. I see the good intentions, though, and the job is not easy. But this course is definitely not teaching any data structures or any algorithms. Zero. Students are using tuples, lists and dictionaries, strings and numbers, but they're not studying any strategies whatsoever. The exercises make students use a few basic facts of mathematics, but there is pretty much no investigation into the strategies behind some of these facts. It's not very intelligible. I *kinda* like that it's restrictive because it allows us to show students at least a few idioms: otherwise there's so much syntax to digest that there is no time to show a few useful applications of them. But then I read your next paragraph and it brings me to a very important point, which I think it's at the back of your mind too. Let's see. > So... The first thing I would drop is the RESTRICTION to only use what > you've covered in prior sessions... Let the students read the language > reference manual, peruse the library reference manual, and allow them to > use whatever "advanced" techniques they are able to understand on their > own. Precisely. We kill the spirit of investigation by saying --- don't do anything I don't allow you to. This is pretty dangerous. I have a much better idea, I think. You have to give people a tool and say --- use however you want. If we don't want them to use things not introduced in previous lessons, we should give them a precisely-limited tool. But that's not done. The much better idea is to use such a limited language. There are such languages, made precisely for teaching. It comes with very little syntax and lesson after lesson it gets immensely powerful with very little syntax. > Granted you may have to restrict some features if [...] To let students use the entire language feels a bit weird in the sense that the group goes in so many different directions. It definitely put teachers in a position they have to be --- I don't know the answer. It is not my case. But I do think that holding a class with wildly different backgrounds, each going about in their own weird ways is kinda odd. It doesn't seem to bring people together --- on average. The better-idea brings people together by leveling everyone out. Unpopular languages give us this feature. Students hardly ever master them. It's a game nobody played. The rules are very simple. The implications are far-fetching. Sometimes even the programmer-expert in class realizes he is less skilled than the total-novice that never handled a compiler: his tricks don't work in the new game. (It's not that we don't allow him to use them. They're not there. They don't compile.) (We take Ghess players, Backgammon and Checkers players [the students], we teach them a new game, say, Go, and suddenly everyone is learning together. Assume Go is unpopular. It's very simple. Everyone learns the rules quickly and we spend the semester looking into strategies. Much better idea.) > For my Algorithm/Data Structure course (circa 1978), the instructor > allowed us to use any language /he/ could understand (so no SNOBOL). At the > time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma > Assembly, UCSD Pascal (not on the campus main computer, just a pair of > LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked > List". I chose to do that assignment using BASIC! In nearly 45 years, I've > only seen ONE real-world implementation of the HHMLL -- The file system > used by the Commodore Amiga. (Hash the first component of the path/name, > that maps to one of 64 entries in the root directory block; each entry > points the start of a linked list, follow the list until you reach the > block with the component name; if it is a directory block, hash the next > component and repeat; if it is a file block, the "entries" point to data > blocks instead of lists) Repeating my criticism with one more illustration. When ``there's always more than one way to do it'', students can't even count on their classmates to help each other --- because each one is doing a different thing. This is good in science, but what I like the most in schooling is working together and too much freedom like seems not very helpful in this direction. But both worlds is possible. Use a limited tool (which is not computationally limited, quite the contrary) and tell them --- you can do anything you want with this. The effect is that everyone, although everyone is more or less original, the different solutions are never too far apart, so all the exchange is quite possible. -- https://mail.python.org/mailman/listinfo/python-list
