TO BE FILLED IN (eventually). I AM FINALLY FILLING THIS IN (24 Jan 2026).
I am a programmer for fun that happens to write a lot of tooling, interpreters, and compilers.
Youngin’ Years
This journey started when I was around 10 and got a Datel Games ‘n’ Music cart from Walmart; a couple years later I took interest in how NDS homebrew was made, and started learning to “make games” in C to impress friends.
Prior to working “professionally”, I wrote a mildly popular Android app for applying modifications to Minecraft Pocket Edition, called PocketTool. This preceeded much better tooling to come out later like BlockLauncher (a name I suggested :P) by the talented Zhuowei Zhang. At the time, this applied mods by unzipping the Minecraft apk, overwritting the asset files, re-zipping the package and re-installing. For installing mods, I had created a new, simple binary patching format, I called PTPatch. PocketTool would take a PTPatch file, find the offset in the binary to overwrite, then apply the edit. The inital PTPatch format only allowed editing one location per-patch. I later introduced a V2 of the format that supported overwriting many locations in a single patch. Prior to PocketTool and PTPatch, very few people were creating mods for Minecraft PE. Without a mod-manager of any kind, the few (or maybe it was just Zhang), would have to modify the game binary manually, and then distribute the binary. Since this was kind of sketchy, IIRC, this was only done for the demo version of the game (for obvious reasons). I later released the source to GitHub: https://github.com/machinamentum/PocketTool
I found interest in the 3DS homebrew scene and made some minor contributions to some projects such as neobrain’s nihstro. I also wrote an OpenGL implementation on top of libcrtu; and experimented with writing a GLSL compiler.
I then explored my long-standing interest in emulators, and implemented a working (runs a couple homebrew games) PSX emulator. A lot of people speculated at the time that 3DS was not powerful enough to emulate N64 games without dynamic recompilation and without being able to flush icache, so I threw my hat in the ring and started working on an N64 emulator for 3DS, though I had never gotten to the point of being able to run software.
Around this time I also experimented with building a compiler for a new language: htn. I did not know much about compilers at the time, so it was largely an exploration of learing to generate code based on what I knew about assembly, and the code generated by C compilers.
At some point, I was feeling nostalgic for CSPSP, a fanstatic homebrew game inspired by CSGO by Kevin Chen; I ported the game to 3DS: CS3DS.
“Professional” Rapper Programmer
Thekla
In 2016, as a young fletchling, fresh out of the “fumbling around with programming for almost 10 years” phase, I was hired to work on “the language” known only in text as “jai”. Chris Lattner once asked me what the pronuciation was during a job interview and I laughed so hard that I never received a second interview.
I am the mysterious “joshua hewelsman” of legend
During my time with Thekla, I had:
- Written the LLVM backend
- Written debug info generators for Dwarf and CodeView
- Written a famously mediocre bindings generator using libclang
- Brought Linux support from mostly abandoned to being up to speed with Windows support
- Including implementing Modules for X11-windowing, game-controller, ALSA, etc..
- Implemented macOS support
- Including implementing Modules for many objc API’s, NSWindow-ing, GCController, CoreAudio, etc..
- Implemented Linux and macOS platform support for Order of the Sinking Star (then-called “sokoban”)
- in addition to the standard Modules support, this included things like file-system notifications for hot-reloading shaders and models.
- Implemented mac and Linux support for X64 code gen, and improved Windows support
- Wrote a 3D-rendered snake clone that someone then turned into some sort of weird shooter where the haad of the snake model rolls around.
- Maintained internal build automation software
- Fixed a compiler bug or two
- Fumbled trying to fix a compiler bug or two (or three)
Separate from my professional work, during the last year I had spent with the company, I had created a new programming language called Jiyu, as mentioned in my blog. Regrettably, my work on this project had led to a falling out with my employer, and my departure from the company.
Roblox
In 2020, I was hired to work on Roblox’s implementation of Lua, called Luau. Early on, I helped shipped the initial version of the static type-inference engine. Luau has a gradual type system; that is to say that user code may opt-in to annotating types on data for semantic enforcement, and the types for all unnannotated data is calculated based on the uses of the data. The type-system as used by the user is described better by https://luau.org/types/.
I then worked on implmenting a number of optimizations to the Luau interpreter and runtime, as well as helping to ship Parallel Luau, a Roblox-engine solution to being able to write parallizable code in Lua for executing in a Roblox experience (or withing Roblox Studio).
Later, I shipped (with some help) a sampling profiler for use withing the Roblox Developer Console: ScriptProfiler. As well as a developer API to use the ScriptProfiler internals as part of custom tooling in RobloxStudio: New Features in ScriptProfiler.
I also helped ship Native Code Generation for Luau, which supports x64 and ARM, ahead-of-time code generation, as well has some optimizations that come along with that. NCG is an interesting thing to do for a system like Lua(u) because the generated native code is essentially just an optimized, unrolled version of the interpreter loop. Thanks to this, optimizations can be applied to an intermediate representation based on inferred assumptions we can make about the code that we cannot normally assume in the interpreter. Furthermore, the native code path assumes optimal environmental conditions, such that we can assume we can do things like inline basic built-in library functions. If in any case that the user code does something unoptimal or modifies the environment such that these assumptions cannot be met, native code, exits its execution, and the code is resumed under the interpreter at the bytecode that would have been executing if we weren’t in native code.
Additionally, I worked on various changes to the Roblox engine, including things like auditing code for, implementing thread safety, and improving performance.
guy writing code
After leaving Roblox in early 2024, I decided to survive on some savings I had accumulated in order to work on projects that interest me. Currently, that includes:
- a 3D platforming game
- a new iPad IDE for writing C code
- the josh build system that lets users write their build scripts entirely in plain C
- a new scripting environment designed to work somewhat like an emulator, enabling interpretation of low-level systems languages (like C)
- a new C compiler
- a UEFI boot example with some convenience scripts for setting up tooling (written using
josh build!): uefi_example
I spent a large amount of time writing C++ code prior to going “independent,” so why all does all this stuff focus on C?
When I began working on the iPad IDE, I made the difficult decision to implement a C compiler and a VM runtime as the existing solutions kind of suck. For example, existing apps essentially integrate the entire clang+LLVM stack in interpreter mode. This works and has the advantage of supporting C++, but it comes with the cost of clang+LLVM’s compilation speed, waiting for clang+LLVM builds, dealing with clang+LLVM’s internal complexity if I wanted to implement C features that clang doesn’t have yet, and having to deal with clang’s API (clang’s C++ interface is not stable and changes frequently; the C API is stable but it incomplete and is kind of high friction to use).
Since C++ is extremely complex and requires a much larger standard library, I had to narrow my focus on a much simpler language: C.
Since, the IDE would only ship with a C compiler (at least, in the foreseeable future), I felt it necessary to write the entire compiler in C, and to exclusively use C for everything I can, except for the IDE app itself. Implementing my own C compiler enables an instant feedback loop in developing new features, much faster compilation times (for both me and the user), and much easier vertical integration into the iPad app. Implementing new C features like defer takes an just afternoon instead of days (or weeks).
