And yet LiveCode supports them, as do most of the world's great languages.
An English teacher I once had used to enjoy the irony of telling us, "Never use absolutes".
A more balanced recommendation might be:
Please use global variables mindfully - here's the reason:
Global variables are supported in most programming languages because they serve a uniquely valuable role. Yes, it's possible to abuse them, but abuse of language features is not limited to global variables. Any language feature should be considered in light of the task at hand to determine the best fit for the problem being solved.
First, it's important to note that Mr. Kenyon's article isn't titled "Never Use Global Variables", but merely "Avoiding Global Variables". The difference is important, as he never recommends LiveCode stop supporting them, nor has any engineer who's ever worked on the code base.
The four reasons he outlines there why globals may sometimes be problematic are good things to keep in mind, but with all due respect to the author his recommended alternatives are not without tradeoffs of their own:
Use Local Variables Instead: This is probably the best alternative, but requires a bit more code and a few extra clock cycles to execute. After all, locals are, well, local, so the only way to make their values available to handlers residing in other scripts is to write accessors for them, simple commands and functions to get and set their values. The execution overhead of calling a separate function or command is low enough that accessors are usually a very good alternative in those cases where globals may be problematic.
That said, if one has developed the discipline to write accessors as a matter of habit that same discpline lends itself equally well to using globals smartly in ways that avoid the problems outlined in the article to begin with. So while I often do this myself I see it almost as a wash within my own code; accessors don't really begin to shine as an unquestionable advantage until you're writing code designed to be used by others.
Use Custom Properties: This is so frequently recommended as an alternative, and so much less useful, even problematic, when compared to accessors or even just using globals directly, that it really merits very careful consideration.
Custom properties are very useful for binding data with a specific object, and esp. useful when persistence is needed. But for data unrelated to any specific object they require much more cumbersome syntax to use:
put the uCustomPropName of btn 1 of stack "MyArbitraryValueStore" into fld 1
vs.
put gSomeVal into fld 1
The persistence inherent with custom properties can be either good or bad, depending on the needs of the problem at hand. When used in a temporary stack that will only reside in memory and never be saved persistence is never in question. But when used in any stack that will be saved, you'll want to carefully consider whether the values it has when you save are the values you'll want next time the stack is opened, and if not you'll need to write additional code to establish the correct values on init. Not back-breaking, but once again anyone with the discipline to do that faithfully probably isn't having a problem with globals either.
Use Virtual Custom Properties: getProp and setProp are two of the most exciting features in the language, but their current implementation makes them almost unusable in a great many cases where you may not have complete control over message locking.
Calling them requires the same relatively verbose syntax used for working with custom properties directly, but with the added advantage of being able to overload or override what happens when those properties are accessed.
And like custom properties, they're ideal in code where there's a logical relationship between the value and the object the value resides in.
But there's a serious drawback to relying on those triggers: currently they're among the system messages blocked with lockMessages, so if any script has set the lockMessages to true at anytime during the sequence in which your code may need those triggers, they simply won't fire.
This introduces a scope management requirement not all that different from just using a global: everyone who writes any code used in an app that depends on getProp or setProp must at all times remain aware of when those triggers are needed, and make sure not to lock messages when they are.
Fortunately, in another thread here Mark Waddingham (for newcomers, the lead engineer for LiveCode) has expressed his opinion that getProp and setProp should be recategorized from system messages to user-defined messages, which would make them immune to any effects of the state of lockMessages.
But until that change is implemented (recommended in RQCC #226), getProp and setProp are exciting options but ones which require at least as much discpline as using globals well.
TL/DR:
Yes, globals need to be used mindfully to be used well, but so do most other language features. When used well, they provide a simplicity and performance that's hard to beat. Use them sparingly, but enjoy the freedom that LiveCode offers to choose them when they're a good fit for what you're doing.
There has never been a plan to remove them from LiveCode or any of the other hundreds of languages that offer them, and as far as I know they'll remain an option we can choose to use or not as we like in all engine versions going forward.
After all, the author of that article was a member of the LiveCode IDE team, and the LiveCode IDE uses more than two dozen globals.
