On Tue, Jan 25, 2022 at 04:19:31PM +0000, Kyle via Digitalmars-d wrote:
> On Tuesday, 25 January 2022 at 15:47:12 UTC, Ali Çehreli wrote:
> > ... https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/...
[...]
> This is a good read, other than this paragraph:
> 
> "Other egregious deviations from standard practice were the number of global variables in the system. (A variable is a location in memory that has a number in it. A global variable is any piece of software anywhere in the system can get to that number and read it or write it.) The academic standard is zero. Toyota had more than 10,000 global variables."
> 
> I couldn't help feeling like the article was describing a particular .NET project my job has me assigned to.

Don't worry, it happens more frequently than most people would like to admit in "enterprise" software.  After having dealt with "enterprise" code for several decades, I do not have many good things to say about it. I often like to allude to one particular project I had the misfortune of being assigned to, where on one occasion I had to go through 6 layers of abstraction just to make a single function call -- one layer of which involved fwrite() of the arguments into a *temporary file* (yes, in /tmp/) and fread()'ing it from the other end of an RPC call.  (Happily, the component that that particular piece of code was in has since been trashed and rewritten from ground up -- without those egregious useless layers of abstraction.)

And unfortunately, "deviations from standard practice" are IMO not an accurate description of the industry; IME spaghetti code with tons of global variables and other code smells *are* the de facto standard practice in "enterprise" code, esp. those of significant size and worked on by large teams of programmers.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.

On Tuesday, 25 January 2022 at 15:47:12 UTC, Ali Çehreli wrote:
> On 1/25/22 01:53, rempas wrote:
>
> > people dislike global variables
>
> The situation is much better in D because I suspect what you call global is D's module-scope and thread-local.
>
> (Note: I don't want to argue whether thread-local by default was a good decision or not but I certainly take full advantage of the ease of thread-local variables in D.)
>
> So, module-scope variables are just fine: std.parallelism uses a default ThreadPool object, std.stdio functions use stdout, in this case a truly global object, etc.
>
> > When I have a variable that I must pass down to 5-6
> > functions, I find it much easier to make it global rather
> than having it
> > been passed in all the functions that need it.
>
> I've used that method once, which I mentioned at this point during a presentation:
>
>   https://youtu.be/dRORNQIB2wA?t=2946
>
> Both you and I realize that a module is an object and in our case there is a single object of it. That works.
>
> When you need more than one object (more than one context), then you move all those variables to a user-defined type and they become proper member variables.
>
> > global variables can mess me up
>
> Otherwise, as everybody else told, global variables can be very dangerous:
>
>
> https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/
>
Toyota, lol. I also had once to interact with software coming from them. It was surpzising to say it politely. It was a order system for suppliers of parts. The orders were tickets the suppliers had to scrape from a website. The very uncommon feature of the site was that it checked credentials (username/password) for the connection but didn't check if the client managed to read the ticket or not. Any read attempt of the tickets url would delete it on the server. The problem was that there was no "developer" server, only the real production server and I had to write the client software without losing orders as these were real orders of parts the supplier. It was impossible to negotiate with T. that there system was stupid. I managed to only lose 4 orders which amounted to several thousands of euros.

On Tue, Jan 25, 2022 at 05:10:40PM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Tuesday, 25 January 2022 at 15:47:12 UTC, Ali Çehreli wrote:
[...]
> Toyota, lol. I also had once to interact with software coming from them. It was surpzising to say it politely. It was a order system for suppliers of parts. The orders were tickets the suppliers had to scrape from a website.  The very uncommon feature of the site was that it checked credentials (username/password) for the connection but didn't check if the client managed to read the ticket or not. Any read attempt of the tickets url would delete it on the server.

And this, ladies and gentlemen, is a prime example of why the range API should not conflate .front with .popFront. ;-)


> The problem was that there was no "developer" server, only the real production server and I had to write the client software without losing orders as these were real orders of parts the supplier. It was impossible to negotiate with T. that there system was stupid. I managed to only lose 4 orders which amounted to several thousands of euros.

Ah yes, the good ole read-once-only system. It's starting to sound more and more like a legacy system inherited from the 70's or 80's where such weird practices were commonplace. Probably a 90's website bolted on top of a 70's legacy system, inextricably linked to the single production server so it cannot be cloned into a staging server but only works with the real one.  Wouldn't be surprised if the developers actually *worked* on the real server and don't even have a testing server to test their changes on.


T

-- 
Why have vacation when you can work?? -- EC

On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:
>
> So can someone make examples about how global variables can mess me up. I know that probably everyone here has more personal experience than me so I really want to learn why global variables are considered so harmful.

// ---

module test;
import std;

int x = 0;

void main()
{
    writeln(foo);
}

int foo()
{
    int x = 10;

    if(x) // ooh. you sure this was your intention??
        return x;
    else
        return .x;
}

// ---