Back in the 1970s I worked at a computer manufacturer, writing code for their product's instruction set in assembler. The computers were designed and built around AMD2901 bit slices. The hardware guys implemented the instruction sets using microcode and, as the computers got bigger and more complicated some of the instructions got so elaborate that programmers found ways to do an operation faster using a few simpler instructions instead of one complicated one.

Nowadays, with the kind of speedups from using cache memory, branch prediction, and so on, I reckon it could be a whole different ballgame. I suspect though, that proving correctness might become the most important criteria, and simpler would make proving correctness easier.

The Concorde also had a sonic boom which limited the airports it could fly to. (Competitors may have exaggerated the problem, but I do believe it was a problem.)

I'm not a C++ programmer. But I have come across situations where people seemed to deliberately use weird, obfuscating stuff just so nobody else could take their place, (I particularly remember a company where somebody had convinced management to use UUCP instead of FTP for internal data xfers because it was more secure. When I was being interviewed on the phone they asked me what I thought of UUCP, and I think I was one of the few people they interviewed who had even heard of it.)

So, if C++ is as complicated and full of stuff as I keep reading about, I can see how somebody might deliberately cultivate for themselves a set of esoteric off the wall constructions that they'd throw in their code just so nobody else could work with it, all the time selling management on how 'good' it was.

"Life is a learning experience, so break out the reference manuals"
That's fine if you're a student. I've been in situations where I was working for a small company and I had to fix problems for the company quickly so they could bill their client and make payroll. If C++ is supposed to be a bunch of languages rolled in to one, then, the code should be flagged, "This is C++ as a functional language, only people who know all the functional stuff should use it, or be hired to maintain it in the future, and don't stick in anything of exotic flavors X, Y, or Z from C++ in it". Or, if the company was serious about doing the product in a functional way, one could use Haskell or Scheme or whatever in the first place."

NOW, after my moderator points have expired, somebody posts something I would want to mod up!

From my own experience, when I had really difficult, gnarly problems, the code came out really clean at the end. The bugs came when I was least expecting them with stuff that should have been a piece of cake.

I think it might be a bit like what somebody once told me about private airplane pilots. Statistically, accidents didn't happen the most when people were novices, but after a certain number of flight hours. I don't remember exactly what they were. Actually there were 2 peaks, for the sake of argument I'll say that one was at 2000 hours and one at 8000 hours flight time. An interesting phenomenon.

Hear Hear,
I generally use vi myself, though I've actually forgotten some of the fancier stuff. I even have some muscle memory for emacs which I acquired because I had an Atari 500 ST back in the 1980s. Having cut my teeth on old glass teletypes (Uniscopes, Hazeltines, and even genuine VT-100s with the gold keys pad) I needed a basic term window and text editor for my Atari. The best text editor for the Atari that I could find on Usenet in the old binaries groups was 'Micro-Emacs', a very stripped down version of emacs, but in using it, my fingers learned CTR-E to go to the end of a line, CTRL X 2 to split a screen, etc. It's because of that that I still use emacs sometimes for very basic stuff. (I always install the -nox version). Heh, back in the 80s, I knew if I was on a fast computer at work if I could use emacs and it was responsive, which made Micro-Emacs, running on my Atari so well, all that much more impressive.

IANAG (I am not a gamer). Also, I did not RTFA, but I did read the summary, where it explicitly didn't comment on the game itself, but on 'poor behavior'. I think there's a difference.

Ah, this is getting off topic, but your comment raised a question in my mind. Suppose the light is blue shifted for an observer approaching it so that it does have the energy to form an electron-positron pair, but for another observer not approaching it as fast, it doesn't have the energy. Might one observer see the pair formation while the other did not?

Could the encryption be in the form of a one time pad? Then it would be 'unbreakable'. Perhaps there could be several one time pads, and only when all of them were brought together would the data be decodable.

Ultimately, the only suggestion I saw, including suggestions on the site, that would be as inviolable as the laws of physics, is sending the message in to space as electromagnetic radiation to a place where it would be echoed back. But first you would have to have something in position to do the echoing, so that won't be practical for a long time.

All the other methods depend on the world not changing too much. Governments, laws, and institutions remaining stable, Encryption methods not being cracked. Using a satellite in a far elliptical orbit would work with present technology, but if the message is supposed to be kept for 50 or 100 years, technology might catch up and the satellite be retrieved sooner than the originators wanted.

Despite being on the Internet for a pretty long time (I made my first post to Usenet in 1984) I only have a hazy notion of what Facebook is. I've heard about it, and in googling and stuff actually been on Facebook pages of some sort I think. I say this to establish my credentials as NOT being a Facebook fanboy.

Nevertheless, I've heard that in other countries when there were revolutions and stuff going on, people used Facebook to rally and organize. So give the devil his due. (Or am I getting Facebook mixed up with some other social media thingy?)

I got my intro to programming in the mid 1960s with 'the college computer' a PDP-8 that we programmed in Fortran using punched cards. In those days, just getting access to a computer was a pretty big deal, but things were changing, so 'programming paradigms' started appearing, and the first one that I remember was 'structured programming'. This is where I first heard the mantra of 'goto-less' programming. (Before that, the mantra was not to write self-modifying code, which was something you almost had to be writing assembly language code to be able to do, though COBOL had an 'alters' statement as I recall.)

I remember being somewhat startled by the idea of excluding gotos. How could you write non trivial code without any goto statements? I actually thought of it almost as a challenge to figure out how to do so. The opposite of structured code was 'spaghetti code'. Anyway, it's become a conventional bit of wisdom that I suppose is just automatically passed down to each generation of students without anyone ever seriously questioning it, except those who find they really need it sometimes. At some point I started defiantly putting an occasional goto in my code again, but not often.

Aargh, you're right, my bad. My brain must have cross-connected with something else.

My apologies.

A discussion of decision making algorithms for various situations is a reasonable topic, but using the word 'kill' with respect to what the robots should do was bound to provoke responses the kind of responses the author is bemoaning.

I used to write drivers for hardware a looong time ago (disc drives, UARTS, that kind of thing.) I realize that these graphics cards are way more complicated and trying to squeeze every last ounce of performance out of them can be a lot of effort. (I can remember spending a day trying to save a single instruction inside a device interrupt, and those were relatively simple devices.)

Even so, eventually you can't just kkep adding people to a project. If the concepts are well known then you get some decent programmers to do a workmanlike job of writing the software. If there are still areas of research and black art, then you need people who are initiates in the black art. So, I'm just curious, how many people, and what kind of skills, are involved in creating good drivers for this hardware, and, when a new piece of hardware comes out, how much new stuff is required to make use of it?

Why worry about this kind of stuff when so much worse is going on? Maybe it's a good way to practice for the bigger stuff. Somebody starts out fretting about overdone 'intellectual property' for their favorite movie, then later, they're ready to take on something bigger. (Or maybe they become jaded and cynical and ask 'why bother', who knows?)