[jstimpfle]

> Often, because the assumption that it can exist only once is wrong; this is particularly true of instances of some descriptive class of interface to an external hardware resource, which covers all of your examples.

The key here is how to understand the word "can". It's "only" a design decision! Of course you can do almost anything on a computer. However, most programs don't make sense with two sound modules or network modules or graphics modules. So "can" here means, "it absolutely makes no sense, and I'm never realistically going to instance two or more of this thing". (And if I really want to do that later, 1 in 1000 times, I'll just edit the code).

> it usually isn't the whole difference between the desirable modular code and the bad global-using code that should be made, and quite often if you aren't writing it as a global resource in the first place, you never make the other wrong decisions that would need to be changed.

Give an example: I don't think there are any. I can easily give you some bad things that happen when avoiding globals to represent static resources: Much more input and output arguments to type. Then, the syntactically ugly, useless, meaningless Singleton. I've seen it many times, and it is the best proof that it made no sense to avoid the global in the first place, and it even potentially leads to nondeterministic initialization.

And more importantly, an occasional reader has a much harder time browsing through the code because she never knows where the local variables are pointing at.

[loup-vaillant]

Most VR games make sense with 2 displays (Headset + screen), and 2 sound systems (binaural for the headset + stereo for the audience). You'd likely know that from the outset, though.

[jstimpfle]

Yes - and for each of these examples, there would likely be still a single "object instance" managing these devices (e.g. "Display" module). Or two entirely different modules ("Headset" module + "Screen" module), again each having only a single "instance".

The concept of instancing is inappropriate to most situations. The things that we have more than one ("dynamically many") instances from are typically dead data, but then again these are typically managed in a single pool. (That's "tables", again).

[loup-vaillant]

> The concept of instancing is inappropriate to most situations.

At the application level, maybe. At the library level, this can easily kill reuse. See Lex/Yacc. They used to assume a program would only have one parser. Then some naive developer tried to parse both JSON and Lua tables in the same program. Oops.

Another example: standard libraries (including home grown ones). They instantiate everywhere: arrays, hash tables, file descriptors…

[jstimpfle]

Sure, there are exceptions. The other side goes the same way: If it's not a static resource, don't make it a global...

> arrays, hash tables, file descriptors

Most arrays / hashtables in my own use are actually static resources as well...

File descriptors, same thing. They are (or correspond to) a process-wide resource managed by the OS. Most maintainable way is to manage them in a global pool.

[loup-vaillant]

I feel we are not talking about the same thing.

There's no question you instantiate a substantial number of arrays and hash tables in your program. Maybe most of them are global variables, but you still spawn several instances of arrays and hash tables. You do not have a single giant array and a single giant hash table, you have several of them.

Same thing with parsers. Lex/Yacc used to allow only one parser of any kind in the whole program. But if you want to parse 2 languages, you need 2 parsers. Of course, you'd need only one parser per language, and perhaps those two parsers parser's state will be stored in global/static variables. You still instantiated 2 parsers.

At least that's how I understand "instantiation".