Andrei Dragomir adragomir

things I don't know

I took this list from What CS majors should know.

I think it is fun to list things I don't know so I did it =D. I actually found it to be a cool exercise -- maybe I should do a fun graphics project and learn about Open GL!

i wrote this because, while i think the things on this list are potentially worth knowing, and I actually think it's an awesome list of project ideas as well as good food for thought for people developing CS curricula (many of the things I don't know are great exercises!) -- I thought it was really weird to say that every CS student should know all of them. I have a CS degree and I learned very few of the things I do know inside my degree.

I classify "do know" as anything that I have a reasonable grasp of or at least some basic experience with -- the kind of experience I'd expect a CS student to be able to get. If I say I don't know something, it means either I know pretty much nothing about it (for "gr

What is the appeal of dynamically-typed languages?

Kris Nuttycombe asks:

I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?

I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.

I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

Two developers working on independent features must never be blocked by each other
- No code freeze! Ever! For any reason!
A developer must be able to base derivative work on another developer's work, without waiting for any third party
Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
Developers must be able to work on multiple features simultaneously, or at lea

	#include <stdio.h>
	#include <stdint.h>
	#include <assert.h>

	#include <sys/types.h>
	#include <sys/stat.h>
	#include <sys/mman.h>
	#include <fcntl.h>
	#include <unistd.h>

	#include <stdio.h>
	#include <stdlib.h>
	#include <stdint.h>
	#include <assert.h>
	#include <string.h>
	#define streq(a, b) (!strcmp((a), (b)))

	#ifndef __USE_GNU
	#define __USE_GNU
	#endif

	// My investigations on the C standard compliance of Gob and related techniques:
	// https://gist.github.com/pervognsen/5249a405fe7d76ded1cf08ed50fa9176

	#pragma once

	#include <stdint.h>

	#pragma pack(push, 8)

	#if __cplusplus >= 201103L \|\| (__cplusplus && _MSC_VER >= 1900)

	#define _CRT_SECURE_NO_WARNINGS
	#include <string.h>
	#include <stdio.h>
	#include <windows.h>
	#pragma warning (disable: 4146)
	#include <stdint.h>

	#ifdef _DEBUG
	#define Assert(x) \
	if (!(x)) { MessageBoxA(0, #x, "Assertion Failure", MB_OK); __debugbreak(); }

	#include <stdio.h>
	#include <stdlib.h>
	#include <string.h>

	int addi(int a, int b) {
	return a + b;
	}

	char adds(char a, char *b) {
	char *res = malloc(strlen(a) + strlen(b) + 1);

	// Mini memory editor for Dear ImGui (to embed in your game/tools)
	// Animated GIF: https://twitter.com/ocornut/status/894242704317530112

	// THE MEMORY EDITOR CODE HAS MOVED TO GIT:
	// https://github.com/ocornut/imgui_club/tree/master/imgui_memory_editor
	// Click "Revisions" on the Gist to see old version.

	#!/usr/bin/env bash
	# Generic macOS workstation setup
	#
	# A pragmatic, public bootstrap for developer / technical-productivity Macs.
	# It installs Homebrew, common CLI utilities, runtimes, terminal/editor/agentic
	# coding apps, viewers, media tools, and a curated font set.
	#
	# Philosophy:
	# - Open-source / cross-platform first.
	# - Commercial apps only when explicitly useful/common for this workflow.