@jperla, official documentation https://docs.julialang.org/en/v1/manual is not so good wrt the scoping rules. the prose is not clear. it contains seemingly contradictory info. at one point it says
This eliminated the notion of soft scope…
but it would seem that soft scope still exists… it would be good for the up-to-date documentation to only describe the present functionality. if needed, a discussion of past functionality and contrasting it with the present, should be placed in a totally separate document and linked-to from the current main documentation.
in general the prose is unnecessarily longwinded, talky, musing, joking (sarcastic?).
but most importantly, in the end, it is far from clear why the current (soft?) scoping rule exists. other than
- a facility (as explained in this forum) for being able to paste-insert code chunk
xinto and inside another code chunkUwithout havingxcontaminateU - not having to bother about forgotten variables further up in a long script (as explained in the documentation)
… other than this, no reason, subtle or not, is offered.
if a subtle but substantial reason does exist, im very interested in knowing about it. maybe it will turn me into a staunch advocate of the rule. i am no rocket scientist but i do have a msc in computer science.
as it stands, the counter-intuitive and (to me) bothersome soft-scope remedy seems to me to be much more problematic than what it “fixes”: if you paste-insert code chunk x into code chunk U, it should be highly intuitive that x will contaminate U and that it is in that situation that it is reasonable to expect that a little mechanical effort be expended by the programmer/user, eg. by converting x into a function. as to “forgetting” about variables further up in a script, you have the parser to kindly point those cases out to you.
btw, before encountering the scopes chapter, i was actually impressed by the clarity, simplicity, brevity of the documentation. scoping should not be an “advanced” or subtle subject, neither intrinsically (=> leads to poorly designed code and/or code that is hard to maintain) nor because of a confusing documentation (=> leads to poorly designed code by those who do not abandon julia entirely). i am now reading the types chapter, and once again, i think this chapter could also be tightened, maybe contain half or 1/3 as much text. the chapter’s introduction seems to me to be more of a treatise on cs principles rather than a hands-on practical guide for non-programmers or beginning programmers. but experienced programmers also do not need that discussion, in that prominent place. if needed, it should be placed in a separate document and linked-to from the main documentation. however, the not-so-straightforward language continues through the whole chapter.
please consider my criticism as constructive. i like julia a lot and i hope for it to take off seriously. for that to happen, every friction should be eliminated as soon as possible. as a closing remark, i do not understand the commitment to backwards compatibility; there are many ways to honour that in practice for previous users and programs, eg. by feature/behaviour-freezing the current version into a new maintenance-line of future versions. only from a resource view point does it make sense not to offer two version-lines (“maintenance” and “new-feature”) but if the cost is a stagnating adoption-rate, is that a rational decision? from a business-model point of view, adoption-rate should be the most important KPI, by far.
personally, i think i can live with the quirk, for now.