Chris Angelico <ros...@gmail.com> writes: > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote: >> >> I totally agree with you but I didn't know that even numbers were like >> that in Python. In fact, I still don't quite believe it... >> >> >>> 2.__add__(3) >> SyntaxError: invalid syntax > > Yeah, that's because "2." looks like the beginning of a float. > >> But then I tried: >> >> >>> (2).__add__(3) >> 5 >> >> Now I do believe it! :-) Awesome. I had no idea. > > You can also do it this way: > >>>> x = 2 >>>> x.__add__(3) > 5 > > But don't teach this; it ignores several problems.
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. [...] >> (*) More opinions >> >> So, yeah, the idea of a course like that is to try to simplify the world >> to students, but it totally backfires in my opinion. There is so much >> syntax to learn, so many little details... We spend the entire semester >> discussing these little details. > > Agreed, and if you try to teach all the syntax, you're inevitably > going to get bogged down like that. Indeed. >> I posted here recently a study of the semantics of slices. When I >> finally got it, I concluded it's not very simple. The course introduces >> a few examples and expects students to get it all from these examples. >> I would rather not introduce slices but teach students enough to write >> procedures that give them the slices. The slices are the fish; learning >> to write the procedures is the know-how. (I'm fine with even teaching >> them how to write procedures to add or subtract numbers [and the rest of >> arithmetic], although none of them would find mysterious what is the >> meaning of arithmetic expressions such as 3 + 6 - 9, even taking >> precedence of operators into account. That's syntax they already know. >> If we teach them the syntax of procedures, we could be essentially done >> with syntax.) > > A language like Python is useful, not because every tiny part of it is > easy to explain, but because the language *as a whole* does what is > expected of it. Toy languages are a lot easier to explain on a > concrete level (look up Brainf*ck - it has very few operations and > each one can be very simply defined), and that might be tempting in > terms of "hey, we can teach the entire language in ten minutes", but > they're utterly useless for students. Sure. I would never use a toy language like that. I think we need a compromise --- some syntax, but not too much; in fact, just a little bit of syntax. For instance, could we do away with slices? We could. If we learn one way of looping, we can build slices with procedures. This is a good opportunity in fact --- it will show students how slices really work and how to get what they want with it. (Then towards the end we could give out a lecture for anyone interested in Python --- ``while we didn't show you how Pythonists usually write, here's a few things that Pythonists would do that we didn't do in this course...'') > Instead, my recommendation would be: Entice students with power. > Pretend you're teaching some aspect of magic at a wizards' school and > make sure your students feel massively OP. Sure, they might not > understand what makes those cantrips work, but they know that they DO > work. You can have students casting print calls left and right, doing > complex incantations with list comprehensions, and even defining their > own classes, all without ever worrying about the details of how it all > works. Then once the "wow" is achieved, you can delve into the details > of how things actually function, transforming progressively from > "wizardry" to "science". I really like that, but I would predict that, in a typical university, professors are not really willing to go that way. Everything has to be extremely simple --- and a mess is made in trying to achive that. (In a sense, professors are all failing terribly. They're lucky that nobody is giving them a grade based on how effective they are as evidenced by the facts, however such thing would be done in practice if one were to take it seriously.) > And to be quite frank, a lot of code IS magic to most programmers. Definitely. You guys are showing me so much Python here that I've never seen --- which I expect, because I'm only paying attention at Python now since I'm conducting students through a course that's using it. (I admire the language, but I never used it in any project on my own. I probably would if I were not in love with other similar technology.) > Which isn't a problem. Do you REALLY need to understand how your CPU > does register renaming in order to benefit from it? Or do you need to > know every detail of the TCP packet header before using the internet? > Not likely. Not at all. (Although, of course, we like to know these stuff.) > Those details hide away under the covers, and we make happy use of > them. There's infinite knowledge out there, and you - and your > students - are free to dip into exactly as much as you're comfortable > with. ``A man after my own heart.'' -- https://mail.python.org/mailman/listinfo/python-list
