Wherein I will gently and briefly guide the reader through certain high-level aspects of the type systems of several programming languages, with the intent to demonstrate that a sufficiently strong and expressive type system can be a powerful tool not only for proving the correctness of our programs, but also for assisting and guiding us in the process of the design and implementation of the programs that we write.

Some lisp-like noodlings in JS, by someone who doesn't really know lisp.

There is an unusual, and potentially very frustrating bug in Chrome’s DevTools (at least as of version 46.0.2490.80). It does not appear to have been documented elsewhere, so it is being recorded here in the hope that it may prevent some future hair-pulling.

A computational fluid dynamics simulation.

A 3d sound visualizer.

3D software engine.

An ASCII video renderer.

If you’ve done much work with the HTML5 canvas API, and especially if you’ve ever looked into performance tuning your canvas apps, you’ve likely come across the advice to batch your canvas calls together. For example, you may have read that when drawing multiple lines or shapes, it’s better to create a single path and only call your draw method once, drawing all lines and shapes in one go, than it is to draw each line or shape individually.

After I completed a working version of my 3D rendering engine wireframe.js, I started looking for ways to make improvements, both in terms of performance, and usability. While both efforts are still ongoing, there are a few things I have learned with regard to performance that I wanted to get down in writing.

In which the author addresses the claim, made in the new O'Reilly book 'Data Structures and Algorithms in JavaScript', that 'it is not possible to [implement Mergesort as a recursive algorithm] in JavaScript, as the recursion goes too deep for the language to handle'.

Being an attempt to write a computational fluid dynamics simulation using no more than two raised to the power ten bytes.

First, before I begin, N.B: apparently the extreme brevity required by this project has put me in rather a garrulous mood, so I apologize for the length of this post-mortem. If you’re interested in maybe learning a few byte shaving tricks for your own js1k, though, read on. Also, verbose variable names will be used for the sake of clarity, though keep in mind that all variables here have a single letter identifier in the final program.

Over the 2013 winter holidays I was looking for a project to work on. I had been interested in learning more about the canvas element for a while, so, with the snow driving o’er the fields, I decided to make a simple snow simulation to start learning some canvas basics. Once I had a simple snow program up and running in the canvas, I turned my attention to implementing a wind system that would allow users to interact with the snow, creating gusts of wind with their mouse. My initial naive attempts—which mostly involved a mesh of nodes which contained a single wind vector, and some mechanism to propagate those vectors to the next node in their direction of travel—were fairly unsatisfactory, so I began to look for ways to improve the wind system. After some cursory googling, I started looking in earnest at computational fluid dynamics. This led me to the Navier-Stokes equations, which seemed just a little too complicated for what I was after. Navier-Stokes led me to lattice-gas automata (LGA), which, while conceptually quite simple, has some inherent issues. Finally, LGA led to the lattice Boltzmann methods (LBM).

A* pathfinding.

Conway's Game of Life made with JavaScript.

Lattice Boltzmann, implemented in under 1K.