#AltDevBlogADay

The tweet contains zero substance. I did the dirty work to dig through the linked links to get the goods and share, enjoy! It's a good read.

---

Thanks!

A few comments:

In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think “good C++” is better than “good C” from a readability standpoint, all other things being equal.

I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.

I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.

I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.

The major evolution that is still going on for me…

Two related things I've been studying in more depth lately: Dataflow programming and behavior trees(the game AI concept).

http://en.wikipedia.org/wiki/Dataflow_programming

http://www.altdevblogaday.com/2011/02/24/introduction-to-behavior-trees/

The first comes up anytime you want to make a signal processing chain more modular and composable(graphics and audio are the classic applications) and many of its concepts share space with FP theory. Graph demonstrates a implementation built around certain needs of web apps. Note that it seems like implementations vary a lot with the data types - audio processing, for example, may allow for cyclical feedback loops, and mainly distinguishes between two types of data - multi-channel PCM data(which may be split and combined between nodes) and parameter changes over time.

The second describes a form of concurrent finite states with good compositional properties - parent-child relationships that result in concurrency expressions passed back to parents(success, failure, in progress). Coroutines are comparable in power, but put emphasis on direct control of the concurrency, while BTs use modules of state + logic with pre-designed yielding points. (I think other finite state constructs have applications, too, BTs just happen to be my focus right now)

I currently believe that highly-concurrent applications can be abstractly architected as a combination of dataflow, behavior trees, and asynchronous events - each one of those covers a very…

>It is hard, though, to build and maintain the structures of the old, “smaller” internet. You can, today, still go back to the can-to-can structure that a personal website, an RSS feed, and a browser provide.

I think the author ignores another reason that people (especially us techies) don't like to admit: The majority of people don't care about following a list of personal websites. Instead, websurfers just get whatever snippets of information they want (e.g. food recipe, medical trivia) from whatever website happens to have it and then move on.

The disinterest in personal websites comes from both the websurfers and many content authors themselves.

Some examples from the content creators...

Clay Shirky's essay happens to be on the HN front page right now. But he doesn't maintain his personal website anymore. He gave reasons for it[1] and even said he regrets letting it rot. But even today, his personal website remains empty and previous links all return 404 errors. But he does stay active on Twitter: https://twitter.com/cshirky

John Carmack's old personal website "altdevblogaday.com" is gone now.[2] But he does stay active on Twitter: https://twitter.com/id_aa_carmack

Those 2 guys are obviously internet-savvy and need no lectures on personal websites -- and yet they choose to abandon them.

As to examples for websurfers, if you ask normal people if they sometimes search the internet for a cooking recipe, they'll say "yes". But if then followup with "Can you…

I have desperately wanted to understand the Fourier Transform and signal processing for a long time. In high school I read every tutorial or book I could get my hands on, hoping that one would finally "click." The very first thing I did when I got to college was approach the CS faculty and ask for recommendations for literature that would help me understand it. My college didn't have a signals and systems class, but a few years later I heard that Richard Lyons's book "Understanding Digital Signal Processing" was supposed to be the friendliest book on the subject so I bought and read it.

I say all of this just to impress upon you that I was serious about wanting to understand this stuff.

Despite all the effort, the FFT and DFT were never more than opaque blobs of math to me, mysterious boxes that you put inputs into and could extract outputs from (albeit in a very obscure format that seemed to involve complex numbers for no apparent reason). I sort of gave up and forgot about it for several years.

Recently I came upon Stuart Riffle's article (http://www.altdevblogaday.com/2011/05/17/understanding-the-fourier-transform/) which explained it in terms of the circular approach that this article adopts. Rotate the waveform about the origin at the frequency of interest and average the samples, simple as that.

I am not exaggerating when I say that after 10 minutes of reading that article, I had an understanding that years of highly motivated knowledge-seeking had not given…

I only clicked to see the comments because it said Doom 3.

Thanks for posting the article and thanks for pointing out the section on linked lists.
I agree that that section is really interesting. In what sense do you mean lockless applications - applications built around compare and swap primitives or something else?

I can't really follow what:

"byte otherMembers[64]" is used for.

What useful data is stored in there? If pointers are 32bit and cache lines are 64bit, the comment:

"// over a cache line worth of other members"

doesn't really make sense because you can only fit two full addresses per cache line.

It's a shame that the idList type he is suggesting in favour of the other types, a resizeable heap array, is not declared in the body of the pdf. Might be worth looking it up.

The distinction between non-intrusive and intrusive linked lists is new to me, I didn't know there was a word for that!

This is the best "link" I've found on them:

http://www.altdevblogaday.com/2011/12/06/intrusive-lists/

John Carmack wrote a great blog post a while back about Static Code Analysis.

http://altdevblogaday.com/2011/12/24/static-code-analysis/

While not all of this is immediately applicable to JSHint and the like, it provides some insight into why static code analysis can be seen as helpful.

As you also mention, it's really helpful for code within a codebase to be consistently written. JSHint can help enforce some of that consistency. This is where JSHint really shines.

If your JS is tied to some sort of "build" process (even a short 1-2 second one), catching errors before running the build is incredibly helpful. If you intend to minify your JS code (as you should) before distribution, finding missing semicolons can be very important, indeed. I find the most helpful JSHint errors to be about mistyped variable names. It's so much easier to see that in my editor, fix it, and THEN run it in the browser.