Local vs global scope again

This will not change. This is the backside of every great success and achievement, especially for complex ones. Try to think of this not as complains. It is an expression of great involvment for example, or what ever fits for you. Frustration will let you overlook the vast amount of triumph Julia is (admitted a bit of exaggeration :grinning:)!

On the other side I don’t see OP as dismissive. Not at all. It isn’t skepticism or criticism. All negatively annotated. It is just only another contribution to a public debate of a specific detail. This is science and development, it is never finalized.


Before getting into scientific computing and Julia I mostly did web development in JavaScript/Node.js. I would routinely get burned by some scoping issue (especially before they introduced let and const) that would take forever to track down. I don’t recall this ever having happened to me in Julia. On very rare occasions I have to stick a global in front of a variable name somewhere to achieve the desired behavior but, for the most part, I’ve found that scoping in Julia just works for me. So much so that I’ve never actually spent much time reading about how it works :blush:. In contrast, I read extensively on scoping in JavaScript because it was necessary to understand it deeply in order to keep from getting burned over and over :wink:


My apologies to all Julia core developers. I shouldn’t have vented here.
I do like simple rules (OCD?), but that boat has sailed.
Now it’s the time to get used to the way things work. :slightly_smiling_face:


It seems like the current rule is pretty simple…

1 Like

If you are referring to my post, I was talking about the student (and in reply to the previous post), not about the OP himself.

1 Like

All true, but this is setting up a false comparison: The non-REPL julia rules vs. a language without loops introducing scopes.

It is now 2 years since IJulia patched things to add the v0.6 scoping rules back in. How many issues have you seen in discourse/stack exchange/etc. on Jupyter scoping rules since then. I have seen zero. Literally none. I may have missed something, but it might actually be zero. Anytime jupyter it is mentioned in a quetsion/comment it is always the “Jupyter does what I expected. I don’t understand why running it as a .jl file doesn’t behave like jupyter”.

That doesn’t mean it is possible to immediately switch everything over to jupyter/1.5 REPL rules (as it is breaking behavior and there were legitimate tradeoffs which led to the decision for v1.0), but it suggests there was a previous design does have a coherent set of rules given the various tradeoffs involved.


I see, it wasn’t clear.
Looking back it was the quote of the students:

which was called dismissive I guess.
Yes it is, but they are strudents in a (probably) beginners course, and I guess, it was just said without so much thinking. It should not be taken serious by the words.

But OP point still is valid as a general point of view. And it should be explicit said, that this type of topic (OP) is always welcome, now and in future, because Julia must always develop further. There should never be a “it is now what it is forever so be quiet”.

To be clear: it wasn’t said, that OP should not be created. I just felt some bad tendencies, first when “dismissive” wasn’t clearly pointed to the quote “ugly”, second when I felt some kind of frustration with the topic in general.

1 Like

It was mainly a comment on the previous post, with just a side note on the student’s remark. I meant to reflect on the sometimes thin line between teaching skepticism and avoid being overly dismissive.

1 Like

I like the selected solution a lot: :bouquet: “snippet code” just works - no need to know/care about scopes, :bouquet: more involved code in files is “properly scoped” and :bouquet: there is a warning when there are ambiguities.

As a result one can learn about “the finer scope” at a later time (or maybe even skip it :relaxed:).


I don’t see a tradeoff between validating a student’s ideas and teaching them humility in how they weigh those ideas. For example: “You’re right that there are some advantages to the rules you’re proposing. However, there are disadvantages too, such as […]. In general, it’s wise to assume that design decisions are made by competent people based on carefully assessed tradeoffs. You can learn a lot by exploring some of those considerations, if you’re interested.”

1 Like

As I’ve pointed out over and over, the 0.6 behavior was a serious bug trap. Yes, it didn’t surprise people but it was also with regularity silently doing the wrong thing in non-toy programs, which is arguably much worse. People can’t file issues about a problem they don’t know they have.


Let’s not chastise the poor student for having an opinion that they didn’t even express in public.




I don’t see how this relates to my post, which was making a pretty trivial point, that though dismissing things is bad, healthy skepticism is good :man_shrugging:

I agree — we should be chastising @PetrKryslUCSD instead for bringing up scope again :wink:

1 Like

I think that’s out of the scope of this thread


I agree too. What I’m suggesting is a way of handling an objection to a well-trod issue that doesn’t involve re-surfacing the issue. But on second thought, I think your/Stefan’s suggestion of requesting a more detailed analysis is better, since it teaches the same lesson but with a more Socratic tone.

Just to clarify (in case the :wink: wasn’t enough): I was joking. We don’t need to chastise anyone.

I think that a lot of confusion happens because people think about Julia as a “new” language, imagining that it may be immature, with a lot of low-hanging fruits for improvement. So if some part of the language is surprising, it must be because its designers didn’t know better, and this is a great opportunity to enlighten them. This happens with scope, why-dont-we-have-OOP, surface syntax, etc.

This is somewhat understandable — after all, 1.0 is not that old, and Julia may be a newcomer in certain fields. But at the same time Julia is very mature: it has been around for almost a decade now, and builds on half a century of experience in programming language design. Various ideas have been tried, tested, and refined, and incorporated into the language.

It follows that changes to core features of the language need very compelling arguments at this stage. IMO this is the key point that should be communicated in these discussions: it’s not that the Julia community is hostile to any fundamental change a priori, just that the burden of demonstrating the advantages and, most importantly, how the proposal integrates with Julia is on the person making it.


Even though explaining the paradigms selected in Julia to badly-informed programmers may seem like a waste of time, it is a good selling point. Multiple dispatch made sense to me after a few days, while OOP never made any even after years of work. And looking at the code of other Julians, I think they share this opinion with me.


I’ve been using Julia since March 2019 and it took (and is still taking) some time for me to understand the design and how to best exploit it. I only figured out what multiple dispatch had to do with my life in the last couple weeks.

I’m still a badly informed Julia programmer and appreciate the responses to my novice confusion from the people on discourse. @zlatan is right about sales and marketing. When students in math ask if they should think about moving from Matlab to Julia, I can tell them that the learning curve is steep but that the community is helpful.

To stay on topic, I got burned so often by scoping inside the REPL vs outside that I have become ultra conservative. The new changes may protect me from some REPL errors, but won’t change my scoping phobia overall.