One morass I repeatedly see conversations fall into is trying to make generalizations about "programming". The discussion about "most time spent programming" is like this. And also the discussion of static vs dynamic types above. Programming is a huge field! Indeed, as it eats everything it's better seen as an aspect of all fields of endeavor. Like reading. Or history. Try to make a valid statement about "most time spent performing arithmetic", and hopefully it's clear how silly such statements are about programming. What we should be focusing on is domains. Games require very different languages and libraries and processors from scientific simulations, compilers have their own requirements. Even the category of "web app" is huge, because web apps can do many things. I work on deployment tools in my day job, and the domain has certain properties whether you create commandline tools or GUIs or web apps. (We've done them all.) The challenge of end-user programming isn't to figure out the smallest set of things people need. I promise you programming will overflow any box you put it into. No, we have to meet people half-way in each domain separately.

Try to make a valid statement about "most time spent performing arithmetic"

Here are a handful: • A typical person equipped with a calculator or adding machine or (etc) has an edge over a typical person with a pencil and paper when it comes to doing repeat arithmetic. • Some people can do arithmetic with very quickly in their head, even with large numbers. • If you need to produce results that have more than a dozen-ish digits of precision, most calculators won't help you — pencil and paper and knowing how to do math "manually" can be essential in this case. • The notation we use to represent numbers is very broadly useful, but sometimes other notations are faster or richer for manipulating. • Arithmetic won't help you console someone who is dying. We're programmers — we can come up with abstractions that throw away the right amount of detail needed to put damn anything in a box. We can choose to retain as much detail as we need to still state things meaningfully. • The amount of time people spend on various kinds of programming tasks is measurable, and has been measured, both broadly (across languages, skill levels, domains) and narrowly (within a language, skill level, domain). • Our gut intuitions about such matters are, more often than not, worth listening to. Especially when discussing things in a group, sharing and challenging our collective intuitions. • Totally agree about needing to focus on domains. That's a great way to carve up the space, to decrease the abstractness of our discussions. But we can also achieve similar carvings-up other ways — and one such way is saying, "Let's look at the spectrum/space of static to dynamic and see what clusterings of ideas we can place in that space"

https://www.joelonsoftware.com/2002/05/06/five-worlds/ As an example AFAIK git has not made much inroads into AAA game dev as it's horrible for large files and horrible for helping to deal with non mergeable binary assets. Not really a programming thing but I suspect the majority of programmers take git as a given now-a-days. It's not and the problems it doesn't solve seem mostly ignored outside of game dev. Another example of a difference for many AAA game devs, they fill up ram. I've shipped games where I often needed to change jumps (3 bytes) into unconditional branches (2 bytes) so I could squeeze in a bug fix. Maybe not a good example. I've shipped games that used all but 2k of all available ram and for example had to put all data in one file to prevent the OS from allocating more memory opening multiple files. Many languages are lax at memory management and so either are not appropriate or else my app will get xx% less features/level size/texture detail since I need to keep xx% of ram free for the language to play with. Another example might be loading binary files. AFAIK most executable loaders load the executable straight into memory, fix up some pointers and then execute it where as most language level serialization libraries load some intermediate representation into memory, then parse that building language native objects from the representation. Plenty of games though use the executable style. Load the data, fix up pointers, use the data in place. They don't have space to have things in memory twice, once in an intermediate format and again in a language native format. But most languages don't support that at all (one arguable advantage of C/C++) for certain domains.

I'd forgotten that article. Thank you for bumping it.