Clicky

Programming


Some notes from Mongo

Sat 08 Nov 2025

Conventional Commits considered harmful

Tue 30 Sep 2025

Words to Avoid: OSS

Thu 17 Jul 2025

A useful Git ’trick’

Wed 02 Jul 2025

What is a distributed system

Tue 01 Apr 2025

Implementing Salesforce SSO with Cognito Using SF SessionID

Sat 29 Mar 2025

Why Apple makes better software

Mon 17 Mar 2025

Extract https://www.kotobee.com/

Sun 24 Nov 2024

Identifying issues and newcomers to Linux

Sat 06 Jan 2024

The Perfect Programming Language

Thu 10 Aug 2023

Lisp Programming Language

Thu 16 Feb 2023

Introduction to The Relational Language

Fri 22 Apr 2022

The Go Programming Language

Sun 09 Jan 2022

Short Posts

Safari was based on KDE

Thu 20 Nov 2025

Matt Holiday

Thu 06 Nov 2025

Designing inefficiency

Sat 01 Nov 2025

Give me more build systems

Fri 24 Oct 2025

Some other notes on exception handling

Fri 17 Oct 2025

“Clean Architecture”

Thu 09 Oct 2025

Note for Windows Programmers

Tue 16 Sep 2025

Supabase

Sat 21 Jun 2025

Floyd’s tortoise and hare

Tue 27 May 2025

Fix: (org-ql-view.el) Adjust priority for agenda elements by anpandey

Thu 17 Oct 2024

I can’t find a Lisp

Mon 22 Jul 2024

Another killer feature for Go

Fri 16 Feb 2024

Clojure has Go-like channels

Thu 08 Feb 2024

A thought about Clojure

Sun 04 Feb 2024

Reconsidering SBCL

Sun 15 Oct 2023

Stop naming your libraries.

Sat 02 Sep 2023

Navigating Computing Boundaries

Sat 15 Jul 2023

TL;DRs

Sat 15 Jul 2023

What We Lost

Sat 15 Jul 2023

Notes

Software shouldn’t be modified by people who do not understand it

I read it in: Software Design is Knowledge Building

In his Software Aging paper, David Parnas warns against putting software in the hands of developers who haven’t contributed to (and thus don’t understand) its design:

Although it is essential to upgrade software to prevent aging, changing software can cause a different form of aging. The designer of a piece of software usually had a simple concept in mind when writing the program. If the program is large, understanding that concept allows one to find those sections of the program that must be altered when an update or correction is needed. Understanding that concept also implies understanding the interfaces used within the system and between the system and its environment.

Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade. Under those circumstances, changes will be inconsistent with the original concept; in fact, they will invalidate the original concept. Sometimes the damage is small, but often it is quite severe. After those changes, one must know both the original design rules, and the newly introduced exceptions to the rules, to understand the product. After many such changes, the original designers no longer understand the product. Those who made the changes, never did. In other words, nobody understands the modified product. Software that has been repeatedly modified (maintained) in this way becomes very expensive to update. Changes take longer and are more likely to introduce new “bugs”. Change induced aging is often exacerbated by the fact that the maintainers feel that they do not have time to update the documentation. The documentation becomes increasingly inaccurate thereby making future changes even more difficult.

Casey Muratori incident

From: https://news.ycombinator.com/item?id=38650254

Microsoft’s new terminal application rendered text extremely slowly, like 10 minutes to cat 1gb of text slow.

Casey submitted a bug saying that it’s slow and should be much much faster. Microsoft responded something like “text is hard … … phd dissertation on rendering text”

Casey made a terminal renderer with more features than Microsoft’s renderer in a weekend, it performed orders of magnitude faster, had zero optimization work performed and he jokingly (and hilariously) titled the video “a phd dissertation”.

Next, the excuse parade rolled in and came up with all manner of excuses as to why Muratoris renderer was so much faster, so he made a follow up video addressing the excuse parade, as well as containing some very minor optimization.

Also note that Casey’s implementation isn’t even as fast as things could be. His optimizations are minor.

https://github.com/microsoft/terminal/issues/10362 https://m.youtube.com/playlist?list=PLEMXAbCVnmY6zCgpCFlgggR

The case against OOP

Here there’s a list of critiques against Object-Oriented Programming, I agree with most of which. This is a reference list, for people who never faced a critique of OOP, as well as a reference for me to refer to when people who only worked with OOO for the most of their lives are questioning how could anything be wrong with it (I worked for a while with people who had no clue that there are other possibilities for writing software, or even couldn’t imagine that procedural code could be sometimes better than an OOO variant.)


Some works I recommend engaging with:

I seek refuge in God, from Satan the rejected. Generated by: Emacs 30.2 (Org mode 9.7.34). Written by: Salih Muhammed, by the date of: . Last build date: 2025-11-22 Sat 01:14.