Notes

Datastar is HTMX-like framework that attempts to minimize the amount of Javascript you using a few concepts: Use html attributes for dynamism prefixed with data- Easy in-document updates similar to Turbo Real-time updating via SSE Signals for client-side state If we compare it to other approaches, we can understand some of the tradeoffs: Unlike React, signals are global to a page and is expected to have less state than a full SPA. Complex UI elements are recommended to be web components with Datastar. Real-time updating via SSE for compression and automatic reconnects provided by the browser (instead of WebSockets which LiveView uses) Unlike HTMX, it uses mostly just plain Javascript so you don’t have to include hyperscript, Alpinejs or another supplementary library for more complex logic. HTML content is swapped via dom morph swaps instead of innerHTML replacement by default in an attempt to better preserve the DOM state. Datastar is explicitly NOT a Single Page Application framework. Whenever something should be another page, it should be a separate server-rendered page. As a default, complexity should be pushed towards the server: ...

ADTs is a fancy term for a type composed from other types. There are two kinds of Algebraic Data Types. Product Types Product types are structs and tuples, which contain a sequence of types. Most programming languages have product types, so ADTs are often seen as shorthand for sum types, but that’s technically inaccurate. Sum Types Sum types are unions plus enums. They contain one of the specified underlying types: ...

Monads are interfaces for sequencing behaviors related to a data type. Monads are similar to Unix pipes. They transform input and return the same output type. While pipes describe the function, Monads describe the data type flowing through pipes. Let’s look at pseudocode defining a monad: // Java: one of the best languages for defining interfaces... interface Monad<M, T> { // Return is a class method: static isn't legal java static Monad<M, T> Return(value T) Monad<M, U> Bind<U>(f Function<T, U>) // f = func(T) -> U } We define the Monad as a generic interface. M is the data type implementing the monad interface and T is the input type for pipeline functions. M is the output value and T is the input type. In the simplest case, both can be the same type, like Text in Unix pipes. ...

As part of trying out Svelte, I’ve also stepped into the modern web development ecosystem. I previously worked primarily in Clojurescript, so my reference point is based on being away from conventional web dev for many years. The Good Parts Getting Started is Easy Having not have to build anything yourself is can be nice if you want to deliver something quickly. This is doubly true when Svelte allows you to pull a library that doesn’t have explicit view framework support (eg - ReactJS). Need auth? Use AuthJS. Everything is so easy. ...

Disclaimer: I didn’t learn Svelte before v5, so this is an experience report on translating Svelte 4 code to 5. This is a blind jump into Svelte. The Basics Svelte components end in .svelte like .jsx or .tsx. They look more HTML-like than JavaScript. In comparison, ReactJS is more JavaScript-like than HTML. <script> let { name } = $props(); </script> <h1>Hello, {name}!</h1> Typescript To use TypeScript, add lang=”ts” to the script tag: ...

Background Since migrating this site to Hugo, I felt like it was finally time to avoid learning TOML. This assumes you don’t know TOML but know other data formats? Time to speedrun through. The 30-second Start You can think of toml as key value file format with namespace prefixes that translate to JSON: # this is a comment key = "value" [my-key-prefix] key2 = "value2" person.name = "John" Conceptually produces { "key": "value", "my-key-prefix": { "key2": "value2" }, "person": { "name": "John" } } Dot-notation indicates a nested object. In the spec, TOML calls objects tables. ...

One of the most interesting parts of generative testing (aka QuickCheck). Is state machine testing. The original purpose I built Fox was to explore state machine testing. In particular, the talk from John Hughes video was inspirational to exploring this further: In short, John makes a case: dynamically generating state machines to detect errors that is more effective and economical than traditional example based tests. There’s lots of work managing example based tests that can be better solved with generative testing. ...

I’m fascinated by how engineers read and interpret code that they work on a daily basis. It’s no doubt different for everyone, but few explain how they go about and understand a unfamiliar codebase. For me, being comfortable in a codebase usually means two things: Being able to jump to relevant, related parts of the code. Understand the implications of changing a piece of code Inside the system – impact of code quality. How does the code influence code in the same project? Outside the system – implications for human and program collaborators. How does the code influence other projects, teams, or users? Both can be addressed by following the data flow of the code. I refer to my strategy as assertions and assumptions. Take this arbitrary code snippet from Django: ...

When evaluating companies, its utmostly important to learn about the engineering culture. Culture for a company is simular to scope for code – culture provides a context for getting work done. Companies advertise their culture, but note that each company has a different culture. There’s plenty of articles about culture, so I won’t bother covering that. Just remember they aren’t necessarily the same. Companies tend not to be explicit about making sure their process matches what you expect. Be suspicious for a company that can’t explain it’s culture because that just means they’re not activitely trying to cultivate one. And that means it’s implicitly defined by the leaders of the company. Even if they choose not to define it. ...

Trying to concisely describe concepts is an interesting exercise. The ideal goal is to build upon existing concepts, but as you add more concepts you run the risk of being inconsistent. So with at most two sentences, I present a list of common programming concepts. This goes without warning that lossy compression is inevitable. Data: Ones and zeros. Values: Meaningful data. Types / Encodings: Interpretations of values. State: A value that changes over time. Usually also considered a Value. Variables: Names for values over time. Collections: A value that’s a a group of values of same type. Structs: A value that’s a group of values with possibly differing types. Classes: Structs with functions that have itself as the first argument. Inheritance: A concise way to implement a class by referring to part of its implementation from one class. Multiple Inheritance: A class that inherits from multiple other classes. Extensions: Adding methods to a previously defined type. Mixins: Adding (Multiple) Inheritance to a previously defined type. Interface / Protocols: Inheritance of a class that has only functions that should be implemented by the class that inherits it. Traits: Interfaces that may have function implementations. Generics: Treating a type as a variable. Allows algorithms independent of specific types. Type Classes: Generic Interfaces. Monad: An interface defining the expected behavior for map. Functor: An interface defining the expected behavior for apply. Pointers: A value that indicates where to find another value. An home address is a pointer to a home. Big-O Notation: A method to estimate the number of main-memory operations Slice: A value that is a pointer and length into an existing collection Value Objects: An struct / class with equality and hashCode semantics. Object-Oriented Programming: The concept of classes talking to each other using value objects. Procedure: A sequence of operations to execute. Most programming languages mean procedure when they say function. Function: Vaguely defined / blurred by current norms. See Procedure. Pure Function: A procedure that returns the same output for the same inputs. Side Effects: Any observable state that occurs besides a return value. Functional Programming: The practice of using less state and more pure functions. Code: A value that is a series of operations AST (Abstract Syntax Tree): Hierarchy of typed code Program: A collection of code that a computer that can execute. Compiler: Program that take code and produce programs. Interpreter: A program that executes code without producing a program. Emulator: A program that mimics the behavior of hardware. Virtual Machine: A computer emulator where the hardware may not actually exist (eg - Java Virtual Machine). Static: Known at compile-time. Dynamic: Known at execution-time. Type Checker: A program that validates what types flowing through your code. Type Inference: A compiler or interpreter feature can that deduce types without always explicitly specifying it in code. Optimization: Writing code for the computer first, instead of humans. Performance: Turning memory operations for lower frequency, and higher throughput. Reference Counting: Counting number of owners of a piece of memory to know when to free it. Garbage Collection: An embedded program that frees another program’s memory that is no longer being used. Reflection: Code that can inspect and/or modify itself as it’s executing. Macros: An operation that can be translated to a sequence of operations before program execution. JIT (Just-In-Time) Compilation: A feature of interpreters or emulators that compiles code during its execution. The last concept pushes the limits of definitions this concise. Some interesting implications result from these definitions: ...