thu

One of the nice thing about having an underlying structured representation of those texts is that I can also render them to e.g. Markdown[1].

I've experimented about generating the Markdown files corresponding to multiple versions (archives) of a given text and committing them to the same Git repository to be able to see diffs or blames[2].

I would like to assign the proper dates to each commit, but given there are texts in e.g. 1791, it's not possible.

I've started the Slab templating language[0] to be able to define reusable HTML fragments. It means using a dedicated tool but hopefully not needing to resort to a real programming language.

Two, although it's possible to introspect a blaze-html -generated tree, you can't easily have tooling to, say, list HTML fragments, where they are used, which one are full HTML documents (i.e. starting with a doctype)... One of my goal with Slab is to have a "refactorable" language to write "large" HTML code bases (I'm mainly thinking of design systems reference implementations). Having a tool that can "see" the tree structure, the fragment calls, the list of files, ... opens new tooling opportunities.

I'm one of those people that says syntax doesn't matter; we should talk about semantic instead (and thus just adopt s-expressions for syntax). Yet, in this case, I think that a very lightweight syntax that maps clearly to HTML, in particular for non-programmers (e.g. designers), is very valuable.

Note also that I make available a statically-linked `slab` binary that makes super easy to start using Slab. You don't need a programming environment with a compiler and so on. (I'd like to try to create a Cosmopolitan[2] binary in the future.)

The `slab` binary also has a "watch" feature that rebuilds pages and reload the browse as you edit `.slab` files. I guess I mean that having an integrated tool can offer a very good developer (or designer ?) experience.

In particular, I tried to respect a principle often found in programming languages: user-defined elements (fragments) are no different than builtin ones. For example notice how `page` (which is user-defined) is used in the same way as as `body` (which is builtin) in the first code snippet of the introduction[1].

(In the future, I hope that instead of providing builtins, Slab will instead use libraries of elements. There is an undocumented feature to define elements[2].)

In Pug, to reuse bits of HTML, you can define mixins, but they are called with a `+` sign in front of their name. I also believe mixins can have expression arguments, but not other blocks of HTML. To pass blocks of HTML as "arguments", Pug provides the `extends` keyword, but I think it can only be used at the toplevel of a template. In Slab, the concept of fragments is a bit more uniform: a fragment can be used with expression arguments, and block arguments.

+15 years of professional experience mainly with Python

+4 years of hands-on technical leadership

I'd love to work with Haskell and Nix (my side projects use them), although I've been using Python professionally for about 10 years. I like to get my hands dirty and have always worked with things like CI/CD pipelines, provisioning VMs, and so on (for example, I've been using Docker since 2013). I'm used to complicated code bases that need serious improvement.

    1 + if true then 1 else a b + c

    ⟨+ 1 ⟨if␣then␣else␣ true 1 ⟨+ ⟨a b⟩ c⟩⟩⟩

What prompted me to do so was that the Wikipedia page in french mentioned a VM running multiple threads, which I thought was very interesting for 1989.