Posts

What am I hoping to achieve? Type systems usually express the input and output types of a function, but not what side effects the function may have. I want to be able to deny certain side effects in some parts of my code, for safety, correctness or documentation purposes. What are some examples of side effects to forbid? Must not panic, since that leaves my program in an undefined state. Must not access the network, to prevent unwanted calls. Must not access filesystem, to prevent reading local data or having slow performance. Must not write to the filesystem, to prevent causing damage to the persistent system state. Must not allocate memory, to prevent memory exhaustion errors for embedded systems. Must not cause interrupts, to prevent triple faults in interrupt handlers. Must not block, to prevent blocking event threads in async context. Must not syscall, to prevent manipulating the system state. Must not loop, to prevent unbounded loops making the system unresponsive. Must not recurse, to prevent stack overflows. Must not cause non-determinism, to make results deterministic and time independent. Must not branch, to ensure constant execution time, or better GPU core utilization. Must not divide, to prevent division by zero errors. Must not perform floating point arithmetic, to ensure financial code does not suffer rounding errors, or that code is portable to low-end CPUs. Must not spawn threads, to enforce single-threading. Must not lock, useful to ensure and communicate that functions are lock-free. Must not use atomics, to ensure that there is no cache contention risk. Must not use SIMD/vector extensions, to ensure the code remains portable or doesn’t force the CPU into an inefficient processor state. What are the benefits of such a system? There are several benefits to this mechanism: ...

What is wrong with the current compile lifecycle? It is slow. When developing, I value fast feedback. Immediate feedback. The faster I can see where my code is broken, the faster I can fix it. But currently there’s a 3-step process for this feedback: Modify code Run checks/lints/tests or examples Apply fixes Step 2 is usually the time-consuming part, since it requires compiling the code, linking it, running the tests, etc. This breaks my development flow. ...

How can we improve developer documentation? More thoughts on improving the documentation process and experience: A core issue with documentation is that it does not answer the right questions. Oftentimes, there is documentation, but it only rehashes the code, without adding any value, or describes some irrelevant aspect. My hypothesis is that by applying Question-Driven Documentation (QDD), i.e using questions as headings, and letting them drive the documentation process, we can improve the quality of the documentation. ...

What’s wrong with developer documentation? I have been thinking a lot lately about developer documentation and from my perspective, there are two main issues with it from my experience: It’s hard to find the relevant documentation for a piece of code. The documentation is outdated, and does not reflect the current state of the code I feel that often #2 is a direct consequence of #1. How do we fix this? Here’s my simple pitch to address these issues: ...