Python doesn't wrap indices to a valid one. However, it does allow for negative indices which are shorthand for the length of the list plus that negative index.
>>> a = [1, 2, 3]
>>> a[3]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: list index out of range
>>> a[-1]
3
>>> a[-3]
1
>>> a[-4]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: list index out of range
That jumped out at me too, also an excellent example of where poking at a 'mystery language' rather than reading the documentation can lead to some really weird mental models (I'm reminded of myself trying to force a haskell program together until it ran).
On that note, how the hell would you understand currying or do notation by trial and error?
I wonder if they implemented one of their languages with true wrapping index behaviour.
But as @justinpombrio says, this is also tied to a particular pedagogy. The day after the homework is due, in class, we:
- collectively build up a classifier (programs that tell the languages apart)
- present the intended theory (our ground truth of what is going on)
and then spend the remaining time (30+ minutes) talking about which languages did those particular things, and — most importantly — why those languages did that, especially for the "weird" behaviors. There were often very good reasons for doing so, when viewed in a historical context. In this regard, I'm very much a historicist in the Kuhnian sense.
> I wonder if they implemented one of their languages with true wrapping index behaviour.
No, that was just me writing carelessly. None of the mystery languages use array indexing, and if they did we'd be careful to get it right. I actually know this behavior of Python, but didn't think about it much as I wrote.
> On that note, how the hell would you understand currying or do notation by trial and error?
It's not easy, but many of our mystery languages are harder than this, and our students figure them out! Sometimes they'll get 2/3 of the way to a solid explanation, and then Shriram gives them a canonical explanation in class the next day, while it's fresh in their minds. And sometimes they come to a perfect understanding by themselves.
And currying could make a good mystery language. Thanks for the idea!
"Syntax vs. Semantics: We are frustrated by how frequently discussions about programming languages revolve around syntax."
I couldn't agree more strongly. Syntax is bikeshedding and semantics is language design. My favorite example is the wholesale abandonment of M-Expressions by the early lispers. I don't know of any other (kind of) mainstream language community that has so wholeheartedly put semantics first. Maybe the ML family? Any other examples?
No, syntax is not merely bikeshedding, but endless discussions about it can certainly turn into that. I don't know what qualifies as "mainstream", but anything that sprang from the head of Milner, you can be sure, put semantics first. As, for that matter, did work from Dijkstra, Hoare, etc. Lots of good semantics work out there that has often indirectly had a huge influence on the mainstream.
I was engaging in a little hyperbole. Dijkstra has some compelling monographs on the value of choosing good syntax, it's true. You understood my meaning though as referring to the standard substandard discussion of the subject.
Yeah Dijkstra, Hoare, Knuth, Lamport, and friends are basically my heroes. Algol 60 is fine work. It has a very readable syntax. It's easy to see why it's even now used for scholarly publication. Hadn't heard of Milner though, any suggested reading?
Very interesting as a pedagogical technique. This was never included in the curricula in any of the programs I've taken, except in those that are explicitly designed as adversarial, but those were more from the security perspective. I love the concept of teaching "tinkering" and black-box investigation as part of fundamentals. Is this is an exclusively Brown thing?
A bunch of schools include CTF-type reverse engineering challenges as part of a course. IMO those tend to be a little more addicting as well, as there's the instant feedback that you have the correct answer.
If you know of other places that do it specifically for programming languages, using this kind of approach, let us know so we can study and attribute properly. Thanks. (In the 2012 PL MOOC that Joe Politz and I ran, we had CTF-style exercises, which are still on the Web.)
Note: CTF is a very different kind of thing than what we are doing here. In CTF, usually, there is some clear sense of a goal and you are (as you note) given a measure of how close you are, or at least told when you've Ced The F. In mystery languages, there is no well-defined end and there is no measure. Also, your job is not to break one thing, but rather to break the difference between multiple things. That kind of «differential reasoning» is its own separate sort of activity.
As an aside, real life often does not give you a measure or an indication of when you're done. Sometimes, maybe, you've set yourself your own goal (e.g., to steal a particular resource), and then you may be able to tell. But otherwise, especially when it comes to learning new things (like programming languages), I'd say this is a more authentic learning activity. Indeed, it grew out in part from my trying to reflect on how I myself approached a new language. So, at least, it's more authentic to me. (-:
> Also, your job is not to break one thing, but rather to break the difference between multiple things. That kind of «differential reasoning» is its own separate sort of activity.
This seems like splitting hairs. You could wrap this differential reasoning assignment in a function that returns true iff the outputs are different and achieve the same CTF-style behavior. The only difference here is that students get one assignment at a time instead.
Reductionist theories don't work out that way in practice, but sure: Build it, teach it, and then I'd be happy to talk about your experience and how the difference is only "splitting hairs".
Any chance you'd record the lectures like the 2012 iteration? Seems that the discussions are a big part of this pedagogical approach; and those are better captured through videos than notes/books. Also, the latest version of PaPL book doesn't seem to incorporate the mystery languages. Is there a plan to include them in the book?
I would love to record and publish the videos. However, the moment I do, I have essentially published the solutions to the homeworks. It's very hard to reuse them again. But mystery languages are really difficult to generate (especially with the additional constraints that we explain in the SNAPL paper), as there are only so many meaningful variations to go around. So, no.
You are very right that PAPL doesn't incorporate them at all. Part of the issue is the above. But part of it is also, now that I am getting really comfortable with this being a notable portion of my PL course, what becomes the nature of a "textbook" for such a course? I've struggled with this question before: I taught a (I think) really good software engineering course, but couldn't really can it into a book. I feel the same way about this now. But it means PAPL may end up being less a (half) PL textbook and more some other thing that is still being formed in my mind…
Python doesn't wrap indices to a valid one. However, it does allow for negative indices which are shorthand for the length of the list plus that negative index.