Stuart P. Bentley stuartpb

Mr Walé’s Inclusion Fusion Vernacular Spectacular!
or Decoupling from (Bad) Shibboleths in the Developer Community
Link to Slides

A problem with developers is that we often say and do things that are esoteric and treat them as criteria for being a “developer.” This conflicts with the fact that a developer can come any background.

Today I’m going to talk about shibboleths. What’s a shibboleth? A shibboleth is a proverbial line in the sand that determines who belongs and who is an outsider. Many are in programming. Text editors, paradigms, languages, type systems, are all topics of… um…, “vigorous conversation.”

If you want to think about it in terms of middle school Venn Diagrams, the developer community does not do enough to encourage seeing different developer groups as unions instead of as intersections. This can have a lot of different manifestations. Say you're working on a pr

Best thing about Docker

To run something messy with complicated dependencies that was designed for a big distro like Ubuntu and doesn't have a Nix package built for it yet, Docker provides a sledgehammer approach that is simple and reliable.

For things like CI servers, it seems like a good lightweight alternative to VMs.

Worst thing about Docker

Lost from https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/

When I switched over the C# compiler team, I had hoped that I would be able to give some insight into how the design team works, what decisions we make, etc. Language design is a very esoteric field, and there's not a lot written about it (though “Design and evolution of C++“ is a pretty good read). I had hoped that I would be able to do this with concrete examples, as that makes it much easier.

I've been watching for candidate topics to write about, but haven't yet come up with any good ones. One of the problems is that features have a tendency to morph in design (and in whether they'll make it into Whidbey) as time goes by, and it would be bad for me to say, “we're talking about doing“ and then have us decide it wasn't a good idea. Or, for us to decide that doesn't fit into our schedule, or it would break existing code, or any of the other reasons that might cause us to pull a feature. We're generally not comfortable re

	'use strict';

	const x = (() => {

	// This is always >= 0
	let nonNegative = 0;

	return {

	// Return the value

	meta:
	id: exapunks_solution
	file-extension: exapunks_solution
	endian: le
	seq:
	- id: magic
	contents: [0xEF, 0x03, 0x00, 0x00]
	- id: file_id
	type: pstr
	- id: name