A thought provoking article on the coding syntax of sequences (lists, fields, pipes). An interesting reflection on how we typically intuit about sequence syntax in natural languages and how it may be better written in the other way around.

Interesting though useless knowledge on the evolution of the term "boilerplate" in programming context.

TL;DR: first it refers to the plate used to roll into water boiler cylinder in the steam age. Then in linotype age there is a technique to make mold lead into the lines of text for printing. These plates of lines of texts looks similar to boilerplates. And the connotation of "copy-pasted" text comes from the usage of these plates been casted several times and sent to various new publishers for printing.

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).