In theory, when the "big bang" occurred, the gravity was so intense that the light could not escape. (The gravity was more intense then a big black hole.) At some time later, when the gravity subsided, the pieces left that central point and moved out in all directions. Also, the more intense the gravity, the more time shrinks. Items closer to intense gravity will move faster than items much further away. To us, in our time, it may seem like 14 million years. But, much closer to the high gravity source, it would have been a longer time.

Isn't that what Apple tried to do with the Mac?

Remember, Bing Is Not Google.

"Carbonated Coffee"? Or have a Coke or Pepsi.

With var, we can write the code easier, but reading it in some cases is open to interpretation. It should not be necessary to look at a function call to see what it returns to glean the type returned that goes into the variable typed as 'var'.

Unfortunately, companies can't think of all the ways its software can be hacked. It must rely on the users and other nefarious players to find new ways to hack their software.

Similarly, no software is 100% bug free.

Or have the '?' at the end of the conditional then what falls under it is the answer:

if (x is not null)?
{
do_something();
}

we first ask if x is not null, then the answer would be to do_something(). This does make the language look more conversational. (Yes, this is going off the deep end.)

I have learned to agree with you on that. In the old days, I was taught that you write

int f(MyObject obj)
{
    int result = 0;
    MyObject2 obj2 = obj.FunctionA();
    if (obj2 != null)
    {
        MyObject3 obj3 = obj2.FunctionB();
        if (obj3 != null) 
        {
            MyObject4 obj4 = obj3.FunctionC();
            if (obj4 != null)
            {
                result = obj4.value;
            }
        }
    }
    return result;
}

Now I find it easier to understand when I write

int f(MyObject obj)
{
    MyObject2 obj2 = obj.FunctionA();
    if (null == obj2)
    {
        return 0;
    }

    MyObject3 obj3 = obj2.FunctionB();
    if (null == obj3) 
    {
        return 0;
    }

    MyObject4 obj4 = obj3.FunctionC();
    if (obj4 != null) 
    {
        return 0;
    }

    result = obj4.value;
}

This is easier to understand than having the code march off the right side of the page and removes exceptions to normal processing early on without cluttering the main part of the code. Since I write software application applications, I'm normally have these types of code where

Another offshoot of the brace wars.

Now I have a better understanding of the reasoning behind the brace wars back in the old C days. Whether to place the opening brace on the same line as the if/for/while/switch/function or on the next line. Most were of the next line camp and preferred it to make the code look more elegant and increase the lines of code. And also, it looked good if you had a 'pretty printer' utility for your code. But, when only having 25 lines per screen, that was limiting, and you wanted you screen real estate to be populated with meaningful lines of code rather than entry and exit braces fluff.

Be careful, he might decide to run for President. Remember that guy called Trump?

The software always lags behind the software.

Don't be fooled as we were with Windows Vista. Back then, XP was good enough for me, until after Win 7 came along.

The help was much better too.

Like playing solitaire with a deck of 51 cards.

(MAGA)

IMO, because doing something guilelessly makes a person appear to be a bad engineering example.

That is one reason I never liked to program in Unix. The Programmers wrote code that was that was terrible to understand, even for C programming. Compared to writing C for MS or PC DOS where the code was understandable. I can see why Unix has been called a "write only operating system" and why other coders who read someone else's code will call it crap.

Sad to say, C# is beginning to look more like JavaScript. The readability is lower and with more linq expressions, it takes longer to understand what the code is doing. For true engineering quality code, it should be more readable so there is less wasting of time understanding it.