Combo</th>	Result</th></tr></thead>
`Q</code> + A</code></td>`	Enter</td></tr>
`W</code> + S</code></td>`	Backspace</td></tr>
`E</code> + D</code></td>`	Escape</td></tr>
`R</code> + F</code></td>`	Delete</td></tr> </tbody></table> These vertical combos only work with keycaps that are large or flat enough to prevent large gaps between adjacent keys. But you can come up with any kind of combination that suits your situation better.</p> This frees up some keys on the navigation layer:</p> I took the liberty of adding a `Shift+Tab</code> (Bktb</code>) macro to the navigation layer for the sake of symmetry and practicality.</p>` Keymap</a></h2> Our current layout has almost completely eliminated lateral movements for our fingers. Unfortunately, we still have to move our index fingers to the T</code>/G</code>/B</code> and Y</code>/H</code>/N</code> inner columns. We can improve the situation by changing our keymap and placing rarely used keys there instead.</p> Keymaps are a very complex topic and how optimal they are depends largely on what you are going to type. For example, a keymap optimized for typing english prose might not be that good for typing spanish prose.</p> Inner column usage is only one of the stats that make a keymap more ergonomic. Modern keymaps are designed using the help of an analyzer program. The keymap designer feeds a large corpus of text (for example all of wikipedia) to the program. The program then computes all the stats of a given keymap with respect to the provided corpus. The designer then decides if the keymap is good enough depending on how much weight he gives to each of the stats. Here</a>'s a website where you can find a bunch of keymaps with their stats.</p> Some keymap designers choose to relax some conventional constraints to open up additional optimization opportunities. The most common trade-off is to put a letter on a thumb key (typically E</code>, R</code> or T</code>). Another one is to put some rarely used letters on a different layer.</p> One such person is the creator of the Hands Down</em></a> keymaps.</p> We can adapt his Vibranium v</a> variation for our example keyboard:</p> To make this work we also needed to make a few changes to our thumb keys:</p> Our layer keys are now both on the left side.</li> The Nav</code> key is a tap-hold key that produces R</code> when tapped and gives access to our numpad/navigation layer when held.</li> The Sym</code> key is a tap-hold key that gives access to our shortcut layer when tapped and to our symbol layer when held.</li> </ul> Some of you might be wondering where we should put our f-keys. A simple solution would be to put them on the right side of our shortcut layer:</p> Making the keyboard</a></h2> Now that we have designed our perfect keyboard layout, we probably want to hold it in our hands and use it. I hope I can write an entire DIY tutorial for this keyboard in the future. In the meantime, you can check out this</a> tutorial.</p> The easiest solution is to buy a similar keyboard though. The Ferris Sweep</em></a>, the Corne</em></a> and the Totem</em></a> are examples of small ergonomic keyboards you can buy off the shelf.</p> I'm currently using a layout similar to the one we discussed on a Corne keyboard.</p> Conclusion</a></h2> Two years ago, as I was frustrated by my subpar typing experience, I went down the rabbit hole of ergonomic split keyboards and optimized keymaps. It has now been more than a year that I've switched to the layout I described in this article as my daily driver. I can definitely say that my typing experience is much more enjoyable and completely painless now.</p> On the subject of pointer syntax 2026-03-29T00:00:00+00:00 The C programming language was initially designed by Dennis Ritchie and one of his key design principles was that declaration syntax should mimic expression syntax1</a></sup>.</p> //</span> Declarations </span></span>char</span> </span>p;</span> </span>int</span> f</span></span>(</span></span></span>)</span></span></span>;</span> </span> </span>//</span> Expressions </span></span>return</span> </span>p;</span> </span>return</span> f</span>(</span></span></span></span>)</span></span></span>;</span> </span></code></pre> The declaration char p;</code> means that the expression p</code> will be of type char</code>. The declaration int f();</code> means that the expression f()</code> will be of type int</code>.</p> This principle also applies to declarations that have multiple declarators:</p> int</span> main</span></span>(</span></span></span>)</span></span></span> </span>{</span></span></span> </span></span></span> int</span> x =</span> 5</span>;</span> </span></span></span> int</span> </span>p =</span> &</span>x,</span> f</span>(</span></span></span></span>)</span></span></span>;</span> </span></span></span> return</span> f</span>(</span></span></span></span>)</span></span></span> +</span> </span>p;</span> </span></span></span></span></span>}</span></span></span> </span> </span>int</span> f</span></span>(</span></span></span>)</span></span></span> </span>{</span></span></span> </span></span></span> return</span> 5</span>;</span> </span></span></span></span></span>}</span></span></span> </span></code></pre> In the program above, the declaration int p = &x, f();</code> means that both p</code> and f()</code> will be expressions of type int</code>.</p> However, we can see that this principle is not an absolute rule:</p> int</span> main</span></span>(</span></span></span>)</span></span></span> </span>{</span></span></span> </span></span></span> int</span> add</span>(</span></span></span>int</span>,</span> int</span></span></span>)</span></span></span>;</span> </span></span></span> return</span> add</span>(</span></span></span>3</span>,</span> 4</span></span></span>)</span></span></span>;</span> </span></span></span></span></span>}</span></span></span> </span> </span>int</span> add</span></span>(</span></span></span>int</span> a</span>,</span> int</span> b</span>)</span></span></span> </span>{</span></span></span> </span></span></span> return</span> a +</span> b;</span> </span></span></span></span></span>}</span></span></span> </span></code></pre> In the example above, the declaration int add(int, int);</code> does not mean that add(int, int)</code> will be an expression of type int</code>. It is not considered a well-formed expression to begin with.</p> The way to think about it is that add(X1, X2)</code> (X1</code> and X2</code> being expressions of type int</code>) is an expression of type int</code>.</p> Array declaration syntax is an even worse offender:</p> int</span> a[</span>5</span>]</span></span> =</span> {</span>0</span>,</span> 1</span>,</span> 2</span>,</span> 3</span>,</span> 4</span>}</span></span>;</span> </span></code></pre> Here, applying the "declaration syntax mimics expression syntax" is not only wrong but could also be harmful. The expression a[5]</code> would cause an out-of-bounds access error.</p> Nonetheless, understanding the spirit of this design principle can help us decipher more complex declarations:</p> int</span> (</span></span></span></span>(</span></span>foo</span>(</span></span></span>int</span> a</span></span>)</span></span></span>)</span></span>(</span>double</span>,</span> char</span> </span>)</span></span></span>)</span></span></span>(</span>long</span>)</span></span>;</span> </span></code></pre> Declarations in C should be read inside-out starting with the name of the declared entity (foo</code> in this example). Prefix operators (such as </code>) have lower precedence compared to postfix operators (such as the function call operator()</code>).</p> Knowing this fact allows us to establish that foo</code> is a function which has a parameter of type int</code>.</li> We know that it returns a pointer since the value returned by foo</code> can be dereferenced (foo(int a)</code>).</li> We know that the returned pointer points to a function that has a parameter of type double</code> and a parameter of type char </code> ((foo(int a))(double, char )</code>).</li> That function returns a pointer ((foo(int a))(double, char )</code>).</li> That pointer points to a function that has a parameter of type long</code> and returns a value of type int</code>.</li> </ol> It is obviously not obvious at a glance that foo</code> is a function which returns a pointer to a function which returns a pointer to a function which returns a value of type int</code>.</p> In fact, declarations can become so hard to read that the maintainer of the Fish</a> shell created a website</a> that deciphers C declarations for you.</p> Even though declarations in C are notoriously hard to read and write, expressions can also be tricky due to their many nested parentheses.</p> My goal here is not to write a C language tutorial or explain in depth all the implications of this principle but to discuss language design.</p> A postfix indirection operator</a></h2> In The Development of the C Language</a>, Dennis Ritchie mentions that declarations and expressions involving pointers would be more readable if the indirection operator was a postfix operator.</p> Let's imagine for a moment that !</code> is the postfix indirection operator.</p> int</span> main</span></span>(</span></span></span>)</span></span></span> </span>{</span></span></span> </span></span></span> int</span> x =</span> 5</span>;</span> </span></span></span> int</span> p!</span> =</span> &</span>x;</span> </span></span></span> return</span> p!</span>;</span> </span></span></span></span></span>}</span></span></span> </span></code></pre> The declaration of foo</code> would now look like the following:</p> int</span> foo</span></span>(</span></span></span>int</span> a</span>)</span></span></span>!</span>(</span>double</span>,</span> char</span> !</span>)</span></span>!</span>(</span>long</span>)</span></span>;</span> </span></code></pre> It can almost be read from left to right. We just have to go back at the beginning to read the type specifier (int</code>). It is clearer that foo</code> is a function that takes an int</code> and returns a pointer to a function that takes a double</code> and a char !</code> and returns a pointer to a function that takes a long</code> and returns an int</code>.</p> Ideally, the type specifier should go at the end but we would need a keyword to introduce declarations:</p> let p !</span>int</span> =</span> &</span>x;</span> </span>let a [</span>3</span>]</span></span>int</span> =</span> {</span>1</span>,</span> 2</span>,</span> 3</span>}</span></span>;</span> </span>let foo</span></span>(</span></span></span>a int</span>)</span></span></span>!</span>(</span>double</span>,</span> !</span>int</span>)</span></span>!</span>(</span>long</span>)</span></span> int</span>;</span> </span></code></pre> A postfix indirection operator also removes the need for the arrow operator -></code>.</p> //</span> Without arrow operator </span></span>return</span> (</span></span>pointer)</span></span>.</span>property</span>;</span> </span> </span>//</span> Arrow operator </span></span>return</span> pointer-></span>property;</span> </span> </span>//</span> Postfix indirection operator combined with the '.' operator </span></span>return</span> pointer!</span>.</span>property</span>;</span> </span></code></pre> Another issue that the prefix </code> operator causes occurs during parsing2</a></sup>. Consider the following code snippet:</p> a </span> b;</span> </span></code></pre> It is ambiguous during parsing whether a * b;</code> is an expression statement or a declaration of a variable named b</code> of type "pointer to a</code>". This ambiguity complicates and slows down tools such as formatters, linters and syntax highlighters.</p> Other languages</a></h2> There are many other languages which have pointers and it's interesting to see how familiarity and popularity shape programming language design more than anything else.</p> Pascal</a></h3> Pascal and C emerged around the same period but Pascal used ^</code> as a postfix indirection operator from the very beginning.</p> The syntax to access fields of a record then becomes trivial: p^.field</code>.</p> Ada</a></h3> Ada emerged a few years later than C and Pascal. It has "access types"3</a></sup> which are roughly equivalent to pointers. Ada uses .all</code> as a postfix indirection operator. It also has an implicit dereferencing feature to access fields of a record which means it is possible to write Ptr.Field</code> instead of Ptr.all.Field</code>.</p> Rust</a></h3> Rust uses </code> as a prefix indirection operator just like C and has implicit dereferencing just like Ada. Rust also has implicit borrowing when calling methods.</p> Declaration syntax is not tied to expression syntax so declarations stay readable.</p> Despite its implicit borrowing/dereferencing features and its .deref()</code> method, there are still discussions about adding postfix borrowing and dereferencing operators4</a></sup>.</p> Go</a></h3> Go also uses the same operators as C and has implicit dereferencing. It changes the syntax of declarations to make them readable.</p> Zig</a></h3> Zig uses .</code> as a postfix indirection operator.</p> Odin</a></h3> Odin uses the same operator as Pascal.</p> Hare</a></h3> Hare is similar to Go and Rust in this regard.</p> C3</a></h3> C3 uses the same operators as C.</p> V</a></h3> V uses the same operators as C.</p> Conclusion</a></h2> Some would argue that language designers should completely avoid unary operators5</a></sup>. Others would argue that all unary operators should have the same fixity. My stance is not that extreme.</p> However, Pascal appeared in the 1970s and Dennis Ritchie mentioned in 1993 that a postfix indirection operator would be better. I find it unfortunate that the language designers of Go, Rust, Hare, C3, and V made the mistake of disregarding this insight.</p> When designing a new language (especially a spiritual successor to C) which breaks source retrocompatibility, avoiding simple improvements like making a prefix operator postfix because of familiarity6</a></sup> is bad design.</p> The Development of the C Language</a> ↩</a></p> </li> Lexer Hack</a> ↩</a></p> </li> Access Types</a> ↩</a></p> </li> Postfix borrow/deref</a> ↩</a></p> </li> Unary Operators are Unnecessary</a> ↩</a></p> </li> Familiarity</a> ↩</a></p> </li> </ol> </section> Creating this blog using Zola, Abridge and Netlify 2025-11-04T00:00:00+00:00 I have been thinking about setting up a blog for a long time and that time has finally come.</p> Tech Stack</a></h2> This blog relies mainly on Zola</a> which is a static site generator written in Rust and Abridge which probably is the most advanced theme for Zola. This stack makes the website particularly fast to build, load and offers great SEO out of the box.</p> For hosting, I use Netlify for free which allows building this website directly from a private Git repository.</p> Setup</a></h2> The first step was to install</a> Zola on my system. I could then start setting up my blog and Abridge</a>.</p> #</span></span> Create Zola website</span> </span></span>yes</span></span> "</span>"</span></span></span> \|</span> zola</span></span> init mysite</span> </span>cd</span></span> mysite</span> </span> </span>#</span></span> Turn it into a git repository and add Abridge as a submodule</span> </span></span>git</span></span> init</span> </span>git</span></span> submodule add https://github.com/jieiku/abridge.git themes/abridge</span> </span>git</span></span> submodule update --</span>init</span> --</span>recursive</span></span> </span>git</span></span> submodule update --</span>remote</span> --</span>merge</span></span> </span> </span>#</span></span> Copy essential files for Abridge to my website</span> </span></span>rsync</span></span> themes/abridge/.gitignore .gitignore</span> </span>rsync</span></span> themes/abridge/config.toml config.toml</span> </span>rsync</span></span> themes/abridge/content/_index.md content/</span> </span>rsync</span></span> -</span>r</span> themes/abridge/COPY-TO-ROOT-SASS/*</span> sass/</span> </span>rsync</span></span> themes/abridge/netlify.toml netlify.toml</span> </span>rsync</span></span> themes/abridge/package_abridge.js package_abridge.js</span> </span>rsync</span></span> themes/abridge/package.json package.json</span> </span></code></pre> I then went to the config.toml</code> file and uncommented the following line.</p> #</span>theme = "abridge"</span> </span></code></pre> Making it my own</a></h2> In my config.toml</code>, I changed a few things such as the base_url</code>, title</code>, description</code>, author</code> and keywords</code> keys. I also commented out the textlogo</code> so that the name of my blog would appear instead of the Abridge logo.</p> I then added a favicon-32x32.png</code> file to the static</code> folder and commented out all the other icons in config.toml</code>. It doesn't look great but at least it's mine.</p> PWA</a></h2> I could then easily turn my website into a progressive web app thanks to Abridge. This allows users to install my website as if it was a native application.</p> I copied the necessary manifest.json</code> file.</p> cp</span></span> themes/abridge/static/manifest.json static/</span> </span></code></pre> I then modified it with the name of my blog and added my icon files.</p> And finally, I ran the abridge script to generate the minified manifest file.</p> npm</span></span> install</span> </span>npm</span></span> run abridge</span> </span></code></pre> Netlify</a></h2> The last thing I had to do before publishing was modify the netlify.toml</code> file to adapt it to my url.</p> Conclusion</a></h1> Building a performant static blog with advanced features is pretty easy nowadays. And I hope I will be publishing many articles on this blog.</p>

A better keyboard layout

2026-07-01T00:00:00+00:00

Two years ago, as I was touch-typing on my keyboard at my day job, I realized that I often made mistakes when I switched rows. My fingers would end up between two keys instead of landing on one specific key.

For example, if I pressed H</code> with my right index finger and then tried to press U</code>, I would often press Y</code> instead or press both Y</code> and U</code> at the same time.

Stagger</a></h2> The main reason why this happens is that the top row is staggered asymmetrically by 0.25 keys to the left with respect to the home row while the bottom row is staggered by 0.5 keys. It means that your fingers have to move horizontally by either 0.25 or 0.5 keys when switching rows. This requires a lot of training to be able to do accurately and consistently while touch-typing. A marginally better alternative would be to make the row stagger symmetrical. Horizontal movements when switching rows would then consistently be 0.5 keys. Unfortunately, this doesn't completely solve my accuracy problem. According to the standard touch-typing rules, I'm supposed to hit the T</code>, G</code>, B</code> keys with my left hand and the Y</code>, H</code>, N</code> keys with my right hand. It means that both of my hands should move along a top-left to bottom-right axis when switching rows. This goes against what is easy and natural for muscle memory. It would be much more intuitive if our hands moved along mirrored axes: However, it is still uncomfortable and hard to move our hands and fingers horizontally. It is more natural to move fingers vertically. Thus, we can do even better if we almost completely eliminate horizontal movement. The naive approach would be the following: This ortholinear keyboard layout still has 2 obvious flaws. The first issue is that it forces your hands to be parallel which puts strain on your wrists. The second issue is that it doesn't take into account that fingers all have different lengths. The solution is to split our keyboard into 2 parts, rotate them to match the most comfortable angle for our wrists and introduce columnar stagger. The Atreus keyboard layout is such an example: We'll keep the ortholinear layout for the rest of this article as it is easier to modify. Layers</a></h2> Now that we've explored the subject of stagger extensively, let's talk about the second biggest ergonomy killer: hand movement. Doesn't reaching for the numpad or even the Escape</code> key feel exhausting? What if we had another key like Shift</code> that gave you access to another layer of keys? We can split our space bar into multiple thumb keys and use one of them as a layer key: This layout provides multiple benefits: It provides one-handed access to the numpad with our left hand while we use the mouse with our right hand.</li> It provides access to the navigation keys without moving our right hand.</li> It removes the far right column of the keyboard which reduces the strain on our right hand.</li> </ul> It might be hard to keep our layer key down while accessing the bottom row one-handed. Let's lower our thumb keys to make it easier: The number row is redundant with our numpad/navigation layer but we don't have enough space to put all of our symbols on the same layer. We could make our left layer key and our right layer key toggle different layers. The benefits of this layout are the following: No need to stretch our hands to reach the number row for symbols.</li> Our pinkies are provided some relief by eliminating the outer columns.</li> No need to alternate between the left and right Shift</code> keys when typing consecutive uppercase letters.</li> </ul> We still have to twist our fingers in uncomfortable ways to use common shortcuts such as Ctrl-z</code>, Ctrl-x</code>, Ctrl-c</code> and Ctrl-v</code> one-handed. A solution for this would be to turn our Nav</code> layer key into a tap-hold key. When we press a key while we hold Nav</code> down, we would get a key from our navigation/numpad layer. But if we just tap Nav</code> and then press a key, the next key we would get would be from our shortcut layer. Our shortcut layer could look something like the following: Ideally, we shouldn't have to stretch our hands at all to reach for our modifier keys (Ctrl</code>, Win</code> and Alt</code>). Home Row Mods</a></h2> This is where home row mods come into play. You can put modifier keys on your home row using tap-hold keys. For example the S</code> and L</code> keys could double as the Ctrl</code> key when held instead of tapped. The main drawback of this approach is that you can accidentaly trigger shortcuts while typing. Fortunately, a member of the ergonomic keyboard community has mostly solved this problem. You can read more about it here: Urob's Timeless Home Row Mods</a>. You can probably decrease false positives further by moving your mod keys to the bottom row. Our keyboard now looks like the following without dedicated mod keys: Combos</a></h2> There are some keys that come in handy no matter what layer you are on and you often want them accessible even while holding your mouse. For me, it's mainly Backspace</code> but I also like having Enter</code>, Escape</code> and Delete</code> on all of my layers. How can we make this happen even though our layers are mostly full on the left half of our keyboard? The solution is to set up key combinations. By pressing two keys at the same time, we can produce the signal of a different key. For example, when I press W</code> and S</code> at the same time, my keyboard could produce the signal for Backspace</code> instead. Here are a few we could use for our keyboard: Combo</th> Result</th></tr></thead> Q</code> + A</code></td> Enter</td></tr> W</code> + S</code></td> Backspace</td></tr> E</code> + D</code></td> Escape</td></tr> R</code> + F</code></td> Delete</td></tr> </tbody></table> These vertical combos only work with keycaps that are large or flat enough to prevent large gaps between adjacent keys. But you can come up with any kind of combination that suits your situation better. This frees up some keys on the navigation layer: I took the liberty of adding a Shift+Tab</code> (Bktb</code>) macro to the navigation layer for the sake of symmetry and practicality. Keymap</a></h2> Our current layout has almost completely eliminated lateral movements for our fingers. Unfortunately, we still have to move our index fingers to the T</code>/G</code>/B</code> and Y</code>/H</code>/N</code> inner columns. We can improve the situation by changing our keymap and placing rarely used keys there instead. Keymaps are a very complex topic and how optimal they are depends largely on what you are going to type. For example, a keymap optimized for typing english prose might not be that good for typing spanish prose. Inner column usage is only one of the stats that make a keymap more ergonomic. Modern keymaps are designed using the help of an analyzer program. The keymap designer feeds a large corpus of text (for example all of wikipedia) to the program. The program then computes all the stats of a given keymap with respect to the provided corpus. The designer then decides if the keymap is good enough depending on how much weight he gives to each of the stats. Here</a>'s a website where you can find a bunch of keymaps with their stats. Some keymap designers choose to relax some conventional constraints to open up additional optimization opportunities. The most common trade-off is to put a letter on a thumb key (typically E</code>, R</code> or T</code>). Another one is to put some rarely used letters on a different layer. One such person is the creator of the Hands Down</a> keymaps. We can adapt his Vibranium v</a> variation for our example keyboard: To make this work we also needed to make a few changes to our thumb keys: Our layer keys are now both on the left side.</li> The Nav</code> key is a tap-hold key that produces R</code> when tapped and gives access to our numpad/navigation layer when held.</li> The Sym</code> key is a tap-hold key that gives access to our shortcut layer when tapped and to our symbol layer when held.</li> </ul> Some of you might be wondering where we should put our f-keys. A simple solution would be to put them on the right side of our shortcut layer: Making the keyboard</a></h2> Now that we have designed our perfect keyboard layout, we probably want to hold it in our hands and use it. I hope I can write an entire DIY tutorial for this keyboard in the future. In the meantime, you can check out this</a> tutorial. The easiest solution is to buy a similar keyboard though. The Ferris Sweep</a>, the Corne</a> and the Totem</a> are examples of small ergonomic keyboards you can buy off the shelf. I'm currently using a layout similar to the one we discussed on a Corne keyboard. Conclusion</a></h2> Two years ago, as I was frustrated by my subpar typing experience, I went down the rabbit hole of ergonomic split keyboards and optimized keymaps. It has now been more than a year that I've switched to the layout I described in this article as my daily driver. I can definitely say that my typing experience is much more enjoyable and completely painless now. On the subject of pointer syntax 2026-03-29T00:00:00+00:00 The C programming language was initially designed by Dennis Ritchie and one of his key design principles was that declaration syntax should mimic expression syntax1</a>. // Declarations char p; int f(); // Expressions return p; return f(); </code></pre> The declaration char p;</code> means that the expression p</code> will be of type char</code>. The declaration int f();</code> means that the expression f()</code> will be of type int</code>. This principle also applies to declarations that have multiple declarators: int main() { int x = 5; int p = &x, f(); return f() + p; } int f() { return 5; } </code></pre> In the program above, the declaration int p = &x, f();</code> means that both p</code> and f()</code> will be expressions of type int</code>. However, we can see that this principle is not an absolute rule: int main() { int add(int, int); return add(3, 4); } int add(int a, int b) { return a + b; } </code></pre> In the example above, the declaration int add(int, int);</code> does not mean that add(int, int)</code> will be an expression of type int</code>. It is not considered a well-formed expression to begin with. The way to think about it is that add(X1, X2)</code> (X1</code> and X2</code> being expressions of type int</code>) is an expression of type int</code>. Array declaration syntax is an even worse offender: int a[5] = {0, 1, 2, 3, 4}; </code></pre> Here, applying the "declaration syntax mimics expression syntax" is not only wrong but could also be harmful. The expression a[5]</code> would cause an out-of-bounds access error. Nonetheless, understanding the spirit of this design principle can help us decipher more complex declarations: int ((foo(int a))(double, char ))(long); </code></pre> Declarations in C should be read inside-out starting with the name of the declared entity (foo</code> in this example). Prefix operators (such as </code>) have lower precedence compared to postfix operators (such as the function call operator()</code>). Knowing this fact allows us to establish that foo</code> is a function which has a parameter of type int</code>.</li> We know that it returns a pointer since the value returned by foo</code> can be dereferenced (foo(int a)</code>).</li> We know that the returned pointer points to a function that has a parameter of type double</code> and a parameter of type char </code> ((foo(int a))(double, char )</code>).</li> That function returns a pointer ((foo(int a))(double, char )</code>).</li> That pointer points to a function that has a parameter of type long</code> and returns a value of type int</code>.</li> </ol> It is obviously not obvious at a glance that foo</code> is a function which returns a pointer to a function which returns a pointer to a function which returns a value of type int</code>. In fact, declarations can become so hard to read that the maintainer of the Fish</a> shell created a website</a> that deciphers C declarations for you. Even though declarations in C are notoriously hard to read and write, expressions can also be tricky due to their many nested parentheses. My goal here is not to write a C language tutorial or explain in depth all the implications of this principle but to discuss language design. A postfix indirection operator</a></h2> In The Development of the C Language</a>, Dennis Ritchie mentions that declarations and expressions involving pointers would be more readable if the indirection operator was a postfix operator. Let's imagine for a moment that !</code> is the postfix indirection operator. int main() { int x = 5; int p! = &x; return p!; } </code></pre> The declaration of foo</code> would now look like the following: int foo(int a)!(double, char !)!(long); </code></pre> It can almost be read from left to right. We just have to go back at the beginning to read the type specifier (int</code>). It is clearer that foo</code> is a function that takes an int</code> and returns a pointer to a function that takes a double</code> and a char !</code> and returns a pointer to a function that takes a long</code> and returns an int</code>. Ideally, the type specifier should go at the end but we would need a keyword to introduce declarations: let p !int = &x; let a [3]int = {1, 2, 3}; let foo(a int)!(double, !int)!(long) int; </code></pre> A postfix indirection operator also removes the need for the arrow operator -></code>. // Without arrow operator return (pointer).property; // Arrow operator return pointer->property; // Postfix indirection operator combined with the '.' operator return pointer!.property; </code></pre> Another issue that the prefix </code> operator causes occurs during parsing2</a>. Consider the following code snippet: a b; </code></pre> It is ambiguous during parsing whether a * b;</code> is an expression statement or a declaration of a variable named b</code> of type "pointer to a</code>". This ambiguity complicates and slows down tools such as formatters, linters and syntax highlighters. Other languages</a></h2> There are many other languages which have pointers and it's interesting to see how familiarity and popularity shape programming language design more than anything else. Pascal</a></h3> Pascal and C emerged around the same period but Pascal used ^</code> as a postfix indirection operator from the very beginning. The syntax to access fields of a record then becomes trivial: p^.field</code>. Ada</a></h3> Ada emerged a few years later than C and Pascal. It has "access types"3</a> which are roughly equivalent to pointers. Ada uses .all</code> as a postfix indirection operator. It also has an implicit dereferencing feature to access fields of a record which means it is possible to write Ptr.Field</code> instead of Ptr.all.Field</code>. Rust</a></h3> Rust uses </code> as a prefix indirection operator just like C and has implicit dereferencing just like Ada. Rust also has implicit borrowing when calling methods. Declaration syntax is not tied to expression syntax so declarations stay readable. Despite its implicit borrowing/dereferencing features and its .deref()</code> method, there are still discussions about adding postfix borrowing and dereferencing operators4</a>. Go</a></h3> Go also uses the same operators as C and has implicit dereferencing. It changes the syntax of declarations to make them readable. Zig</a></h3> Zig uses .</code> as a postfix indirection operator. Odin</a></h3> Odin uses the same operator as Pascal. Hare</a></h3> Hare is similar to Go and Rust in this regard. C3</a></h3> C3 uses the same operators as C. V</a></h3> V uses the same operators as C. Conclusion</a></h2> Some would argue that language designers should completely avoid unary operators5</a>. Others would argue that all unary operators should have the same fixity. My stance is not that extreme. However, Pascal appeared in the 1970s and Dennis Ritchie mentioned in 1993 that a postfix indirection operator would be better. I find it unfortunate that the language designers of Go, Rust, Hare, C3, and V made the mistake of disregarding this insight. When designing a new language (especially a spiritual successor to C) which breaks source retrocompatibility, avoiding simple improvements like making a prefix operator postfix because of familiarity6</a> is bad design. The Development of the C Language</a> ↩</a> </li> Lexer Hack</a> ↩</a> </li> Access Types</a> ↩</a> </li> Postfix borrow/deref</a> ↩</a> </li> Unary Operators are Unnecessary</a> ↩</a> </li> Familiarity</a> ↩</a> </li> </ol> </section> Creating this blog using Zola, Abridge and Netlify 2025-11-04T00:00:00+00:00 I have been thinking about setting up a blog for a long time and that time has finally come. Tech Stack</a></h2> This blog relies mainly on Zola</a> which is a static site generator written in Rust and Abridge which probably is the most advanced theme for Zola. This stack makes the website particularly fast to build, load and offers great SEO out of the box. For hosting, I use Netlify for free which allows building this website directly from a private Git repository. Setup</a></h2> The first step was to install</a> Zola on my system. I could then start setting up my blog and Abridge</a>. # Create Zola website yes "" | zola init mysite cd mysite # Turn it into a git repository and add Abridge as a submodule git init git submodule add https://github.com/jieiku/abridge.git themes/abridge git submodule update --init --recursive git submodule update --remote --merge # Copy essential files for Abridge to my website rsync themes/abridge/.gitignore .gitignore rsync themes/abridge/config.toml config.toml rsync themes/abridge/content/_index.md content/ rsync -r themes/abridge/COPY-TO-ROOT-SASS/* sass/ rsync themes/abridge/netlify.toml netlify.toml rsync themes/abridge/package_abridge.js package_abridge.js rsync themes/abridge/package.json package.json </code></pre> I then went to the config.toml</code> file and uncommented the following line. #theme = "abridge" </code></pre> Making it my own</a></h2> In my config.toml</code>, I changed a few things such as the base_url</code>, title</code>, description</code>, author</code> and keywords</code> keys. I also commented out the textlogo</code> so that the name of my blog would appear instead of the Abridge logo. I then added a favicon-32x32.png</code> file to the static</code> folder and commented out all the other icons in config.toml</code>. It doesn't look great but at least it's mine. PWA</a></h2> I could then easily turn my website into a progressive web app thanks to Abridge. This allows users to install my website as if it was a native application. I copied the necessary manifest.json</code> file. cp themes/abridge/static/manifest.json static/ </code></pre> I then modified it with the name of my blog and added my icon files. And finally, I ran the abridge script to generate the minified manifest file. npm install npm run abridge </code></pre> Netlify</a></h2> The last thing I had to do before publishing was modify the netlify.toml</code> file to adapt it to my url. Conclusion</a></h1> Building a performant static blog with advanced features is pretty easy nowadays. And I hope I will be publishing many articles on this blog.

On the subject of pointer syntax

Creating this blog using Zola, Abridge and Netlify

Netlify</a></h2>
The last thing I had to do before publishing was modify the `netlify.toml</code> file to adapt it to my url.</p>`
`Conclusion</a></h1> Building a performant static blog with advanced features is pretty easy nowadays. And I hope I will be publishing many articles on this blog.</p>`

`Conclusion</a></h1> Building a performant static blog with advanced features is pretty easy nowadays. And I hope I will be publishing many articles on this blog.</p>`

Vahan's Blog

A better keyboard layout