Snowstorms in New England are notoriously hard to predict
Yes, NYC, Melbourne, and Tokyo all get considerable research attention from meteorologist because they are notoriously hard to predict.
.... lead or follow it in EXACTLY the same orbit. That would be a feat of orbital mechanics never before achieved.
The GRACE mission has been doing it for a few years now, tiny fluctuations in gravity can be inferred by the change in distance between the two probes. However it's not a geostationary orbit, just one probe following the other in low orbit. Personally I think it's a genius idea to turn the problem of keeping two probes in sync into a highly accurate gravity probe.
You do understand that Pascal was first released in 1970, right? Many Pascal programmers in the 1970s asked the same question - why do we need C, with its dangerous string handling and obtuse preprocessor, if it doesn't solve any new problems?
Um, you realize that C came out at almost exactly the same time, don't you? Granted, I wasn't programming anything in the 1970s, but I know enough history to know that the Unix kernel was already being ported to C right around 1970.
I like the End-X style, such as VB's, because if the nesting gets messed up due to a typo, End-X carries info about which block ender went with which block starter. "End While" goes with "While", obviously, not an IF statement. Brackets lack this ability.
"Lacks" is a strong word; it's just not inherent. Back when I used to write software in C and C++ for money, I would religiously put "}//end if" to make sure I could keep track of which braces went where. If I needed even more context, I would put " }//end if(var1 == var2). It's not that hard. Like many things in C, you have plenty of rope to hang yourself if you really want to, but you can also make it tidy and sensible if you care to. C is not your friend, and is not your enemy.
C is like an M1 rifle. Sturdy, proved in battle many times over, occasionally finnicky, and ready to put a high-powered round precisely where you aim it without apology. Whether you aim at your foot is your business.
C++ rewards good design but brutally punishes poor designs.
You hit the nail on the head, somewhere in the early 90's, language vendors stopped claiming "Our language supports OO concepts" and started claiming "Our language is OO".
The first C++ compiler I used professionally was Wacom's (circa 1991). Back then the Watcom C++ extensions were not part of the language, they were implemented with a bunch of C macros pulled in with include files, the macros themselves were riddled with goto (another macro) statements. I still have nightmares....
The fact is any general purpose language can be used to implement an OO design because OO is not about language features, it's a design methodology, or at least that's what I was taught when studying for my CS degree in the late 80's. As my smalltalk lecturer pointed out at the time, most of the examples in K&R's "The C language" are also great examples of OO design that were written long before the term OO was invented.
Disclaimer: These days I spend much more time tying spaghetti balls with different flavoured source together than I do trying to untangle the individual gordian knots.
Cannot fathom why your post id marked redundant, OT maybe, but redundant?
Maybe they don't get the 'lazy evaluation' part if they've never dabbled in functional programming
"Lazy evaluation" is an optimization technique for evaluating Boolean expressions, I've never heard of a programming language that doesn't use it by default
Here's a random conundrum for you - why is February the hottest month in Melbourne when the summer solstice in is December?