Ace17

"But ophthalmologists aren’t worried. The blue light emanating from the sun drastically overpowers any rays coming from your screen. And so far, all of the research on how real human eyes react to blue light has failed to link screens to permanent damage of any kind. Blue light’s most concerning effects still seems limited to sleeplessness."

OK, so what else is there to learn?

How will you be able to trust such generated code? What if you forgot/mistyped one of your tests?

The intent of the author is not very clear.

Of course there are duplicate features, that's an obvious downside to keeping backward compatibility while still allowing improvement.

If two equivalent/overlapping features were introduced in the same C++ version, then, yes it would be an indicator of a faulty design process.

> You should just assign a different compression factor to the chroma channels instead [of subsampling chroma].

The good news is that we don't need to change the H.264 standard for this.

Supposing that:

- most of the already deployed embedded H.264 decoders support 4:4:4 profiles

- non-chroma-downsampled input content is available

Then, it's only a matter of changing encoder implementations to do exactly as you say.

If your tests:

- run fast (<10s)

- run on your local machine

- run on your local code (including uncomitted diffs)

... whether they're called "integration" or "unit" tests doesn't matter, as they will detect regressions at the earliest possible time.

Unit tests might guarantee smaller code search area (because maybe the failing test only executed 1% of the code), but if running "git stash" makes all the tests pass again, I have a pretty good confidence about where the error lies.

> About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout.

It's the same for almost all hardware: graphics cards, sound cards, all use their own register map (which, to make the matter worse, is often kept secret). Even USB stuff, which is supposed to be already homogeneized (i.e USB classes) often requires sending vendor-specific "quirk" strings to get the hardware working (e.g the list of 'quirks' in the snd-usbmidi Linux kernel module).

The hardware diversity isn't a detail here. It's the root of the "too many abstractions" problem, and I don't think this is something you can avoid. This is why device drivers exist. This is why operating systems try hard to impose APIs on device drivers (ALSA, Direct3D, etc.) so Firefox, MS Word, Half-Life ... can run on future hardware.

This is one reason why the abstraction layers exist (I'm not even talking about memory protection / safety here) : because you don't want to re-release your app every time some vendors makes a new sound card, graphics card, MIDI interface, wi-fi chip, etc. And you don't want to code the support for all this hardware yourself.

All my projects have a top-level 'check' script, which always does, in order:

- reformat the whole codebase

- build (if needed, e.g a C++ project)

- run all tests

The programming workflow is then:

- edit code

- run the 'check' script

- repeat.

The benefit (compared to more classic formatting) only occurs if you're inserting at the end of the argument list.

If adding stuff to the end of a class or of an argument list is your most frequent case, you might have a software design problem.

> My fictive grand kids will be able to play those games long after the worms have gnawed my bones.

I would love that you be right. And by far, I strongly prefer physical media.

However, physical media is no guarantee either.

- Sometimes, the pain is on purpose: some apps require an online activation, and the corresponding service, 30 years later, is not available anymore.

- Sometimes, it's a lack of foresight from the developers (i.e overzealous Windows version checks, refusing newer versions).

- Sometimes, it's plain dumb stupidity (the installer is a 16-bit windows executable).

If you're not convinced, I suggest you try installing, say, Wipeout XL (for Windows 95) on a recent laptop (spoiler: at this point it's easier to play the PSX version on an emulator).

Debugging is reverse-engineering, i.e trying to understand what's really happening inside a program.

It necessarily implies some loss of control over the code you (or somebody else) wrote, i.e you're not sure anymore of what the program does - otherwise, you wouldn't be debugging it, right?

If you get into this situation, then indeed, firing up a debugger might be the fastest route to recovery (there are exceptions: e.g sometimes printf-debugging might be more appropriate, because it flattens time, and allows you to visually navigate through history and determine when thing started to went wrong).

But getting into this situation should be the exception rather than the norm. Because whatever your debugging tools are, debugging remains an unpredictable time sink (especially step-by-step debugging, cf. Peter Sommerlad "Interactive debugging is the greatest time waste" ( https://twitter.com/petersommerlad/status/107895802717532979... ) ). It's very hard to estimate how long finding and fixing a bug will take.

Using proper modularity and testing, it's indeed possible to greatly reduce the likelihood of this situation, and when it occurs, to greatly reduce the search area of a bug (e.g the crash occurs in a test that only covers 5% of the code).

I suspect, though, that most of us are dealing with legacy codebases and volatile/undocumented third-party frameworks. Which means we're in this "loss-of-control" situation from the start, and most of the time, our work consist in striving to get some control/understanding back. To make the matter worse, fully getting out of this situation might require an amount of work whose estimate would give any manager a heart attack.

This very much looks like the scientific method, applied to software.

> Please do tell use about these nonsexual ways.

Sharing syringes (e.g between drug users).

> Unfortunately, most interesting questions in life don't have single, un-debatable, simple answers.

Because as soon as they have, they stop being interesting.

phaedrus explained why use an infix operator, but why specially the shift operator?

My guess: because it has very low precedence, allowing stuff like:

> cout << a + b * c << " is the result\n";

Instead of:

> cout << (a + b * c) << " is the result\n";

> we just add a delete operator to free memory explicitly and an exception which is thrown if the program dereferences a pointer to freed memory.

Is there any sensible thing to do when this exception is caught, appart from halting the program? If the answer is "no", why have an exception at all?

"Perhaps consciousness arises when the brain's simulation of the world becomes so complex that it must include a model of itself" ( Richard Dawkins - The Selfish Gene )

Is consciousness different from self-awareness? Because we're already using an experimental protocol for testing self-awareness in animals.

Too bad, the article only deals with how to recognize individual components (like a french dictionnary that would be entitled "how to read french").

I fail to see how this takedown benefits Nintendo.

How could a C64 port of a NES game released more than 30 years ago could threaten any sale of anything ?

> Past tense is not necessarily programmer-centric. Release notes are generally written in the past tense (with headings like Added/Changed/Removed).

... which makes past-tense release notes "team-centric". In other words, past-tense release notes are about justifying the work that was done (like some kind of work report), rather than being an exhaustive list of changes in the application behavior brought by a new version.

> If commits are written in the past tense and from the user's point of view they can be used pretty directly to create the release notes.

Bad idea IMHO.

Making developers worry about their commit messages potentially being used "pretty directly" as release note lines seems dangerous:

- It implicitly convey the idea that commits and release note lines should have the same granularity. This might be true in some cases for programming error fixes, but it's generally not for features.

- What about confidential stuff? commit messages are going to get a lot less informative if there's technically relevant stuff that programmers can't mention anymore (like the names of other customers, the yet-to-be-announced next product, etc.).

Yes.

But the point was that Mozart didn't need to be rich to do great music.

Whether he deserved to be rich is another question (more related to morale than economics).

> Before recorded music, a live band (or one man show!) was the only game in town.

Don't forget the orchestra. Unless you consider it to belong the "live band" category :-)

> It's a bad argument. It ignores the fact that humans progress by division of talent and labour.

I suspect the "bad" argument is actually compatible with division of talent and labour. Could you explain the link between this division and income?

> You wouldn't apply it to physicists, engineers, medical specialists, lawyers, politicians [1], financial experts, sports, or software developers. > So why is it fine to apply it to an art?

Because history shows us that "some" art gets done, even when no money is directly involved. And actually, it's the same for physicists, engineers, sports, software developers - not sure about lawyers, policitans, or financial experts.

Now we have to ask ourselves: for all these domains, what's an acceptable amount for "some"?

TL;DR:

"Calling a function with parameters is just another form of synchronous message passing, either by-reference or by-value [...] But yes, we already have message-oriented programming languages—if you squint the right way"

> The report [...] hasn’t yet been peer-reviewed. It didn’t test any object-detection models actually being used by self-driving cars, nor did it leverage any training datasets actually being used by autonomous vehicle manufacturers.

> the fact remains that darker skinned people are harder for machine vision systems to work with due to the lack of contrast.

Is it also harder for human drivers?

I think you're confusing "music" with "radio" here.

> the closed source nature of many services / software [...] in some case is necessary for that platform’s very existence.

Could you please give an example of this?

Beware of arguments like "had it been free software, it couldn't have been monetized it as it was": this reasonning presupposed a fixed set of business models, and doesn't account for the emergence of new ones (e.g online games with subscription, "free-to-play" games, etc.).

Here's all you need to track header file dependencies. Basically, when compiling a .cpp file to generate a .o file, a corresponding .deps file is also generated. And at make startup, we include all the .deps files we find in the bin (output) directory, if there's one.

$(BIN)/%.cpp.o: %.cpp

     $(CXX)  -c $(CXXFLAGS) "$<" -o "$@"

     @$(CXX) -c $(CXXFLAGS) "$<" -o "$@.deps" -MP -MM -MT "$@"

-include $(shell test -d $(BIN) && find $(BIN) -name "*.deps")

ECS is the "microservices" of game development : it's touted as the way to go, and in some cases it's the best solution, but it comes with increased wiring complexity cost, and the hype surrounding it causes it to often be adopted for dubious reasons (e.g "deep class hierarchies are bad, therefore I need ECS").

Very interesting article here: https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...

Fun related quote from reddit:

"you can tell if someone started game development as a hobby because they ARE using an ECS."