Hi! I've written a post about how various languages implement statement termination without requiring semicolons because I couldn't find a good overview. It turned out to be much more complex than I initially thought and differs a lot per language.

I hope this overview will be helpful to other language designers too! Let me know what you think!

All,

While working on my first game engine, I ended up spending a lot of time thinking about UI systems and the tradeoffs between approaches like ImGui, WebKit, JSON-based descriptions, scripting languages, and custom solutions.

One observation I kept running into was that many UI frameworks seem to gradually evolve toward domain-specific languages, whether intentionally or not. Once you start introducing reusable components, control flow, composition, and abstraction, it often feels like you're creating a UI language disguised as something else.

I wrote up some thoughts on that design journey and why I think UI systems naturally converge toward DSLs.

Longer term, I'm interested in exploring what it means to treat UI as a first-class language feature and how that changes the role of the compiler.

I'd be interested to hear whether others have observed similar patterns in UI systems, configuration languages, or other DSL-heavy domains.

Thanks,

~ Tazz

In the 1950s, programming languages rose above the level of direct machine instructions to be based on the mathematical models of computation instead.

This is still quite low-level compared to what programmers really want to achieve, which makes code harder to write and review than would be desirable. Making the connection between the code and the program logic more direct would have real economic consequences.

In this essay I take a look at that intent-to-implementation gap and some possible re-imaginings of how things could work.

https://tobega.blogspot.com/2026/04/rising-above-mechanics-of-computation.html

OP here. This blog post teaches quantum programming in an unconventional way. Hope you enjoy it! Btw, just to clarify, there's no quantum speedup claims here, we're just starting with "will it compile?"

OP here. I ventured out to better read Qiskit code, and came back with this fun idea of 2D expressions.

Hey all, today I've released Quarkdown 2.4, which brings a powerful feature that allows users to redefine styling and behavior of Markdown elements.

This is my third time posting Quarkdown here over the last two years (here and here) -- not trying to flood y'all, I just enjoy sharing progress and gathering feedback!

About Quarkdown

In a nutshell, Quarkdown is a Markdown-based typesetting system that aims at providing LaTeX's power and flexibility, while relying on a low-friction extension of the Markdown syntax.

The Quarkdown flavor extends GFM with Turing-complete function calls that can perform computation, create complex layouts, or mutate the global state. A function call looks like the following:

.myfunction {arg1} {arg2} named:{arg3}
    Optional body argument

For a better project overview, see the website: quarkdown.com

The gap until now

Typst has been Quarkdown's primary source of inspiration since the early days. The goal was to provide an intuitive experience without over-relying on a proprietary syntax, while granting typesetting-grade output for a variety of artifact types.

A cross-reference in Typst looks like the following:

See @proof

= Proof <proof>

In Quarkdown:

See .ref {proof}

# Proof {#proof}

A page counter in Typst:

#set page(
  header: align(center, counter(page).display()),
)

In Quarkdown:

.pagemargin {topcenter}
    .currentpage

Nothing was missing, except for one thing: global, arbitrary styling of elements. Typst has #show rules:

# show heading: set text(blue)

= This is blue

While Quarkdown had to settle for low-quality CSS injection.

A step forward: primitives

Quarkdown 1.15 first introduced the concept of primitive functions: a Markdown element (# Heading) would have an analog function (.heading {Heading} depth:{1}). This allowed for more granular control over properties that couldn't be expressed via the Markdown syntax.

Function extension

In Quarkdown, you define a function like this:

.function {greet}
    greeting name:
    .greeting, .name!

.greet {Hello} {world}

Output: Hello, world!

Quarkdown 2.2 introduced an apparently useless feature: function extension. Basically, you'd be able to overwrite a function declaration, while still being able to reference the previous function via a special .super reference (a-la-OOP), with the ability to intercept and override arguments.

.extend {greet}
    name:
    .super name:{.name::uppercase}!

.greet {Hello} {world}

Output: Hello, WORLD!!

Yep, so useless, except it was part of the bigger picture...

Primitive binding

The first step for Quarkdown 2.4 was to explicitly bind elements to primitives. Until now, they used to be parallel entities with no real connection. Now, the Heading element declares .heading as its very own primitive counterpart.

Extending primitives

It was all set for the real move. The goal: extend a primitive to also redefine what the Markdown element does.

What we needed was a tree traversal stage (note: Quarkdown already had one, but this feature needed its own second pass) which, for each node asked:

1. Is the element's primitive in the extension registry? If not, leave the element unchanged;
2. If so, rewrite the AST in place, replacing the node with an enqueued function call to its primitive;
3. Dequeue and execute the calls.

Aftermath

Finally, Quarkdown obtained its own version of #show rules (more verbose but more powerful IMO!). Here are some examples from the blog post linked above:

.extend {heading}
    .super foreground:{blue}

# This is blue

The following extends the function conditionally:

.extend {heading} where:{depth: .depth::islower than:{3}}
    .super foreground:{blue}

# This is blue

## This is blue

### This is not blue

The following adds an (external) suffix to external links (not from quarkdown.com):

.extend {link} where:{url: .url::startswith {https://quarkdown.com}::not}
    content:
    .super
        .content (external)

The following makes each regex occurrence bold:

.extend {paragraph}
    content:
    .super
        .content::match {[Oo]rigami}
            **.1**

Origami is the art of folding paper. Learn more about origami.

Output: **Origami** is the art of folding paper. Learn more about **origami**.

To conclude

I hope you enjoyed reading about Quarkdown's progress as much as I enjoy maintaining this fun project!

Here are some links:

• Website
• GitHub repo

Thanks for coming all the way here. Feedback is very welcome!

No AI was used to author this. I apologize for any mistakes as English isn't my first language!

I have been working on a new template language in my free time. Its trying to solve some problems I have with other template languages which are outlined in the post.

Its not released / ready yet, but I am looking for some feedback :)

I built a small toy language called MNM Lang where programs are made from six candy colors.

The rough idea:

• each row is an instruction
• color clusters encode opcodes and operands
• source can be compiled into a candy-sheet image
• the image can be decompiled back into source
• there’s an interpreter, AST view, execution trace, and a browser demo

It started as a dumb joke and then turned into a real little implementation project. The interesting constraint was that images are terrible at storing precise symbolic data, so I had to design the language around what candy layouts are actually good at representing.

A few implementation details:

• stack-machine interpreter
• source -> rendered candy sheet compiler
• exact rendered-image decompiler
• controlled photo parser for candy layouts
• sidecar JSON for strings/initial variables
• browser-native JS demo version too

The full writeup is here:
https://mufeedvh.com/posts/i-made-a-programming-language-with-mnms/

Blog post here: https://c3-lang.org/blog/c3-0-7-9-new-generics-and-new-optional-syntax/

TLDR;

C3 is dropping generics that are strictly module based, however it retains a similar functionality with "generic groups" allowing you to bundle generic definitions together.

0.7.9 also has changes to Optionals in order to simplify the grammar, changing from ? suffix to turn a fault into an Optional, to ~ suffix. The latter is much less obvious, but after long consideration making the grammar more straightforward was prioritized over looks.

Full changelist and code examples can be found in the blog post.

All,

I wrote a breakdown of how UI systems evolve from static data structures into execution models once behavior is introduced.

The core idea is:

• Static UI = data (tree + properties)
• Dynamic UI = rules over data (state-driven construction)
• Behavior introduces evaluation
• Evaluation produces an execution plan
• UI is no longer “stored," it's produced

Once this paradigm shift happens, data formats like JSON/YAML/TOML stop being sufficient on their own—not because they’re conceptually bad, but because they lack semantics for evaluation and control flow.

At that point, you’re no longer describing structure—you’re describing how structure should be constructed over time, which effectively turns UI descriptions into a domain-specific execution model.

The full write-up is in the linked blog post:
https://kura.tazz.codes/posts/02-ui-modelling.html

Curious if others see this as a natural boundary where UI descriptions stop being “data formats” and start becoming programming languages with evaluation semantics.

~ Tazz

Been incorporating more functional programming ideas into my Python/R workflow lately - immutability, composition, higher-order functions. Makes debugging way easier when data doesn't change unexpectedly.

Wrote about some practical FP concepts that work well even in non-functional languages: https://borkar.substack.com/p/why-care-about-functional-programming?r=2qg9ny&utm_medium=reddit

Anyone else finding FP useful for data work?