Hi! I’m Jeremy.
Around 2000, I read K&R. I didn’t actually care about C. I wanted to write LPC to hack on the MUD Muddy Waters. LPC is an odd-duck offshoot of C: an interpreted language with a prototypal object system. (Some folks are still using it for non-MUD software under the name of Pike.)
In 2008, I found myself working as a software engineer writing Objective-C. Objective-C is an odd-duck offshoot of C: a compiled language with a Smalltalk object system.
Most of my online socializing happens on Pnut.io.
I stream highlights from reading to Pnut (using the share extension of Dominik Hauser’s Phazel) and Twitter (using Tweetbot).
Longer thoughts and reading notes end up on this blog, or sometimes at my employer’s blog.
How can we more quickly create more reliable software?
- Automated testing: I’ve been reading a lot about agile processes and the practice of test-driven development.
- Fault-tolerant design: I’m poking at Elixir and Erlang, specifically the fault-tolerant design patterns provided by OTP.
- Provably-correct code:
- Proof extraction (where you prove something, then use that to generate code in a programming language) interests me, but Coq is a rough place to start.
- Dependently-typed programming: I’ve had more luck with this tack, especially since I learnt of Idris.
- Progressive refinement of a proven-correct design; I’ve looked at Alloy in the past, but found it unwieldy, and am now looking at TLA+ for exhaustive model-checking of concurrent algorithms.
- Raising the level of abstraction that we program at:
- Domain Specific Languages, and viewing all APIs as better or worse expressions of domain-specific languages, provides some hope here.
- Libraries for common tasks: I’m looking for missing pieces, specifically in the context of Swift apps, as well as extant pieces that I’m not making use of.
How can we create maintainable software?
- Automated testing: This time, with an eye to tests as documentation.
- Forward-looking comments
- Intention-revealing code and domain-driven design
- Selecting a language at the right level of abstraction, or building one in the context of an existing language (DSLs); standard object-oriented design principles also come into play here.
How can we best apply Swift towards building iOS and OS X apps?
- I work with this stuff all day, so I’ve a vested interest in improving how it is used.
I find myself fascinated by systems. I’ve focused on languages, math/CS, and random DIY pursuits like textiles and home improvement. The latter might seem surprising, but houses are full of systems: the way a structure is arranged to bear weight, electrical cabling painstakingly routed and wired together, plumbing soldered, and HVAC cobbled together to make the place comfortable.
- Comfortable reading French, though been some years since I spoke it.
- OKish reading German and Swedish.
- Slow-going at Latin.
- Programming language design and theory fascinate me.
- I’ve looked at and played with a lot of programming languages, and I enjoy making the acquaintance of novel ones.
- I’ve been paid to program in C, C++, Objective-C, Swift, Clojure, and Urbiscript.
- Knitting: I taught myself to knit using the Web during an REU in Hong Kong Summer 2007 or so.
- Crochet: I taught myself to crochet using the Web and some books during 2012.
- Nalbinding: I shaped an old toothbrush into a nalbinding needle and played around with the various knotting techniques during 2013.
- See: Professional. I find a lot of the same things I do professionally interesting enough to learn about in my spare time, particularly those touching on programming language theory and computer science.