I can’t believe I’ve never tried making own my base class, considering that I’ve made my own CSS reset.

I mentioned it in my post about defining custom elements, so let’s start with the static register() method.

It's been a few years since I wrote about my challenges with
async/await-based systems and how they just seem to not support back
pressure well]]. A few years later, I do not
think that this problem has subsided much, but my thinking and
understanding have perhaps evolved a bit. I'm now convinced that
async/await is, in fact, a bad abstraction for most languages, and we
should be aiming for something better instead and that I believe to be
thread.

When I started a new PhD-level compilers course a few years ago,
I thought it was important to use a “hands-on” structure.
There is a big difference between understanding an algorithm on a whiteboard and implementing it, inevitably running into bugs when your implementation encounters real programs.
At the same time, I wanted students to get started quickly, without learning the overwhelming APIs that come with industrial-strength compilers.

I created Bril, the Big Red Intermediate Language, to support the class’s implementation projects.
Bril isn’t very interesting from a compiler engineering perspective, but
I think it’s pretty good for the specific use case of teaching compilers classes.
Here’s a factorial program:

Just as algebra is fundamental to the whole of mathematics, algebraic data types (ADTs) are fundamental to many common functional programming languages. They’re the primitives upon which all of our richer data structures are built, including everything from sets, maps, and queues, to bloom filters and neural networks.

I had a small insight yesterday while building a component for a small web app: the user interface for editing an incomplete value of sum type A+B needs to remember a product of input 2×A×B from the user

Learn how to apply established UI patterns for a more organized and maintainable codebase and discover the benefits of layering architecture in React development

tablature player in Rust.

Clojure was designed to be a general-purpose, practical functional language, suitable for use by professionals
wherever its host language, e.g., Java, would be. Initially designed in 2005 and released in 2007, Clojure is
a dialect of Lisp, but is not a direct descendant of any prior Lisp. It complements programming with pure
functions of immutable data with concurrency-safe state management constructs that support writing correct
multithreaded programs without the complexity of mutex locks.
Clojure is intentionally hosted, in that it compiles to and runs on the runtime of another language, such as
the JVM. This is more than an implementation strategy; numerous features ensure that programs written in
Clojure can leverage and interoperate with the libraries of the host language directly and efficiently.
In spite of combining two (at the time) rather unpopular ideas, functional programming and Lisp, Clojure has
since seen adoption in industries as diverse as finance, climate science, retail, databases, analytics, publishing,
healthcare, advertising and genomics, and by consultancies and startups worldwide, much to the career-altering
surprise of its author.
Most of the ideas in Clojure were not novel, but their combination puts Clojure in a unique spot in language
design (functional, hosted, Lisp). This paper recounts the motivation behind the initial development of Clojure
and the rationale for various design decisions and language constructs. It then covers its evolution subsequent
to release and adoption

Use enums instead.

With any blanket statements like this, there are always exceptions.
Though in general, I believe the use of enums is often a better choice compared to boolean, unless you really need to squeeze your data into one single physical bit.

Let’s talk about some of the fundamental software design principles, which are typically applied behind the scenes by designers.

Software architecture represents the result of a sequence of design decisions which take place over time as long as software system complexity increases.

For the sake of clarity, let’s define an architecture as a collection of components combined together via connectors, which represent constraints on how components interact.

These are my personal principles for building software. I hope to frequently update them as my views change. There can be
valid reasons for breaking them (they are principles, not laws), but in general I believe following
them works out well.

This is a collection of things I believe about computer programming as of today.
It’s based on my own experience.