Sean Barrett

I have not heard this 'criticism' ever before and it's absolutely ridiculous on so many levels to me as a person tangentially interested in gamedev, C, C++, runtimes, system programming, retro stuff, history of gaemdev, etc.

1. Why would a web dev suddenly decide to write in such a spartan way an algorithm heavy library in C or C++? This makes no sense except to somehow tie modern web dev failures like left pad with this style of libraries to portray them in negative light...

2. In gamedev neat organization is/was not some golden long standing standard, i.e. in comments under[0] you can find information that with 3D graphics it was customary to use a single file to let the early compilers do a better job since they didn't optimize across translation units and many old codebases have no problem with thousands of lines of spaghetti per file.

3. These libraries are meant to be compiled once ever per project (except when you clean out all your object files) with a define in a single source file (which any modern compiler should handle), otherwise most of their text is thrown away in a single ifdef which should be trivial and speedy on a modern compiler. The resulting header shouldn't be a problem for any modern compiler and is as light or lighter than an entire include tree would be. Most of these libraries are also single purpose and have very small API and C is light compared to template heavy C++ anyway. If you develop such a library you can keep it split up and ship…

Aside from the many great soundbites in it, the thing I like most about this article is that its author is Sean Barrett, whose background is in game development and as a traditional, pre-Web client programmer. (See [1].)

Usually, the same way that ecosystems stratify around languages, opinions in questions of tech advocacy tends to stratify based on developer background. Most of the progression in web standards that the author is against has been bolstered by the attitude from people that hail from his background. (Roughly, that camp's attitude tends to resemble something like, just give the developer the ability he or she needs in order to do what he or she wants.) It's the exact attitude that gave rise to developer-first QOL improvements like WebAssembly and many other things that have popped up in the nearly 1.5 decades after this was written.

This is notable because that camp's overriding perspective is the exact opposite of the author's own grumble about "your experience interacting with the web could be vastly better, but browser authors are instead caught up in enhancing the abilities of content creators". I.e., the author prioritizes a user-first perspective, recognizing that the developer-first mindset has almost always been in conflict with his ideal vision for the Web, despite his own background.

There's also the really great breakdown of Web content as type #1 vs #2 vs #3, which predates similar descriptions that I'd only seen start to become…

You are insulted by the idea of programming puzzles in an interview situation. That's fair enough by me. But then you go on to say this:

> I also happen to hire and if the candidate does not have an open source project I give them a meaningful challenge (add value to the community) and tell them to create a github acct and share a link to the repo. At least by the end of the process they have something to walk away with

Could you be any more silly and condescending? Right back at you: Unless your nickname is a literal and accurate description of your programming abilities, I will take a bet of dollars to donuts that every programmer in my office has more raw coding acumen than you. But guess what? None of them has a GitHub account and that is unlikely to change. Neither do most of the other top-tier programmers I know. One of my coworkers has put out numerous public domain libraries (http://nothings.org), most of them developed on RAD's dime, but he'd probably be appalled to be considered a member of your "community".

I actually have an old, effectively defunct GitHub account that I continue paying $8/month for because I like what those guys are doing. The problem isn't GitHub. GitHub is great. The problem is you, and people like you.

Don't be a GitHub Douche.

I had no idea Thief, one of my favourite games, was built with an ECS-like architecture. Two articles with more interesting details about Thief (I especially love its "temporal" CSG world model):

https://nothings.org/gamedev/thief_rendering.html

https://www.gamedeveloper.com/design/postmortem-i-thief-the-dark-project-i-

I skipped a fair chunk of the middle of this video as I really wanted to get to the Sketchpad discussion, which I found very valuable (starting around 1:10).

I think Casey was fairly balanced, and emphasized near the end of the talk that some of the things under the OOP umbrella aren't necessarily bad, just overused. For example, actors communicating with message passing could be a great way to model distributed systems. Just not, maybe, a game or editor. Along similar lines, I love this old post "reconstructing" OOP ideas with a much simpler take similar to what Casey advocates for:

https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/

But I of course enjoyed him calling out the absolutely dire state of OOP education/tutorials. I satirized this on my own blog ages ago:

https://crabmusket.net/how-i-learned-oop/

In that post I referenced Sandi Metz as an antidote to awful OOP education. I may just have to include Casey as well.

Skip lists and splay trees, two frequent suggestions on this thread, are "lesser known" for a reason: skip lists because for any given skip list implementation there is most probably an encoding of balanced binary trees that outperforms it, even in concurrency, and splay trees because every balanced binary tree outperforms them --- and, in order to avoid writing and testing balancing code, you have to trade off the fact that reading the tree modifies the data structure.

Judy arrays came up once too; there's a really excellent critique of Judy arrays here:

http://www.nothings.org/computer/judy/

(Long story short: you can get comparable performance from a straightforward hash table, and Judy Arrays have to be tuned to the microarchitecture).

Favorite data structure not cited here:

Aguri trees, which marry a bounded-size radix trie (like you'd use in a software routing table) to an LRU list, and automatically synthesize aggregates (like, 10.0.0.0/16 from 1,000 observations across all IPs) from the pattern of insertion. They're best known in traffic analysis, but we've used them on in runtime memory analysis as well.

This sounded promising but then I saw a performance benchmark [1] that was done on a pentium(!) with a very suboptimal hash table design compared to [2] and [3].

The Judy site itself [4] is full of phrases like "may be out of date", when the entire site was last updated in 2004. If it was already out of date in 2004...

It seems that Judy arrays are just kind of a forgotten datastructure, and it doesn't look promising enough for me to put in effort to revive it. Maybe someone else will?

[1] http://www.nothings.org/computer/judy/

[2] https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/

[3] https://probablydance.com/2018/05/28/a-new-fast-hash-table-in-response-to-googles-new-fast-hash-table/

[4] http://judy.sourceforge.net/