I looked at TeensyMud and there's one global, and it's only referenced in the line after it's defined.
Doesn't even need to be declared. Of course there are quite a few ruby built-in globals.

However, all locals in ruby are globals including those on the stack (other than immediate values).

Check this out…

def afunction
  a = "xyzzy"
  puts a
  change_local_a
  puts a
end

afunction

$ ruby globals.rb
xyzzy
plugh

Function change_local_a
Spoiler

And if course all automatics in C are allocated on a global stack and can also be accessed from anywhere in your program.

And that just summed up the entire thread. There shouldn't be need for further discussion, right?

I'll sum it up a different way. It's purists versus pragmatists. Conditioning versus critical thinking.
You don't need to do any thinking to regurgitate the children's stories that may or may not have been taught in
CS 101(?) like "Globals are bad" or "GOTOs are bad". Advice to newbies aren't commandments for experts.

Some people have to code with these on and think everybody else should too.

Some people don't.

Some people like to troll. Other people like to make nuanced arguments. Nobody has said that every single usage of globals in the entire world is bad. But it's much more fun to make it look like they did, so you can post cutesy kiddy pics.

Anybody who's paying attention to this thread and behaving in good faith will see that even those advocating against globals have identified cases in which they're useful.

Well, I consider you a good developer and TeensyMud to be well designed. So maybe new developers should follow your lead?

Of all the vast majority of the coders in the MUD community that I've encountered over the years, very few would I consider to be expert programmers. Most started learning to code after playing MUDs and have little or no programming experience/formal instruction outside of hobby MUD development. That's just my experience.

I'm willing to bet my experiences reflect the general MUD community pretty well. So, recognizing the specific brand of programming we're (that is, us MUD developers here on Mudbytes (!!!)) dealing with, let's try not to drag an equally common regurgitation of a less relevant issue into a thread titled 'global variables'.

..and by 'us' I mean Tyche. "Don't use GOTO's" and "Avoid overusing globals" are called heuristic rules. In case you missed English on your way over to CS-whatever the hell you failed, heuristic could mean a common sense rule or set of rules intended to increase the probability of solving a problem. Kind of like the opposite of what your posts seem to do. Heuristic could also mean of or relating to a general formulation that can help guide investigation. Like letting newbies know in their welcome post that – to get the best help with problems – they should post language specific questions in the languages' respective sub-forum and avoid or ignore Tyche.

The previous situations described, like any heuristic guidelines (the GOTO rule, global namespace pollution) will obviously have exceptions. If you program enough and gain a suitable working knowledge of the language and the compiler, you're bound to discover situations where the optimal solution is putting something in the global namespace. Hell, if you do a lot of coding, and really have an understanding of what's going on, you might find a good place to use GOTOs.

Similarly, if you frequent Mudbytes diligently for a long enough period of time, you might see Tyche post something constructive.

Still, the point remains, that case would be the exception - which is why we call them heuristic rules.

Damn assembly language…amirite?

Why all the Tyche hate?

Well, Tyche is a notorious troll. I'm not sure hate (if that's really what you'd call this) is entirely warranted in this case, but with his reputation what it is, yeah….

Tyche is not a troll. If he was, he would have said something like:

You must be new here, Vigud…… oh wait. :wink:

FWIW, that is a distinction that adds little, because for all practical intents and purposes a file-level variable that other compilation units can see is pretty much as "global" as "global" gets.

It's not that Tyche isn't good at what he does. Of course he is. He occasionally even shows it. It's that he finds it more interesting to rib other people and contradict them even when his own code supports their position. He also finds it amusing to crassly distort their position so that he can make fun of it.

I'm not hating Tyche at all. He made a point of trolling (me specifically) in some threads I've recently posted in. Having invested a bit more time and thought into my post in this thread, and considering the significance of issues like non-locality in collaborative-natured projects, I wanted to express my appreciation for his excellent troll of this thread and extend my gratitude for his contributions by responding in kind.

I don't want to lead you all on or seem pretentious though - the unfortunate truth is that I've squandered my time away writing, testing and debugging source-code instead of diligently practicing my trolling technique, so I humbly accept the fact that my troll is likely a sub-par piece of work typical of an amateur lurker. I can only hope Tyche finds my post to be as constructive, insightful and amusing as I found his.

I think if we go closer to the core of the problem it is IQ (problem solving ability) vs Creativity (ability to associate).

People with low creativity have difficulty creating and comprehending complex associations, however, for everyday life it's totally unnecessary to be creative if you follow the golden rule: Whatever your highest authority says goes (Jesus, Hitler, Oprah, etc). Wikipedia follows the exact same guideline, and it works remarkably well (in most instances).

I'd offer solutions, but if you really think about it (associatively), a true solution to the problem becomes increasingly elusive, unless of course you kill all dummies and robots, but that'd be too pragmatic to be acceptable.

QFAbsurdity

see scandum like globals too so why are we even arguing lol

You've been conditioned to behave in accordance with the idea that your mind and thereby your brain and thinking are your highest ordered faculties whereby you conscientiously act and consequential to that condition you are constrained to experience life through only the faculties and modes of perception you are capable of commanding thoughtfully.

The truth is - thinking is thinking is thinking - and 'critical' is subjective. I say you're argument is glib, like the teenage girl who disingenuously steals a sense of belonging by conforming to the views of non-conformists or the rebel who preaches anarchy to soldiers marching in orderly, single-file lines.

If all your critical thinking has to offer is pervasive dissension among your peers and dissociation then I will - without thought - forgo any endeavor to operate thusly.

On the topic of globals, they say in Asia - don't believe everything you think.

I can't believe we're getting into the zen of global variables now… Have we no lives?

One aspect of the question we haven't touched upon yet is audience. If I code as part of a team, or with future coders in mind, I am much more likely to produce readable and modular, even if longer, code. Globals are definitely a sign of a "first draft," as Runter has already suggested. In my case, I fly solo 99% of the time, and never really write code with sharing in mind, although I do end up sharing some of it. Knowing that I'm likely to be the only audience makes my coding style a lot more relaxed and goal-oriented–the fastest solution to the problem becomes the best solution.

But I can totally see how someone primarily interested in writing codebases or accustomed to coding in a team would shy away from globals. In the context of teamwork, it is definitely "best practice" to limit the use of globals as much as possible, and that's what's taught in schools which aim to produce good team players.

There's nothing wrong with establishing best practices for coding teamwork, knowing full well that in the real world everything can and will fall short of the ideal. Resources will be limited, deadlines will be impossible, etc. That's why I'm sure that even in the best of coding teams, globals come up. And why not? They are a tool in the toolkit.

No, we're not. I'm highlighting the point that - prior to posting - I think anyone with half a brain can ask themselves (a) what is the question? (b) what is the context? © is my response helpful? without cluttering an otherwise decent forum with needless babble about trivial issues like 'pragmatics vs purists'. What I said in my last post is probably true. Is it -really- at all helpful? Does it belong here?

That's nice of you to say, but which lead? This one is full of globals…
http://sourcery.dyndns.org/svn/rocketmud...

TeensyMud was written following "The Ruby Way". It's full of object model meta-programming, AOP code injection, and indirection. You've got to be at least an intermediate Ruby programmer to follow along. Here's the problem. If a design is so "language centric" to be pretty much non-portable, is it really a good design?

OTOH, pretty much any programmer with a language or two under their belt can pick up and follow RocketMud and CoralMud.
Isn't the global $player_list more accessible and less opaque than Engine.instance.world.connected_characters?

What? I don't see you having outlined any problem. You do seem to drag in a lot of heavy terms without any real indication of why. Reflection and indirection are both very common, especially in object-oriented languages and I don't understand how utilizing those features of a language is a problem. Aspect-oriented programming can cause problems for new users reading your code if they are completely unfamiliar with the concept or if you aren't documenting well.

void readpost…(…) {
    // there's a new post from Tyche
    // read the post and realize it's a troll
   // bang head because its a troll
    Mudbytes.reply();
}

void readpost…(…) {
    // there's a new post from Tyche
    // it doesn't look like a trolll
   //  further review & it looks like a troll
    Mudbytes.reply();
}

void readpost…(…) {
    // there's a new post from Scandum
    // throw an exception
    Mudbytes.reply();
}

So I'm constantly calling Mudbytes.reply() from my readpost() function. Let's save time.

after() : readpost() {
   Mudbytes.reply();
}

pointcut readpost() : execution(* readpost*(*) ) && this(MyMudbytesClass) && within(some.ForumHacks.*);

Now I can write it like this

void readpost…(…) {
    // there's a new post from Tyche
    // it doesn't look like a trolll
   //  further review & it looks like a troll
}

and my nifty little AOP preprocessor calls Mudbytes.reply() every time it reaches the pointcut I set (every time readpost is called).

This is not really a different paradigm. It's more like a tool that can be used with object-oriented programming. You're asking if the use of these things is a problem? What a silly question. Almost anything can be abused in code: you can abuse data encapsulation, you can abuse inheritance, you can abuse globals. If AOP is efficient for the specific job and you have no constraints regarding your 'audience', why would it be a bad design decision? If you like looking at your code in more cohesive, modular units without the clutter of whatever the hell they call it… crosscutting? ….. I don't even know why you asked.