# Scope behaviors in Atom (Juno)

**URL:** <https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706>\
**Category:** General Usage\
**Created:** [September 16, 2020, 11:33am UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706 "2020-09-16T11:33:30Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![goodluck](https://avatars.discourse-cdn.com/v4/letter/g/65b543/32.png) [@goodluck](https://discourse.julialang.org/u/goodluck)\
**Post date:** [September 17, 2020, 12:08pm UTC](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706/17 "2020-09-17T12:08:35Z")

</div>

@jperla, official documentation [https://docs.julialang.org/en/v1/manual](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 `x` into and inside another code chunk `U` without having `x` contaminate `U`
- 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.

---

_[View the full topic](https://discourse.julialang.org/t/scope-behaviors-in-atom-juno/46706)._
