I always wanted to write an article about how to write readable code. This article did it for me!

The core idea is that our brain has a small working memory. We are able to hold 4-6 things simultaneously, but no more. So to make the code more digestible, we need to abstract related things together into a bigger chunk if there are more than a handful of things to be dealt with.

Another thing the article didn't mention is that we can use symmetry to reduce the amount of memory needed. Symmetrical things require fewer places in working memory. "match cases" and "pipelining operators" are useful to construct symmetrical structures. The structures hints the brain on what to expect and we know the sub-expressions are equal in rank. This is why I am against using pipeline operator in places where there is no pipeline semantics (each step should be an endofunction).

A Preprocessor Iceberg Meme on C preprocessor magic. Similar to "The Cursed Computer Iceberg Meme".

The author made a point that reference count is almost always superior than GC in any case.

Tricks and misconceptions about tui apps, like how to make terminal appear a lot responsive.

You could harden a Linux server by killing the init process. That would cause a kernel panic, and prevent new processes running (e.g. shells). Existing processes like Web servers would continue to function, so you could put this at the end of the boot script :)

I never thought that is possible! Kind of stupidily funny and brilliant at the same time.

A discussion about unconventional data structures and algorithms.

A collection of miniature programming languages which demonstrates various concepts and techniques used in programming language design and implementation.

A comment on hackernews summarized it well:

If you want to do great work, you need freedom first.

There's fundamentally 3 architypes of programmers, divided by which ideals we hold in highest esteem:

• You are a poet and a mathematician. Programming is your poetry
• You are a hacker. You make hardware dance to your tune
• You are a maker. You build things for people to use

And you don't have to pick one - I realize myself jumping between the three when coding. I often aim for the most beautiful code possible but can easily relegate to the rest when facing real-life challenges.

In short, after you finished your feature branch, reset the branch against master and re-create commit history based on logical groups.

A bunch of nice tricks to use browsers' web debugger console and console.log() faimilies.

More tricks shared in HN comments: https://news.ycombinator.com/item?id=29071700

A clever idea. It uses an unsafe non-existent function to induce link-time error. Normally, if the call to this non-existence function is proven unreachable by the compiler, then the call to this function will be removed and won't catch any errors. Otherwise it raises a link-time error instead of runtime error.

A nice textbook on programming language and type theory. I use it as a supplement material of Types and Programming Languages.

An accured list of computing weirdness. Each piece of text is a link that leads to the explanation.

I found it in a recent episode of the Corecursive podcast. https://corecursive.com/quines-polyglot-code/

Y combinator wonderfully-explained!

commonly used features in a side-by-side format

Huh! This is one question I've been thinking about since I learned some Assembly - why isn't there dynamically growing array on stack? This answer solved the mystery wonderfully:

1. because stack grows backwards (from high to low), the array index cannot be 0, 1, ... if we want to make the array grow in the same direction as the stack. The index would have to be 0, -1, -2, ...
2. You can't have more than one of such arrays for the array to be contiguous.
3. The array cannot grow when there are any stack push operations (e.g. function call).

Unison is a langauge where segments of code are not addressed by names (like function names), but by the hash of their contents represented as AST.

By building a language based on this central idea, the problem of dependency conflict is a non-problem. The author also demonstrated the potential of elastic distributed computing based on the idea.

This project reminds me of From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of Transient Functional Containers, which is built around a similar idea, but implemented as a computing system instead of a programming language.