We have known for decades that adding people to a late software project only makes it later.

So why is it that nobody gets hired for a team that is ahead of schedule?

Seriously considering a ground-up rewrite of the compiler... Yet again. The existing project is riddled with assumptions that I don't like, is very poorly organized, and implements a language that is almost - but not quite - what I want it to be.

If I do it, I will keep large chunks of the existing code (linker mostly). But it's a big enough lift that I am very hesitant.

Anyone got some recommendations for reducing .PCH file sizes? Besides the obvious one ("include less").

I would love to have Clang's chained PCH support in Visual Studio, but oh well.

Presently doing 50GB of disk IO just on PCHs for every clean build of a certain project. Would love to make that number a lot smaller.


Computers are truly amazing. I can transfer literally billions of pieces of information from one place to another in a second.

Software is equally amazing. I can squander the immense performance capabilities of the computer effortlessly by writing some sloppy code.

Turns out cache invalidation is still a Hard Problem.

Renewing my search for users (or instances!) that might have an interest in - particularly design and implementation.

Here is my current project: github.com/apoch/epoch-languag

(It isn't very approachable right now, but I am making good progress on the second self-hosted compiler and IDE integration with VS2017.)

The quintessential Friday afternoon is listening to a discussion about design patterns get drowned out by random people saying "blood!" in silly voices.

On side projects, I tend to prefer committing code in many tiny changes. The only time I (generally) commit more than a function or two is when the pieces are inseparably coupled.

This is mostly only practical on solo projects. At work I make much larger commits but routinely shelve code while working on them, as a sort of serialized Undo/Redo stack.


I would really like to understand why LLVM's CodeView support generates symbol types that are rarely (never?) emitted by actual Microsoft compilers.

Getting the Visual Studio debugger to properly inspect variables has been a long running nightmare, punctuated by "temporary" hacks and workarounds.

It really reinforces my strong suspicions that LLVM is philosophically hostile to debuggers (see: inspecting its source code in a debugger is a waste of time).

Recently resumed work on after a couple months off. Currently striving for a 64-bit self hosted compiler.

The 64-bit self host is so far smoother than 32-bit was, largely because the debugging experience is much better. Having PDB symbols is a huge win, even without variable inspection.

Low key pet peeve: saying C is "close to the metal."

It is *closer* than virtually any other structured language in use today, but C is still fundamentally a considerable abstraction layer over hardware.

Even when it was first gaining traction, C was appealing *because* it was in fact reasonably far removed from "the metal."

The amputated fraction of a distributed version control system: a GitNub

I feel conflicted about movie villains that meticulously plan their lives.

We're supposed to dislike them, but they're just so organized and methodical and rigorous... How do you dislike that?

Oh... Most people don't place life value on having a thousand contingency plans for every inconceivable scenario, do they.

O...okay.

Me: better find the places this identifier is used

*grep intensifies*

Me: well clearly this particular mention of said identifier is totally irrelevant

Also me: why can't I figure out what's reliant on this identifier??

*headdesk*

Mike Lewis boosted

TIL - c# linq's .Select() method can use a lambda which takes TWO params, the first being the "value", the second being the index of the "value" in the enumerable. I'd only ever used the single param version before.

Opening GDC speaker evaluations is like the career version of getting a report card.

It is fascinating to watch my assertiveness vary by audience.

To reports: "X is a fact."
Peers: "I think X is a fact."
Seniors: "Is X a fact?"

The degree of certainty behind a statement can even feel different by someone new walking into the room.

No real point, just think it's interesting.

I've properly decided to commit to writing my second self-hosting compiler for - this time aiming for 64-bit native.

Should be more pleasant this time around since at a minimum I will have usable call stack traces... Once the PDB generator is sufficiently generalized of course.

Sometimes it makes all the difference to step away and rethink.

And other times it doesn't change a thing, but at least you have confirmation you're on track.

I am ever so slightly envious of non-games programmers and their freedom to not worry about a few percent of performance.

But I also get a huge kick out of making those savings when a budget is tight.

I wish that, as a species, we were all more willing to experience moments of minor but sincere emotional vulnerability.

There is amazing value in being able to be genuine and earnest in interactions that are normally seen as formal or professional.

Show more
Gamedev Mastodon

Game development! Discussions about game development and related fields, and/or by game developers and related professions.