I have taught absolute beginners (other languages) and is indeed not really that difficult to introduce scope to them in a way they understand IF you can do it at the appropriate time (i.e. when introducing functions), and if it is a the version of scope as implemented in any other language:
You generally start with operators, variables and loops. Assigning something to a variable and then doing something with it in a loop is an extremely common pattern (I am convinced, even without checking, that the v1 change invalidated code in the majority of pre v1 tutorials). Having to explain that they have to use global to access the variable right in front of loop (for no apparent reason) is going to be difficult. The easy place to explain scope is functions: you have a separate piece of code that you are calling from another location, so there it is logical that the variables are contained to that part. You are also giving the values from your current location/scope needed by the function as parameters. One of the worst things of v1 scope then is that at this point you are going to have to explain that what they learned in the beginning (putting globals to get at the variable in front of the loop) does not apply if you put it in a function.
Some of the other suggestions here are even more complex and difficult to explain than v1. In my experience, if I start needing a lot of exceptions and lengthy explanations, I am usually on the wrong track (KISS principle). The original proposal by @jeff.bezanson is simple and consistent, and poses a very limited amount of incompatiblity.
Adding my 2c to the teaching discussion, particularly fresh since I’m just wrapping up teaching an intro computing course for biologists in python.
My experience is that students, esp in an intro course, will take a lot on faith. All the syntax they’re learning is new, all the concepts are new. If you tell them that for is spelled global for, they’ll do it until you tell them to do otherwise. No one asked for example why it’s print(string) but string.split().
For the particularly curious students you can say, “great question - it’s not critical that you understand right now, but Google ‘scope’ if you’re interested in learning more, or stop by office hours.”
I don’t have a strong opinion on the underlying merits of the different ideas. I got bit by this early in the transition, but adapted quickly. Given how great the language design is generally, and how much time the core devs think and reason about the decisions0 (a fact which has become even more glaringly obvious in the last 6 weeks teaching python, which I used to think was fine), my inclination would be to trust the reasons for the design as implemented. More informative error messages are always great of course.
Late to the party here. I just want to add some importance to the quote above. Packages are not the only things imported, datasets too. Big data analysts need to import data of 10G or even 100G into the memory; it will be a nightmare for them to keep restarting the program.
This hasn’t changed and has always behaved like this; do syntax is just shorthand for passing an anonymous function to a higher order function. (Your code also doesn’t make much sense as far as I can tell—which m is supposed to persist outside?)
Now that the debate seems to be cooled down, I would like to say that, when the devs feel that they have a clear roadmap and are confident with the eventual solution, I would love to read a blog post or some other kind of document explaining this point, and what we can expect in future versions of Julia, even before the changes are implemented.
Ideally, with hints for people who develop teaching materials, about how the issue might be approached to avoid misunderstandings.
I think that this will help to have users prepared for the changes, and will make the transition less messy.
I’ve come up with a different solution that is non-breaking and solves the issue less drastically while retaining the benefits of the current design. I will write it up in a new thread and link to it from here.
Let’s try to keep the conversations around this topic organized — the latest discussion is happening in the New scope solution thread. I’m going to close this topic in favor of that one.
I will delete this message too to not spoil this topic…