some problems for an introductory python test

Hope Rouselle hrouselle at jevedi.com
Sat Aug 14 23:35:55 EDT 2021


Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

> On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle <hrouselle at 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.


More information about the Python-list mailing list