Ace17

Actualy, I think it is.

You said it yourself:

> on desktop I can't paste between Emacs and Confluence because Atlassian went out of their way to break it.

Which presupposes that by default (i.e without Atlassian's messing things up), it would have worked. On desktop applications, File-level and copy-paste interoperability are there by default.

This is the difference: what is the amount of interoperability you get by default, i.e without specific actions from the app developers?

The fact that you can break interoperability is irrelevant.

off topic: vimium scrolling doesn't seem to work on this page. Seems like vimium can't keep up with the creativity of nowadays web developers :D

It's only programmable in the Matrix movie.

Today's real world requires you to practice before saying "I know kung fu".

Great idea! This might be a fantastic pedagogic tool.

Some minor details that annoyed me (I'm only listing them here for improvement purposes):

- You can't "Expand" the whole program, only one statement at a time. However, having the fully expanded view is IMHO key to correct concurrent reasoning.

- Each mission's objective is hidden inside a big explanation text. I already know what mutexes/deadlocks/atomics/monitors/etc. are, I just want to play, thus I only need to know what will be considered as victory (as you can't unambiguously deduce it from the code: sometimes you must reach an Assert(false), sometimes you must deadlock the program, etc.).

- The confirmation dialog for 'reset level' is annoying (especially considering the 1s visual fade delay).

I'm only expressing those minor quibbles of mine for improvement purposes ; this game is fun and pedagogic and its author cleary did a great job here. Thanks to her/him!

> When other people try to look at the "cleaner" version they have to spend more time trying to understand it and mentally untangle the abstraction.

If you have to do this, either your abstraction is "wrong" (e.g leaky) ; or perhaps your identifiers are inappropriate?

(As a rule of thumb: not being able to figure out a good name is a sign that the abstraction might be misplaced.)

Code is not clean : code is cleanable. What is clean today might not be clean tomorrow (Robert C. Martin, author of the book "Clean Code")

Trying to evaluate code cleanliness in isolation is a waste of time ; as it strongly depends on the way your requirements evolve (but it's not subjective). You only need abstraction points at the frontiers between parts of your requirements that change at different times.

Duplication is better than a wrong abstraction (Sandi Metz, author of Practical Object Oriented Design in Ruby).

Trying to religiously factorize every structural similarity you can find, for the sake of the almighty DRY principle, without taking into account how business requirements evolve, is counterproductive.

I work for a 40-people game studio.

A major limitation of git is how it deals with many "big" (~10Mb) binary files (3D models, textures, sounds, etc.).

We ended up developing our own layer over git, and we're very happy ; even git-lfs can't provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.

Greg Wilson made the talk "What We Actually Know About Software Development, and Why We Believe It’s True".

The gist of it is that we're too much willing to believe bloggers without experimental evidence (e.g "DSLs are good"), and not willing enough to follow/apply proven scientific results ("code reviews significantly reduce errors" ).

That was 10 years ago. Today, he writes:

> "The best way—in fact, the only way—to improve productivity is to improve quality"

This is a highly controversial statement (with which I agree, but that's not the point), stated here without supporting evidence.

Are we supposed to trust him? Where's the Greg Wilson from 10 years ago? He could have been the evidence-based software guy giving the software industry the push it needs towards more proof/experimental-studies!

JSON provides a lot of flexibility: it's human readable, it has explicitly-named/optional/variable-length fields, it provides nesting ... all of this comes with a cost:

- extra branching in the parsing code (the parser cannot predict anymore what the next field will be, they could be in any order)

- extra memory allocations, decreased memory locality (due to variable-length/optional fields, and also the tree-like structure).

So if your data consists in a single object composed of a timed-fixed set of little-endian integer fields, you're comparing the above costs to the cost of a single fread call* with no memory allocations.

* many other data formats provide similar flexibility, text-based ones (XML) and also binary-based ones (IFF, protobuf, ISOBMFF, etc.)

don't write it as such though, you must write the endianess-decoding code (which the optimizer should trash anyway on little-endian architectures - e.g LLVM does).

> Software Security Is a Programming Languages Issue

Then, how could a programming language help me prevent high-level security bugs like Shellshock? Is it even possible/practical?

"The only valid use of a debugger is to analyze deadlocks in post Mortem core dumps. Interactive debugging is the greatest time waste. Write automated tests for your debug hypotheses instead." (Peter Sommerlad)

"Although this is only anecdotal evidence"

This should have been at the start of the article, not the end.

Modularity requires more than being a "set of interconnecting components" (otherwise, all codebases with more than one source file would be "modular", and there would be no monoliths).

Modularity implies formalization and restrictions about how components communicate and depend.

One of the goals: the ability to replace the implementation of one component without having to modify/adapt the others (the top-level component (also called 'main' or 'composition root') used to instantiate all the others doesn't count).

If your components can be compiled separately (e.g without having to recompile the whole app), then you know you're modular (however, modularity doesn't necessarily involve dynamic linking).

Real world examples of modularity:

- device drivers of the Linux kernel

- SDL device backends

- decoders/demuxers in VLC

- Cubase VST effects

- Filters in DirectShow and Gstreamer

Real world non-examples:

- LLVM backends: in practice front-end implementations need to know about the various backends, so you can't simply add one.

- GCC frontends: almost modular, however, there's some bunch of places you still need to modify so they know about your new frontend.

- GCC plugins: although no line of code in GCC know about your plugin, your plugin can depend upon almost anything from the GCC implementation itself, in other words, the plugin API is too big (=the density of interconnections is too high).

- Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).

We haven't seen anything yet. Wait until PulseAudio is merged into System-D.

PCM doesn't make any special case for different wavelengths. It's simply the air pressure over time (pressure on your ears, on the speaker's membrane, etc.) It doesn't directly correspond to the volume ("f(t)=1" is as silent at "f(t)=0").

So yes, an (uncompressed) audio stream is just a sequence of samples of pressure (or displacement, depending on the medium).

The variety you get comes from the high sampling frequency: a high sampling frequency allows representing vibrations of the air pressure at many frequencies.

I suggest you google for "cat bites vs dog bites".

"Maximizing your audience" != "strengthening your game"

Audience maximization is almost literally regression towards the mean to maximize profit. It implies cutting corners ; but some of these corners are actually making your game stronger, they're giving it its personality.

Think of "Dwarf Fortress", "brogue", or even "Minecraft". What kind of feedback do you expect to get from most players? Better graphics? Real-time play? Would it make the game stronger?

I have 15 years experience as a professional C++ programmer in various teams and companies (and although I don't know 100% of C++17, I consider myself productive!).

When diving into new codebases, the couple of esoteric-used-features-you-did-not-know-existed in C++ was never a big deal. Learning the required C++ features was always a matter of days (because the codebase is full of real examples).

Understanding the overall structure of the code, the interactions/dependencies between the components, in what file/directory should go your first feature... this is the hard part. And it's many orders of magnitude harder than learning a couple of new language features.

Don't get me wrong, I'd really like that C++ and D be smaller, and I don't like feature bloat. I once wrote a source code processor based on clang, and then you realize how big the language really is (there are many AST node types), and having all your code written in it starts to feel like technical debt.

However, I pragmatically have to recognize that feature bloat isn't a real problem for professional C++ programmers (It might be, for compiler vendors - at this point, I'm not expecting any new C++ compiler to be created).

PS1: C++ certainly gives you some shiny tools to make interesting messes (I've seen codebases where simply including a header would change the program behavior). This isn't related to the feature count, but rather to the semantic of the individual features themselves, like macros/templates. At least we don't have monkey patching ...

PS2: About your Lua example: even without knowing the syntax, can you sincerely have the slightest doubt about what "player:set_pos{x=0, y=0}" actually does?

> The feature bloat makes it very hard to learn D, let alone being an expert on it.

Learning 100% of any programming language should not be a goal. I know less than 10% of the functionalities of my microwave oven or my washing machine. This doesn't prevent me from successfully using them and save a lot of time.

Bjarne Stroustrup himself says learning all the nitty-gritty details of C++ is counterproductive and unnecessary.

Feel free to create the "moral/ethical software" movement, but please don't touch the current definition of free software.

People already have a hard time understanding what free software exactly is/requires/provides. Changing the definition at this point would only create confusion, especially if the new one is even more ethically grounded.

Data structures won't tell you the communication paths and dependencies between modules/components/services.

While I agree with you, I'd like to point out there are interesting exceptions: software components that can never be "complete". Such components require permanent maintenance workforce, and you might not want to dedicate resources for this.

Such as:

- API abstraction layers (like SDL, Allegro, SFML, etc.): you want to support new operating systems / new APIs by default. And most of the time, you don't want to spent time learning about the specifics of X11 window creation or Win32 events, as this would be throw-away knowledge anyway.

- hardware abstraction layers: you want to support new hardware by default, this is why we use operating systems and drivers.

- Format/protocols abstraction layers: if your game engine only uses JPEG files directly coming from your in-house asset pipeline, it's perfectly fine to develop in-house loaders (from scratch or from stb_image). But if your picture processing command-line tool aims to support every file format (especially, the ones that don't exist yet), then you should rather go with an updeatable third-party library, which will allow you to get all new formats by default.

- all kind of optimizers, including compilers, code JIT-ters, audio/video encoders, etc. More generally, all code that uses some heuristic so try to solve a problem that's not completely solved/solvable. You might be ready to accept the performance of a specific version of, for example, libjit. But you might instead consider that in your case, not having state-of-the-art JIT performance might be detrimental to your business, in this case you want to get the performance enhancements by default.

> "with default settings, the AOM encoder is slow, but as we have seen, that does not mean that the AV1 format is too slow."

OK, so there's currently no proof that AV1 is slow.

But arguing that "it could be made fast" is actually propagating the idea that "currently, it's slow".

There's no better way to convince everyone than pointing to an existing fast implementation.

> There's no reason for an encrypted file to be more than 100 bytes larger than the unencrypted file.

Video engineer currently implementing MPEG Common Encryption here:

Actually, there is.

MPEG CENC (Common Encryption) uses AES CTR and requires conveying one initialization vector for each audio/video frame. Those are generally 16-byte long.

To make the matter (a little) worse, MPEG CENC adds signalization to the file, to specify which parts of the streams are encrypted or not: indeed, for remux-without-decrypt reasons, each video frame must have its headers in cleartext.

In fine, you get some dozen of bytes of overhead per audio/video frame ; do the math.

Of course, this overhead remains negligible and could by no means explain a 30% size reduction when decrypting.

> To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all the : and << flying around.

Visual appearance is a rather weak reason for preferring one language over another (especially if it's for explicitly personal reasons).

> I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding.

Maybe they don't know what they are missing.

When I was learning C two decades ago, my first thought was that pointers were solving no real problems, and that I will be able to do without them. Then I had to implement the "swap" function.

Nitpicking too: perimeter != area.

Independent deployability might not be a goal per-se, however it shields teams from other team design choices.

Whose role is it to enforce copyright?

When was the last time you checked the return value of 'printf' ?

Would you consider it a good thing to be forced to do?

Moreover, there are functions for which "not ignoring" the return value isn't the same as "checking it" (e.g malloc, fopen, etc.).

(CppCon about error handling: https://www.youtube.com/watch?v=GC4cp4U2f2E )