Tinkerings

WebAssembly

I’m fascinated by WebAssembly, and have been tinkering with implementing a subset of Simple Statistics in it. Early efforts have been tricky - there are a bunch of different versions of WebAssembly bitcode and they aren’t compatible or evenly distributed between Node/Browser targets.

But I’m excited about it as a restrictive, tiny language for performance-critical pieces of code, like math, crypto, or decoders. It probably won’t be a panacea for Simple Statistics performance, especially given that the library deals mainly in arrays and WebAssembly will require a middle step of converting to ArrayBuffer objects.

I’ve already started on a super crude, undocumented implementation if you truly want to see the early work. With a few hours of practice the WebAssembly text format started to feel like a decently friendly little language.

Property based testing

Property-based testing is nothing new to the wider world - QuickCheck (Haskell), ScalaCheck, and hypothesis (Python) are popular in their respective communities.

I’ve been tinkering with JSVerify.

Modern testing frameworks like Jest and ava make unit testing faster and simpler, but they’re built on the same basic assumptions: that test suites compare a set of handpicked, discrete inputs to expected outputs.

As I’ve gotten more experience with unit testing, I’ve gotten better at picking inputs - immediately testing corner cases like empty arrays, testing error conditions, testing the extremes. But still, unit testing demands creativity to guess which inputs might be problematic, and unit test suites tend to grow as they protect against regressions.

Property-based testing, on the other hand, tests the validity of assumptions across an entire type: if a property-based test claims, for instance, that Math.abs always returns a positive number given any other number, it will quickly test that assumption across a gigantic range of numbers, generating them deterministically. Instead of testing outputs given concrete inputs, it’s testing assumptions given the values possible of a certain type.

So far I’ve just switched leftpad (not left-pad) to JSVerify, to test assumptions - that it can pad any number, that running it multiple times yields the same value (that it’s idempotent), and so on.

Commit conventions & release tools

I’ve switched all my projects over to using the Angular commit convention, with cz-cli making it easy to write those messages.

And then I’m switching everything over to using standard-version to author new releases. The combination is making changelog authoring and just releasing software in general so much better.

Crafting Interpreters

I’ve been working through this lovely book about creating language implementations: so far I’ve finished the segment on lexers.

It’s really well-written and structured, and includes as a bonus clarifying snippets like:

An argument is an actual value you pass to a function when you call it. So a function call has an argument list. Sometimes you hear “actual parameter” used for these. A parameter is a variable that holds the value of the argument inside the body of the function. Thus, a function declaration has a parameter list. Others call these “formal parameters” or simply “formals”.

I’m following my usual rules for doing programming tutorials:

• Type everything, never copy & paste
• Try to guess and write the code sample before writing the code.