Blog on La Vita Nouva

Reading leaked Claude Code source code

Tue, 31 Mar 2026 00:00:00 +0000

Reading leaked Claude Code source code

This post was discussed in Lobsters

Interesting findings from reading 132,000 lines of TypeScript that power Claude Code. The post uses the repo at https://github.com/chatgptprojects/claude-code to reference code, note that it might go down by the time you are reading this.

[2026-04-01 Wed 00:53]: after writing this, I found another interesting read by Alex Kim's blog

Anthropic accidentally leaked a source map file (cli.js.map) containing the full, unobfuscated TypeScript source code. 1,897 files around 132,000 LOC. What I found is a piece of software that is surprisingly more opinionated and more paranoid than I expected. Here are some of things that I found worth talking about.

The codename canary problem

In src/buddy/types.ts, all the species names are hex-encoded:

const c = String.fromCharCode
export const duck = c(0x64,0x75,0x63,0x6b) as 'duck'
export const goose = c(0x67,0x6f,0x6f,0x73,0x65) as 'goose'

All 18 species, spelled out character by character in hexadecimal. The comment explains a funny reason:

One species name collides with a model-codename canary in excluded-strings.txt. The check greps build output (not source), so runtime-constructing the value keeps the literal out of the bundle while the check stays armed for the actual codename.

So somewhere in Anthropic's build pipeline there's a file called excluded-strings.txt that contains codenames for unreleased models, and a build check that greps the output to make sure none of them leaked into the public build. One of the companion species names happens to match one of these internal codenames. Rather than rename the species, they encoded all of them uniformly in hex so the literal string never appears in the compiled output.

I find this hilarious. Somewhere inside Anthropic, a model is codenamed after an animal that's also a companion species in Claude Code, and the solution is to write "duck" as 0x64,0x75,0x63,0x6b. For the record I don't think the conflicting species is actually "duck" (that would be too simple), but the comment says they encoded all of them uniformly so you can't tell which one it is. Clever.

`goodClaude`, `bughunter` and other internal commands

The commands file has a section of internal-only commands that are hidden in external builds: bughunter, commitPushPr, ctx_viz, goodClaude (which is disabled and hidden, we will never know what it did), ultraplan, ultrareview, teleport, and ant-trace. These exist only in Anthropic's internal build.

There's also a rich set of feature flags for experimental modes: PROACTIVE (autonomous agent), KAIROS (an assistant/brief mode), COORDINATOR_MODE (multi-agent orchestration where Claude spawns worker agents), AGENT_TRIGGERS (cron job scheduling for agents), VOICE_MODE, and BUDDY (the companion pets). The coordinator mode is particularly interesting because it explicitly tells the orchestrating agent: "Never write 'based on your findings' or 'based on the research.' These phrases delegate understanding to the worker instead of doing it yourself." Whoever wrote that has seen too many LLM responses that start with "Based on my findings…"

`import I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS`

In src/query.ts, line 24, there's this import:

import {
 logEvent,
 type AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS,
} from 'src/services/analytics/index.js'

This is a TypeScript type and its name is a sentence. Every developer who uses it must type out "I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS" as part of their code. It's a forcing function as you can't accidentally send file paths or code content to analytics without literally typing "I verified this is not code or filepaths."

Multi-Clauding analytics

The /insights command includes a section called "Multi-Clauding (Parallel Sessions)." The function detectMultiClauding() uses a sliding window algorithm to find the pattern: session1 -> session2 -> session1 within a 30-minute window. It counts and reports these as "overlap events."

I think they're tracking when you're running multiple Claude sessions simultaneously and reporting it as a usage metric.

2,600 lines of preventing rm -rf

The bash security system (bashSecurity.ts, 2,592 lines) is pure paranoia, and it's fascinating. It validates every shell command against a checklist of attack patterns.

Some highlights of what it checks for:

Zsh's =cmd expansion, where =curl evil.com expands to /usr/bin/curl evil.com, bypassing permission rules because the parser sees "=curl" as the command name, not "curl"
zmodload (gateway to zsh/mapfile which enables invisible file I/O)
Heredoc injection, with a full line-by-line matching algorithm that replicates bash's heredoc-closing behavior
Shell ANSI-C quoting ($'\x41') because it can encode arbitrary characters
Process substitution in both directions (<() and >())
emulate (eval-equivalent arbitrary code execution in zsh)
ztcp (TCP exfiltration through Zsh builtins)

There's a separate file for destructive command warnings that pattern-matches things like git reset --hard ("may discard uncommitted changes"), rm -rf ("may recursively force-remove files"), DROP TABLE, and kubectl delete ("may delete Kubernetes resources"), each with a human-readable warning explaining what you're about to lose. And all of this is replicated for PowerShell in a separate file that tracks alias hijacking, module loading, and script block cmdlets.

There's a comment "This is really ugly but our current Tool type doesn't make it easy" in the MCP utility code, which feels honest, however I would say the security code is obsessive and thorough in a way that suggests real incidents behind every check, rather than ugly (code is generally ugly, arguably).

YOLO

Claude Code has a permission system with five modes: default (asks for permission), acceptEdits (auto-allows file editing), dontAsk (blocks everything), bypassPermissions (allows everything), and auto. The auto mode uses an ML-based classifier to decide whether a tool call is safe to run without asking the user, and internally, the file that implements this classifier is called yoloClassifier.ts (1,495 lines), I find this funny because; the classifier performs a two-stage evaluation: a fast initial decision, then an extended reasoning step if needed. It tracks which stage made the decision, cache metrics, token usage, and whether the decision was overridden. Now, the fact that they built an actual thoughtful safety system and named it "yolo" is so hilarious to me.

A complete Vim implementation, from scratch

src/vim/ contains a full Vim keybinding implementation as a state machine. Not a wrapper around a library. A hand-rolled state machine with INSERT and NORMAL modes, operators (delete, change, yank; 556 lines), motions (h/j/k/l, w/b/e, W/B/E, 0/^/$, G), text objects (words, quotes, brackets, braces), find motions (f/F/t/T with repeat via ;/,), indent/outdent, join lines, replace, toggle case, and dot-repeat. The transitions file (490 lines) handles the full state machine logic.

The motions are pure functions and operators handle smart newline logic. There's a register system with linewise detection. Having went through many Vim (and "evil", in case of Emacs) plugins myself, honestly this is a more complete Vim implementation than most "Vim mode/evil packages" plugins I've used, and it's very impressive.

If ye does not heed

The query orchestration loop (src/query.ts, 1,729 lines) contains this comment at line 151:

/**
 * The rules of thinking are lengthy and fortuitous. They require plenty
 * of thinking of most long duration and deep meditation for a wizard to
 * wrap one's noggin around.
 *
 * The rules follow:
 * 1. A message that contains a thinking or redacted_thinking block must
 * be part of a query whose max_thinking_length > 0
 * 2. A thinking block may not be the last message in a block
 * 3. Thinking blocks must be preserved for the duration of an assistant
 * trajectory
 *
 * Heed these rules well, young wizard. For they are the rules of
 * thinking, and the rules of thinking are the rules of the universe.
 * If ye does not heed these rules, ye will be punished with an entire
 * day of debugging and hair pulling.
 */

There are three rules about how thinking blocks must be handled in the API, and apparently they caused so much suffering that someone chose to document them in medieval English as a warning to future developers. "If ye does not heed these rules, ye will be punished with an entire day of debugging and hair pulling", and the line directly below this comment is ironically const MAX_OUTPUT_TOKENS_RECOVERY_LIMIT = 3. I imagine this constant was born from exactly such a day.

You have a pet

There's a directory called src/buddy/. It implements a companion pet system, complete with species, rarity tiers, stats, ASCII art sprites with idle animations, hats, and eye styles.

Your user ID is hashed (using Mulberry32, a tiny PRNG that has the beautiful comment "good enough for picking ducks") and deterministically rolled into a companion. The species list includes duck, goose, blob, cat, dragon, octopus, owl, penguin, turtle, snail, ghost, axolotl, capybara, cactus, robot, rabbit, mushroom, and "chonk" (see the full species array).

Each companion has a rarity (common 60%, uncommon 25%, rare 10%, epic 4%, legendary 1%), and rarity determines whether your buddy can get a hat. Common buddies always go hatless. Uncommon and above roll from the HATS array, which includes crown, tophat, propeller, halo, wizard hat, beanie, or a "tinyduck", which is apparently a tiny duck sitting on top of your ASCII animal. The array also includes "none" though, so your epic companion might still go bald.

Each companion has five stats: DEBUGGING, PATIENCE, CHAOS, WISDOM, and SNARK. There's always one peak stat and one dump stat, just like D&D character generation. Legendary companions have a floor of 50 in all stats while common ones start at 5.

The architecture is split into "bones" and "soul". Bones (species, rarity, stats, eyes, hat, shininess) are deterministic from your user ID and regenerated every time, so you cannot edit your config file to fake a legendary rarity. The soul (name and personality) is generated once by the model and stored. There's even a shiny boolean with a 1% chance, like shiny Pokémon.

The sprites themselves are defined as 5x12 ASCII art grids with 3 frames of animation each. The cat goes:

 /\_/\
 ( · · )
 ( ω )
 (")_(")

And in frame 2 it wiggles its tail: (")_(")~. The dragon breathes little tildes () in its third frame. The [[https://github.com/chatgptprojects/claude-code/blob/main/src/buddy/sprites.ts#L142-L164][octopus]] alternates between ~/\/\/\/\ and \/\/\/\/ tentacle positions. It's the kind of detail that makes you realize someone on the team was having a genuinely good time.

The companion sits beside the input box and "occasionally comments in a speech bubble." The system prompt instructs Claude not to pretend to be the companion or narrate what it might say, because the companion is handled separately. When the user addresses the companion by name, Claude is told to "stay out of the way: respond in ONE line or less."

The whole thing is behind a feature flag called BUDDY and almost nobody knows it exists.

Other things worth mentioning

Some things that I didn't cover in detail but are still worth knowing:

The loading spinner randomly selects from 186 verbs including "Clauding", "Flibbertigibbeting", "Boondoggling", "Prestidigitating", "Photosynthesizing", "Shenaniganing", "Whatchamacalliting", and "Tomfoolering". When it finishes, it uses past tense verbs (many cooking-themed, like "Sautéed" and "Baked", plus some like "Cogitated" and "Crunched"), so you might see "Sautéed for 12s". You can extend or replace the spinner list in your settings.
There's a /stickers command that opens your browser to stickermule.com/claudecode. That's the whole command.
The team memory sync system describes its conflict resolution strategy as "the lesser evil" because local edits overwrite the server version, but the alternative (silently discarding local work) is worse.
The keyboard parser handles both Kitty and XTerm extended key protocols and has special code paths for SSH tunnels where TERM_PROGRAM isn't forwarded. #Programming

Make macOS 26 consistently bad (unironically)

Fri, 27 Mar 2026 00:00:00 +0000

Make macOS 26 consistently bad (unironically)

This post was discussed in HackerNews

Alongside the various bugs you get, one of the issues of upgrading to MacOS 26 is that it has one of the most notorious inconsistency issues in window corners. I'm not sure what exactly pushes product designers to like the excessive roundness¹. I believe that UI design is the most influencive² field ever since designers just try to follow whatever big companies do (in fact I see this a lot in my work, when two designers are having an argument, one of them would resolve it to, let's see how Apple draw that button), which means that we are probably going to see this ugly effect elsewhere very soon.

Anyway, recently I had to upgrade to macOS 26. And I found the edges ugly, like everyone else did. However, what's even uglier, is the inconsistency. Many people try to resolve this by disabling MacOS system integrity protection, which results in making them possibly vulnerable³. The reason why you need to disable SIP, is that to edit the dynamic libraries that system apps like Safari (which has crazy bad corners) use, you need to edit system libraries that exist the root. To me though, I don't find the corners so bad, but I find the inconsistency very annoying. So I think a better solution to this is; instead of making everything roundless, make everything more rounded, which requires you to edit only user apps (i.e. no SIP disabling needed). I forked a solution that makes things roundless to modify it to have my approach. It's simply as follows:

#import <AppKit/AppKit.h>
#import <objc/runtime.h>

static CGFloat kDesiredCornerRadius = 23.0;

static double swizzled_cornerRadius(id self, SEL _cmd) {
 return kDesiredCornerRadius;
}

static double swizzled_getCachedCornerRadius(id self, SEL _cmd) {
 return kDesiredCornerRadius;
}

static CGSize swizzled_topCornerSize(id self, SEL _cmd) {
 return CGSizeMake(kDesiredCornerRadius, kDesiredCornerRadius);
}

static CGSize swizzled_bottomCornerSize(id self, SEL _cmd) {
 return CGSizeMake(kDesiredCornerRadius, kDesiredCornerRadius);
}

__attribute__((constructor))
static void init(void) {
 // Only apply to third-party GUI apps; skip CLI tools, daemons, and Apple system apps
 NSString *bid = [[NSBundle mainBundle] bundleIdentifier];
 if (!bid || [bid hasPrefix:@"com.apple."]) return;

 Class cls = NSClassFromString(@"NSThemeFrame");
 if (!cls) return;

 Method m1 = class_getInstanceMethod(cls, @selector(_cornerRadius));
 if (m1) method_setImplementation(m1, (IMP)swizzled_cornerRadius);

 Method m2 = class_getInstanceMethod(cls, @selector(_getCachedWindowCornerRadius));
 if (m2) method_setImplementation(m2, (IMP)swizzled_getCachedCornerRadius);

 Method m3 = class_getInstanceMethod(cls, @selector(_topCornerSize));
 if (m3) method_setImplementation(m3, (IMP)swizzled_topCornerSize);

 Method m4 = class_getInstanceMethod(cls, @selector(_bottomCornerSize));
 if (m4) method_setImplementation(m4, (IMP)swizzled_bottomCornerSize);
}

Then compile, sign, and store:

clang -arch arm64e -arch x86_64 -dynamiclib -framework AppKit \
 -o SafariCornerTweak.dylib \
 SafariCornerTweak.m

sudo mkdir -p /usr/local/lib/
sudo cp SafariCornerTweak.dylib /usr/local/lib/
sudo codesign -f -s - /usr/local/lib/SafariCornerTweak.dylib
cp com.local.dyld-inject.plist ~/Library/LaunchAgents/com.local.dyld-inject.plist

You can have this plist too to load it in once your computer loads:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.local.dyld-inject</string>
 <key>ProgramArguments</key>
 <array>
 <string>launchctl</string>
 <string>setenv</string>
 <string>DYLD_INSERT_LIBRARIES</string>
 <string>/usr/local/lib/SafariCornerTweak.dylib</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
</dict>
</plist>

Load it:

launchctl load ~/Library/LaunchAgents/com.local.dyld-inject.plist

Now at least everything is consistently bad. #Programming

Footnotes

One of the ugliest roundness examples I've ever seen is the current one in the YouTube UI design

that's to say, contagious form inwards

Arguable, since you just lose security over /root, which is not a big deal if someone already gained access to your machine, at least for me. Edit: I learnt that this is not the case from comments, however, I still believe that if you're already pwned, SIP can't do much there.

Little Known Development Methods (2009)

Sun, 22 Mar 2026 00:00:00 +0000

Little Known Development Methods (2009)

Following post is by programmer and once-active HN contributor Ed Weissman (Profile: edw519), I found it while going through his "The Best of edw519", it dates to 2009, and I thought it will be worth looking at again. Comments are mine and were not included in the original post.

Garbage Perpetuation Development (GPD) — You can’t believe how bad the existing code base is, but you’re afraid to open a can of worms, so everything you add to it is written in the same style. For the rest of your life, you can say, “It was like that when I got here.”

Eighteen years later and this is somehow more relevant, not less. what nobody saw coming is that now we have LLMs-based coding assistants trained on the entire internet, which means they’ve ingested billions of lines of GPD-produced code and will cheerfully suggest the same patterns right back at you. I remember reading a darkly funny thread on this from Simon Willison, or someone on Twitter, where they note that Copilot and friends are essentially the world’s most confident GPD practitioner, i.e. they’ll mirror whatever style surrounds them without judgment.

· · ·

Mansion in the Quicksand Development (MQD) — The opposite of Garbage Perpetuation Development, you are so shocked by the poor quality of the existing code that you vow that you’d rather swallow razor blades that code the same way. So you write a tight beautiful refactored masterpiece that will crash as soon as the underlying database loses its integrity (later tonight).

Joel Spolsky’s 2000 post “Things You Should Never Do, Part I” was already making this point about Netscape’s catastrophic rewrite, and yet we keep doing it. I believe the reason this pattern persists is that the beautiful new code feels like progress (I personally still like how the git blame shows my name next to clean principled work) and the rotten foundation is invisible until it isn’t. The 2022-era wave of “we’re migrating from our monolith to microservices” produced a fresh epidemic of this, stunning new service boundaries built on top of a PostgreSQL schema that hadn’t been touched since 2009 and was quietly on fire.

· · ·

Defer to the Framework Development (DFD) — You’re not sure how to tackle quite a few critical design/architecture issues, so you convince your boss to adopt the framework du jour and decide to “let it handle it”. As soon as someone needs something that the framework doesn’t handle, you blame management for making such a myopic technology decision and say that it can’t be done. You keep your job and get a new boss every two years.

This post was written in 2009, which means the Rails hype cycle was at absolute peak. Looking back, the framework-du-jour carousel has spun so many times since then; Backbone → Angular → Ember → React → Vue → Svelte → htmx, that “DFD” is now practically a job title. The irony is that React, which became the dominant “let it handle it” choice for the better part of a decade, is now itself the thing people are fleeing. Addy Osmani has written about the cost of JS framework churn and how each migration has tended to cost far more than the original adoption.

· · ·

Not Invented Here Development (NIHD) — The opposite of Defer to the Framework Development, as soon as you discover something the current framework can’t handle, you abandon it and write all your own routines. Everything now works exactly as you want it, but with all the additional code to maintain, your backlog has just grown from 6 months to 2 years.

Some of the most NIH-afflicted organizations (early Amazon, early Google) turned their internal reinventions into products (AWS, Bigtable/BigQuery) and ended up winning. The rest just quietly accrued two-year backlogs as described. The honest version of NIHD’s calculus is that owning your stack gives you deep understanding but the cost compounds ruthlessly over time (Kellan Elliott-McCrea wrote about this during his time at Etsy).

· · ·

Whoever Screams Loudest Development (WSLD) — Just as the name implies, you work for the customer who screams the loudest. If anyone screams louder, you drop everything and work on their project.

· · ·

F-Bomb Development (FBD) — Whenever everyone is screaming so loud you can’t hear anything, you work on the project of the customer who drops the most F-bombs.

This one is timeless.

· · ·

Start Over Development (SOD) — A critical requirement cannot be supported by the current architecture, so you decide to rewrite it. You spend 3 months designing the new architecture and then 6 months writing the new code. You never finish because you’re out of business. Now you know what “critical” means.

The autopsy for this pattern remains Spolsky’s Netscape post, but the case study that really drove it home for a generation of developers was the Friendster-to-Facebook transition and, more painfully, the Digg v4 rewrite in 2010, which effectively killed the company. The 3-month architecture phase feels like real progress and generates real excitement, and again, it’s the most enjoyable part of software development for a lot of people.

· · ·

Workaround Development (WAD) — The opposite of Start Over Development, you can make the current system do anything. You are so clever with your extra algorithms, functions, and databases. Even with all your great variable naming and comments, six months later, you have no idea how anything works.

Foote and Yoder named this the “Big Ball of Mud” in their 1999 paper of the same name, and their observation that it’s actually the dominant architecture in production systems worldwide remains one of the most quietly devastating things ever written about software. It often produces genuinely working software for longer than any of the cleaner approaches (arguably) the system is alive, users are happy (arguably), and it’s only the next developer (or future you) who pays the price. Ward Cunningham’s original framing of “technical debt” was meant to describe exactly this tradeoff: borrowing against future understanding to ship today.

· · ·

Code Generation Development (CGD) — You’re so tired of writing the same code over and over, that you write a code generator to do it for you. What used to take a week only takes a few hours with the new tool. But you’re no further ahead because 80% of your time is needed to enhance and maintain the code generator.

This one did not age the way the author expected. The code generation problem got absorbed by an industry: first by scaffolding tools, then by platform engineering teams, and eventually by LLMs. The new version of this is that you spend 80% of your time writing and maintaining prompts instead of a generator, which is arguably the same trap with a different texture.

· · ·

Infinite Prototyping Development (IPD) — Your customers and users are unable to describe or document their requirements. So you spend lots of time with them understanding their business and when you’re ready, you throw together a prototype. They love it, but it needs just a few changes. You keep making changes, but it always needs more. It stays a prototype forever. When the app crashes because of security or scaling issues, you’re off the hook because, “It’s only a prototype.”

The Lean Startup movement (Ries, 2011) tried to rehabilitate the prototype by renaming it the MVP and giving it a lifecycle, so the “forever prototype” is a failure of process, not of the artifact itself. It helped somewhat. What it didn’t fix is the social contract problem at IPD’s core because once stakeholders have seen something running, they shift from “requirements document” to “change request,” and you can never get them back. Many people do not know this but React was originally an internal Facebook prototype that just… never stopped (React is still referenced ironically in the 0ver satire).

· · ·

Infinite Analysis Development (IAD) — You never have to do anything because you never have specs. Woo hoo!

The Agile Manifesto was signed in 2001, eight years before this post, specifically because this had become the dominant mode of enterprise software development through the 1990s. And yet here we are in 2009 still writing about it, and here it is in 2026 still happening in every organization large enough to have a dedicated “architecture review board.” If the thing you’d build is going to be wrong, not building it yet has real value. The problem is that the people practicing it rarely know which situation they’re in.

These were already old in 2009 and they still hold up seventeen years later because, IMHO, most of them aren’t software problems but people problems wearing software clothes.

Read it again: every pattern has a destructive opposite. GPD and MQD. DFD and NIHD. SOD and WAD. The narrow, uncomfortable space between each pair is where actual engineering happens, but nobody writes a blog post about it because it doesn’t have a funny acronym (yet?). #Programming

Declaring Emacs Bankruptcy

Wed, 18 Mar 2026 00:00:00 +0000

Declaring Emacs Bankruptcy

I declared Emacs bankruptcy.

Not because I stopped using Emacs —I could not do that— but because the config had accumulated so many layers over the years that fixing one thing would break two others. Opening a new file caused a noticeable freeze, Org-roam completion worked sometimes. Grammar checking occasionally ate all the CPU. The theme had a visual glitch. Nothing catastrophic on its own. Everything catastrophic together.

So I rewrote it from scratch with two hard requirements: modular and fast.

The new one keeps config.el as a thin orchestrator and splits functionality into named modules:

modules/
 lr-macos.el macOS-specific frame and system settings
 lr-ui.el theme, modeline, dashboard
 lr-completion.el Corfu, Vertico, Consult
 lr-editor.el evil, editing behaviour
 lr-prog.el LSP, flycheck, error navigation
 lr-tools.el magit, dired, terminals
 lr-writing.el ltex-ls grammar checker
 lr-org-core.el org-mode base settings
 lr-org-roam.el org-roam, vulpea, dailies
 lr-org-noter.el pdf annotation
 lr-academic.el citar, bibtex, references
 lr-email.el mu4e
 lr-irc.el circe

config.el loads the performance-critical modules immediately and defers the heavy ones:

;; Load immediately (all fast, no I/O at startup)
(require 'lr-macos)
(require 'lr-ui)
(require 'lr-completion)
(require 'lr-editor)
(require 'lr-prog)
(require 'lr-tools)
(require 'lr-writing)

;; Defer heavy modules until org is first needed
(with-eval-after-load 'org
 (require 'lr-org-core)
 (require 'lr-org-roam)
 (require 'lr-org-noter)
 (require 'lr-academic))

;; mu4e deferred until first use
(with-eval-after-load 'mu4e
 (require 'lr-email))

This alone cut visible startup time substantially. The org stack never loads until you open an org file or an idle timer fires.

The org-roam startup problem

This was the hardest bug to fix and the most instructive.

The symptom: opening any org file would freeze Emacs for several seconds. The stack trace (sent via pkill -SIGUSR2) showed:

font-lock-fontify-keywords-region
→ citar-org-activate (font-lock function)
→ (require 'citar)
→ citar-org-roam-setup
→ org-roam-db-sync ← here
→ org-roam-db-query
→ +org-roam-try-init-db-a (Doom's lazy-init advice, fires on first query)
→ org-roam-db-sync again ← second sync
→ find-file-noselect (for every roam file)
→ vc-refresh-state
→ git subprocess per file ← freeze

A font-lock function requiring citar triggered a full org-roam DB sync, which opened every file in the roam directory, which ran git status on each one, which blocked. citar-org-activate is a font-lock keyword handler, it runs during redisplay when you first view a file containing a citation. You never see it coming.

The fix: block org-roam-db-sync entirely except in two cases — when called interactively (M-x org-roam-db-sync) or when an idle timer explicitly allows it.

(defvar salih/--org-roam-allow-sync nil)

(defadvice! salih/org-roam-block-eager-sync-a (&rest _)
 :before-while #'org-roam-db-sync
 (or salih/--org-roam-allow-sync
 (called-interactively-p 'any)))

;; Safe sync after 5s of idle — Emacs is not busy, no UX impact
(run-with-idle-timer
 5 nil
 (lambda ()
 (when (featurep 'org-roam)
 (let ((salih/--org-roam-allow-sync t))
 (org-roam-db-sync)))))

Doom's +org-init-roam-h internally uses cl-letf to replace org-roam-db-sync with ignore during autosync setup. cl-letf bypasses nadvice entirely, so startup is already safe — the advice only catches the citar and lazy-init triggered syncs that happen later.

The iCloud symlink bug

All my org-roam notes live under ~/roam, but the actual files are in iCloud: ~/roam/main, ~/roam/references, etc. are symlinks pointing into /Library/Mobile Documents/com~apple~CloudDocs/sync/org/.

Doom Emacs sets find-file-visit-truename t. This means that when you open /roam/main/foo.org, Emacs sets buffer-file-name to the iCloud truename, not the ~/roam path.

org-roam-file-p checks whether file-truename(buffer-file-name) is under file-truename(org-roam-directory). org-roam-directory is /Users/l/roam. The iCloud truename is /Users/l/Library/Mobile Documents/.... These share no common prefix. org-roam-file-p returns nil for every file accessed via a symlink.

That silently broke DB updates on save, find-file hooks, and the [[roam:Title]] → [[id:...]] link replacement.

The fix: pre-compute the truenames of symlinked subdirectories and extend org-roam-file-p to return t when a file is under any of them.

(defvar salih/--roam-symlink-truenames nil)

(defun salih/--compute-roam-symlink-truenames ()
 (when (bound-and-true-p org-roam-directory)
 (let ((roam-dir (expand-file-name org-roam-directory)))
 (setq salih/--roam-symlink-truenames
 (delq nil
 (mapcar (lambda (entry)
 (let ((path (expand-file-name entry roam-dir)))
 (when (and (file-directory-p path)
 (file-symlink-p path))
 (file-truename path))))
 (directory-files roam-dir nil "^[^.]")))))))

(defadvice! salih/org-roam-file-p-symlink-a (fn &optional file)
 :around #'org-roam-file-p
 (or (funcall fn file)
 (when salih/--roam-symlink-truenames
 (let ((path (expand-file-name
 (or file (buffer-file-name (buffer-base-buffer))))))
 (and path
 (not (auto-save-file-name-p path))
 (not (backup-file-name-p path))
 (string-suffix-p ".org" path t)
 (cl-some (lambda (dir)
 (string-prefix-p (file-name-as-directory dir) path))
 salih/--roam-symlink-truenames))))))

And consult-ripgrep does not follow symlinks by default, so the org-roam full-text search was also missing all symlinked directories. Fixed by adding --follow to the ripgrep invocation.

The ltex-ls completion conflict

I use ltex-ls for grammar checking in writing modes. ltex-ls registers itself as an LSP client for org-mode by default (via lsp-ltex-active-modes).

When ltex-ls starts in an org buffer, lsp-mode adds lsp-completion-at-point to the buffer's completion-at-point-functions. ltex-ls does not actually support textDocument/completion, so every completion attempt produced a noisy error and silently displaced org-roam's completion functions from the capf list.

The initial instinct was to remove org-mode from the registered LSP client after it loaded:

;; This does not work
(when-let ((client (gethash 'ltex-ls lsp-clients)))
 (setf (lsp--client-major-modes client) ...))

setf with lsp--client-major-modes requires a generalized-variable setter that lsp-mode does not define for runtime use — it works at compile time but not inside with-eval-after-load blocks. The error message was void-function (setf lsp--client-major-modes).

The correct fix: set lsp-ltex-active-modes before lsp-ltex.el loads. lsp-register-client evaluates lsp-ltex-active-modes at load time to build the client's :major-modes list.

;; Must be set before lsp-ltex.el loads (top of lr-writing.el, before after! blocks)
(setq lsp-ltex-active-modes
 '(text-mode latex-mode LaTeX-mode markdown-mode gfm-mode
 org-mode ; kept so SPC t G can start it manually; not in auto-start hook
 rst-mode message-mode mu4e-compose-mode))

The global-git-commit-mode error

On first file open, the doom-first-file-hook tried to enable global-git-commit-mode and crashed with void-variable function. The magit-commit library was being loaded via a mode-line hook before its dependencies were ready.

The fix is minimal: remove it from the first-file hook and wire it properly:

(remove-hook 'doom-first-file-hook #'global-git-commit-mode)
(with-eval-after-load 'git-commit
 (add-hook 'find-file-hook #'git-commit-setup-check-buffer)
 (add-hook 'after-change-major-mode-hook
 #'git-commit-setup-font-lock-in-buffer))

Full configuration is available at: github

It might be interesting to try out scala again now. Follow up on Emacs and Scala #Emacs #Programming

I beg you to follow Crocker's Rules, even if you will be rude to me

Sun, 08 Mar 2026 00:00:00 +0000

I beg you to follow Crocker's Rules, even if you will be rude to me

spoiler: you probably won't!

This post was discussed in HackerNews and Lobsters

Gabriela Seabra replied to this post

[2026-03-16 Mon 03:09] Since this might be prone to misinterpretation as an excuse to treat people rudely, a clarification is warranted. Being direct is not rude, and this style of communication assumes an established relationship between both parties¹. When dealing with a newcomer, or someone I'm trying to make comfortable working with me, I make the effort to be as accommodating as possible, by being nice to them, and I recommend everyone to do the same. I should also note that this applies strictly to text-based communication. Text is supposed to be optimal, searchable, and accountable, and I prefer it to also be direct. Verbal and in-person interaction is a different thing entirely and should remain kind and humane. Finally, I do genuinely appreciate directness in professional settings, but outside that context, I come from a culture where politeness is not just appreciated but expected, and I have no intention of leaving that at the door.

There is a concept called Crocker's Rules, and if you have never heard of it, the short version is this: you give people around you explicit permission to be maximally direct with you, to skip social cushioning. The person invoking Crocker's Rules is saying, in effect, "your feelings about how I might receive this are your problem to manage, not mine, just give me the information."

So a person receiving a message bears responsibility for their own emotional reaction to its content. If someone tells you your code is wrong, your emotional response to that is your problem to manage, not theirs to preemptively defuse².

What it means in practice is that your colleague can write "this approach is wrong, here's why" instead of "hey, hope you're doing well, I had some time to look at your PR and I just wanted to shared a few small thoughts, please take these as just one perspective, and of course you know the codebase better than I do, but I was wondering if maybe we could potentially consider [useful thing here]" and then bury the actual point six paragraphs deep. Both messages contain the same information, however one of them respects time.

The Slack message that starts with "Hey! Hope you had a great weekend :)"³ before asking a technical question or the PR comment that opens with "I'm not sure if I'm missing something here and sorry if this is a dumb question but" before raising a completely valid concern, or that incident text that spends two full paragraphs explaining that the author was sleep-deprived and had a lot on their plate and the monitoring tool had a weird quirk that they didn't know about and their lead had told them something ambiguous three weeks ago, before finally getting around to saying what actually broke and why. This is the literal opposite of professionalism and sometimes I see it as anxiety cosplaying as politeness.

I personally value directness, so when someone communicates with me in that way, it does influence how I perceive them, even subconsciously. I would also argue that this effect happens to most people, including those who aren’t aware of Crocker’s Rules or don’t particularly care about them:

When you spend the first third of your message establishing that you are a nice person who means well, you are not being considerate but you are making the recipient wade through noise to get to signal. You are training them to skim your messages, which means that when you actually need them to read carefully, they might not. You are demonstrating that you do not trust the relationship enough to just say the thing and you are signaling a level of insecurity that undermines the technical credibility you are trying to establish. Nobody reads "hope you had a great weekend" and thinks better of the person who wrote it, they probably just being trained to take you less seriously in the future, or at worse, if they're evil loving of Crocker's like myself, they just think about the couple of seconds of their life they will never get back.

Another behavior that I'd say highly related to that kind of noisy politeness, which I find actually worse is apologizing preemptively, this is the behavior where someone, when something goes wrong or when they need to explain a decision, does not just explain the decision; they explain why they made the decision, and then explain the contextual factors that influenced that, and then explain why those contextual factors existed, and then explain why it would have been unreasonable to expect them to anticipate the downstream effect of those factors, and by the end you have some fat five paragraphs that contains maybe one sentence worth of information and reads like a legal defense brief written by someone who knows they are guilty.

Please do not do that. If the payment service went down because a config value was wrong, the incident report should say: the payment service went down because config value X was set to Y when it needed to be set to Z.

The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear⁴, or that you asked your lead and they said it was probably fine, none of that is relevant to the incident report. You can document contributing factors if they are actually actionable, meaning if there is something structural that needs to change, name it specifically and attach a proposed fix to it. But confessing your emotional state and your reasoning process and your extenuating circumstances is not documentation, it is self-absolution and everyone reading it can tell the difference.

More importantly: it wastes their time and it buries the information they actually need to act on.

More examples

Instead of

"I hope this is okay to bring up and sorry for the long message, I just wanted to flag that I've been looking at the latency numbers and I'm not totally sure but it seems like there might be an issue with the caching layer?"

You get

"The caching layer is causing a 400ms overhead on cold requests. Here's the trace."

The second message is more useful, faster to read, and actually more respectful of everyone involved.

Instead of

"I know this might not be the right place to say this and I totally understand if you disagree, but I was thinking maybe the current approach to error handling might have some potential downsides?"

you get

"The current error handling swallows exceptions silently, which is making debugging hell. We should propagate errors to the caller."

The second person sounds like an engineer. The first sounds like they are asking permission to have an opinion, after the other party say something like "can you elaborate" they might start mentioning silent exceptions or whatever is the issue.

If you are a junior engineer reading this and feeling defensive, the defensiveness is worth examining. The weekend was fine. Nobody needed to know. Write the message.

Politeness has a place, but I beg you put clarity first. A team that cannot tolerate direct statements about reality cannot debug anything larger than a typo. If the caching layer is slow, say it is slow. If the design is wrong, say it is wrong. The rest is noise.

Footnotes

In fact I even emphasized about this in the post, saying that not being direct by adding unnecessary politeness padding implies that you don't trust the relationship yet to stay direct.

And no this is not a way to get away with cruelty nor an invitation to insult people it is just a mutual agreement that both parties are here to exchange information efficiently, and neither party is going to spend calories on social theater that adds zero signal.

musql

Tue, 10 Feb 2026 00:00:00 +0000

musql

Years ago I was building my own music aggregation interface called musql, I called it the intentional play on music and SQL. Later I eventually moved to Apple Music largely because smart playlists got closer to this idea than anything else out there.

I am extremely picky about my music and even more about how it is played. Shuffle always felt intellectually lazy and static playlists are bad. What I wanted was a system driven by intent.

Assume you have the following in your music library;

Beethoven, Piano Sonata No. 14 “Moonlight”, Adagio sostenuto
Tchaikovsky, Symphony No. 6 “Pathétique”, Adagio lamentoso
Bach, Goldberg Variations, Aria
Mahler, Symphony No. 9, final movement
Schubert, Piano Sonata D.960, first movement

In a traditional player you would probably dump these into a playlist called “Calm” or “Melancholy” and forget about it. musql treated them differently. Tags were never genres. Genre collapses too much nuance, especially in classical music. Tags describe emotional or conceptual intent.

Some examples;

sad Tchaikovsky’s Pathétique finale, Mahler’s Ninth ending, and Schubert’s late sonatas all express sadness, but each in a different register. One is despair, one is farewell, one is quiet exhaustion.
love Bach’s Aria from the Goldberg Variations, slow movements of Mozart piano sonatas, or the Benedictus from Beethoven’s Missa Solemnis. Love without excess, balanced and human.
madness Beethoven’s Große Fuge, late Scriabin piano works, parts of Berlioz’s Symphonie fantastique. Structure stretched until it starts to hallucinate.
sublime Beethoven Op. 111 second movement, Mahler’s slow movements, Bruckner adagios. Music that suspends time rather than fills it.

A track could carry many tags at once. The Schubert D.960 opening might be sad, intimate, sublime, and restrained. None of this pretends to be objective. It is simply how I listen.

In musql a playlist was never a list. It was a query.

For example:

All tracks tagged sad and sublime
Exclude madness
Prefer orchestral or solo piano
Duration longer than 8 minutes

That playlist contained logic, not tracks. Today it might include Mahler 9 and Schubert. Tomorrow, when you add late Brahms or slow movements of Shostakovich, they appear automatically. Nothing is edited by hand. A playlist should evolve as your library evolves.

Another use case that I also liked was writing something like this:

You might write:
Composer = Rachmaninoff
Exclude years 1897 to 1900

Those years follow the failure of his First Symphony. He was blocked and depressed, and if you are building a playlist around confidence or emotional generosity, that period simply does not belong.

Or:

Composer = Richard Strauss
Include works after 1905

Because you are here for Elektra, Salome, and Der Rosenkavalier, not the polite early tone poems.

Or even:

Composer = Beethoven
Include works after Op. 90
Exclude early piano sonatas

Because tonight you want the fractured, inward, almost metaphysical Beethoven, not the classical prodigy.

I never wake up wanting “track 4”. I wake up wanting clarity, grief, restraint, transcendence, or sometimes controlled chaos.

musql was my attempt to let the player meet me at that level. #Programming #Music

I'm not consulting an LLM

Fri, 30 Jan 2026 00:00:00 +0000

I'm not consulting an LLM

This post was discussed in HackerNews and Lobsters

Here's my problem with using GPT, or an LLM generally for anything¹, even if the LLM would do it 'effectively', I will speak specifically of looking for information as an example, and let's assume the following scenario; ever used the "I'm feeling Lucky" button in Google? This button usually gives the first result of the search without actually showing you the search results, let's assume that, you lived in a perfect world where in every Google search you have ever done, you clicked this button, and it was extremely, extremely, precise and efficient in finding the perfect fit for whatever you were looking for, that is to say, every search you have ever done in your life, was successful, from the first hit.

Now, in such a world, do you think that your intellect would have grown the same amount in which you had to actually do proper research, encounter crazy people, cultures, controversies, jokes, people who wrote interesting enough stuff that you followed them, arguments you disagreed with but couldn’t quite dismiss, footnotes that led nowhere and everywhere at once, half-broken blogs, bad takes that forced you to sharpen your own, or sources that contradicted each other so hard you had to build a model of the world just to survive the tension?

I guess not.

Because what would be missing isn’t information but the experience. And experience is where intellect actually gets trained.

“I’m Feeling Lucky” intelligence is optimized for arrival, not for becoming. You get the answer but nothing else (keep in mind we are assuming that it's a good answer). You don’t learn how ideas fight, mutate, or die. You don’t develop a sense for epistemic smell or the ability to feel when something is off before you can formally prove it.

Now back to reality, LLMs are never that good, they're never near that hypothetical "I'm feeling lucky", and this has to do with how they're fundamentally designed, I never so far asked GPT about something that I'm specialized at, and it gave me a sufficient answer that I would expect from someone who is as much as expert as me in that given field. People tend to think that GPT (and other LLMs) is doing so well, but only when it comes to things that they themselves do not understand that well (Gell-Mann Amnesia²), even when it sounds confident, it may be approximating, averaging, exaggerate (Peters 2025) or confidently (Sun 2025) reproducing a mistake. There is no guarantee whatsoever that the answer it gives is the best one, the contested one, or even a correct one, only that it is a plausible one. And that distinction matters, because intellect isn’t built on plausibility but on understanding why something might be wrong, who disagrees with it, what assumptions are being smuggled in, and what breaks when those assumptions fail

A tool can be efficient and still be intellectually corrosive, not because it lies all the time, but because it lies well enough. Its smoothness hides uncertainty, which is important unless you want intellect-rot. #Modus Vivendi #LLMs

Footnotes

Maybe I should add the exceptions of stupid tasks, i.e. repetitive and easily automatable procedures, things that I would make an Emacs macro for them before the age of LLMs.

"Briefly stated, the Gell-Mann Amnesia effect is as follows. You open the newspaper to an article on some subject you know well. In Murray's case, physics. In mine, show business. You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward—reversing cause and effect. I call these the "wet streets cause rain" stories. Paper's full of them. In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know." - Michael Crichton.

References

Peters, Uwe and Chin-Yee, Benjamin (2025). Generalization bias in large language model summarization of scientific research. The Royal Society. Link
Sun, Fengfei and Li, Ningke and Wang, Kailong and Goette, Lorenz (2025). Large Language Models are overconfident and amplify human bias. arXiv. Link

On Object-Oriented Programming and Clean Code

Fri, 16 Jan 2026 00:00:00 +0000

On Object-Oriented Programming and Clean Code

The word "Clean Code" is not subjecting some code to be clean rather a cult of developing and designing software, that claims to produce clean software, I will argue in this post that it does not.

The motive for this reference, long, document is that often times when I'm talking with friends or coworker and I joke about the Clean Code mindset, some people are surprised that it's even possible to argue against it, for many it has been the Bible of software design. Same thing happens when I talk about OOP, and in both cases I'm in the "oh, how shall I start?" state.

So I will try to make this document here a reference, for my very honest thoughts about Clean Code and Object-Oriented Programming (OOP henceforwards).

Clean Code is a symptom of OOP's deeper failures. For two decades, developers have followed a set of principles that promise clarity and maintainability and that always failed to deliver. Functions should be small, two to four lines. Every class does one thing. Polymorphism should replace conditionals and keep abstracting away the details. All of which has resulted in software that is harder to understand than the “unclean” version it replaced and architectures so layered that finding business logic requires archaeological expeditions. Systems that crawl on hardware a thousand times faster than what ran snappier software in 1995.

Clean Code

I claim that OOP's fundamental design philosophy is wrong. The abstractions OOP encourages, encapsulation that fragments related logic, polymorphism that hides control flow, inheritance hierarchies that couple things that should be separate, and all the whatnot, these create the pressure that Clean Code “solves” badly. We'll examine OOP's failures later.

Decomposition

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.”

The recommended function length in Clean Code is two to four lines. This advice is not only wrong it produces code that is actively harder to understand. The blind pursuit of small functions confuses a proxy metric (line count) with the actual goal (comprehensibility), and the confusion leads to codebases that are fragmented beyond recognition.

To understand this we need to understand the difference between deep modules vs shallow modules. Good software design creates deep modules: units that provide significant functionality through simple interfaces. The Unix file API (open, read, write, close, seek) is deep. Five functions with simple signatures however, they have an immense complexity handling file systems, caching, permissions, concurrency, multiple storage backends, etc… The interface hides the complexity; that's the value of abstraction. You can use these functions without understanding their implementations. The abstraction pays for itself many times over.

Clean Code produces shallow modules: functions that do almost nothing, with interfaces nearly as complex as their implementations. When a function has four lines and no branches, there's nothing to abstract. The “interface” is the implementation with a name attached. Consider the mathematics: abstraction value equals implementation complexity minus interface complexity. If both are tiny, the value is zero or negative, you've added indirection without reducing cognitive load. Each shallow function becomes another node in an entangled web, that requires you to chase definitions rather than read code linearly.

Okay but what does that actually means? Let's have a look at some code.

Here is example code from the Clean Code book, presented as the correct way to write software, it's a prime number generator;

public class PrimeGenerator {
 private static int[] primes;
 private static ArrayList<Integer> multiplesOfPrimeFactors;

 protected static int[] generate(int n) {
 primes = new int[n];
 multiplesOfPrimeFactors = new ArrayList<Integer>();
 set2AsFirstPrime();
 checkOddNumbersForSubsequentPrimes();
 return primes;
 }

 private static void set2AsFirstPrime() {
 primes[0] = 2;
 multiplesOfPrimeFactors.add(2);
 }

 private static void checkOddNumbersForSubsequentPrimes() {
 int primeIndex = 1;
 for (int candidate = 3; primeIndex < primes.length; candidate += 2) {
 if (isPrime(candidate))
 primes[primeIndex++] = candidate;
 }
 }

 private static boolean isPrime(int candidate) {
 if (isLeastRelevantMultipleOfLargerPrimeFactor(candidate)) {
 multiplesOfPrimeFactors.add(candidate);
 return false;
 }
 return isNotMultipleOfAnyPreviousPrimeFactor(candidate);
 }

 private static boolean isLeastRelevantMultipleOfLargerPrimeFactor(int candidate) {
 int nextLargerPrimeFactor = primes[multiplesOfPrimeFactors.size()];
 int leastRelevantMultiple = nextLargerPrimeFactor * nextLargerPrimeFactor;
 return candidate == leastRelevantMultiple;
 }

 private static boolean isNotMultipleOfAnyPreviousPrimeFactor(int candidate) {
 for (int n = 1; n < multiplesOfPrimeFactors.size(); n++) {
 if (isMultipleOfNthPrimeFactor(candidate, n))
 return false;
 }
 return true;
 }

 private static boolean isMultipleOfNthPrimeFactor(int candidate, int n) {
 return candidate == smallestOddNthMultipleNotLessThanCandidate(candidate, n);
 }

 private static int smallestOddNthMultipleNotLessThanCandidate(int candidate, int n) {
 int multiple = multiplesOfPrimeFactors.get(n);
 while (multiple < candidate)
 multiple += 2 * primes[n];
 multiplesOfPrimeFactors.set(n, multiple);
 return multiple;
 }
}

Do you understand it? I don't think you do, I can't either, nor can the Clean Code author after revisiting it 18 years later. He actually says something very interesting about it:

“I could see all the moving parts, but I could not figure out why those moving parts generated a list of prime numbers.”

The decomposition obscured rather than revealed.

When you decompose aggressively, you don't get independent modules. You get entangled modules, pieces that cannot be understood in isolation. isNotMultipleOfAnyPreviousPrimeFactor calls isMultipleOfNthPrimeFactor, which calls smallestOddNthMultipleNotLessThanCandidate. To understand any one, you must understand all three. They share implicit state (multiplesOfPrimeFactors). They have implicit ordering constraints (the candidate parameter must be non-decreasing across calls). None of this is documented in the interfaces. This is worse than a single longer function. With one function, you read it once, top to bottom. With entangled functions, you're jumping between definitions, holding multiple frames in your head, trying to reconstruct the data flow that the decomposition deliberately obscured.

The Clean Code book rails against side effects:

“Side effects are lies. Your function promises to do one thing, but it also does other hidden things.”

Yet smallestOddNthMultipleNotLessThanCandidate-which sounds like a pure computation-mutates multiplesOfPrimeFactors. The decomposition hid the side effect behind an interface that appears pure. The code is more dishonest, not less. The author admits he had to go on an hour-long bike ride to understand why the algorithm's square optimization was correct, a comment could have saved him from that, but Clean Code argues that writing comments is an “acknowledgment of failure of writing expressive code.” I could talk a lot about how problematic that position is, but here I'm interested in software design more than coding style.

Abstraction

Clean Code treats abstraction as an unqualified good. The practice is as follow: create abstractions, which hides implementations, later depend on interfaces, not concretions. But abstraction has costs, every abstraction is a bet that the interface captures what matters and hides what doesn't. When that bet is wrong (when the hidden details do matter, which believe me, happens much more than you think, much much more) abstraction becomes an obstacle. And the bet is wrong more often than abstraction enthusiasts admit.

Let's look at the code again, The PrimeGenerator's methods have interfaces (their signatures) and implementations (their bodies). But the interfaces don't capture crucial constraints: smallestOddNthMultipleNotLessThanCandidate requires that candidate never decrease and isMultipleOfNthPrimeFactor depends on prior calls having updated multiplesOfPrimeFactors. The order of calls to different methods matters, these are implementation details that leak through to callers. and you cannot use these functions correctly without understanding their implementations. The abstraction promises independence it cannot deliver.

This is endemic to OOP because objects encapsulate state, so related logic is scattered across method boundaries. Each method sees its own slice. The interactions between slices (the actual system behavior) are implicit in the call patterns, to understand the system, you must mentally simulate the calls. The “abstraction” doesn't help here, instead it fragments the picture you need to see whole. What appears modular is actually tangled; the tangling is just hidden behind method boundaries rather than visible in a single function.

The Clean Code philosophy descends from Parnas's information hiding: modules should hide design decisions likely to change. This is sound in principle, however, in practice, OOP developers hide everything, whether it's likely to change or not. The result is code where finding anything requires traversing abstraction layers. You want to know what happens when a user clicks a button? Follow the event handler to the controller to the service to the repository to the database adapter. Each layer hides the next and each layer has its own interface that doesn't quite say what happens behind it. Good design makes common cases obvious and hides irrelevant details. OOP-style abstraction hides everything equally, making common cases as hard to trace as edge cases.

Clean Code emphasizes interfaces and depend on abstractions, not implementations. But an interface without a contract is a fiction, the Java interface tells you the method names and types, it does not tell you what the method actually does, what preconditions must hold, what postconditions are guaranteed, what side effects occur, or what exceptions might be thrown and when (More on that #Exception handling). Without this information, you cannot use the interface correctly. You must read the implementation, defeating the purpose of the interface. OOP languages provide no mechanism for specifying contracts, and Clean Code provides no guidance for documenting them informally.

Polymorphism

“Replace conditional with polymorphism.”

This is core Clean Code practice. Instead of if-else or switch statements that handle different cases, create a class hierarchy where each case is a subclass. I claim that this advice is architecturally dangerous.

A switch statement puts related logic in one place. All the cases are visible together, you can see what happens in each case and you absolutely can add a new case by adding one block. By contrast, polymorphism scatters the cases across multiple files, each subclass handles one case. To understand all the cases, you must find and read all the subclasses. To add a new case, you must create a new file, ensure it's registered wherever subclasses are discovered, and hope you haven't missed any abstract methods, this is presented as a benefit: “The Open/Closed Principle! You can add new cases without modifying existing code!” But you do need to understand existing code to add a new case, you need to understand the base class contract, the existing subclasses' conventions, the registration mechanism. And when requirements change to affect all cases simultaneously, which happens constantly, you must modify every subclass anyway.

Polymorphism has a runtime cost: virtual method dispatch, the CPU cannot see through the abstraction to predict which code will run. Branch predictors fail more often, instruction caches contain code for all subclasses, not just the path being executed. Inlining is impossible because the target is unknown at compile time. Data layout is fragmented because each subclass has its own fields and For any single polymorphic call, this cost is small. But Clean Code applies polymorphism everywhere. When every design decision adds indirection, the costs compound. Modern software is often 10-100x slower than equivalent software from decades ago, running on hardware 1000x faster. Where did the performance go? Virtual calls, cache misses, memory allocation for objects that exist only to enable polymorphism can say a bit about this.

There's a fundamental asymmetry in program structure: you can organize code by operations (what you do to data) or by data types (what the data is). OOP organizes by data types, each class handles a type. Adding a new type is easy: add a new class. But adding a new operation is hard: you must modify every class. Functional programming organizes by operations, each function handles an operation, adding a new operation is easy: add a new function, but adding a new type is hard: you must modify every function, Clean Code assumes you will add types, not operations which is often wrong. Many systems have stable types and evolving operations, for these systems, OOP's organization is exactly backwards, and polymorphism makes the common operation, adding a new behavior, unnecessarily painful.

Performance

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs.”

Clean Code interprets this Knuth quote as license to ignore performance entirely. Abstract first, optimize never (or “later,” which means never). I claim that this interpretation is both wrong and dangerous.

Each Clean Code practice has a performance cost. Small methods mean more call overhead and less inlining, polymorphism means virtual dispatch and poor branch prediction. Encapsulation means accessor methods instead of direct field access. Dependency injection means runtime lookup and extra allocations. Many small objects mean cache misses and allocation pressure.

Individually, each cost is negligible, however, collectively, they are catastrophic. A simple CRUD operation might traverse as follows

HTTP handler → router → controller → service → repository → ORM → connection pool → database driver.

Each layer allocates objects, makes virtual calls, checks preconditions, catches and rethrows exceptions. The actual database query is a fraction of the total work. This is why “enterprise” software requires enterprises' worth of hardware.

“Optimize later” assumes you can optimize later, that performance problems will be localized, a hot function you can tune without restructuring. Often, performance problems are architectural, they stem from too many layers of indirection, data layouts that cause cache misses, allocation patterns that pressure the garbage collector, and polymorphism preventing inlining of hot paths. You cannot fix architectural performance problems without rewriting the architecture.

And rewrites don't happen. The business has deadlines, the original developers left and whatnot, the test suite assumes the current structure and a slow system does not really "hurt".

Proposal

Clean Code fails because it optimizes for the wrong things: function length, abstraction count, test-first ritual, which are proxies for good design, pursued to extremes where they become anti-patterns. What should we optimize for instead?

If you read my past post about Names (Programmers and software developers lost the plot on naming their tools) you can tell that I actually love optimizing for cognition loads. The goal of software design is reducing the cognitive load required to understand and modify code. Everything else is instrumental, for example, small functions reduce cognitive load when they create meaningful abstractions, they increase cognitive load when they fragment coherent logic. Polymorphism reduces cognitive load when the cases are truly independent but it increases cognitive load when you need to understand the interaction between cases.

Abstraction reduces cognitive load when it hides irrelevant details, it increases cognitive load when it hides details you need to see. There is no universal rule (like) “functions should be small,” “always use polymorphism” that reliably reduces cognitive load, you must evaluate each design decision in context.

Locality. Related code should be together. This is the opposite of Clean Code's scattering approach, if understanding A requires understanding B, put A and B together. If modifying A usually requires modifying B, put A and B together. If A and B share implicit constraints, put A and B together so the constraints are visible. This is why a 50-line function is often better than five 10-line functions.

Finally, data oriented design. OOP organizes code around objects: bundles of data with methods attached. This fragments data and scatters operations, data-oriented design organizes code around data flows: what data exists, how it transforms, where it goes. This keeps related data together (which helps improving cache behavior) and keeps related operations together (which, again, helps improving comprehensibility). Many performance improvements come from thinking about data layout: arrays instead of linked structures, structs-of-arrays instead of arrays-of-structs, batched operations instead of per-object calls.

Object-Oriented Programming

Clean Code's has the following symptoms: aggressive decomposition that obscures rather than reveals, abstractions that leak, polymorphism that scatters logic, and a systematic blindness to performance. But these are symptoms, not causes. I claim that the cause is OPP itself, a paradigm that has dominated industry practice for three decades while consistently failing to deliver on its promises, and that made issues, many of them, that Clean Code, Design Patterns, SOLID, and other stuff try to solve, which all of them do badly.

This is not a fringe position, (which most people think when I talk about OOP, that this is my own weird conspiracy theory) Edsger Dijkstra called object-oriented programs “alternatives to correct ones.” Alan Kay, who coined the term “object-oriented”, is a vocal critic of what OOP has become, saying “I invented the term, and I can tell you I did not have C++ in mind” and calling Java “the most distressing thing to happen to computing since MS-DOS.”, Joe Armstrong, creator of Erlang, stated flatly that “objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds.” These are not marginal figures, they are architects of systems that actually work at scale.

OOP originated from a simple need: greater customization for data types. In procedural programming, you had records, flat collections of fields. Classes extended records by attaching methods, functions that operate on the record's data, so the idea was actually elegant: bundle data with the operations that manipulate it, encapsulate the internals so they can change without affecting callers.

This seemed like good engineering practice, and in the narrow case of protecting access to mutable state, it was defensible, however OOP didn't stop there. It inflated this modest abstraction mechanism into an entire programming philosophy, insisting that everything should be modeled as objects, that all code should be organized around class hierarchies, and that all behavior should be attached to data. This was a category error, the techniques that work for encapsulating mutable state do not generalize to organizing entire programs.

Methods

Instance methods are what distinguish OOP from procedural programming. A method is a function attached to a class, with an implicit this or self parameter referring to the object instance, it seems like a minor syntactic convenience, but it introduces fundamental problems with reusability and coupling.

Consider a simple example¹. Here's a method that formats a user's display name:

class User {
 firstName: string
 lastName?: string
 middleName?: string
 address: string
 friends: User[]

 constructor(firstName: string, lastName?: string, middleName?: string) {
 this.firstName = firstName
 this.lastName = lastName
 this.middleName = middleName
 this.address = ""
 this.friends = []
 }

 getDisplayName(): string {
 return [this.firstName, this.middleName, this.lastName]
 .filter(Boolean)
 .join(" ")
 }

 hasFriend(id: string): boolean {
 return this.friends.some(f => f.id === id)
 }
}

And here's an equivalent function:

const getDisplayName = (user: {
 firstName: string
 lastName?: string
 middleName?: string
} | null | undefined): string | undefined => {
 if (!user) return undefined
 return [user.firstName, user.middleName, user.lastName]
 .filter(Boolean)
 .join(" ")
}

How do these differ?

The method is tightly coupled to a specific class, it depends not on an interface, but on the concrete User class, it requires not only the data it actually needs (firstName, lastName, middleName) but also every other field and method that exists in User, including address, friends, hasFriend, and anything added later. Anyone wanting to reuse getDisplayName must either inherit from User (bringing in all the baggage) or use delegation (adding boilerplate).

The method cannot be used without an instance, you cannot call getDisplayName on a plain object literal with the same fields. You must first construct a User:

// OOP: Requires class instantiation
const name = new User("Alexander", "Danilov").getDisplayName()

// Cannot do this:
({firstName: "Alexander"}).getDisplayName() // Error: object has no such method

// FP: Works with any object matching the shape
getDisplayName({firstName: "Alexander"}) // "Alexander"

The method conflates interface and implementation, the method's signature says it takes no arguments, but it actually depends on three fields. This dependency is invisible at the call site., the function's signature explicitly declares what data it needs.

The coupling problem becomes severe when you need to share logic across different types. Suppose you have an Npc class that also has firstName, lastName, and middleName. How do you reuse getDisplayName?

class Dog {
 firstName: string
 lastName?: string
 color: string

 // How to reuse getDisplayName from User class?
}

In OOP, your options are ugly:

You can make Dog extend User. But this forces Dog to include address, friends, hasFriend, and everything else User has. You're forced to provide values for fields you don't need:

class Npc extends User {
 constructor(name: string, surname: string) {
 super(name, surname, "", []) // Forced to provide address and friends
 }
}

This violates the Liskov Substitution Principle (a Dog is not a User), creates meaningless fields, and couples unrelated concepts.

You can also modify the existing code to create a Nameable class:

class Nameable {
 name: string
 surname: string
 getDisplayName() { ... }
}

class Friendable {
 friends: User[]
 hasFriend(id: string) { ... }
}

// But User needs both! No multiple inheritance.
// Which to inherit, which to embed?
class User {
 nameable: Nameable
 friendable: Friendable
 // Now getDisplayName is accessed as user.nameable.getDisplayName()
 // The interface has been broken.
}

This breaks existing code, forces awkward delegation, and doesn't even work if you need both behaviors (most languages lack multiple inheritance for good reason).

Finally, you can actually write the same method in both classes. Violates DRY.

Compare with the functional approach:

type BaseUser = {
 id: string
 name: string
 surname: string
}

type User = BaseUser & {
 address: string
 friendIds: string[]
}

type Npc = BaseUser

// Function specifies only what it needs
const getDisplayName = (entity: {
 firstName: string
 lastName?: string
 middleName?: string
}) => {
 return [entity.firstName, entity.middleName, entity.lastName]
 .filter(Boolean)
 .join(" ")
}

const hasFriend = (entity: { friendIds: string[] }, friendId: string) => {
 return entity.friendIds.includes(friendId)
}

// Works with anything that has the right shape
getDisplayName(user) // OK
getDisplayName(npc) // OK
getDisplayName({firstName: "Charlie", lastName: "Brown"}) // OK

hasFriend(user, "123") // OK
hasFriend(npc, "123") // Compile error: Npc has no friendIds

Types compose freely through intersection (&) and union (|). Functions declare precisely what they need through their parameter types. There's no hierarchy to manage, no base classes to extract, no forced coupling between unrelated concepts.

OOP languages provide multiple mechanisms for method overriding, each with subtle differences that create opportunities for bugs:

public void GetDisplayName() // Cannot be overridden in subclasses

public virtual void GetDisplayName() // Can be overridden

public override void GetDisplayName() // Overrides parent method

public sealed override void GetDisplayName() // Overrides but prevents further override

public new void GetDisplayName() // "Hides" the parent method - behavior depends on 
 // reference type at call site, not runtime type

The new keyword is particularly dangerous. The method called depends on the compile-time type of the reference, not the runtime type of the object:

class Parent {
 public void Print() => Console.WriteLine("Parent");
}

class Child : Parent {
 public new void Print() => Console.WriteLine("Child");
}

Child c = new Child();
c.Print(); // "Child"

Parent p = c; // Same object, different reference type
p.Print(); // "Parent" - Surprise!

This is a source of subtle bugs that functional programming simply doesn't have. In FP, there's nothing to override:

const getParentDisplayName = (entity: Parent) => { ... }

const getChildDisplayName = (entity: Child) => {
 // Can reuse parent logic if needed
 if (someCondition) return getParentDisplayName(entity)
 // Or do something different
 return ...
}

Everything is explicit. There are no surprises about which code runs.

Inheritance

Even among OOP developers, inheritance has become an anti-pattern. The standard advice is now “prefer composition over inheritance.” This is an extraordinary admission: the mechanism that was supposed to be OOP's killer feature for code reuse is now officially discouraged.

Joe Armstrong articulated the fundamental problem: “You wanted a banana, but what you got was a gorilla holding the banana and the entire jungle.”

You cannot inherit specific fields or methods, you inherit the entire class. Want to reuse one method? Take everything:

class User {
 id: string
 name: string
 surname: string
 address: string
 friends: User[]
 paymentMethods: PaymentMethod[]
 subscriptionTier: string
 loginHistory: Date[]
 preferences: Preferences

 getDisplayName() { ... }
 hasFriend(id: string) { ... }
 addPaymentMethod(pm: PaymentMethod) { ... }
 upgradeTier(tier: string) { ... }
 recordLogin() { ... }
 updatePreferences(prefs: Partial<Preferences>) { ... }
}

// I just want getDisplayName!
class Npc extends User {
 constructor(name: string, surname: string) {
 // Forced to initialize everything
 super(
 generateId(),
 name,
 surname,
 "", // No address needed
 [], // No friends
 [], // No payment methods
 "none", // No subscription
 [], // No login history
 defaultPrefs // No preferences
 )
 }

 // Npc now has all these methods that make no sense:
 // addPaymentMethod? upgradeTier? recordLogin?
}

Inheritance creates tight coupling between parent and child classes. Seemingly safe modifications to a parent class can break child classes in subtle ways:

// Version 1
class HashSet {
 private int addCount = 0;

 public void add(Object o) {
 addCount++;
 // add to set...
 }

 public void addAll(Collection c) {
 for (Object o : c) {
 add(o);
 }
 }

 public int getAddCount() { return addCount; }
}

class InstrumentedSet extends HashSet {
 private int addCount = 0;

 @Override
 public void add(Object o) {
 addCount++;
 super.add(o);
 }

 @Override
 public void addAll(Collection c) {
 addCount += c.size();
 super.addAll(c);
 }
}

Have you found the bug? addAll in the child adds c.size() to addCount, then calls super.addAll, which calls add for each element, which increments addCount again. You've double-counted.

You might fix this by not overriding addAll. But then:

// Version 2: Parent implementation changes
class HashSet {
 public void addAll(Collection c) {
 // Optimization: bulk insert without calling add()
 internalBulkAdd(c);
 }
}

Now InstrumentedSet.addAll doesn't count at all, because add() is never called. The parent's internal implementation detail has broken the child. You cannot examine a base class in isolation and know whether changes are safe, you must understand all descendants.

Multiple inheritance creates the “diamond problem”: if a class inherits from two classes that share a common ancestor, which version of the ancestor's methods should it use?

Drawable
/ \
Shape Colorable
\ /
ColoredShape

If Shape and Colorable both override Drawable.render(), what does ColoredShape.render() do? Different languages handle this differently (C++ has virtual inheritance, Python has MRO, Java forbids it), but all solutions are complex and error-prone.

Most OOP languages “solved” this by prohibiting multiple inheritance of implementation. But this cripples inheritance as a reuse mechanism, you can only inherit from one class, better make it count!

The standard advice is “use composition instead of inheritance.” But composition in OOP requires explicit delegation i.e. boilerplate code for every method you want to expose:

class Nameable {
 name: string
 surname: string
 getDisplayName() { return `${this.name} ${this.surname}` }
}

class User {
 private nameable: Nameable
 private friendable: Friendable

 // Delegation boilerplate for every method
 getDisplayName() { return this.nameable.getDisplayName() }
 hasFriend(id: string) { return this.friendable.hasFriend(id) }
 addFriend(friend: User) { return this.friendable.addFriend(friend) }
 removeFriend(id: string) { return this.friendable.removeFriend(id) }
 // ... and so on for every method
}

This is OnceAndOnlyOnce violation at scale. Every method in every component must be delegated, if a component adds a method, every class that composes it must add delegation.

Compare with FP type composition:

type Nameable = { name: string; surname: string }
type Friendable = { friendIds: string[] }
type User = Nameable & Friendable & { address: string }

// Functions work on any type with the right fields
const getDisplayName = (n: Nameable) => `${n.name} ${n.surname}`
const hasFriend = (f: Friendable, id: string) => f.friendIds.includes(id)

const user: User = { name: "Alex", surname: "Smith", friendIds: ["1"], address: "..." }
getDisplayName(user) // Works - User is Nameable
hasFriend(user, "1") // Works - User is Friendable

Encapsulation

Encapsulation is sold as OOP's safety mechanism, protect internal state from outside access. Objects hide their data; you interact only through their public interface.

I claim that encapsulation is a Trojan horse. It sells the idea of shared mutable state by making it appear safe but it doesn't eliminate mutable state, instead it hides it. And hidden mutable state is more dangerous than visible mutable state, because you cannot see what's happening.

Rich Hickey, creator of Clojure, articulated the core issue:

“I think that large object-oriented programs struggle with increasing complexity as you build this large object graph of mutable objects. You know, trying to understand and keep in your mind what will happen when you call a method and what will the side effects be.”

The human brain can hold approximately five items in working memory. Programming with mutable state consumes those slots. When reasoning about OOP code, you must track:

Which objects exist
What state each object is in
What references each object holds to other objects
What any given method call might mutate
Whether other parts of the code hold references to the same objects

This is cognitive overhead that has nothing to do with the problem you're solving. It's pure tax imposed by the paradigm.

Consider a concrete example:

class ShoppingCart {
 private List<Item> items;
 private DiscountStrategy discount;
 private TaxCalculator tax;

 public void addItem(Item item) {
 items.add(item);
 // Does this affect the discount? The tax? Other carts?
 }

 public double getTotal() {
 double subtotal = items.stream().mapToDouble(Item::getPrice).sum();
 double discounted = discount.apply(subtotal, items);
 return tax.calculate(discounted);
 // What state is discount in? Tax? Has someone else modified items?
 }
}

To understand getTotal(), you need to know: 1. What items are in the list (could have changed since the cart was created) 2. What state the discount strategy is in (could be stateful) 3. What state the tax calculator is in (could depend on previous calculations) 4. Whether anyone else has a reference to items and might be modifying it concurrently.

None of this is visible from the code, but must trace through the entire codebase to find where these objects were created, who has references to them, and what mutations might occur.

The promise of encapsulation is that each object's state is isolated. The reality is that objects hold references to other objects, and through those references, the entire object graph becomes interconnected mutable state.

Consider dependency injection-, the “best practice” for managing object creation:

class OrderProcessor {
 private final InventoryService inventory;
 private final PaymentGateway payment;
 private final NotificationService notifications;
 private final AuditLog auditLog;

 public OrderProcessor(
 InventoryService inventory,
 PaymentGateway payment,
 NotificationService notifications,
 AuditLog auditLog
 ) {
 this.inventory = inventory;
 this.payment = payment;
 this.notifications = notifications;
 this.auditLog = auditLog;
 }

 public void processOrder(Order order) {
 inventory.reserve(order.getItems());
 payment.charge(order.getTotal());
 notifications.sendConfirmation(order);
 auditLog.record(order);
 }
}

This looks clean. Each dependency is injected, so they can be mocked for testing. But what's really happening?

Each injected dependency is a reference to a shared, mutable object. The InventoryService is used by other processors. The PaymentGateway has internal state (connection pools, retry counters, rate limiters). The NotificationService might batch messages. The AuditLog writes to shared storage.

When you call processOrder, you're not operating in isolation. You're reaching into a web of shared mutable state, making changes that affect objects used by other parts of the program. Encapsulation promised isolation; dependency injection delivers shared global state with extra steps.

The ritual of encapsulation in OOP produces getters and setters, methods that provide access to fields:

class Person {
 private String name;
 private int age;

 public String getName() { return name; }
 public void setName(String name) { this.name = name; }
 public int getAge() { return age; }
 public void setAge(int age) { this.age = age; }
}

How is this different from public fields? It's not. The data is still externally accessible and mutable. The “encapsulation” is theatrical, it adds boilerplate without adding protection.

Some argue that getters and setters allow you to add validation or logging later. But this assumes a change pattern that rarely occurs. In practice: 1. If you need validation, you probably know it upfront 2. Adding validation to setters later breaks existing code that relied on the lack of validation 3. The setter pattern encourages mutation, which is the real problem

Compare with immutable data:

type Person = { readonly name: string; readonly age: number }

const withUpdatedAge = (person: Person, age: number): Person => ({
 ...person,
 age: age >= 0 ? age : person.age // Validation at creation
})

Mutable state shared across objects creates concurrency nightmares. When multiple threads access the same object graph:

class BankAccount {
 private double balance;

 public synchronized void deposit(double amount) {
 balance += amount;
 }

 public synchronized void withdraw(double amount) {
 if (balance >= amount) {
 balance -= amount;
 }
 }

 public synchronized double getBalance() {
 return balance;
 }
}

// Thread safety violation despite synchronized methods
if (account.getBalance() >= 100) {
 account.withdraw(100); // Balance might have changed!
}

Between getBalance() and withdraw(), another thread might have modified the balance. The synchronization on individual methods doesn't help because the operation spans multiple calls.

To fix this, you need transaction-level locking, which leads to deadlock risks when multiple objects are involved. The complexity compounds, and encapsulation provides zero help, in fact, it makes reasoning about the problem harder because the state is hidden.

Functional programming with immutable data sidesteps this entirely. Immutable data can be freely shared across threads without synchronization. There are no race conditions when nothing can change.

Polymorphism

Polymorphism is type-based dispatch, it fragments codebases, hides control flow, and prevents optimization.

With polymorphism, each subclass handles one case. The logic for all cases is scattered across multiple files:

shapes/
Shape.java // abstract base
Circle.java // implements draw() for circles
Rectangle.java // implements draw() for rectangles
Triangle.java // implements draw() for triangles
Ellipse.java // implements draw() for ellipses
Pentagon.java // implements draw() for pentagons
...

To understand what “draw” means in your system, you must find and read every subclass. To understand the full behavior, you must hold all implementations in your head simultaneously.

Compare with a single function:

type Shape =
 | { type: 'circle'; radius: number }
 | { type: 'rectangle'; width: number; height: number }
 | { type: 'triangle'; a: number; b: number; c: number }

const draw = (shape: Shape): void => {
 switch (shape.type) {
 case 'circle':
 drawCircle(shape.radius)
 break
 case 'rectangle':
 drawRectangle(shape.width, shape.height)
 break
 case 'triangle':
 drawTriangle(shape.a, shape.b, shape.c)
 break
 }
}

All cases are visible in one place. You can see the complete behavior by reading one function. Adding a case requires adding one block, not creating a new file.

OOP's subtype polymorphism is uncontrolled. A virtual method can do anything. There's no constraint on what subclasses implement beyond matching the signature:

interface Drawable {
 void draw();
}

// Subclass can do literally anything
class MaliciousDrawable implements Drawable {
 public void draw() {
 System.delete("/"); // "Draw" to the filesystem
 }
}

The type signature tells you nothing about what the method does.

Functional programming offers parametric polymorphism, where the type signature constrains the implementation:

-- This type signature tells you exactly what the function CAN do
map :: (a -> b) -> [a] -> [b]

A function of type map must apply the given function to each element of the list. It cannot do anything else (inspect the elements, modify global state, delete files) because a and b are completely abstract. The type is the documentation.

This is called parametricity, and it's one of the most powerful tools for reasoning about code. OOP lacks it entirely.

Nouns

Steve Yegge's famous essay “Execution in the Kingdom of Nouns” diagnosed a fundamental problem: OOP forces everything to be nouns.

Actions are natural in human thought and in code. “Open the file.” “Calculate the tax.” “Send the email.” But in OOP, you cannot have standalone actions. You must have:

FileOpener.open()
TaxCalculator.calculate()
EmailSender.send()

Or worse, following enterprise patterns:

FileOpeningStrategy.execute()
TaxCalculationService.performCalculation()
EmailSendingFacade.dispatchMessage()

The nouns are meaningless wrappers. The TaxCalculator class exists only to hold the calculate method. The class adds nothing, it's ceremony required by the paradigm.

This reaches its absurd conclusion in enterprise Java:

SimpleBeanFactoryAwareAspectInstanceFactory
AbstractInterceptorDrivenBeanDefinitionDecorator
TransactionAwarePersistenceManagerFactoryProxy
RequestProcessorFactoryFactory

These are real class names from production frameworks. Each represents a sincere attempt to express something in OOP's noun-centric vocabulary.

A factory is already a noun. But what if you need to create factories? FactoryFactory. What if you need to configure how FactoryFactory creates factories? FactoryFactoryConfigurationProvider.

In functional languages, you just have functions:

const openFile = (path: string) => ...
const calculateTax = (income: number, brackets: TaxBracket[]) => ...
const sendEmail = (to: string, subject: string, body: string) => ...

No wrapper classes. No nouns for nouns' sake. The code expresses actions directly.

Compare implementations of the same operation:

// OOP: Need a class to hold the comparison logic
public class StringLengthComparator implements Comparator<String> {
 public int compare(String a, String b) {
 return a.length() - b.length();
 }
}

// Used as:
Collections.sort(list, new StringLengthComparator());

// FP: Just express the comparison
list.sort((a, b) => a.length - b.length)

What replaces OOP?

A lot of programmers I knew, including myself, learnt programming by learning OOP, they can not think of another approach, and to them, a critique of OOP is a critique of programming. Here are some proven-to-be-better approaches to programming:

Functional Programming

Functions are simpler than methods. Pure functions are simpler than stateful ones, composition is simpler than inheritance. Higher-order functions are simpler (much) than design patterns.

Languages like Clojure and Elixir make these approaches natural. Languages like TypeScript, Kotlin, and Swift allow them with discipline. Even in Java and C#, you can write procedurally, using classes as namespaces for static methods.

Data-Oriented Design

Data and behavior separate. Data lives in contiguous memory, laid out for cache efficiency. Behavior operates on batches, not individual objects. There are no inheritance hierarchies, no tangled object graphs, just data and transformations.

Less

Often the alternative to OOP isn't another paradigm, it's less structure. A 200-line script beats a 2000-line “properly architected” application. A single file beats five files with interfaces and factories. Procedural code with clear control flow beats dispersed methods with hidden state.

The best code is code that doesn't exist, the second best is code that's obviously correct.

Furthers

/For further reading: “A Philosophy of Software Design” by John Ousterhout; “Domain Modeling Made Functional” by Scott Wlaschin; honorable mentions are:

Object-Oriented Considered Harmful
Object-Oriented Programming is Embarrassing [video]
Object-Oriented Programming is Garbage [video]
Goodbye, OOP [medium]
Object-Oriented Programming — The Trillion Dollar Disaster
Arguments against OOP [c2wiki]
"Clean" Code, Horrible Performance [video]
Case against OOP is understated, not overstated
OOP: the worst thing that happened to programming
OOP: Anatomy of a Thirty-five-year Mistake [video]
Stop Writing Classes [video]

#Programming #The case against OOP

Footnotes

Copied from this article

Scala bounds and variance

Thu, 15 Jan 2026 00:00:00 +0000

Scala bounds and variance

I've been learning Scala lately. One topic that I found a bit hard to comprehend is bounds and variance in the Scala type system. I want to document a real use case that came into my mind, that might be helpful to anyone in the future trying to understand the type system in Scala.

A typed plugin system.

Imagine you’re building a payment platform. 1. We're going to support different payment methods. 2. Each payment method has its own request type. 3. You want a generic processor that: (a). Accepts only valid payment requests (b). Can be extended safely (c). Doesn’t require rewriting logic everywhere

trait PaymentRequest {
 def amount: BigDecimal
}

final case class CardPayment(
 amount: BigDecimal,
 cardNumber: String
) extends PaymentRequest

final case class BankTransfer(
 amount: BigDecimal,
 iban: String
) extends PaymentRequest

Now let's have a processor:

trait Processor[T] {
 def process(request: T): Unit
}

This, however, allows any type to be called with. Even a string or an int. What we can do is to use boundaries to restrict T to payment requests:

trait Processor[T <: PaymentRequest] {
 def process(request: T): Unit
}

Now any other call with something that is not extending PaymentRequest becomes illegal.

Then use your concrete processors:

class CardProcessor extends Processor[CardPayment] {
 def process(request: CardPayment): Unit =
 println(s"Charging card ${request.cardNumber} for ${request.amount}")
}

class BankProcessor extends Processor[BankTransfer] {
 def process(request: BankTransfer): Unit =
 println(s"Transferring ${request.amount} to ${request.iban}")
}

Adding variance

Now you want a generic handler that can work with any payment processor:

def handle(
 processor: Processor[PaymentRequest],
 request: PaymentRequest
): Unit =
 processor.process(request)

This fails. Processor[CardPayment] is not a subtype of Processor[PaymentRequest], although CardPayment, is of PaymentRequest. Let's abstract to the fact that: a processor consumes T, which means: processor of general payments can handle specific payments. This is declared like following:

trait Processor[-T <: PaymentRequest] {
 def process(request: T): Unit
}

This is saying; If A is a subtype of B, then Processor[B] is a subtype of Processor[A].

Now this paramter is valid:

val genericProcessor: Processor[PaymentRequest] =
 new Processor[PaymentRequest] {
 def process(request: PaymentRequest): Unit =
 println(s"Processing payment of ${request.amount}")
 }

handlePayment(genericProcessor, CardPayment(100, "1234"))
handlePayment(genericProcessor, BankTransfer(250, "IBAN123"))

Consumers and Producers laws

If a type only CONSUMES T → use -T

Processor[-T]
Function1[-A, +B]
Comparator[-T]

This is known as The consumer rule

Producer laws

List[+T]
Option[+T]

If it happens to be both, then you're dealing with an invariant and you're going to populate data.

Full Example

trait PaymentRequest {
 def amount: BigDecimal
}

case class CardPayment(
 amount: BigDecimal,
 cardNumber: String
) extends PaymentRequest

case class BankTransfer(
 amount: BigDecimal,
 iban: String
) extends PaymentRequest

trait Processor[-T <: PaymentRequest] {
 def process(request: T): Unit
}

class CardProcessor extends Processor[CardPayment] {
 def process(request: CardPayment): Unit =
 println(s"Charging card ${request.cardNumber} for ${request.amount}")
}

class BankProcessor extends Processor[BankTransfer] {
 def process(request: BankTransfer): Unit =
 println(s"Transferring ${request.amount} to ${request.iban}")
}

class GenericProcessor extends Processor[PaymentRequest] {
 def process(request: PaymentRequest): Unit =
 println(s"Processing payment of ${request.amount}")
}

class LoggingProcessor[T <: PaymentRequest](
 underlying: Processor[T]
) extends Processor[T] {
 def process(request: T): Unit = {
 println("LOGGING")
 underlying.process(request)
 }
}

object PaymentApp extends App {

 val card = CardPayment(100, "1234-5678")
 val bank = BankTransfer(250, "IBAN-XYZ")

 val genericProcessor = new GenericProcessor

 val loggingCardProcessor =
 new LoggingProcessor[CardPayment](genericProcessor)

 val loggingBankProcessor =
 new LoggingProcessor[BankTransfer](genericProcessor)

 loggingCardProcessor.process(card)
 // println()
 loggingBankProcessor.process(bank)
}

#Programming #Scala

Enforcing invariants in Scala datatypes

Wed, 14 Jan 2026 00:00:00 +0000

Enforcing invariants in Scala datatypes

copied from Github.

Scala provides many tools to help us build programs with less runtime errors. Instead of relying on nulls, the recommended practice is to use the Option type. Instead of throwing exceptions, Try and Either types are used for representing potential error scenarios. What's common with these features is that they're used for capturing runtime features in the type system, thus lifting the runtime scenario handling to the compilation phase: your program doesn't compile until you've explicitly handled nulls, exceptions, and other runtime features in your code.

In his "Strategic Scala Style" blog post series, Li Haoyi explores patterns for enforcing invariants in datatypes using techniques such as self-checks and structural enforcement. Some of the techniques described in the blog post rely on runtime assertions. Thus, while they prevent invalid data from appearing in your datatypes, the datatype construction is not fully represented in the type system.

In this blog post, I'll expand the techniques by demonstrating ways to enforce invariants using type-safe, compile-time techniques. First, I'll demonstrate how the runtime assertion style works using an example datatype. I'll then show how we can enforce invariants in the example datatype in a type-safe style. Finally, I'll briefly cover the pitfalls of using case classes for datatypes with type-safe invariant validation, and how we can regain the case class features using tricks in the class inheritance system and ScalaMeta macros.

Invariant validation using runtime assertions

As an example, let's create a datatype for conferences. A conference has a name, a start date, and an end date. The name of the conference cannot be empty, and the end date cannot be before the start date. Using the runtime assertion technique, the datatype could be represented as follows:

 import java.time.LocalDate

 case class Conference(name: String, startDate: LocalDate, endDate: LocalDate) {
 require(name.nonEmpty)
 require(startDate.isEqual(endDate) || startDate.isBefore(endDate))
 }

In the example above, we use Scala's builtin function require to ensure our datatype complies to our requirements. In order to ensure we've captured the potential runtime errors, we can either wrap the datatype construction with a try-catch block or the Try constructor:

 try {
 val invalidConference = new Conference("", LocalDate.now(), LocalDate.now())
 } catch {
 case ex: IllegalArgumentException =>
 // Handle the error in any way you like here
 println("Invalid parameters when creating a conference: " + ex.getMessage)
 }

 val invalidConference: Try[Conference] = Try(new Conference("", LocalDate.now(), LocalDate.now()))

The issue here is the same as with any other function that throws errors: the function is partial, not total. This means that only a subset of inputs will produce a value corresponding to the expected type while the rest of the inputs will cause the program execution to escape the normal program flow. The outcome of the invalid inputs is not represented in the type system, thus it is not type-safe.

In practice, the issue with invariant validation that is not type-safe is that it puts the burden of capturing errors on the user's side. Failing to capture errors produces non-working software in places where you'd normally expect them work just fine. As the places where the datatype is constructed increases, so does the chance of failing to capture the errors.

Enforcing invariants in a type-safe style

In order ease the burden of manually catching errors, we can make the invariant validation type-safe by representing the potential runtime errors in the type system. This can be done by providing the users a constructor that returns either the constructed value (an instance of a conference) or an error value.

 class Conference private (
 name: String,
 startDate: LocalDate,
 endDate: LocalDate
 )

 object Conference {
 def apply(name: String, startDate: LocalDate, endDate: LocalDate): Option[Conference] =
 if (name.nonEmpty && (startDate.isEqual(endDate) || startDate.isBefore(endDate))) {
 Some(new Conference(name, startDate, endDate))
 } else {
 None
 }
 }

 val validConference: Option[Conference] = Conference("ScalaDays 2017", LocalDate.of(2017, 5, 30), LocalDate.of(2017, 6, 2))
 val invalidConference: Option[Conference] = Conference("", LocalDate.now(), LocaDate.now())

In the example above, we've defined a class for the conference datatype, and an alternative constructor function in the datatype's companion object that validates the input. For the sake of simplicity, we've represented the return type of the alternative constructor as an Option[Conference], where the absence of the value represents a validation error.

We've also hidden the primary constructor of the datatype. This way the constructor can only be used in the scope of the alternative constructor to create validated instances. If the constructor is not hidden, invalid instances may be created by the user accidentally using the wrong constructor. Hiding the primary constructor also effectively prevents the extension of the class.

A more detailed representation of the construction could include more details about the invariant validation errors. When using the Either type, one of the sides in the type could be used for representing one or more validation errors, while the other side would represent the successful value. For example in Either[List[Error], Conference], the left-side represents all of the errors found during construction, and the right-side represents the successfully built instance of a conference. Regardless of which return type is used, the pattern for building type-safe values is similar: the return value must be "unwrapped" to reach the actual value.

We can further enhance the validation process by creating meaningful datatypes for the datatype's fields. For example, the name of the conference can made to its own datatype with its own validation rules:

 class Name private (val name: String) extends AnyVal

 object Name {
 def apply(name: String): Option[Name] =
 if (name.nonEmpty) Some(new Name(name))
 else None
 }

Here the name is encapsulated in a single value class. By making the datatype a value class (i.e. it extends AnyVal), we can in some cases avoid the overhead of allocating the object around the string, but at the same time enjoy the type-safety it provides compared to plain strings. As a value class, the class will also automatically have equals and hashCode methods based on the type it wraps.

With the Name type in place, we can make the Conference type use it without having to repeat the validation process.

 class Conference private (
 name: Name,
 startDate: LocalDate,
 endDate: LocalDate
 )

 object Conference {
 def apply(name: Name, startDate: LocalDate, endDate: LocalDate): Option[Conference] =
 if (startDate.isEqual(endDate) || startDate.isBefore(endDate)) {
 Some(new Conference(name, startDate, endDate))
 } else {
 None
 }
 }

 val validConference: Option[Conference] = for {
 name <- Name("ScalaDays 2017")
 conference <- Conference(name, LocalDate.of(2017, 5, 30), LocalDate.of(2017, 6, 2))
 } yield conference

Escaping invariant validation in case class datatypes

In Scala, case classes bring a bag full of goodies to regular old classes. For example, case classes have an automatically implemented equals, hashCode, toString methods, and an extractor for pattern matching based on the class fields.

Case classes are convenient for implementing datatypes, so it makes sense to use them as the base type for datatypes where invariants are validated in a type-safe way. However, they also make it easy to bypass the validation checks. Unlike regular classes, case classes have more than one constructor that need hiding. Besides the regular constructor, case classes can also be constructed using their auto-generated apply function and copy methods.

 case class Conference private (
 name: String,
 startDate: LocalDate,
 endDate: LocalDate
 )

 object Conference {
 def create(name: String, startDate: LocalDate, endDate: LocalDate): Option[Conference] =
 if (name.nonEmpty && (startDate.isEqual(endDate) || startDate.isBefore(endDate))) {
 Some(new Conference(name, startDate, endDate))
 } else {
 None
 }
 }

 // Invalid instance through apply function
 val invalidConference1: Conference = Conference("", LocalDate.now(), LocalDate.now())

 // Valid instance...
 val Some(validConference) = Conference.create("ScalaDays 2017", LocalDate.of(2017, 5, 30), LocalDate.of(2017, 6, 2))

 // ...can be a gateway to an invalid instance.
 val invalidConference2: Conference = validConference.copy(name = "")

In the example above, we've replaced the normal Conference class with a case class. We can still create validated instances of the datatype using the create function in the companion object. However, we can still access the auto-generated apply method, and create invalid instances that way. Moreover, we can use the copy method to create an invalid copy of the datatype from a valid datatype.

The copy method can be erased by manually overriding it with a method that doesn't produce invalid copies, but the apply function can neither be overridden or hidden. The inability to replace the function is why the validating constructor function has to occupy a different name. These features make case classes unfeasible for datatypes that enforce invariants in a type-safe way.

Regaining the case class features

As mentioned earlier, case classes contain a lot of useful features. Thus it would be a shame to lose them just because their apply and copy constructors clash with the invariant validation process. How can we keep the case class features that don't conflict with the validation?

One way to have case classes without apply and copy constructors is to make the case classes abstract and sealed. Like any other class, case classes can be made abstract. This means that the class may define function interfaces that are left open for implementation in its subclasses. It also means that the class must be extended as no instance of it can be created directly even when there's nothing left for the subclass to implement. Therefore, apply or copy constructors are not generated for the case class because there's no known constructor to base their implementation on.

Because there is no final modifier for limiting subclassing with traits and abstract classes, we'll have to use the sealed modifier instead. The sealed modifier allows us to limit the scope in which subclasses are made to the source file. Thus, no instances can be made without accessing the constructors we provide.

 sealed abstract case class Conference(name: String, startDate: LocalDate, endDate: LocalDate)

 object Conference {
 def apply(name: Name, startDate: LocalDate, endDate: LocalDate): Option[Conference] =
 if (name.nonEmpty && (startDate.isEqual(endDate) || startDate.isBefore(endDate)))
 Some(new Conference(name, startDate, endDate) {})
 else
 None
 }

In the example above, we've recreated the earlier Conference datatype, but this time as a sealed abstract case class. Our only means of constructing an instance is through the custom constructor we provide. However, as the datatype is now a case class, we can use its case class features such as auto-generated equals and hashCode functions.

An alternative way to get case class features in a regular class is to use ScalaMeta's @data annotation macro. The @data annotation macro automatically generates case class features for any regular class that uses the annotation. The annotation allows selecting which case class features are included for each class.

In order to use the annotation, we first need to enable ScalaMeta and the paradise compiler plugin for the project. Here's an example of what needs to be added to our SBT configuration:

 // Resolvers for the ScalaMeta library and paradise plugin
 resolvers in ThisBuild += Resolver.url("scalameta", url("http://dl.bintray.com/scalameta/maven"))(Resolver.ivyStylePatterns)

 // Enable paradise compiler plugin
 addCompilerPlugin("org.scalameta" % "paradise" % "3.0.0.138" cross CrossVersion.full)
 scalacOptions += "-Xplugin-require:macroparadise"

 // Add library dependency for ScalaMeta
 libraryDependencies += "org.scalameta" %% "scalameta" % "1.3.0"

After enabling the library and the compiler plugin, we can use the @data annotation.

 @data(copy = false, apply = false)
 class Conference private (name: String, startDate: LocalDate, endDate: LocalDate)

 object Conference {
 def apply(name: String, startDate: LocalDate, endDate: LocalDate): Option[Conference] =
 if (name.nonEmpty && (startDate.isEqual(endDate) || startDate.isBefore(endDate)))
 Some(new Conference(name, startDate, endDate))
 else
 None
 }

In the example above, we've annotated the Conference class with the @data annotation. By default, all of the case class features are enabled for the class. Here we've disabling the copy and apply constructors, thus we can have full control of the constructors that are visible to the datatype user. #Scala #Class Invariant

Opening this PNG in Chrome shows a different image than in Safari or any desktop app

Sat, 27 Dec 2025 00:00:00 +0000

Opening this PNG in Chrome shows a different image than in Safari or any desktop app

This post was discussed in HackerNews

Check this beautiful painting, Pleading, an artwork by Sir Lawrence Alma-Tadema:

If you are using Firefox or a Chromium browser (for me Google Chrome 143.0.7499.170), it's very likely that you are seeing a very foggy version of the painting, however, if you download the image and open it with your default image viewer (or open it in the Safari browser), you will see the image normally.

My website contains some of these artworks, you're probably looking at one now on the right side of the page if you are reading from a desktop browser, I sent one of the pages to my friend and he told me that the image looks foggy, and I spent hours debugging a nasty edge case in how browsers handle PNG color profiles.

What's going on

You open a PNG screenshot in your desktop app, it looks great, you include it in a web page suddenly there's a white, foggy veil over everything. The contrast is wrong, colors look washed out, and you're left wondering if the file got corrupted somehow. The instinct? “Something must be wrong with the image encoding.” Maybe it's alpha transparency? Gamma? Some weird metadata? (will tbh this was not really my instinct, I first debugged my web server for 20 minutes.)

Attempt 1: Strip Metadata and Fix Alpha

The first suspect is usually alpha channel issues or embedded metadata:

mogrify -strip -alpha off -alpha on -colorspace sRGB *.png

Result: No change. The images still look foggy in Chrome.

Attempt 2: Fix the Gamma

When you run identify -verbose on the image, you might see:

Gamma: 0.454545

Aha! Surely this is a gamma correction issue. Chrome must be applying gamma math differently than desktop apps.

mogrify -gamma 2.2 -colorspace sRGB -strip *.png

Result: The image gets even more foggy. Now it's worse!

(fun-related fact: ImageMagick's identify command reports an assumed gamma for PNG decoding, not necessarily the presence of an actual gAMA chunk in the file. You were chasing a phantom.)

Attempt 3: Nuclear option

Fine, let's just rewrite all the pixels from scratch:

mogrify -alpha remove -background white -flatten -colorspace sRGB *.png

Result: Still foggy. Nothing changed.

Because the problem isn't in the pixel data at all.

Attempt 4: Remove the gAMA Chunk

Maybe it's that pesky gamma chunk after all. Let's use pngcrush to remove it without touching the pixels:

pngcrush -ow -rem gAMA -rem cHRM -rem iCCP -rem sRGB *.png

Result: Still no change.

Plot twist; here was never a gAMA chunk to begin with!

The Smoking Gun

After all these failed attempts, it's time to actually look at what's in the PNG file:

pngcheck -v image.png

The output reveals the truth:

chunk iCCP at offset 0x00025, length 5147
profile name = ICC Profile, compression method = 0 (deflate)
compressed profile = 5134 bytes

There it is: an embedded ICC color profile, about 5KB in size. No gAMA chunk. No broken alpha. Just an ICC profile

What's Really Happening

(1) The PNG contains an embedded ICC color profile* (likely Display-P3 or another wide-gamut color space), (2) Chrome fully honors ICC profiles and performs proper color management (3) Desktop image viewers often ignore or approximate ICC profiles to keep things simple.

Result: Chrome shows you what the image actually looks like according to its embedded profile, while desktop apps (and apparently Safari) show you a “helpful lie”.

The paintings came from the internet, likely screenshots from macOS, iOS, or modern web tools that default to the Display-P3 color space. The pixel values are encoded for Display-P3, but when Chrome renders them, it respects that color space. Desktop apps? They just assume sRGB and move on.

You don't want to strip the ICC profile, that would leave Display-P3 pixel values being interpreted as sRGB, making things worse. You need to convert the pixels to sRGB:

magick mogrify -profile /System/Library/ColorSync/Profiles/sRGB\ Profile.icc *.png

This command does three things: 1. Reads the embedded ICC profile 2. Converts the pixel values from that color space to sRGB 3. Embeds a correct sRGB ICC profile

After running this, Chrome will display the images correctly, matching what you saw in your desktop apps all along.

Unironically we're living in a world where modern devices support Display-P3, DCI-P3, and other wider color spaces but some apps do full color management, others fake it.

The “helpful lies” that desktop image viewers tell you (ignoring ICC profiles, making assumptions about color space) work great until you need actual color accuracy. Then they break down.

Takeaways:

Chrome was not wrong. it's doing proper color management by respecting the embedded ICC profile
Desktop apps might lie. they ignore color profiles to avoid confusion, but this masks the real issue
Identify might mislead you. the “Gamma” value it reports is often ImageMagick's assumption, not file metadata
Convert, don't strip. When dealing with ICC profiles, you must convert pixel values to the target color space, not just remove the profile

#Programming

Email as a universal feed reader

Thu, 25 Dec 2025 00:00:00 +0000

Email as a universal feed reader

I was chatting with some friends on IRC about RSS feeds and elfeed came up. While elfeed is great, it has some real limitations - try forwarding a feed item as an email, or converting it to HTML for further processing (like turning it into Org mode notes). These pain points got me thinking.

Three years ago, I switched to mu4e for email management and fell in love with how extensible it is. The query system is incredible - you can find exactly the emails you want with surgical precision.

Then it hit me: why not use this same powerful interface for everything? RSS feeds, newsletters, email subscriptions, Reddit, YouTube - all in one unified view. The approach seemed so intuitive to me that I'm genuinely surprised more people don't do this.

Here's my current setup that gives me a single dashboard for all content (It's Ridiculously Simple):

Install rss2email; plenty of guides online for this. Add all your feeds and configure it to use a unique identifier (I use myusername+feeds@mymailprovider.com as the sender address).
Set up email filtering; Create a rule in your email provider to catch anything with your unique RSS identifier and automatically file it into an /rss folder. The trickier part is manually moving your existing newsletters and subscriptions into this folder too, but it's a one-time task.
Configure mu4e views; set up your mu4e to display the RSS folder however you like.

That's it. Now I have RSS feeds, newsletters, Reddit posts, YouTube notifications, and everything else that supports RSS/Atom in one searchable, taggable, forwardable interface. I can process items as emails, convert them to other formats, or integrate them into my note-taking workflow seamlessly.

The whole thing just feels so natural - email is already a universal inbox, so why not make it truly universal?

Might be related: Where to get news? #Emacs #Programming

Re: Programmers and software developers lost the plot on naming their tools

Mon, 15 Dec 2025 00:00:00 +0000

Re: Programmers and software developers lost the plot on naming their tools

My last post Programmers and software developers lost the plot on naming their tools was discussed heavily in HackerNews, Lobsters, and r/coding. I'd like here to response to some comments that repeated fairly frequently.

`awk` is not a good name

This comment specifically argues on this part:

Perhaps I was not very clear, but I didn't claim that any of these are good-enough names. Unlike many other disciplines, computer scientists never considered the problem of naming seriously, ideally, as I claimed in the previous post, we would have compound terms or namespaces for naming (so when another person develop another global regular expression print, it won't have collision with grep). Instead, my claim was that any of these names are still much better than "dogfind" or whatever anime character someone would pick to name their regex implementation after. Awk is indeed a bad name, but at least people back then were able to relate it to something, even if it was the author initials.

Scientists have Sonic hedgehog, and other very unusual names

The claim was that even other scientists maintain some strange naming. But you can notice from the linked Wikipedia links how they indicate that they're "unusual", this should be enough to explain how this case differs from what we have in software development, which is the norm. Here's my response to one of the comments that mentioned Sonic hedgehog and some other bad names:

Sonic hedgehog is a terrible example this case. Researchers literally had to tell parents their children had mutations in the "sonic hedgehog gene." The scientific community recognized this was a problem and it's a widely-known controversy. It's cited as an example of bad naming in medical ethics discussions.

Boaty McBoatface? officials overrode the vote to name it after David Attenborough. The actual research submarine got the joke name. Again, this proves my point.

Fat Gary was an internal chip designation that never needed to be public-facing. Perfectly fine.

"Names are only for distinct identification" if efficiency was not at a question. Why use worse identifiers when better ones cost the same?

There's a lot of mythological links in most, even recent, scientific naming

Again, very different case. My response:

The "Raptor Lake" codename in microprocessors is internal, the product ships with systematic designation. Engineers spec chips by model numbers that encode generation, tier, and performance class.

In Pharmaceuticals, Doctors prescribe "sildenafil," not "Viagra." The generic name describes chemical structure. Brand names are marketing for consumers, not professional nomenclature.

Mythology in chemistry/astronomy has centuries of legacy and connects to human cultural history. Calling an element "Titanium" after Titans carries weight. Calling a SQL replicator "Marmot" connects to… what, exactly? A weekend at the zoo?

If the community followed the author's guidance, we would have names like "Generic LLM wrapper 690"

My response:

Not at all. You don't name by category, you can name by function or approach. PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL). If your "LLM wrapper" does nothing distinctive worth naming, maybe don't publish it. But if it specifically handles streaming, call it something like "llm-stream-client." If it focuses on prompt templating, "prompt-template-engine." The name encodes the actual value proposition.

I actually stated this on the post, but let me reiterate, I think that naming things in somehow fun way is totally okay as long as it stays relevant to what the tool actually does (you can have this achieved by play wording suffixes (Mongo"DB", Open"SSL", Ma"git" are good examples, all are better than elephant, dog, and beaver).

Again, we had much better technology to do much more effectively than that.

Now what all these objections have in common? They're all defending the status quo by pointing to edge cases, internal designations, or acknowledged mistakes in other fields. But renaming is hard!" (So get it right initially.) "But scope changes!" (That's a feature, not a bug, the name should constrain scope.) None of these arguments address the core problem: the cumulative cognitive tax imposed on every developer who encounters your arbitrarily-named tool. They're optimizing for the creator's convenience at shipping time while ignoring the compound interest of confusion paid by every user thereafter.

What I'm Actually Asking For

I'm not insisting every tool be named with Germanic compound precision. I'm asking for a return to the basic professional standard that existed (roughly) before we decided software engineering was too cool for clarity.

The bar is remarkably low:

Does the name give any hint about the domain? (Database, HTTP, parsing, etc.)
Does it avoid actively misleading people about what it does?
Could someone plausibly guess the category from the name alone?

That's it. MongoDB clears this bar. PostgreSQL clears it. "Marmot" for a SQLite replicator does not. "Isso" for a commenting system does not. "Viper" for configuration management does not.

The question isn't "are descriptive names perfect?" They're not. The question is: "are they better than random words?" And the answer is obviously yes.

Every defense of arbitrary naming boils down to: "descriptive naming has edge cases and costs." True. But those costs are one-time (renaming, choosing carefully) or constrained (scope can't silently expand). Random naming has perpetual costs paid by everyone who encounters the tool, forever. #Programming

Programmers and software developers lost the plot on naming their tools

Thu, 11 Dec 2025 00:00:00 +0000

Programmers and software developers lost the plot on naming their tools

This post was discussed in HackerNews, Lobsters, and r/coding. You can check also my response to some comments.

In Dec 2022 I watched Richard Stallman's talk on the EmacsConf¹, it was titled "What I'd like to see in Emacs". One of the interesting points Mr. Stallman pointed out in this talk was "memorable names", "I think every package that you […] should have a name that helps you remember what job it does. […] We've had a tendency to give packages names for the sake of pure wordplay or lack of obvious meaning". That Stallman felt compelled to make this point in 2022 tells you everything about how far we've fallen, even within the Emacs ecosystem (known for its descriptive naming conventions, dired for directory editor, eshell for Emacs shell).

There's an odd tendency in modern software development; we've collectively decided that naming things after random nouns, mythological creatures, or random favorite fictional characters is somehow acceptable professional practice. This would be career suicide in virtually any other technical field.

I remembered Stallman's comment lately when I had some difficulties following my friend who was describing some situation in their infrastructure. She was saying something like that: "We're using Viper for configuration management, which feeds into Cobra for the CLI, and then Melody handles our WebSocket connections, Casbin manages permissions, all through Asynq for our job queue.", perhaps only the last software in this statement was saying something about what the package/software actually does, I spent couple of moments trying to make sense of the names she mentioned, googled some of them, and really while I'm doing that I remembered that I never had to do this when interacting with any other fields: the Golden Gate Bridge tells you it spans the Golden Gate strait. The Hoover Dam is a dam, named after the president who commissioned it, not "Project Thunderfall" or "AquaHold." Steel I-beams are called I-beams because they're shaped like the letter I. Even when engineers get creative, there's logic: a butterfly valve actually looks like butterfly wings. You can tell how the name relates to what it actually defines, and how it can be memorable. If you wrote 100 CLIs, you will never counter with a cobra.

Same thing applies to other fields like chemical engineering, where people there maintain even stricter discipline. IUPAC nomenclature ensures that 2,2,4-trimethylpentane describes exactly one molecule. No chemist wakes up and decides to call it "Steve" because Steve is a funny name and they think it'll make their paper more approachable.

It was not always like that (I believe)

I read a lot into software history, and I can't really say that there was an era of fantastic naming (even very experienced engineers made some very silly naming) but at least some current was trying to make some sense in the 80s; grep (global regular expression print), awk (Aho, Weinberger, Kernighan; the creators' initials), sed (stream editor), cat (concatenate), diff (difference). Even when abbreviated, these names were either functional descriptions or systematic derivations. Nobody named the copy command "Sparkle" or the move command "Whisper."

Early programming languages followed similar logic: FORTRAN (Formula Translation), COBOL (Common Business-Oriented Language), BASIC (Beginner's All-purpose Symbolic Instruction Code), SQL (Structured Query Language), I believe Lisp stands for list processing. The pattern was clear: names conveyed purpose or origin. Somewhere around the 2010s, a memetic virus infected software engineering. Perhaps it started innocently, developers tired of boring corporate naming conventions wanted personality in their open-source projects? maybe. A few quirky names were charming. A database named after an animal? Sure, MongoDB (from "humongous") at least has etymological connection to its purpose, even if "Mongo" became the shorthand.

But we didn't stop there. We kept going. Now we're drowning in a zoo of meaningless appellations where the connection between name and function has been severed entirely. Probably pattern accelerated with the rise of GitHub and startup culture. Everyone wanted to be the next Google, a meaningless name that became iconic through market dominance. Google could afford to build brand recognition through billions in advertising and becoming a verb. Your MIT-licensed file parser with 45 GitHub stars cannot.

The cognitive tax

Every obscure name is a transaction cost levied on every developer who encounters it. When you see "libsodium," you must context-switch from problem-solving mode to detective mode: "What does this do? Let me check the README. Ah, it's a crypto library. Why is it called sodium? Because chemistry? Because NaCl? Clever, I suppose." Now, multiply this by dozens of dependencies in a modern project. Each one demands tribute: a few seconds of mental processing to decode the semantic cipher. Those seconds accumulate into minutes and effort, then career-spanning mountains of wasted cognitive effort.

Imagine that you are to explain to a new engineer how is your codebase structured, and the general architecture of some project, and go through the dependencies you use to delegate some certain tasks to and explain how they orchestrate together. Actually let me put my friend's statement again instead: "We're using Viper for configuration management, which feeds into Cobra for the CLI, and then Melody handles our WebSocket connections, Casbin manages permissions, all through Asynq for our job queue".

Now pause and actually process that sentence. there's a snake, another snake, music, a mysterious proper noun, and… async-with-a-q? Half your mental RAM is busy pattern-matching these arbitrary tokens to their actual functions instead of focusing on the architectural decisions being discussed. This is the equivalent of a cardiologist saying "we'll install a Butterfly in your Whisper to improve your Thunderbeat" instead of "we'll place a stent in your artery to improve your cardiac output." Compare this to reading a scientific paper in materials science. When you encounter "high-entropy alloys" or "shape-memory polymers," the name itself conveys information. You can make educated guesses about properties and applications before reading a single word of description.

Some excuses I've heard of

I was told some of the following when I shared my concerns about naming before, here's my thoughts of some:

"But memorable names help with marketing!" Sure, if you're building a consumer product. Your HTTP client, cli utility helper, whatever library is not a consumer product. The people who will ever care about it just want to know what it does.
"Descriptive names are boring!" Yes, and surgical instruments are boring. Boring is fine when clarity is paramount. This isn't creative writing class.
"It's just for fun!" Your fun has externalities. Every person who encounters your "fun" name pays a small tax. Across the industry, these taxes compound into significant waste².
"All the good descriptive names are taken!" We could have used namespaces, prefixes, or compound terms like every other engineering discipline has done for centuries. We have the technology. But even if you can not do that, at least make the name has anything to do with the product, put a "DB" post-fix, do some word play like how "magit" does. If you couldn't be clear, you could have made it relatable at least.

The path forward

Whatever happened wasn't malicious—it was cultural. As programming shifted from corporate mainframe work to the community builders.³, the social norms shifted too.

Thus, we need a cultural correction. Not regulation open source thrives on freedom, but a revival of professional standards through social pressure and education.

Name your library after what it does. Use compound terms. Embrace verbosity if necessary. http-request-validator is infinitely superior to "zephyr" when someone is scanning dependencies at 2 AM debugging a production incident.

If you absolutely must have a cute mascot or reference, fine-make it the project mascot, not the name. PostgreSQL has Slonik the elephant. PostgreSQL is still called PostgreSQL. The elephant doesn't replace semantic meaning.

Reserve the creative names for end-user products where branding matters. For infrastructure, tools, and libraries, choose clarity. Every time.

The next time you're about to name your project after your favorite anime character, pause. Ask yourself: "Would a civil engineer name a bridge support system this way?" If the answer is no, choose a better name.

Our field deserves better than a zoo of random nouns masquerading as professional nomenclature. Clarity isn't boring, it's respect for your users' time and cognitive resources. #Programming

Footnotes

Today ([2026-03-19 Thu 08:56]) I was reading The Gemini Protocol in 2026, it has the following note: "This article is about Gemini, the HTTP-like Internet protocol for document browsing, and not the large language model or the cryptocurrency of the same name. Nor it is about astrology". This would have been a better intro IMO.

And yeah, I know, this is not our biggest concern nor the biggest problem the industry is facing now, but sorry I had to talk about it.

Which was a good thing.

Deciding my favorite artist

Sat, 06 Dec 2025 00:00:00 +0000

Deciding my favorite artist

I enjoy art and paintings, someone dear to me gifted me recently¹ an encyclopedia of art, it has the names of "every"² artist, starting from roughly where civilization striated, or to be more accurate it starts 600 B.C. and attributes everything before that to "unknown", which is not a big deal for me.

I started reading from it, checking artworks on daily-basis, and document the ones I like in my PKMS. I do skip so many modern artists (for reasons I can explain somewhere else, and I should) but I believe I can cover them later. As of today, I kept my habit for exploring an artwork everyday, for 253 day, I'm still on the "D" letter.

I didn't encounter yet many artists that I love. When I was asked before about my favorite artist, I usually responded with Caspar David Friedrich, I loved the man's journals before his art. Sometimes I would answer with Karl Friedrich Schinkel or Francois-Auguste Ravier. Sometimes just Leonadrdo da Vinci so the other person can relate and contribute to the conversation about the artist.

For me, choosing a favorite artist is much more difficult that choosing a favorite sonata. I still think that both are not possible, I usually answer such questions only to keep the conversation warm. But what if we can define "favorite"? Because it's really hard to tell, is it asking about the most enjoyable? The most noble? The one I endorse the most?

I had that discussion regarding the word favorite with a colleague, and she had a nice suggestion, what if we could decide a formula (thus, a definition) of the most "favored" artists? her approach was; the most favorable is the one that occurs the most, as simple as that. But I wanted more sophisticated approach. Here's how her approach might be represented formally:

\[\text{Favor Score} = \frac{L}{T} \times \log(L + 1)\]

where $L$ represents the number of loved artworks and $T$ represents the total artworks in your library by that artist.

It simply tries to care more about the density of appreciation within exposure rather than occurrence. The ratio $r/T$ captures what we might call “hit rate”: how consistently an artist moves you relative to how much of their work you've encountered. An artist who captivates you with 30 out of 50 works demonstrates a more reliable connection than one who captivates you with 63 out of 700. The logarithmic term $\log(L + 1)$ is a “volume bonus” that prevents the formula from over-penalizing prolific artists. The logarithm grows slowly enough to reward breadth of appreciation without letting it dominate the hit rate. I will call this algorithm 1. Let's see how we can implement it.

Implementing naive occurrence counting (algorithm 1)

We will need first to start with data collection. The book didn't include a number for how many each artist has of works, and I didn't like all of them so I can't depend on my PKMS, nor did I count them. Lucky enough, wikiart.org provides a number of artworks for each artist entity. A quick trick, that I learnt from the Data Engineering 101 class, got me the following list:

Ivan Aivazovsky :nworks:   700
Benjamin West :nworks:   156
Emile Claus :nworks:   26
John Constable :nworks:   190
William Ashford :nworks:   87
Carl Aagaard :nworks:   220

nworks here stands for number of works. I also needed to populate this into my PKMS, which is just Org mode file, I loaded the above result into an EMACS buffer, and evaluated the following:

(defun salih/org-set-nworks-from-buffer (data-buffer org-buffer)
 (interactive
 (list (read-buffer "Data buffer: " (current-buffer))
 (read-buffer "Org buffer: ")))
 (let (alist)
 (with-current-buffer data-buffer
 (goto-char (point-min))
 (while (re-search-forward
 "^\\([^:]+?\\)[[:space:]]*:nworks:[[:space:]]*\\([0-9]+\\)" nil t)
 (let ((name (string-trim (match-string 1)))
 (count (match-string 2)))
 (message "Parsed: %s -> %s" name count)
 (push (cons name count) alist))))
 (with-current-buffer org-buffer
 (org-map-entries
 (lambda ()
 (let* ((heading (string-trim (nth 4 (org-heading-components))))
 (entry (assoc-string heading alist t)))
 (if entry
 (progn
 (message "Setting %s NWORKS=%s" heading (cdr entry))
 (org-set-property "NWORKS" (cdr entry)))
 (message "No data for: %s" heading))))
 t 'file))))

This means that each artist entity in the file will look like the following:

** Nicolai Abildgaard
:PROPERTIES:
:ID: i0jf8l21fkk0
:CUSTOM_ID: i0jf8l21fkk0
:NWORKS: 30
:END:
** Jacques-Laurent Agasse
:PROPERTIES:
:ID: dcjcb680hkk0
:CUSTOM_ID: dcjcb680hkk0
:NWORKS: 45
:END:
** Mariotto Albertinelli
:PROPERTIES:
:ID: 2um0gc80hkk0
:CUSTOM_ID: 2um0gc80hkk0
:NWORKS: 19
:END:
** Domenico Ghirlandaio
:PROPERTIES:
:ID: 1dq2tj80hkk0
:CUSTOM_ID: 1dq2tj80hkk0
:NWORKS: 108

Now we can implement $\frac{L}{T} \times \log(L + 1)\$ easily in Elisp;

(simple-score (loved total)
 "Simple approach: (L/T) * log(L+1)"
 (if (and (> total 0) (> loved 0))
 (* (/ (float loved) total)
 (log (1+ loved)))
 0.0))

Here's the simple score result:

Note I'm running this here as of the date of writing it [2025-12-07 Sun 01:02], as I mentioned above, I only browsed the artists of the D letter. I will add here "Last run" property, so reader can relate to the last update date

Last run [2025-12-07 Sun 01:28]

Artist Total Simple Eval.
Thomas Cole 130 0.5943
Alexey Bogolyubov 46 0.5213
Mariotto Albertinelli 19 0.2189
Pellizza da Volpedo 54 0.2162
Charles Courtney Curran 32 0.2012
Frank Dicksee 27 0.1540
Giuseppe Abbati 28 0.1485
Jasper Francis Cropsey 31 0.1342
Frank Cadogan Cowper 20 0.1099
William Ashford 87 0.1030
Pierre-Henri de Valenciennes 100 0.0896
Gustav Pope 9 0.0770
Pietro da Cortona 29 0.0758
Ivan Aivazovsky 700 0.0757
Jacques Clement Wagrez 10 0.0693
Thomas Francis Dicksee 12 0.0578
Gustave-Claude-Etienne Courtois 13 0.0533
Jacques-Laurent Agasse 45 0.0488
Frederic William Burton 50 0.0439
Jean-Joseph-Xavier Bidauld 16 0.0433
Edouard Debat-Ponsan 17 0.0408
Denis van Alsloot 61 0.0360
Jean-Baptiste Camille Corot 600 0.0345
Arnold Böcklin 124 0.0335
Jacques-Louis David 128 0.0325
Reza Abbasi 23 0.0301
Carl Aagaard 220 0.0293
William-Adolphe Bouguereau 822 0.0292
Emile Claus 26 0.0267
Sir Lawrence Alma-Tadema 444 0.0263
Thomas Couture 28 0.0248
Hermann David Salomon Corrodi 28 0.0248
Alexandre Cabanel 90 0.0244
Nicolai Abildgaard 30 0.0231
Joachim Wtewael 30 0.0231
Charles-Francois Daubigny 102 0.0215
Mattia Preti 33 0.0210
Eduard Quitton 37 0.0187
Domingos Sequeira 40 0.0173
Jacques Stella 41 0.0169
Walter Crane 50 0.0139
Battistello Caracciolo 52 0.0133
Joseph DeCamp 54 0.0128
John Constable 190 0.0116
Jurriaan Andriessen 60 0.0116
Edwin Austin Abbey 61 0.0114
Oswald Achenbach 65 0.0107
Anselm Feuerbach 66 0.0105
Alexandre Antigna 67 0.0103
Frederic Edwin Church 76 0.0091
Giulio Cesare Procaccini 76 0.0091
Knud Baade 79 0.0088
Francesco Albani 80 0.0087
Johan Christian Dahl 100 0.0069
Domenico Ghirlandaio 108 0.0064
Guido Reni 148 0.0047
Benjamin West 156 0.0044
Sandro Botticelli 207 0.0033

However, the issue with depending on occurrence is that, it's very likely that the artists who made significantly more artworks than others, to unfairly be on top of the list, e.g. I love around 63 artworks of Ivan Aivazovsky, but my library of his consists of around 700 artworks (he reportedly made much more than that), it's unfair in my opinion to evaluate this number to another artist, like Thomas Cole for example, who only had around 200 artworks.

Entropy approach (algorithm 2)

The problem with that approach is that, it does not calculate my preference entropy which causes favoritism. For example, I love Caspir's works, I know his melody and life, I would probably relate to any of his works and catch the reference quickly, it's unlikely for me to do the same for someone like John Constable, who I barely know his life. We can count for this like follows:

$$\text{Favor Score} = \frac{L}{T} \cdot \left(1 - \frac{1}{\sqrt{T}}\right) \cdot \left(1 + \frac{H(L,T)}{\log(T+1)}\right)$$

It looks a bit scary, but I promise it's as simple as the previous one, let me explain it. Information theory tells us there's something fundamentally missing from the simple ratio approach: the shape of your preference matters.

Imagine you're at a museum. Artist A has 100 paintings on display, and you love exactly 50 of them. Artist B has 100 paintings, and you love 95 of them. The simple counting method says they're both “50% favorable” and “95% favorable” respectively, okay, sure. But there's something it misses: with Artist A, you're constantly unsure. Will the next painting move you? It's a coin flip. With Artist B, you know you're going to love it, you know him/her, you know you will relate to it and you probably have a backstory already about the painting. That certainty, that decisive connection is what favoritism actually feels like. Information theory gives us a way to measure this decisiveness through something called “entropy” basically, how surprised you are by your own reactions. When you're consistently in love or consistently unmoved, entropy is low (good!). When you're all over the place, entropy is high (suggests a less meaningful relationship). The formula also builds in a confidence check: if you've only seen 4 works by an artist, you can't be that sure yet, so it gently downweights your score until you've seen enough to really know.

So The $L/T$ ratio treats all proportions as equal. Loving 50 out of 100 works scores identically to loving 5 out of 10. The key insight from information theory is that entropy captures the decisiveness of your taste.

Consider Shannon entropy:

$H(L,T) = -\frac{L}{T}\log\frac{L}{T} - \frac{T-L}{T}\log\frac{T-L}{T}$

This measures the uncertainty in predicting whether you'll love a random work by that artist. When $L/T \approx 0.5$, entropy maximizes, you're ambivalent, essentially coin-flipping. When $L/T \to 0$ or $L/T \to 1$, entropy minimizes, your preference is sharp and predictable. A favorite artist should provoke a strong signal, not statistical noise.

The full equation integrates three components: base affinity ($L/T$), confidence scaling ($(1 - 1/\sqrt{T})$ which asymptotically approaches 1 with more samples), and entropy bonus (rewarding low-entropy, decisive preferences).

Now let's bring both together, but sort by algorithm 2:

(defun salih/calculate-artist-favor-scores (org-file)
 (cl-flet ((simple-score (loved total)
 "Simple approach: (L/T) * log(L+1)"
 (if (and (> total 0) (> loved 0))
 (* (/ (float loved) total)
 (log (1+ loved)))
 0.0))
 (entropy-score (loved total)
 "approach with entropy"
 (if (or (<= total 0) (< loved 0))
 0.0
 (let* ((ratio (/ (float loved) total))
 (confidence (- 1 (/ 1 (sqrt total))))
 (p1 ratio)
 (p2 (- 1 ratio))
 (entropy (if (and (> p1 0) (> p2 0))
 (- (+ (* p1 (log p1))
 (* p2 (log p2))))
 0.0))
 (entropy-bonus (if (> total 1)
 (/ entropy (log (1+ total)))
 0.0)))
 (* ratio
 confidence
 (1+ entropy-bonus))))))

 (with-temp-buffer
 (insert-file-contents org-file)
 (org-mode)
 (goto-char (point-min))

 (let ((results '()))
 (while (re-search-forward "^\\*\\* " nil t)
 (let* ((heading (org-get-heading t t t t))
 (id (org-entry-get (point) "ID"))
 (nworks (org-entry-get (point) "NWORKS")))

 (when (and id nworks)
 (let* ((total (string-to-number nworks))
 (node (org-roam-node-from-id id))
 (backlinks (when node (org-roam-backlinks-get node)))
 (loved (length backlinks))
 (simple (simple-score loved total))
 (entropy (entropy-score loved total)))

 (push (list :name heading
 :id id
 ;; :loved loved
 ;; :total total
 :simple-score simple
 :entropy-score entropy)
 results)))))

 (sort results (lambda (a b)
 (> (plist-get a :entropy-score)
 (plist-get b :entropy-score))))))))

This gives us:

Artist Total Entropy Simple
-------------------------------------------------------------------
Alexey Bogolyubov 46 0.2105 0.5213
Thomas Cole 130 0.1849 0.5943
Mariotto Albertinelli 19 0.1394 0.2189
Charles Courtney Curran 32 0.1140 0.2012
Pellizza da Volpedo 54 0.1043 0.2162
Frank Dicksee 27 0.0991 0.1540
Giuseppe Abbati 28 0.0957 0.1485
Jasper Francis Cropsey 31 0.0867 0.1342
Frank Cadogan Cowper 20 0.0859 0.1099
Gustav Pope 9 0.0853 0.0770
Jacques Clement Wagrez 10 0.0776 0.0693
Thomas Francis Dicksee 12 0.0659 0.0578
Gustave-Claude-Etienne Courtois 13 0.0613 0.0533
Pietro da Cortona 29 0.0603 0.0758
William Ashford 87 0.0538 0.1030
Jean-Joseph-Xavier Bidauld 16 0.0507 0.0433
Edouard Debat-Ponsan 17 0.0480 0.0408
Pierre-Henri de Valenciennes 100 0.0469 0.0896
Jacques-Laurent Agasse 45 0.0396 0.0488
Reza Abbasi 23 0.0363 0.0301
Frederic William Burton 50 0.0358 0.0439
Emile Claus 26 0.0324 0.0267
Thomas Couture 28 0.0303 0.0248
Hermann David Salomon Corrodi 28 0.0303 0.0248
Denis van Alsloot 61 0.0296 0.0360
Nicolai Abildgaard 30 0.0284 0.0231
Joachim Wtewael 30 0.0284 0.0231
Mattia Preti 33 0.0260 0.0210
Ivan Aivazovsky 700 0.0252 0.0757
Eduard Quitton 37 0.0234 0.0187
Arnold Böcklin 124 0.0225 0.0335
Jacques-Louis David 128 0.0219 0.0325
Domingos Sequeira 40 0.0217 0.0173
Jacques Stella 41 0.0212 0.0169
Alexandre Cabanel 90 0.0203 0.0244
Charles-Francois Daubigny 102 0.0180 0.0215
Walter Crane 50 0.0176 0.0139
Carl Aagaard 220 0.0172 0.0293
Battistello Caracciolo 52 0.0170 0.0133
Joseph DeCamp 54 0.0164 0.0128
Jurriaan Andriessen 60 0.0148 0.0116
Edwin Austin Abbey 61 0.0146 0.0114
Jean-Baptiste Camille Corot 600 0.0146 0.0345
Oswald Achenbach 65 0.0137 0.0107
Anselm Feuerbach 66 0.0135 0.0105
Alexandre Antigna 67 0.0133 0.0103
Sir Lawrence Alma-Tadema 444 0.0130 0.0263
William-Adolphe Bouguereau 822 0.0119 0.0292
Frederic Edwin Church 76 0.0118 0.0091
Giulio Cesare Procaccini 76 0.0118 0.0091
Knud Baade 79 0.0114 0.0088
Francesco Albani 80 0.0113 0.0087
John Constable 190 0.0099 0.0116
Johan Christian Dahl 100 0.0091 0.0069
Domenico Ghirlandaio 108 0.0085 0.0064
Guido Reni 148 0.0063 0.0047
Benjamin West 156 0.0059 0.0044
Sandro Botticelli 207 0.0045 0.0033
Gustav Klimt 245 0.0038 0.0028
Peter Paul Rubens 684 0.0014 0.0010
Nicolas Poussin 300 0.0000 0.0000

Some of my favorite ones were not affected by approach change, like Thomas Cole, Alexey Bogolyubov and Frank Dicksee, which says that I'm not a lot into favoritism after all :).

I will add an agenda TODO here to remember to update the evaluation every couple of months.

[2025-12-07 Sun 02:32] Honestly I was expecting much more surprises than that, but I guess once the data inflate more (having more artists in my PKMS, finishing more from the encyclopedia) will help.

TODO Update favorite artist evaluation @general

SCHEDULED: <2027-02-08 Mon +1y>

State "DONE" from "TODO" [2025-12-07 Sun 01:35]

#Programming #Art #Mathematics

Footnotes

I wrote this "recently" around 7 months ago when I got the idea of writing this post, and it was left as a draft. I was gifted that book in Jan 2024, almost a year.

More like the ones we get to know

What is it to be done?

Sat, 15 Nov 2025 00:00:00 +0000

What is it to be done?

This is a book by Leo Tolstoy that I picked arbitrarily, I didn't know that it would be about poverty, responsibility and socialism, but I found the name catchy (there are multiple works of the same title that I already possess). The book talks about his experience with surrounding poverty, I really loved how smart he was to challenge what was already accepted, and to take responsibility to investigate and instantiate work on it, although of how tremendous and big such a mission (fixing poverty) would sound to anyone, indeed:

فَتىً لا يَضُمُّ القَلبُ هِمّاتِ قَلبِهِ وَلَو ضَمَّها قَلبٌ لَما ضَمَّهُ صَدرُ

I find the conclusions that he arrived at mostly trivial (at least speaking from the current time), but what I find very important to me, is the emotions shared across the book, the responsibility that took place, and the story overall. Here I'm sharing my selections and anthology of the articles from the book. #Modus Vivendi #What Should We Do? #Leo Tolstoy

Conventional Commits considered harmful

Tue, 30 Sep 2025 00:00:00 +0000

Conventional Commits considered harmful

This post was discussed in Lobsters

I could only see two use cases¹ of using the Conventional Commits v.1.0.0 "convention" when I've heard of it for the first time;

Your project has a very high dependency on history and you expect that you need to check the modification history thoroughly (whatever the kind of project is, let it be a document or a novel being tracked with Git) so you need a very good searchable history with advanced filtering.
You want to fire CI/CD actions on your commits (still questionable purpose and I will explain why).

First let's check the future as described by user _glsb around 8 years ago:

Imagine the following future:

“Have you linted and unit tested your commit message?”

“Junior Developer wanted. 10 years of Conventional Commits experience required.”

“Download Conventionalizer! Now you can write Conventional Commits in plain English, having all the syntax automatically generated! (node, erlang OTP and Jerry’s pre-alpha TensorFlow binding library required. Windows support coming soon.)”

Something tells me the authors are hard at work solving a problem nobody needs solving.

This "future"² happened to me last night when I was trying to support a new feature in Doom Emacs, an Emacs distribution that I've been using, however, upon trying to commit my work I noticed that git is failing to make the commits. Upon investigating I found out that (literally) the linter was not passing my commits³:

1 git … commit --all --
hint: Waiting for your editor to close the file...
Waiting for Emacs...
> Linting commit...
> CURRENT feat(evil): support the new thing
x Invalid scope: evil
! Failures: 1
See https://discourse.doomemacs.org/git-conventions
Please adjust your previous attempt:
feat(evil): support the new thing

I was aware that Doom Emacs is using conventional commits and that the maintainers prefer if the contributors use it too, so I don't really mind doing it since it's the convention for them and I would like to contribute. However, I'm pretty certain that many people just do not give two fucks about how they should style their commits, and just knowing that they need to handle the mental overhead of learning the "proper way" of writing commit messages (oh my God saying that makes me feel horribly silly) but not only that, they need to figure out the proper picklist values of what they need to put between the ( ) and how to write it (for example evil vs evil-mode, :editor or :keyboard), whether their change is breaking or not, whether to put ! or not when is a change considered breaking, and then learn the modifications that the Doom Emacs maintainers put on that "convention". Can you see how unconventional it is for newcomers or people who just want to make a very small change? It filters out so many contributions.

But.. it must be giving something back, right? No. Most software projects do not benefit from having that amount of structure in their commit messages, because it is really not a likely thing that you will need to filter your commits to find out all the "feat" stuff that were added in x module (which is itself is not maintainable in accuracy, because in most software your commits are crosscutting across many modules).

In fact, almost all of the information that would be added in a "conventional commits" are going to be discussed over and over in the PR anyway, you will still have to write a description describing why this change was introduced, if your change has breaking stuff, you will have to do manual work to check that you didn't break any integration (other than the ones that the CI/CD will handle). You will be just passing this information twice.

What about CI/CD triggers from your commits? While this is really useful, it could be totally replaced by much easier checks, in a project I worked in we used to trigger them with GitHub comments in the PR, another quicker way would be to watch certain packages in the CI/CD. For example consider this commit:

fix(keyboard): something was not working

While keyboard is the name of some package. A good way to run CI/CD actions based on this, which is much better than checking the commit and linting it, is to check whether any files under that package were changed, actually doing that will be error-free, as someone might change something in this package and indicate the change as something in totally different package while writing their commits.

Overall this style is just like the many other standards and conventions and it's okay to use, but it's really harmful to enforce it. It values style over content and filters out contributors who care more about the product they're getting and the code more than how your CI/CD is supposed to be managed.

If you still prefer it you can squeeze a PR commits into a single one that follows your preferred style, but please do not ask contributors to learn unuseful and unportable knowledge. #Programming

Footnotes

The maintainers promise that using Conventional Commits will enable some other things that I totally fail to comprehend, like: "Communicating the nature of changes to teammates, the public, and other stakeholders". and how this differs from showing just descriptive commits. And who the hell shows commits to stakeholders anyway?

There are even so many tools that will help you transfer your plain English into syntactically correct conventional commits, just like how the comment describes it (example), nowadays people are using LLMs for that purpose too

As you can see my commit is actually complying to the conventional commits style as well as to the Doom Emacs defined modules, my scope was not invalid. My guess is that it was complaining about the empty description, a bug in the linter probably, but you can get now why it is useless overhead from the first place to have a linter to check your commits.

OSS is not free

Thu, 17 Jul 2025 00:00:00 +0000

OSS is not free

The Wikipedia entry for "Open-source software movement" explicitly warns: "Not to be confused with Free software movement." This distinction matters profoundly. Software that provides source availability, while certainly superior to closed-source alternatives, does not automatically guarantee user freedom. The "open source" label has become a marketing tool that obscures the more fundamental question: does this software respect user autonomy and control?

Telegram is a good example. The company markets itself as "open-source software," yet only portions of its client code are available, and even that availability is questionable¹. Compare this to Signal, which provides complete software freedom: users can examine, modify, and distribute the entire codebase. Telegram's selective transparency creates an illusion of openness while maintaining control over critical components.

Meta's approach to AI represents perhaps the most sophisticated example of this. The company releases what it calls "open source" Large Language Models, providing training code to create an appearance of transparency. This selective disclosure ignores the most crucial elements; no training datasets, no raw data access, no processing scripts, no data samples, no reproducibility mechanisms. This strategic omission allows Meta to claim "open source" credentials while maintaining proprietary control over the foundation of their AI systems. The community's response celebrating Meta as a "leading AI company" for these limited releases demonstrates how effectively this strategy manipulates public perception.

Corporations selectively release components that appear generous while withholding elements that would enable true user freedom. #Programming #Politics

Footnotes

Many times they release the binaries before the code is updated.

The age of commodity

Sun, 17 Nov 2024 00:00:00 +0000

The age of commodity

This post is highly based on (Byron 2019) and Marxism Today content about commodity.

Unlike my previous post, this one is being written while in my travels, I expect it to be less comprehensive but I believe I've some thoughts that deserve to be shared.

Karl Marx described capitalist societies as following: “the wealth of societies in which the capitalist mode of production prevails appears as an immense collection of commodities.”(Marx 1990), it should be noted that "wealth" also imply "value" in Marxism sociology, and not much has changed as of today.

But what's a commodity anyway? Marx described the state of a capitalist society as to be in a "commodity fetishism", the term fetishism here means that an object that appears to have some kind of magical or mystical, supernatural powers within it, which might sound similar to the sexual term as well, when we describe something as a sexual fetish we usually mean that it gets that unexpected (if sexual standardization is a thing) interest in a non-genital human part sexually.

Let's take for example a magic ring as an object. The object somehow contains a power or value that’s perceived to be inherent within it.

The question of where this power or value has come from is obscured, hidden behind a veil of mysticism. Questions regarding where the ring came from, under what conditions it was produced, what its molecular composition is, why it has appeared at this specific moment in time, etc. are all brushed aside. We instead just see a static object that exists with power and value which appears to emanate from the object itself – rather than from complex processes of production among people which have actually given rise to it.

In a capitalist society we are more expected to think of everything as a commodity, no maters what is behind it from production relationship, it's just a commodity that's exchanged with other value commodity, that is money.

In Fifteen Million Merits, Bing works to live, and in order to live he must buy, infinite cycle that even an attempt of breaking it will trigger a rough "resume watching", or he might even get incarcerated. Although the type of commodified life sounds extreme, it's the same kind of society that we live in currently, you can imagine yourself how everything around has been commodified, even the methods you use to read these words are extremely commodified.

One can argue that a commodified life is not that bad, which is usually the counterargument for the free market, however, what about commodified people?

With a historical context, commodification was never the case. Hunter‐gatherers did not have prices for their goods. As societies developed technologically, they often engaged in trade, but there was no system of universalized pricing. For instance, a serf could trade her apples for more chickens, cows, tools, or money. The apples had no normalized universal price stamped on them. But in a capitalist society, eventually one unit of pricing congeals around all objects of use. In Fifteen Million Merits as also in real life (with the concept of international dollars for example) we see the apples are stamped “5000M,” the bananas “2000M,” and the soda “500M.” In principle then, two apples are worth five bananas, or twenty sodas, which infact sounds as a normal thing to us.

No, it's not. As Marx noted, the concept of universalized pricing – where all commodities, including human ones, can theoretically be equated with a single unit of measure – is a relatively recent development. Once established, it appears natural and timeless. As capital expands, it increasingly needs to create markets and commodify goods. This is how capitalism functions to generate more profits, ultimately turning everything into a commodity.

In his essay "Reification and the Consciousness of the Proletariat," Georg Lukács argued that the commodity fetishism inherent in capitalist society was transforming human consciousness. Lukács supported Marx's claim that "it is not the consciousness of men that determines their existence, but their social existence that determines their consciousness." The term "reification" in Lukács's essay refers to a dual phenomenon: people are viewed as objects, like apps and apples, and objects—whether they are people, apps, or apples—take on social relationships.

Reification results from living in a society obsessed with commodity fetishism. "Fifteen Million Merits" offers compelling examples of this, showing how humans are turned into objects and how commodity relationships overshadow human life. One example is Oliver the Lemon, and another is Glee, the silver-haired girl who waits a week for her chance to perform on "Hot Shot." When she finally performs, her voice is found lacking, and she is viewed as unlikable. As a result, Glee is labeled "quite worthless." Her human worth is directly linked to her ability to produce value for exchange.

Abi also tries to create personalized artwork in the form of a papier-mâché penguin, but the janitor throws it away, calling it "detritus" (trash). However, Abi gains value because she can provide sexual gratification in purchasable Wraith Babes episodes. When she makes objects for use rather than for sale, they lack the commodity form and are treated as disposable as trash. Disturbingly, Bing’s fellow cyclist, Dustin, consistently sees humans as objects, making it easier for him to accept their physical and psychological abuse on Wraith Babes and Botherguts (see also Industry and Consumption of Pornography) .

The Real Plot

After Bing is able to get his One Shot he is able to give a speech there, which is regarded the end of the episode. While much of his speech is garbled and nonsensical, it is also insightful and true, both for the world of "Fifteen Million Merits" and our own:

All we know is fake fodder and buying shit. That’s how we speak to each other, how we express ourselves is buying shit. …Show us something real and free and beautiful, you couldn’t. It’d break us, we’re too numb for it, our minds would choke. There’s only so much wonder we can bear, that’s why when you find any wonder whatsoever you dole it out in meager portions, and only then till it’s augmented and packaged and pumped through ten thousand pre‐assigned filters, til it’s nothing more than a meaningless series of lights, while we ride day‐in, day‐out–going where? Powering what? All tiny cells in tiny screens and bigger cells in bigger screens and fuck you…fuck you all, for taking the one thing I ever came close to anything real about anything! For oozing around it and crushing it into a bone, into a joke, one more ugly joke in a kingdom of millions… fuck you!

What really interests me about this episode, especially this scene, is how it's actually is about the previous episode and I think about the show at whole. In my past post about the The National Anthem, I mentioned that what made the plan of the kidnapper successful is that he knew that everyone would be focused in watching the Prime Minster having an intercourse with a pig rather than watching for the princess appearance, although she appeared in the most evident place, the most one that could be noticed, London bridge.

This scene shows us a similar analogy, Bing gave a very strong speech that should affect everyone who's listening to it, to question their life, morals, principles and policy, however, what happens instead is that he gets an offer from the committee to have this performance commodified! That even a message resisting commodification can get commodified itself, and get consumed in that context instead of examining the moralities that it reflects. This concepts apply mostly to every episode in Black Mirror where there a great exciting plot that attracts everyone, similar to Bing's story and speech, however, to most of the consumers, it's just a commodity formed in a video that they purchased from a streaming platform. It's a self-referencing scene. #Postmodern Abyss: Black Mirror

References

Byron, Chris and Brake, Matthew (2019). Fifteen Million Merits and Fighting Capitalism. John Wiley & Sons, Ltd. Link
Karl Marx (1990). Capital Volume I. Penguin.

Proof Mapping is Injection iff Direct Image Mapping is Injection

Mon, 01 Jul 2024 00:00:00 +0000

Proof Mapping is Injection iff Direct Image Mapping is Injection

[2026-03-18 Wed 07:18] Important note

This page was a personal note, content is not original. I'm getting it out of the archive only a the historical purpose. I should also note that this proof is overengineered and slightly sloppy. #Mathematics

Let $ f: S \to T $ be a mapping.

Let $ f^\to: \mathcal{P}(S) \to \mathcal{P}(T) $ be the direct image mapping of $ f $.

Then:

$ f^\to $ is an injection {{iff}} $ f: S \to T $ is also an injection.

Proof:

Suppose $ f: S \to T $ is a mapping, but not injective.

Then: \[ \exists x_1 \ne x_2 \in S: f(x_1) = f(x_2) = y \]

Let: \[ X_1 = \{ x_1 \} \] \[ X_2 = \{ x_2 \} \] \[ Y = \{ y \} \]

Then it follows that: \[ f^\to(X_1) = f^\to(X_2) = Y \]

Thus $ f^\to: \mathcal{P}(S) \to \mathcal{P}(T) $ is not injective.

So by the Rule of Transposition, the result follows.

lemma

Suppose $ f^\to: \mathcal{P}(S) \to \mathcal{P}(T) $ is not an injection.

Then:

\[ \exists Y \in \mathcal{P}(T): \exists X_1, X_2 \in \mathcal{P}(S): X_1 \ne X_2 \land f^\to(X_1) = f^\to(X_2) = Y \]

There are two cases to consider:

Either $ X_1 $ or $ X_2 $ is the empty set.
Neither $ X_1 $ nor $ X_2 $ is the empty set.

WLOG assume that $ X_1 = \emptyset $.

Then, from Image of Empty Set is Empty Set: \[ Y = f^\to(X_1) = \emptyset \]

But that means: \[ f^\to(X_2) = \emptyset \]

Now $ X_1 \ne X_2 $, so $ X_2 \ne \emptyset $.

Thus: \[ \exists x_2 \in X_2: \neg \exists y \in T: f(x_2) = y \] which means that $ f $ is not even a mapping, let alone an injection.

The same argument applies if $ X_2 $ is empty.

lemma

Now, assume that neither $ X_1 $ nor $ X_2 $ is the empty set.

As $ X_1 \ne X_2 $, there must be at least one element in either one which is not in the other.

WLOG assume that $ \exists x_1 \in X_1: x_1 \notin X_2 $.

Now suppose $ f(x_1) = y \in Y $.

However, as $ f^\to(X_2) = Y $, there must be some $ x_2 \in X_2 $ such that $ f(x_2) = y \in Y $.

So: \[ \exists x_1 \ne x_2 \in S: f(x_1) = f(x_2) \] which means, by definition, that $ f $ is not injective.

Thus, if $ f^\to: \mathcal{P}(S) \to \mathcal{P}(T) $ is not an injection then neither is $ f: S \to T $.

Thus, by the Rule of Transposition, the result follows.

qed

The Eghbariah's case, democracy and irresponsibility

Sun, 07 Jan 2024 00:00:00 +0000

The Eghbariah's case, democracy and irresponsibility

Or: how democracy spoils everything.

I think everyone should agree that science is not, nor should it be, democratic. That's probably why science did great in the post-renaissance periods, I personally believe that the democratic methodology is one of the greatest differences between the humanities and science. While the humanities do not embrace any form of democratic methodology, an essence of how democracy works is implicit in the way the humanities are usually produced.

An intuitive example of that is rationality and the refutation of irrationality. The refutation of irrationality is a very regular activity in doing science, it’s actually what science is usually defined as (or how I mostly like to define it): discovering truth by uncovering falsehoods. In the humanities, democracy is a common thing. It’s the common belief of whatever is there (let it be rational or irrational).

I'm not going to criticize democracy here as a political system nor its effects on academic communities, (Caplan 2007) might give you some insights on that about the great problems in democracy like rational ignorance and rational irrationality though, I would like instead to talk about yet another great issue in democracy, that's: responsibility.

Responsibility is also used as a critique of political democracy: no one takes responsibility for their vote because 1. The fraction of one’s vote is too small to understand its segmentation, and 2. People are usually manipulated psychologically through the voting process, some people might change their vote just because they do not like the candidate's name or haircut, and since there is no charge of responsibility and since you do not have to legally and rationally explain why you voted for that candidate, you can do whatever you like.

The tendency to fall for such psychological inclinations rises in situations like that because no one is paying for their mistakes, no one is going to put you in jail for choosing the wrong candidate (assuming that everything is so obvious that the wrongness of one of the candidates can be clearly detected). On the other hand, if one were to be judged for their choice, they might have spent much of their time doing research to clarify their vote.

So basically, responsibility and rationality have a direct relationship: the more you are responsible for your vote, the less you are irrational about it.

Irrationality does not mean unreasonableness, that’s why we have the public choice theory that studies rational irrationality. As I mentioned, you might vote for another candidate just because of reasons that you do not like about him or things that you believe to be bad about him, but you can not be scientifically rational about those reasons even if you are certain about them. For example, let’s say you have some religious belief that makes you believe that one of that candidate’s campaign promises is unlawful and going to rot the world. It’s a religion, so you are probably certain about it ; however, if you can not explain your reasons rationally, it will cause many disputes, so it is defined here as irrationality.

Whilst the current genocide in Gaza has been taking a place, Rabea Eghbariah, Palestinian doctoral candidate at Harvard Law School, submitted a 2,000-word essay arguing that the assault on Gaza is within the legal framework of genocide.

The draft has been in an undergoing process of publication, the typical academic process: "solicited, commissioned, contracted, submitted, edited, fact checked, copy edited, and approved by the relevant editors" as reported.

It seems like a focus group call made the Harvard Law Review president urge to call for an emergency meeting of editors to decide the destiny of the essay: one of the editors who commissioned the essay, Shahriari-Parsa, "and the other top online editor, Sabrina Ochoa, told The Intercept that they had never seen a piece face this level of scrutiny at the Law Review".

Here I'm not interested in giving an example of the constraints on academic freedom, or freedom in general, especially against Palestinian rights, if you are interested in that you can find (Abraham 2014) rather interesting reading (and also check my The Limits on The (allowed) Freedom of Speech), but instead I want the reader to contemplate on the method which the Harvard president called for to decide whether the article should be published or not, do note that the essay perfectly qualifies to be published, as it was reviewed already:

Following requests from over 30 editors, an emergency meeting of the entire journal body was called. After nearly six hours, the more than 100 editors voted anonymously on running the piece or not, with a strong majority voting against publication.

Ironically, the book that I just mentioned had a very similar case, not only similar in the usage of irresponsible, irrational, democracy, but it was also against a Palestinian-rights defender, Norman Finkelstein: after Alan Dershowitz continuous accusations and lobbying of DePaul's professors, department subsequently invited John Mearsheimer and Ian Lustick, two previously uninvolved academics with expertise on the Israel–Palestinian conflict, to evaluate the academic merit of Finkelstein's work; they came to the same conclusion (Forer 2010) that Dershowitz's accusations are based on falsehoods. However, later DePaul's political science department voted nine to three, and the College of Liberal Arts and Sciences Personnel Committee five to zero, to give Finkelstein tenure. The three opposing faculty members subsequently filed a minority report opposing tenure, supported by the Dean of the College, Chuck Suchar. Not only democracy was wrong used in this example, it was moreover violated.

Back to Eghbariah’s story, I think it’s a great depiction and manifestation of what I was talking about earlier, how irresponsibility in democracy can lead to awful choices: the vote was anonymous, no one had to clear any of their intentions, and no one will be asked to clarify them; no one is responsible for choosing anything; even the reviewers who initially approved the article initially (rationally, as that’s their job) can disapprove it by now due to their political views or whatever, as they can now act ’irrationally’ freely.

Irrationality here has reasons (as I mentioned, it does not necessarily have implicit unreasonableness), probably the same reasons one of them would have against Palestine or why to be pro-Israeli. Reasons that shall be disputed can not be introduced as a counterargument to why the essay should not be published, but they can be introduced as arguments why one’s self thinks that it should not be published.

I will give a final example, suppose you are a Muslim or belong to some ethnic group that, for some reason, has a very high crime rate, probably due to historical reasons or poverty; and you have a peer-review work to do on a statistics project that provides shocking information on how the crime rate is very high within your group of people. As a peer-reviewer, you will do your typical job, you might be more skeptical here because you have a motivation, but this should not change anything if the paper was well written.

Now what if you could just vote anonymously to shut down the paper? No questions asked. This will be great, although it’s dishonest: you know that publishing such a paper would have a bad effect, and you start to imagine how the media will use it and link it to racist reasons, how it will be depicted. These are pretty good reasons not to do your job for but unfortunately, such reasons do not work in science, the paper should be published if it qualifies to be. Unless you can provide a clear error in the content, anything you are going to use as a counterargument will be irrationality. #Politics #Democracy Criticism

References

Caplan, Bryan (2007). The Myth of the Rational Voter: Why Democracies Choose Bad Policies. Princeton University Press. Link
Abraham, Matthew (2014). Out of Bounds: Academic Freedom and the Question of Palestine. Bloomsbury Publishing.
Forer, Richard (2010). Breakthrough: Transforming Fear Into Compassion: a New Perspective on the Israel-Palestine Conflict.

Identifying issues and newcomers to Linux

Sat, 06 Jan 2024 00:00:00 +0000

Identifying issues and newcomers to Linux

How I do X on Linux?

I thought I was not going to use this short posts page to write anything technical, but I think being a "power user" does not have anything to do with writing about shit software engineering topics. Anyway, I think I know a fundamental issue new Linux users face, that's not really focused on, it is the understanding of different layers/levels of their operating system. This issue is almost unidentifiable in the other operating systems' communities, although it's there. An example that I've personally seen was asking this question, "I've a DELL laptop, how can I fix this issue with X software?". The question has an unrelated detail that reflects an incomprehension of whatever they are using, they should probably ask how do I fix that on Windows 7 or whatever. Most of the time people who try to help deduce whatever OS or platform they are talking about (mostly from the X), so it is not really a problem on these platforms. However, with Linux, it does really matter especially since the situation on Linux is scarce when it comes to packaging everything. Ubuntu is probably the only Linux distribution that gets the best out of that, for example let's assume that question: how to fix the ugly terminal font in my Ubuntu laptop? well just open gnome settings and change it from there. Once you knew that whoever is asking is an Ubuntu user you know for sure that they are using gnome terminal.

Now let's assume that there's a new Linux user who is looking on how to install Java or Python, they might find an official step from Oracle or Python websites to do something like this:

tar xvf Python-3.2.8.tgz
cd Python-3.2.8
./configure --prefix=/opt/python
make
sudo make install

Which is perfectly fine for a Linux power user, sometimes, but for a newbie it might cause a lot of troubles especially when they download another package from their package manager that might depend on Python (inb4 the package manager finds some files occupying the python installation location and refuses to proceed). Or they actually might just break their system while trying to resolve some issues in the make install error message. A friend of mine was about to go in this loop while trying to install yt-dlp a while ago, while following a tutorial of how to do that on Linux.

[an important side note here, the importance of asking the question the right way is not about of us, the people who might help, get their job done quicker, but for the users to understand what they are looking for, so they might not even have to ask]

Now there's no really a straightforward way to make newbies learn how to ask the question in the correct way since appending what distribution they are using is not really helpful always: how can I fix the terrible font on Manjaro? because this barely gives enough information, yet it's better than "how I fix it on Linux" because there are many possible variables on that, like the desktop environment, the window manager, the composer, etc.. unlike Ubuntu, you can not deduce all of that at once.

I believe that the easier way to resolve this issue on Linux is that for distribution maintainers to provide a simple way to educate users about not only the layers of their operating system but what is each layer responsible for. This way not only they can learn what to ask about, but how to customize everything as they want. #Programming

On Depression

Wed, 29 Nov 2023 00:00:00 +0000

On Depression

I've been experiencing random impulses of depression lately, perhaps a part of what's diagnosed as mood swings and mood disorders. While I can not decide precisely what's going wrong I'm trying to do my best to overcome it. I'm sharing my experience here.

I know so many literature descriptive anthology pieces about depression, however, I really like al-Ghazali's(al-Ghazali 2002, p.135):

For God put a lock upon my tongue so that I was impeded from public teaching. I struggled with myself to teach for a single day, to gratify the hearts of the students who were frequenting my lectures, but my tongue would not utter a single word: I was completely unable to say anything. As a result that impediment of my speech caused a sadness in my heart accompanied by an inability to digest; food and drink became unpalatable to me so that I could neither swallow broth easily nor digest a mouthful of solid food. That led to such a weakening of my powers that the physicians lost hope of treating me and said: “This is something which has settled in his heart and crept from it into his humors; there is no way to treat it unless his heart be eased of the anxiety which has visited it.”

فكنت أُجاهد نفسي أن أُدرس يومًا واحدًا تطييبًا للقلوب المتخلفة إلي، فكان لا ينطق لساني بكلمة ولا استطيعها البتة، حتى اورثت هذه العقلة في اللسان حزنًا في القلب، بطلت معاه قوة الهضم ومراءة الطعام والشراب: فكان لا ينساغ لي ثريد، ولا تنهضم لي لقمة؛ وتعدى إلى ضعف القوى، حتى قطع الأطباء طمعهم من العلاج وقالوا: هذا أمر نزل بالقلب، ومنه سرى إلى المزاج، فلا سبيل اليه بالعلاج، إلا بأن يتروح السر عن الهم الملم.

There's always something different in 1st millennium depression literature (check out Foucault's "History of Insanity"), perhaps it's the most non-casual (at least not from an intellectual perspective) form of depression ever recorded.

al-Ghazali depicted later what helped him survive this state, which was basically Sufism (Read the Sufism chapter of his book if you are interested in more details. Also check: Why a Sufi approach to healing mental illness is so powerful). I think that this approach might not be very helpful. Not specifically Sufism, but intellectual changes generally ([2025-04-19 Sat 14:00] although many will argue otherwise)

As I mentioned my depression was (is?) swinging, I got the feeling of "I'm alright now, that was it, it's overcame" many times before suffering a next wave.

The latest "solution" I've reached so far is routine, and I know that the recipe I'm going to put now is battle-tested because I've tried it when I was and was not in depression, that is; not just keeping self busy but with a purpose to get to the next level.

What I've been doing for example is setting a list of activities to do. I've a very (very) long bucket list myself, so it is not really about lacking organization but doing something at all. The list should be something doable, easy and not critical, most importantly it should be insulated from anything you would have in a normal to-do-list (i.e. do not add stuff related to you work, study or whatever). I believe it should be crowded as well but not too much. The mere purpose is to keep yourself busy, apparently one of the most naive advice for depression is the one that seems to work. The tasks need to be productive, do not add - play a a video game or whatever. Do things that next morning you will feel good about the fact you have done them.

When I get up feeling depressed and awful, I push myself into the list, simulating to myself that only after finishing this item, this pain is going to vanish, and before I even try harder I'd be occupied in getting the first item of the list done. Once I'm done with it I proceed with the next item on the list, and so on. By end of the day if I'm not feeling better already for all the things I have done, I know for certain that I will feel great the next day and I will have a severe desire to go into the same action list just like the day before.

The trade-off here is: 1. You can develop the routine regardless of your state, if you feel so good today you do it and if you do not you do it. 2. It produces something, so even if it does not help healing, at least you are getting things done (I say productive and depressed is better than unproductive and depressed). #Modus Vivendi

[2024-02-11 Sun 05:38] I think this method still works fine after all these months, perhaps the only thing to focus on more is crisis management.
[2024-04-04 Thu 15:34] Well for the most part now I can confirm that this works, empirically.
[2024-08-05 Mon 23:08] I didn't mention that if you're suffering from some kind of clinical depression (major depressive disorder) you should seek professional help. I thought that was too obvious.
[2025-04-19 Sat 14:02] Something else that I think I should have mentioned here is how different it is to have the willing not to be depressed. This is perhaps the most important step in healing from depression for me, and I really regret every time I was extremely depressed and decided not to help myself because I thought it wouldn't make that much of a difference, but it completely will. God helps those who help themselves. Always help yourself to get out of depression, like they say, be the one you always wished to have helping you. If you think having a cup of tea, a good workout, or a walk might even slightly change your mood, do it. Or even if you don't think it will, but you believe that you might like it, do it. For me, I found out that doing my favorite activities that are mostly about me and taking care of myself, and making sure that I am doing the best for me to have a good time, that was always the best way for me to get out of depression.
[2025-12-22 Mon 22:02] Sports really help. As well as a good diet.
[2026-02-17 Tue 22:22] Out of courtesy, I should write here when I'm feeling generally good (and alive) as I wrote here when I felt terrible. I can not tell what helped me to escape depression, because I absolutely have no clue. But I still believe that what was mentioned here, i.e. keeping the self occupied by state of trying to do good things, would have a great help on anyone. والحمدلله رب العالمين.

References

Abū Ḥāmid al-Ghazali and Jamīl Ṣalībā (ed) and Kamel Ali (2002). Deliverance From Error. Dar al-Andalus.

The limits on the (allowed) freedom of speech

Mon, 30 Oct 2023 00:00:00 +0000

The limits on the (allowed) freedom of speech

People are free to do exactly what they are told. ― Ward Churchill

Freedom of speech has limits, some argue that they must have(Gunatilleke 2020) especially on "dangerous" content that could be described as "harmful and offensive", which is arguable of course. I call those limits the overt limits, the ones that you might get sued of criminal speech in many countries.

However, there are always the undercover limits, those that you are not likely to get sued for practicing them, although you are very likely to get (at the very least) marginalized, defamed and underrepresented. The Nazis used this technique for a while against the Jews in Germany, it was called the Judenboykott and it was years before the Nuremberg Laws (the antisemitic laws that were enacted in Nazi Germany), it was a method for marginalizing and underrepresenting the Jewish people without the usage of any kind of law enforcement(Pauley 1998).

Marginalization and underrepresentation are indispensable tools for an oligarchic democracy, or any state that will find a burden in using law enforcement. It's basically the punishment by the elites to align the view for the public stakeholders (i.e. the people), they should be only exposed to certain views, this way it will prevent them from engaging in any unpleasant actions(Chomsky 1997, p. 24)

As long as people are marginalized and distracted, [they] have no way to organize or articulate their sentiments, or even know that others have these sentiments. People assume that they are the only people with a crazy idea in their heads.

Now this comes on a price: teaching the public the lesson of what happens to those who are disaligned, they get defamed, marginalized and basically undercover oppressed and sometimes proscribed.

As the time of writing this it has been a few weeks since the beginning of the Israel-Gaza 2023 war. Compared to clashes that has been going for the past couple of decades between the Palestinian people and the Israeli forces, that most recent conflict has been discussed in much bigger scale, many Israeli-affiliated systems are doing there hard work to make sure that everyone is having standards of support for Israeli militancy.

The kinds of defamation that I mentioned have been always happening with mostly all of the past clashes¹, Dr. Matthew Abraham's great book "Out of Bounds: Academic Freedom and the Question of Palestine"(Abraham 2014) collects many examples for that violation but in academic publishing boundaries. Due to that exceptional case of the current conflict, we are seeing that violation of freedom in much clearer forms and everywhere in public media.

The purpose of this page page to document news and events that are considered to indicate a violation on the freedom of thought and speech, especially but not exclusively on views related to the Israeli–Palestinian conflict. #Politics

Web Summit CEO Resigns After Condemnation of Israeli War Crimes

Paddy Cosgrave, the chief executive officer of a prominent European tech conference called Web Summit, resigned from his role on Saturday amid backlash for his public statements that suggested Israel was committing war crimes (D’Innocenzio 2023).

Right after the publication of that statement, his organization, Web Summit, suffered from boycotts by Google, Strip and Meta(Monahan 2023), which probably caused his resignation.

Florida Governor Ban of Pro-Palestinian Student Organization

The Florida governor and Republican presidential candidate Ron DeSantis has ordered colleges ban pro-Palestinian groups student organization.

"Based on the National SJP’s support of terrorism, in consultation with Governor DeSantis, the student chapters must be deactivated" Rodrigues wrote in a memo to university leaders, as reported(Hay 2023).

British Ministerial Aide Sacked After Calling for Gaza Ceasefire

A ministerial aide has been sacked from his government role after calling for a ceasefire in Gaza(Morton 2023).

Many CEOs Promoted by Mass Media Are Calling for Blacklist of Harvard Students After Israel Condemnation Statement

In 9 Oct 2023 "large number of Harvard student organizations" made a statement that's clear about the Israeli conflict. I personally agree with their views, what happened in 7 October was a consequence of the Israeli actions for the last couple of decades, killing and oppressing Palestinian whilst running the greatest open air prison in the world (Gaza).

Though this is what many CEOs did not like, and now they are calling on Harvard University to shut them down, asking for a full list of their names (Egan 2023). As of the end of October 2023, media has reported that millions of 'funds' for top U.S. universities are gone due to disaligned views of student about the Israeli–Palestinian Conflict. (Jack 2023).

In 17 October 2023; many "top law firm" rescinds their job offers to many of these top universities (Tenbarge 2023) due to the same reasons. All of these are means for lobbying the universities to either suspend the students or shut them up somehow (to make sure that only aligned views are exposed). The suspension of these students or rescinding them from jobs as top companies are doing both serve as an example of the process of alignment mentioned on the top of the article.

Norman Finkelstein Tenure Rejection and Resignation After Debunking Pro-Israeli Book

After the Dershowitz–Finkelstein affair, Alan Dershowitz started campaigned to block Norman Finkelstein tenure bid at DePaul University. His campaign began in 2004 when he sent DePaul president Dennis Holtschneider a manuscript, "Literary McCarthyism," arguing that the university should fire Finkelstein. He also contacted DePaul political science department chair Patrick Callahan.

In 2005, Dershowitz announced his intent to block Finkelstein's tenure bid, saying, "I will come at my own expense, and I will document the case against Finkelstein" and "I'll demonstrate that he doesn't meet the academic standards of the Association of American Universities\" (Abraham 2014, p.85), sounds like Dershowitz view of being associated with American Universities implies an ultimate support of Israel²

In October 2006, he sent members of DePaul's law and political science faculties what he called "a dossier of Norman Finkelstein's most egregious academic sins, and especially his outright lies, misquotations, and distortions" and lobbied DePaul's professors, alumni and administrators to deny Finkelstein tenure (Howard 2007).

In May 2007, Dershowitz spoke at Northwestern University and claimed that Finkelstein had recently attended a Holocaust denial conference in Iran (Abraham 2014, p. 86).

DePaul's political science committee investigated Dershowitz's accusations against Finkelstein and concluded that they were unsubstantiated. The department subsequently invited John Mearsheimer and Ian Lustick, two previously uninvolved academics with expertise on the Israel–Palestinian conflict, to evaluate the academic merit of Finkelstein's work; they came to the same conclusion (Forer 2010).

In early 2007, DePaul's political science department voted nine to three, and the College of Liberal Arts and Sciences Personnel Committee five to zero, to give Finkelstein tenure. The three opposing faculty members subsequently filed a minority report opposing tenure, supported by the Dean of the College, Chuck Suchar.

CEO of eLife Fired After Retweeting "The Onion" Parody Post About Israel/Palestine

"I have been informed that I am being replaced as the Editor in Chief of @eLife for retweeting a @TheOnion piece that calls out indifference to the lives of Palestinian civilians." as reported on his twitter account (Eisen ).

Ironically, the post that he retweeted The Onion was very expressive! it says: "‘The Onion’ Stands With Israel Because It Seems Like You Get In Less Trouble For That"

In fact, the article does a great job in depicting the situation:

In moments of turmoil such as this, some believe it is the responsibility of a newspaper of record like The Onion to delve fully into the nuances of a complex and multifaceted conflict that stretches back not just decades but centuries. These people are wrong.

Instead, this editorial board wishes to take this opportunity to declare its full and unequivocal support for Israel because, frankly, it seems like you get in way less trouble for that.

Artforum Fires Chief Editor Because of His Position From Palestine

David Velasco was removed after the magazine’s publishers said there was a flawed editorial process behind the publication of a letter that supported Palestinian liberation (Small 2023).

MP Andy McDonald Suspends After Speech at Pro-Palestinian Rally

Andy McDonald has been suspended as a Labour MP, after the party said he had made "deeply offensive" comments relating to the Israel-Gaza war, as reported in the BBC(Stuff 2023).

Columbia University Suspends Jewish Voice for Peace and Justice in Palestine

Columbia University is suspending Students for Justice in Palestine (SJP) and Jewish Voice for Peace (JVP) as they "repeatedly violated University policies related to holding campus events, culminating in an unauthorized event"(Editorial 2023).

Footnotes

Of course the ones that the Israeli side were obviously to be blamed for, like Cave of the Patriarchs massacre, would just be kept silent about.

As of the time of writing this he has being confirming that, calling for a condemnation of Harvard students who stands against the Israeli actions.

References

Gehan Gunatilleke (2020). Justifying Limitations on the Freedom of Expression. Springer Science and Business Media {LLC. Link
Bruce F. Pauley (1998). From Prejudice to Persecution: A History of Austrian Anti-Semitism. University of North Carolina Press.
Noam Chomsky (1997). Media Control: The Spectacular Achievements of Propaganda. Seven Stories Press. Link
Abraham, Matthew (2014). Out of Bounds: Academic Freedom and the Question of Palestine. Bloomsbury Publishing.
D’Innocenzio, Anne (2023). CEO of a prominent tech conference resigns amid backlash for public statements over Israel-Hamas war. Associated Press. Link
Monahan, Tabitha and Weckler, Adrian (2023). Meta, Google and Stripe to boycott Web Summit on back of Paddy Cosgrave’s Israel comments. Irish Independent. Link
Hay, Andrew (2023). Florida’s DeSantis bans pro-Palestinian student group. Reuters. Link
Morton, Becky (2023). Paul Bristow: Ministerial aide sacked after call for Israel-Gaza ceasefire. The British Broadcasting Corporation (BBC). Link
Egan, Matt (2023). CEOs call on Harvard to name students linked to statement blaming Israel for Hamas attack. CNN Bussiness. Link
Jack, Andrew (2023). US universities lose millions as donors pull funding over Hamas stance. Financial Times. Link
Tenbarge, Kat (2023). Top law firm rescinds job offers to Ivy League students over Israel letters. NBC News. Link
Howard, Jennifer (2007). Harvard Law Professor Works to Disrupt Tenure Bid of Longtime Nemesis at DePaul U.. The Chronicle of Higher Education. Link
Forer, Richard (2010). Breakthrough: Transforming Fear Into Compassion: a New Perspective on the Israel-Palestine Conflict.
Eisen, Michael (). .
Small, Zachary (2023). Artforum Fires Top Editor After Its Open Letter on Israel-Hamas War. The New York Times. Link
BBC Stuff (2023). Andy McDonald: Labour suspends MP after speech at pro-Palestinian rally . The British Broadcasting Corporation (BBC). Link
{Columbia News Editorial (2023). Statement From Gerald Rosberg, Chair of the Special Committee on Campus Safety. Columbia University in the City of New York. Link

Aids, Sanctions and United States' Nations

Sat, 07 Oct 2023 00:00:00 +0000

Aids, Sanctions and United States' Nations

How does the US manipulate global policy using sanctions and political aids as a carrot and stick strategy.

For anyone who understands the basics of the policies of interests, any kind of political aid is always interpreted as matter of interest or to be used as a pressure method in the future, U.S. foreign assistance to Egypt is a great example for that, not only it makes Egypt more dependent on US-Arms systems which implies more surveillance (only God knows what backdoor might be in those) and need for US services (due to maintenance and training) which will be a great future investment for the US arms industry (one of the greatest ever), but it also can be used as an efficient pressure point especially on the so-called underdeveloped states, i.e. poor countries that probably need these aids the most, which are also the only states qualified for receiving them. In fact we have seen this already happening for Egypt more than once, most recent in 2022, US withheld $130 million of that military aid (Pamuk 2022).

Reading (Gordon 2010), Joy Gordon tells about what Noam Chomsky described once as "pulverization" of 3rd world/undefendable countries that might step on the US toes:

These lessons [of war] are directed to several audiences. For the Third World, the message is simple: Don’t raise your heads. A “much weaker” opponent will not merely be defeated, but pulverized.

Indeed the US could make whatever the change they wanted on Iran by running a coup d'etat, something that they have practiced very well for decades (see (Blum 2003), a fantastic literature on the subject), but this would not achieve the pulverization of Iraq.

Gordon discusses the brutal methods that the US applied using sanctions to cause a humanitarian crisis in Iraq. The war casualties are known to most of you, the 500,000 "worth it" children and death of millions, however, Gordon encourages us to look upon the "invisible war" effect, for example it's known that the alliance targeted many schools, hospitals and other civilian targets (on which the international community would comment "nothing serious", of course it's impossible to get the US into an international court for a war crime, Nicaragua has done its best on that already) however the sanctions resulted in 30% of Iraqi health institutions becoming dysfunctional by 1998, 70% of the population suffered from anemia and other treatable diseases, the annual death toll of Iraq increased by hundreds of thousands due to sanctions on drug imports and lack of electricity to operate medical equipment (Gordon 2010).

However, something else got me very interested on Gordon's book: the process of issuing the security council resolution 661, which was indeed a very critical decision for a country like Iraq that is known to import most of its needs (70% by that time).

There, the US used sanction and aids as tools to get that resolution passed, as Gordon states, all the developing countries that voted for the resolution got many privileges; Egypt, Turkey, China and Jordon got to take their stumbled loans from the World Bank, and aids were sent to other countries like Colombia, Ethiopia and Zaire. Of course alliances had more interested in Iraq itself.

Yemen was one of the countries that voted against that resolution. As I mentioned above, countries that voted for it got so many privileges, which tells us a little about "how much is a seat on the Security Council worth" (Kuziemko 2006)? Ilyana Kuziemko and Eric Werker from Harvard answer in their analysis¹:

We find that a country’s U.S. aid increases by 59 percent and its U.N. aid by 8 percent when it rotates onto the council. This effect increases during years in which key diplomatic events take place (when members’ votes should be especially valuable), and the timing of the effect closely tracks a country’s election to, and exit from, the council. Finally, the U.N. results appear to be driven by UNICEF, an organization over which the United States has historically exerted great control.

Here the reader can expect what happened to Yemen; "That will be the most expensive ‘no’ vote you ever cast" a U.S. diplomat told the Yemeni ambassador before dropping Yemen's aid, a very poor country suffering from unending wars, from $70 million to $0.

Sasha Alyson has a fantastic article (Alyson 2021) investigating further more on UN-related actions, including U.N. membership and UNESCO. #Politics

Footnotes

I really encourage readers to have a look at that paper for further study, it's available for open view on https://www.hbs.edu/faculty/Pages/item.aspx?num=22724

References

Humeyra Pamuk and Simon Lewis (2022). U.S. to withhold $130 mln of military aid to Egypt over human rights -official. Reuters. Link
Joy Gordon (2010). Invisible War: The United States and the Iraq Sanctions. Harvard University Press.
William Blum (2003). Killing Hope: US Military and CIA Interventions Since World War II Part 1. Zed Books Ltd. Link
Kuziemko, Ilyana and Werker, Eric (2006). How much is a seat on the Security Council worth? Foreign aid and bribery at the United Nations. The University of Chicago Press.
Alyson, Sasha (2021). Monetizing the United Nations. Karma Colonialism. Link

Lisp Programming Language

Thu, 16 Feb 2023 00:00:00 +0000

Lisp Programming Language

[2026-03-18 Wed 09:10] From a personal note. content might is not original and might contain mistakes

The Lisp programming language s a family of programming languages with a long history and a distinctive, fully parenthesized prefix notation. Originally specified in 1958, Lisp is the second-oldest high-level programming language still in common use. Only Fortran is older, by one year. Lisp has changed since its early days, and many dialects have existed over its history. Today, the best-known general-purpose Lisp dialects are Common Lisp, Scheme, Racket and Clojure. programming.

Choosing Implementation

The first thing you have to do is to choose a Lisp implementation. This may seem like a strange thing to have to do for folks used to languages such as Perl, Python, Visual Basic (VB), C#, and Java. The difference between Common Lisp and these languages is that Common Lisp is defined by its standard—there is neither a single implementation controlled by a benevolent dictator, as with Perl and Python, nor a canonical implementation controlled by a single company, as with VB, C#, and Java. Anyone who wants to read the standard and implement the language is free to do so. Furthermore, changes to the standard have to be made in accordance with a process controlled by the standards body American National Standards Institute (ANSI). That process is designed to keep any one entity, such as a single vendor, from being able to arbitrarily change the standard. Thus, the Common Lisp standard is a contract between any Common Lisp vendor and Common Lisp programmers. The contract tells you that if you write a program that uses the features of the language the way they’re described in the standard, you can count on your program behaving the same in any conforming implementation.

Hello World

You can just pass "Hello World" (with quotes) to the Lisp REPEL and you will get your first Hello World in Lisp.

This works because strings, like numbers, have a literal syntax that’s understood by the Lisp reader and are self-evaluating objects: Lisp reads the double-quoted string and instantiates a string object in memory that, when evaluated, evaluates to itself and is then printed in the same literal syntax. The quotation marks aren’t part of the string object in memory—they’re just the syntax that tells the reader to read a string. The printer puts them back on when it prints the string because it tries to print objects in the same syntax the reader understands.

However, this may not really qualify as a “hello, world” program. It’s more like the “hello, world” value.

You can take a step toward a real program by writing some code that as a side effect prints the string “hello, world” to standard output. Common Lisp provides a couple ways to emit output, but the most flexible is the FORMAT function. FORMAT takes a variable number of arguments, but the only two required arguments are the place to send the output and a string. You’ll see in the next chapter how the string can contain embedded directives that allow you to interpolate subsequent arguments into the string, à la printf or Python’s string-%. As long as the string doesn’t contain an \~, it will be emitted as-is. If you pass t as its first argument, it sends its output to standard output. So a FORMAT expression that will print “hello, world” looks like this:

CL-USER> (format t "hello, world")
hello, world
NIL

However, it’s still arguable whether you’ve yet written a true “program.” But you’re getting there. And you’re seeing the bottom-up style of programming supported by the REPL: you can experiment with different approaches and build a solution from parts you’ve already tested. Now that you have a simple expression that does what you want, you just need to package it in a function. Functions are one of the basic program building blocks in Lisp and can be defined with a DEFUN expression such as this:

CL-USER> (defun hello-world () (format t "hello, world"))
HELLO-WORLD

At one level, this expression, like all the others you’ve seen, is just another expression to be read, evaluated, and printed by the REPL. The return value in this case is the name of the function you just defined and we will discuss later why was it uppercased.

Why Lisp?

Why learn Lisp? Because it lets you do things that you can't do in other languages. If you just wanted to write a function to return the sum of the numbers less than n> say, it would look much the same in Lisp and C:

(defun sum (n)
 (let ((s 0))
 (dotimes (i n s)
 (incf s i))))

int aum(int n){
 int i , s = 0;
 for ( i = 0; i < n; i++)
 s += i ;
 return(s);
}

If you only need to do such simple things, it doesn't really matter which language you use. Suppose instead you want to write a function that takes a number n, and returns a function that adds n to its argument:

(defun addn (n)
 #'(lambda (x)
 (+ x n)))

What does addn look like in C? You just can't write it. You might be wondering, when does one ever want to do things like this? Programming languages teach you not to want what they cannot provide. You have to think in a language to write programs in it, and it's hard to want something you can't describe. When I first started writing programs—in Basic—I didn't miss recursion, because I didn't know there was such a thing. I thought in Basic. I could only conceive of iterative algorithms, so why should I miss recursion?

Lisp is designed to be extensible: it lets you define new operators yourself. This is possible because the Lisp language is made out of the same functions and macros as your own programs. So it's no more difficult to extend Lisp than to write a program in it. In fact, it's so easy (and so useful) that extending the language is standard practice. As you're writing your program down toward the language, you build the language up toward your program. You work bottom-up, as well as top-down.

As programming environments grow in power, and languages become more abstract, the Lisp style of programming is gradually replacing the old plan-and-implement model.

In the old model, bugs are never supposed to happen. Thorough specifications, painstakingly worked out in advance, are supposed to ensure that programs work perfectly. Sounds good in theory. Unfortunately, the specifications are both written and implemented by humans. The result, in practice, is that the plan-and-implement method does not work very well.

Planning is a necessary evil. It is a response to risk: the more dangerous an undertaking, the more important it is to plan ahead. Powerful tools decrease risk, and so decrease the need for planning. The design of your program can then benefit from what is probably the most useful source of information available: the experience of implementing it.

Lisp style has been evolving in this direction since the 1960s. You can write prototypes so quickly in Lisp that you can go through several iterations of design and implementation before you would, in the old model, have even finished writing out the specifications. You don't have to worry so much about design flaws, because you discover them a lot sooner. Nor do you have to worry so much about bugs. When you program in a functional style, bugs can only have a local effect. When you use a very abstract language, some bugs (e.g. dangling pointers) are no longer possible, and what remain are easy to find, because your programs are so much shorter. And when you have an interactive environment, you can correct bugs instantly, instead of enduring a long cycle of editing, compiling, and testing.

Lisp Specifications

"Okay I'm convinced"

Evaluation

In Lisp, + is a function, and an expression like (+ 2 3) is a function call. When Lisp evaluates a function call, it does so in two steps:

First the arguments are evaluated, from left to right. In this case, each argument evaluates to itself, so the values of the arguments are 2 and 3, respectively.
The values of the arguments are passed to the function named by the operator. In this case, it is the + function, which returns 5.

Not all the operators in Common Lisp are functions, but most are. And function calls are always evaluated this way. The arguments are evaluated left-to-right, and their values are passed to the function, which returns the value of the expression as a whole. This is called the evaluation rule for Common Lisp.

One operator that doesn't follow the Common Lisp evaluation rule is quote. The quote operator is a special operator, meaning that it has a distinct evaluation rule of its own. And the rule is: do nothing. The quote operator takes a single argument, and just returns it verbatim:

(quote (+ 4 5))

(+ 4 5)

For convenience, Common Lisp defines ' as an abbreviation for quote. You can get the effect of calling quote by affixing a ' to the front of any expression:

`(+ 4 5)

(+ 4 5)

It is much more common to use the abbreviation than to write out the whole quote expression.

Lisp provides the quote as a way of protecting expressions from evaluation. The next section will explain how such protection can be useful.

Symbols do not (usually) evaluate to themselves, so if you want to refer to a symbol, you should quote it, as above.

Lists are represented as zero or more elements enclosed in parentheses. The elements can be of any type, including lists. You have to quote lists, or Lisp would take them for function calls:

Data

Lisp offers all the data types we find in most other languages, along with several others that we don't. One data type we have used already is the integer, which is written as a series of digits: 256. Another data type Lisp has in common with most other languages is the string, which is represented as a series of characters surrounded by double-quotes: "ora et labora". Integers and strings both evaluate to themselves.

Lists are represented as zero or more elements enclosed in parentheses. The elements can be of any type, including lists. You have to quote lists, or Lisp would take them for function calls:

`(pray sunrise)

(PRAY SUNRISE)

Notice that one quote protects a whole expression, including expressions within it. You can build lists by calling list. Since list is a function, its arguments are evaluated. Here we see a call to + within a call to list:

(list `my `(+ 2 3))

(MY (+ 2 3))

We are now in a position to appreciate one of the most remarkable features of Lisp. Lisp programs are expressed as lists. If the arguments of flexibility and elegance did not convince you that Lisp notation is a valuable tool, this point should. It means that Lisp programs can generate Lisp code. Lisp programmers can (and often do) write programs to write their programs for them.

List Operations

The function cons builds lists. If its second argument is a list, it returns a new list with the first argument added to the front:

(cons ' a ' (b c d))

(A B C D)

We can build up lists by consing new elements onto an empty list. The list function that we saw in the previous section is just a more convenient way of consing several things onto nil.

The primitive functions for extracting the elements of lists are car and cdr. The car of a list is the first element, and the cdr is everything after the first element:

(car `(ab c))

AB

(cdr `(ab c))

(C)

The parentheses in the cdr are for that it is probably a list, since it is everything but the first element, but in car it is only a one element that's why there is not parentheses.

You can use combinations of car and cdr to reach any element of a list. If you want to get the third element, you could say:

(car (cdr (cdr ' ( a b c d ) ) ) )

However, you can do the same thing more easily by calling third :

( second '( a b c d))

There are also first and second, you can guess what is their functionality.

Truth

In Common Lisp, the symbol t is the default representation for truth. Like nil, t evaluates to itself. The function listp returns true if its argument is a list:

(listp `(a b c))

A function whose return value is intended to be interpreted as truth or falsity is called a predicate. Common Lisp predicates often have names that end with p.

The simplest conditional in Common Lisp is if. It usually takes three arguments: a test expression, a then expression, and an else expression. The test expression is evaluated. If it returns true, the then expression is evaluated and its value is returned. If the test expression returns false, the else expression is evaluated and its value is returned:

(if (listp '(abc))
 (+ 1 2)
 (+ 5 6))

Like quote, if is a special operator. It could not possibly be implemented as a function, because the arguments in a function call are always evaluated, and the whole point of if is that only one of the last two arguments is evaluated. The last argument to if is optional. If you omit it, it defaults to nil.

There are and and or functions, you probably can tell what do they do.

Basic Functions

You can define new functions with defun. It usually takes three or more arguments: a name, a list of parameters, and one or more expressions that will make up the body of the function. Here is how we might define third:

(defun our-third (x)
 (car (cdr (cdr x ))))

OUR-THIRD

Let's try to defun member which tells you if whether an element is a member of function:

(defun somemeeber (obj lst)
 (if (null lst) nil
 (if (eql (car lst) obj) t
 (somemeeber obj (cdr lst)))))

The difference between this implementation (along many other things in the internal implementation) is that instead of evaluating the rest of the list the that member does it, I evaluate the truth value t.

(somemeeber 3 '(1 2 3 4))

I/O

The most general output function in Common Lisp is f ormat. It takes two or more arguments: the first indicates where the output is to be printed, the second is a string template, and the remaining arguments are usually objects whose printed representations are to be inserted into the template. Here is a typical example:

(format t "~A plus ~A equals ~A. ~%" 2 3 ( + 2 3))

2 plus 3 equals 5.
NIL

Notice that two things get displayed here. The first line is displayed by format. The second line is the value returned by the call to format, displayed in the usual way by the toplevel. Ordinarily a function like format is not called directly from the toplevel, but used within programs, so the return value is never seen.

The first argument to format, t, indicates that the output is to be sent to the default place. Ordinarily this will be the toplevel. The second argument is a string that serves as a template for output. Within this string, each ~A indicates a position to be filled, and the ~% indicates a newline. The positions are filled by the values of the remaining arguments, in order.

The standard function for input is read. When given no arguments, it reads from the default place, which will usually be the toplevel. Here is a function that prompts the user for input, and returns whatever is entered:

(defun askem (string)
 (format t ""A" string)
 (read))

Variables

One of the most frequently used operators in Common Lisp is let , which allows you to introduce new local variables.

A let expression has two parts. First comes a list of instructions for creating variables, each of the form (variable expression). Each variable will initially be set to the value of the corresponding expression.

(defun ask-for-number ()
 (format t "Enter a number")
 (let ((n (read)))
 (if (numberp n)
 n
 (ask-for-number))))

You can create a global variable by giving a symbol and a value to defparameter:

Such a variable will then be accessible everywhere, except in expressions that create a new local variable with the same name. To avoid the possibility of this happening by accident, it's conventional to give global variables names that begin and end with asterisks. The name of the variable we just created would be pronounced "star-glob-star".

You can also define global constants, by calling def constant:

(defconstant limit (+ *glob* 1))

There is no'need to give constants distinctive names, because it will cause an error if anyone uses the same name for a variable. If you want to check whether some symbol is the name of a global variable or constant, use boundp:

(defconstant *glob* 43)
(boundp '*glob*)

Assignment

In Common Lisp the most general assignment operator is setf. We can use it to do assignments to either kind of variable:

(setf *glob* 90)

(defun read-number-and-prefix-with-message ()
 (let ((n (ask-for-number)))
 (setf n (+ n 1))
 (format t "The new number is ~A" n)))

Enter a number4
The new number is 5

Iteration

When we want to do something repeatedly, it is sometimes more natural to use iteration than recursion. A typical case for iteration is to generate some sort of table. This function

(defun show-squares (start end)
 (do ((i start (+ i 1)))
 ((> i end) 'done)
 (format t "~A ~A~%" i (* i i))))
(show-squares 2 4)

2 4
3 9
4 16
DONE

The do macro is the fundamental iteration operator in Common Lisp. Like let , do can create variables, and the first argument is a list of variable specifications. Each element of this list can be of the form

{variable initial update)

where variable is a symbol, and initial and update are expressions. Initially each variable will be set to the value of the corresponding initial, on each iteration it will be set to the value of the corresponding update. The do in show-squares creates just one variable, i . On the first iteration i will be set to the value of start , and on successive iterations its value will be incremented by one.

The remaining arguments to do comprise the body of the loop. They will be evaluated, in order, on each iteration. On each iteration the variables are updated, then the termination test is evaluated, and then (if the test failed) the body is evaluated.

(defun show-squares (i end)
 (if (> i end)
 'done
 (progn
 (format t M~A ~A~°/,n i (* i i ) )
 (show-squares (+ i 1) e n d))))

Common Lisp has simpler iteration operators for special cases. To iterate through the elements of a list, for example, you would be more likely to use dolist . Observe the following functions:

(defun our-length-without-do (lst)
 (if (null lst)
 0
 (+ (our-length-without-do (cdr lst)) 1)))

Functions as Objects

In Lisp, functions are regular objects, like symbols or strings or lists. If we give the name of a function to function, it will return the associated object. Like quote, function is a special operator, so we don't have to quote the argument:

(function +)

#<FUNCTION +>

You can replace the + with any other operator or function like read.

This strange-looking return value is the way a function might be displayed in a typical Common Lisp implementation.

Until now we have only dealt with objects that look the same when Lisp displays them as when we typed them in. This convention does not apply to functions. Internally, a built-in function like + is likely to be a segment of machine language code. A Common Lisp implementation may choose whatever external representation it likes.

Just as we can use ' as an abbreviation for quote, we can use #' as an abbreviation for function:

(apply #'+ l) == (apply (function +) l)

#' (aka function) can be used in front of (lambda …) (we will talk about lambda soon) but it's redundant there, so the only place where it's really meaningful is in front of a symbol, as in #'car. In ELisp, #'car and 'car are almost completely equivalent, so one of the main purpose is simply to document the intention (i.e. to indicate to whoever reads this code that you intend to use this symbol as a function). Yet there are a few circumstances, where the difference is more significant:

The byte-compiler takes advantage of this documented intention and when you write #'car it will check whether car exists as a function, and if it doesn't find it, it will emit a warning, just like it would if you had a call to that function.
Inside cl-flet and cl-labels, only #'f can refer to the locally defined function f, because 'f will still refer to the global symbol f (and whichever function might be stored in its symbol-function slot). E.g.
```
(cl-flet ((car (x y) (+ x y)))
(list #'car 'car))
=>
((closure nil (x y) (+ x y)) car)
```
(read: Get in the habit of using sharp quote)

Like any other kind of object, we can pass functions as arguments. One function that takes a function as an argument is apply. It takes a function and a list of arguments for it, and returns the result of applying the function to the arguments:

(apply #'+ ' ( 1 2 3))

The function f u n c a l l does the same thing but does not need the arguments to be packaged in a list:

(funcall #'+ 1 2 3)

The defun macro creates a function and gives it a name. But functions don't have to have names, and we don't need def un to define them. Like most other kinds of Lisp objects, we can refer to functions literally.

To refer literally to an integer, we use a series of digits; to refer literally to a function, we use what's called a lambda expression. A lambda expression is a list containing the symbol lambda, followed by a list of parameters, followed by a body of zero or more expressions.

Here is a lambda expression representing a function that takes two numbers and returns their sum:

(lambda (x y)
 (+ x y))

A lambda expression can be considered as the name of a function. Like an ordinary function name, a lambda expression can be the first element of a function call, for example:

((lambda (x) (+ x 100)) 2)

Types

Lisp has an unusually flexible approach to types. In many languages, variables are what have types, and you can't use a variable without specifying its type. In Common Lisp, values have types, not variables. You could imagine that every object had a label attached to it, identifying its type. This approach is called manifest typing. You don't have to declare the types of variables, because any variable can hold objects of any type.

(read more about manifest typing)

We will study types in details later.

Lists

In Lisp, lists are one of the fundamental data structures in Lisp. In the earliest dialects they were the only data structure: the name "Lisp" originally stood for "LISt Processor." But Lisp has long since outgrown this acronym. Common Lisp is a general-purpose programming language with a wide variety of data structures.

Conses

We previously introduced cons, car, and cdr, the primitive list manipulation functions, what cons really does is combine two objects into a two-part objects into a two-part object called cons. Conceptually, a cons is a pair of pointers; the first one is the car and the second is the cdr.

Conses provide a convenient representation for pairs of any type. The two halves of a cons can point to any kind of object, including conses. It is by taking advantage of the latter possibility that we use conses to build lists. One does not tend to think of lists as pairs, but they can be defined that way. Any nonempty list can be considered as a pair of the first element and the rest of the list.

Lisp lists are the embodiment of this idea. We use one half of the cons to point to the first element of the list, and the other to point to the rest of the list (which is either another cons or nil). The convention in Lisp has always been to use the car for the first element and the cdr for the rest of the list. So now car is synonymous with the first element of a list, and cdr with the rest. Lists are not a distinct kind of object, but conses linked together in this way.

The last two lists we made both have three elements; it just happens that the second element of z is also a list. Such a list is called a nested list, while a list like y that doesn't contain other lists as elements is called a flat list.

The function consp returns true if its argument is a cons. So l i s t p could be defined:

(defun our-listp (x)
 (or (null x) (consp x)))

Since everything that is not a cons is an atom, the predicate atom could be defined:

(defun our-atom (x) (not (consp x )))

Equality

Each time you call cons, Lisp allocates a new piece of memory with room for two pointers. So if we call cons twice with the same arguments, we get back two values that look the same, but are in fact distinct objects:

(eql (cons 'a nil) (cons 'a nil) )

NIL

equal, essentially, returns true if its arguments would print the same:

(equal (cons 'a nil) (cons 'a nil) )

Pointers

One of the secrets to understanding Lisp is to realize that variables have values in the same way that lists have elements. As conses have pointers to their elements, variables have pointers to their values.

You may have used other languages in which pointers were manipulated explicitly. In Lisp you never have to do this, because the language handles pointers for you. We've already seen how this happens with lists. Something

similar happens with variables. Suppose, for example, we set two variables to the same list:

(setf y (list 'a 'b 'c))
(setf x '( a b c))

(A B C)

What actually happens when we set y to the value of x? The location in memory associated with the variable x does not contain the list itself, but a pointer to it. When we assign the same value to y, Lisp copies the pointer, not the list. So whenever you assign one variable the value of another, the two variables will have e q l values:

(setf y (list 'a 'b 'c))
(setf x '( a b c))
(setf y x)
(eql x y)

Example: Compression

As an example, this section shows how to perform a simple form of compression on lists. This algorithm goes by the impressive name of run-length, it should work as follows:

(comprs '(a a a c))

((3 A) C)

(defun comprs (x)
 (ucompr (car x) 1 (cdr x)))


(defun ucompr (elmnt n lst)
 (if (null lst)
 (list (build elmnt n))
 (let ((next (car lst)))
 (if (eql next elmnt)
 (ucompr elmnt (+ n 1) (cdr lst))
 (cons (build elmnt n) (ucompr next 1 (cdr lst)))))))

(defun build (elmnt n)
 (if (> n 1)
 (list n elmnt)
 elmnt))

Can you write one to do uncompress?

(defun unbuild (n elmt)
 (if (zerop n)
 nil
 (cons elmt (unbuild (- n 1) elmt))))

(defun uncompress (lst)
 (if (null lst)
 nil
 (if (listp (car lst))
 (let ((f (car (car lst)))
 (s (cdr (car lst))))
 (cons (unbuild f s)
 (uncompress (cdr lst))))
 (uncompress (cdr lst)))))

This will work, however, as you will see we are going to get some different kind of lists, lists of lists;

(uncompress (list '(3 A) '(3 B) '(2 C)))

(((A) (A) (A)) ((B) (B) (B)) ((C) (C)))

Access

Common Lisp has additional access functions defined in terms of car and cdr. To find the element at a given position in a list we call nth,

(nth 0 ' ( a b c))

and to find the nth cdr, we call nthcdr:

(nthcdr 2 ' ( a b c))

(C)

Both nth and nthcdr are zero-indexed; that is, the elements are numbered starting at zero rather than one. In Common Lisp, whenever you use a number to refer to an element of a data structure, the numbering starts at zero. The two functions do almost the same thing; nth is equivalent to car of nthcdr.

Mapping functions

Common Lisp provides several functions for calling functions on the elements of a list. The most frequently used is mapcar, which takes a function and one or more lists, and returns the result of applying the function to elements taken from each list, until some list runs out:

(mapcar #'(lambda (x) (+ x 10))
 '(1 2 3))

(11 12 13)

The related maplist takes the same arguments, but calls the function on successive cdrs of the lists:

(maplist #'(lambda (x) x)
 '(a b c))

((A B C) (B C) (C))

Trees

Conses can also be considered as binary trees, with the car representing the right subtree and the cdr the left. For example, the list

(a (b c) d)

is also the tree represented in the following figure:

Binary trees without interior nodes are not useful for much. Common Lisp includes functions for operating on trees not because one needs trees as such, but because one needs a way to do something to a list and all the lists within it. For example, suppose we have a list like

(and (integerp x) (zerop (mod x 2)))

and we want to substitute y for x throughout. It won't do to call substitute, which replaces elements in a sequence:

(substitute 'y 'x '(and (integerp x) (zerop (mod x 2))))

(AND (INTEGERP X) (ZEROP (MOD X 2)))

As you can see, this call is ineffective because substitute looks for sequential elements, like this:

(substitute 'y 'x '(x (integerp x) (zerop (mod x 2))))

(Y (INTEGERP X) (ZEROP (MOD X 2)))

However, there is a good replacement which is subset, which can access subtrees:

(subst 'y 'x '(and (integerp x) (zerop (mod x 2))))

(AND (INTEGERP Y) (ZEROP (MOD Y 2)))

Sequences

Another way to think of a list is as a series of objects in a particular order. In Common Lisp, sequences include both lists and vectors.

To copy part of a sequence, we use subseq. The second argument (required) is the position of the first element to be included, and the third argument (optional) is the position of the first element not to be included.

The function reverse returns a sequence with the same elements as its argument, but in the reverse order:

(reverse '(a b c))

(C B A)

Common Lisp has a built-in sort function called sort. It takes a sequence and a comparison function of two arguments, and returns a sequence with the same elements, sorted according to the function:

(sort '( 0 2 1 3 8 ) #'>)

(8 3 2 1 0)

You have to be careful when using sort , because it's destructive. For efficiency reasons, sort is allowed to modify the sequence given to it as an argument. So if you don't want your original sequence modified, pass a copy.

Dotted Pair Notation

Dotted pair notation is a general syntax for cons cells that represents the CAR and CDR explicitly. In this syntax, (a . b) stands for a cons cell whose CAR is the object a and whose CDR is the object b. Dotted pair notation is more general than list syntax because the CDR does not have to be a list. However, it is more cumbersome in cases where list syntax would work. In dotted pair notation, the list (1 2 3) is written as (1 . (2 . (3 . nil))). For nil-terminated lists, you can use either notation, but list notation is usually clearer and more convenient. When printing a list, the dotted pair notation is only used if the CDR of a cons cell is not a list.

KILL Example: Shortest Path @write

Following code contains a program for finding the shortest path through a network. The function shortest-path takes a start node, a destination node, and a network, and returns the shortest path, if there is one.

In this example, nodes are represented as symbols, and networks are represented as assoc-lists with elements of the form

(node . neighbors)

For example:

(setf min '((a b c) (b c) (c d)))

We can visualize it like this:

Garbage

Lists can be slow for several reasons. They offer sequential instead of random access, so retrieving a given element takes longer in a list than an array, for the same reason that it takes longer to find something on a tape than on a disk. Internally, conses tend to be represented as pointers, so traversing a list means traversing a series of pointers, instead of simply incrementing an index, as in an array. But these two costs can be small compared to the cost of allocating and recycling cons cells.

Automatic memory management is one of Lisp's most valuable features. The Lisp system maintains a segment of memory called the heap. The system keeps track of unused memory in the heap and doles it out as new objects are created. The function cons, for example, returns a newly allocated cons.

Allocating memory from the heap is sometimes generically known as consing. If such memory were never freed, Lisp would run out of space for new objects and have to shut down. So the system must periodically search through the heap, looking for memory that is no longer needed. Memory that is no longer needed is called garbage, and the scavenging operation is called garbage collection, or GC.

> (setf 1st (list 'a >b }c))
(A B C)
> (setf 1st nil)
NIL

Since we have no way of reaching this list, it might as well not exist. Objects that we no longer have any way of reaching are garbage. The system can safely reuse these three cons cells.

This way of managing memory is a great convenience to the programmer. You never have to allocate or deallocate memory explicitly. And this means that you never have to deal with the bugs that come from doing so. Memory

leaks and dangling pointers are simply impossible in Lisp.

Data Structure

The preceding discussed the list, Lisp's most versatile data structure. This chapter shows how to use Lisp's other data structures: arrays (including vectors and strings), structures, and hash tables. They may not be as flexible as lists, but they can make access faster, and take up less space.

Arrays

In Common Lisp, you can make an array by calling make-array with a list of dimensions as the first argument. To make a 2x3 array we would say:

(make-array '(2 3))

#2A((0 0 0) (0 0 0))

The n before the A tells how many dimensions the array have. You can also pass a tag initial-element to set its value:

(make-array '(2 3) :initial-element 2)

#2A((2 2 2) (2 2 2))

We can access both vectors and arrays using aref:

(aref (make-array '(2 3) :initial-element 2) 0 0)

However, in the cause of vectors there is a fastere function which is svref

(svref (vector 'a 'b 'c) 2)

KILL Structures @write

Functions

Understanding functions is one of the keys to understanding Lisp. Conceptually, functions are at the core of Lisp. Practically, they are one of the most useful tools at your disposal

The predicate f boundp tells whether there is a function with a given symbol as its name. If a symbol is the name of a function, symbol-function will return it:

(fboundp '+)

#<FUNCTION +>

By setting the symbol-function of some name to a function,

(setf (symbol-function 'add2) #'(lambda (x) (+ x 2)))

#<FUNCTION (LAMBDA (X)) {53563E0B}>

(add2 3)

Functional Programming

Functional programming means writing programs that work by returning values, instead of by modifying things. It is the dominant paradigm in Lisp. Most built-in Lisp functions are meant to be called for the values they return, not for side-effects.

The function remove, for example, takes an object and a list and returns a new list containing everything but that object:

Why not just say that remove removes an object from a list? Because that's not what it does. The original list is untouched afterwards:

(setf 1st ' (c a r a t ) )
(remove 'a 1st)

(C R T)

Why not just say that remove removes an object from a list? Because that's not what it does. The original list is untouched afterwards.

1st

(C A R A T)

So what if you really do want to remove something from a list? In Lisp you generally do such things by passing the list as an argument to some function, and using setf with the return value. To remove all the as from a list x, we say:

(setf x (remove 'a x))

Functional programming means, essentially, avoiding setf and things like it. At first sight it may be difficult to imagine how this is even possible, let alone desirable. How can one build programs just by returning values?

It would be inconvenient to do without side-effects entirely. However, as you read further, you may be surprised to discover how few you really need. And the more side-effects you do without, the better off you'll be.

One of the most important advantages of functional programming is that it allows interactive testing. In purely functional code, you can test each function as you write it. If it returns the values you expect, you can be confident that it is correct. The added confidence, in the aggregate, makes a huge difference. You have instant turnaround when you make changes anywhere in a program. And this instant turnaround enables a whole new style of programming, much as the telephone, as compared to letters, enabled a new style of communication.

Some Other Resources

Concurrncy

TODO Ray-Tracing

Misc: `eqal?`

(eq x y) is true if and only if x and y are the same identical object.

(eq 'a 'b) is false.
(eq 'a 'a) is true.
(eq 3 3) might be true or false, depending on the implementation.
(eq 3 3.0) is false.
(eq 3.0 3.0) might be true or false, depending on the implementation.
(eq #c(3 -4) #c(3 -4))
might be true or false, depending on the implementation.
(eq #c(3 -4.0) #c(3 -4)) is false.
(eq (cons 'a 'b) (cons 'a 'c)) is false.
(eq (cons 'a 'b) (cons 'a 'b)) is false.
(eq '(a . b) '(a . b)) might be true or false.
(progn (setq x (cons 'a 'b)) (eq x x)) is true.
(progn (setq x '(a . b)) (eq x x)) is true.
(eq #\A #\A) might be true or false, depending on the implementation.
(eq "Foo" "Foo") might be true or false.
(eq "Foo" (copy-seq "Foo")) is false.
(eq "FOO" "foo") is false.

The eql predicate is true if its arguments are eq, or if they are numbers of the same type with the same value, or if they are character objects that represent the same character.

(eql 'a 'b) is false.
(eql 'a 'a) is true.
(eql 3 3) is true.
(eql 3 3.0) is false.
(eql 3.0 3.0) is true.
(eql #c(3 -4) #c(3 -4)) is true.
(eql #c(3 -4.0) #c(3 -4)) is false.
(eql (cons 'a 'b) (cons 'a 'c)) is false.
(eql (cons 'a 'b) (cons 'a 'b)) is false.
(eql '(a . b) '(a . b)) might be true or false.
(progn (setq x (cons 'a 'b)) (eql x x)) is true.
(progn (setq x '(a . b)) (eql x x)) is true.
(eql #\A #\A) is true.
(eql "Foo" "Foo") might be true or false.
(eql "Foo" (copy-seq "Foo")) is false.
(eql "FOO" "foo") is false.

The equal predicate is true if its arguments are structurally similar (isomorphic) objects. A rough rule of thumb is that two objects are equal if and only if their printed representations are the same.

YouTube Channels

Concurrency and Parallelism in Go

Fri, 30 Sep 2022 00:00:00 +0000

Concurrency and Parallelism in Go

[2026-03-18 Wed 07:18] Important note

This page was a personal note, content is not original. I'm getting it out of the archive only a the historical purpose.

A tutorial in concurrency and parallelism with the Go programming language.

When most people use the word “concurrent,” they’re usually referring to a process that occurs simultaneously with one or more processes. It is also usually implied that all of these processes are making progress at about the same time. Under this definition, an easy way to think about this is people. You are currently reading this sentence while others in the world are simultaneously living their lives. They are existing concurrently to you. #The Go Programming Language

Why?

As with most paths toward understanding, we’ll begin with a bit of history. Let’s first take a look at how concurrency became such an important topic.

Moore's Law, Web, And the Current Mess

In 1965, Gordon Moore wrote a three-page paper that described both the consolidation of the electronics market toward integrated circuits and the doubling of the number of components in an integrated circuit every year for at least a decade. In 1975, he revised this prediction to state that the number of components on an integrated circuit would double every two years. This prediction more or less held until just recently—around 2012.

Several companies foresaw this slowdown in the rate Moore’s law predicted and began to investigate alternative ways to increase computing power. As the saying goes, necessity is the mother of innovation, and so it was in this way that multicore processors were born.

This looked like a clever way to solve the bounding problems of Moore’s law, but computer scientists soon found themselves facing down the limits of another law: Amdahl’s law, named after computer architect Gene Amdahl. Amdahl’s law describes a way in which to model the potential performance gains from implementing the solution to a problem in a parallel manner. Simply put, it states that the gains are bounded by how much of the program must be written sequentially.

For example, imagine you were writing a program that was largely GUI based: a user is presented with an interface, clicks on some buttons, and stuff happens. This type of program is bounded by one very large sequential portion of the pipeline: human interaction. No matter how many cores you make available to this program, it will always be bounded by how quickly the user can interact with the interface. Now consider a different example, calculating the digits of pi. Thanks to a class of algorithms called spigot algorithms, this problem is called embarrassingly parallel, which —despite sounding made up—is a technical term that means that it can easily be divided into parallel tasks. In this case, significant gains can be made by making more cores available to your program, and your new problem becomes how to combine and store the results.

For problems that are embarrassingly parallel, it is recommended that you write your application so that it can scale horizontally. This means that you can take instances of your program, run it on more CPUs, or machines, and this will cause the runtime of the system to improve. Embarrassingly parallel problems fit this model so well because it’s very easy to structure your program in such a way that you can send chunks of a problem to different instances of your application.

Problems

Concurrent code is notoriously difficult to get right. It usually takes a few iterations to get it working as expected, and even then it’s not uncommon for bugs to exist in code for years before some change in timing (heavier disk utilization, more users logged into the system, etc.) causes a previously undiscovered bug to rear its head. Indeed, for this very book, I’ve gotten as many eyes as possible on the code to try and mitigate this.

Race Conditions

A race condition occurs when two or more operations must execute in the correct order, but the program has not been written so that this order is guaranteed to be maintained.

Most of the time, this shows up in what’s called a data race, where one concurrent operation attempts to read a variable while at some undetermined time another concurrent operation is attempting to write to the same variable.

Here’s a basic example:

var data int
go func() {
 data++
}()
if data == 0 {
 fmt.Printf("the value is %v.\n", data)
}

Atomicity

When something is considered atomic, or has the property of atomicity, this means that within the context that it is operating, it is indivisible, or uninterruptible.

So what does that mean, and why is this important to know when working with concurrent code?

The first and very important thing is the word “context.” Something may be atomic in one context, but not another. Operations that are atomic within the context of your process may not be atomic in the context of the operating system; operations that are atomic within the context of the operating system may not be atomic within the context of your machine, and operations that are atomic within the context of your machine may not be atomic within the context of your application. In other words, the atomicity of an operation can change depending on the currently defined scope. This fact can work both for and against you.

When thinking about atomicity, very often the first thing you need to do is to define the context or scope, and the operation will be considered to be atomic. Everything follows from this.

Now let’s look at the terms “indivisible” and “uninterruptible.” These terms mean that within the context you’ve defined, something that is atomic will happen in its entirety without anything happening in that context simultaneously. That’s still a mouthful, so let’s look at an example:

i++

This is about as simple an example as anyone can contrive, and yet it easily demonstrates the concept of atomicity. It may look atomic, but a brief analysis reveals several operations:

Retrieve the value of i.
Increment the value o.
Store the value of i.

While each of these operations alone is atomic, the combination of the three may not be, depending on your context. This reveals an interesting property of atomic operations: combining them does not necessarily produce a larger atomic operation. Making the operation atomic is dependent on which context you’d like it to be atomic within. If your context is a program with no concurrent processes, then this code is atomic within that context. If your context is a goroutine that doesn’t expose I to other goroutines, then this code is atomic.

Deadlocks

A deadlocked program is one in which all concurrent processes are waiting on one another. In this state, the program will never recover without outside intervention. If that sounds grim, it’s because it is! The Go runtime attempts to do its part and will detect some deadlocks (all goroutines must be blocked, or “asleep”), but this doesn’t do much to help you prevent deadlocks.

To help solidify what a deadlock is, let’s first look at an example.¹

var wg sync.WaitGroup
printSum := func(v1, v2 *value) {
 defer wg.Done()
 v1.mu.Lock() // Here we attempt to enter the critical section for the incoming value.
 defer v1.mu.Unlock() // Here we use the defer statement to exit the critical section before printSum returns.
 time.Sleep(2*time.Second) // Here we sleep for a period of time to simulate wor
 v2.mu.Lock()
 defer v2.mu.Unlock()
 fmt.Printf("sum=%v\n", v1.value + v2.value)
}
var a, b value
wg.Add(2)
go printSum(&a, &b)
go printSum(&b, &a)
wg.Wait()

If you were to try and run this code, you’d probably see:

fatal error: all goroutines are asleep - deadlock!

Why? If you look carefully, you’ll see a timing issue in this code. Following is a graph‐ local representation of what’s going on. The boxes represent functions, the horizontal lines calls to these functions and the vertical bars lifetimes of the function at the head of the graphic

It seems pretty obvious why this deadlock is occurring when we lay it out graphically like that, but we would benefit from a more rigorous definition. It turns out there are a few conditions that must be present for deadlocks to arise, and in 1971, Edgar Coff‐ man enumerated these conditions in a paper. The conditions are now known as the Coffman Conditions are the basis for techniques that help detect, prevent, and correct deadlocks.

Mutual Exclusion A concurrent process holds exclusive rights to a resource at any one time.
Wait For the Condition A concurrent process must simultaneously hold a resource and be waiting for an
additional resources. No Preemption
A resource held by a concurrent process can only be released by that process, so it fulfills this condition.
Circular Wait A concurrent process (P1) must be waiting on a chain of other concurrent pro‐ cesses (P2), which are in turn waiting on it (P1), so it fulfills this final condition too.

KILL Livelock

Livelocks are programs that are actively performing concurrent operations, but these operations do nothing to move the state of the program forward.

Have you ever been in a hallway walking toward another person? She moves to one side to let you pass, but you’ve just done the same. So you move to the other side, but she’s also done the same. Imagine this going on forever, and you understand livelocks.

KILL Starvation

Concurrency vs Parallelism

The fact that concurrency is different from parallelism is often overlooked or misunderstood. In conversations between many developers, the two terms are often used interchangeably to mean “something that runs at the same time as something else.” Sometimes using the word “parallel” in this context is correct, but usually, if the developers are discussing code, they really ought to be using the word “concurrent.”

The reason to differentiate goes well beyond pedantry. The difference between concurrency and parallelism turns out to be a very powerful abstraction when modeling your code, and Go takes full advantage of this. Let’s take a look at how the two concepts are different so that we can understand the power of this abstraction. We’ll start with a very simple statement:

Concurrency is a property of the code; parallelism is a property of the running program.

Don’t we usually think about these two things the same way? We write our code so that it will execute in parallel. Right?

Well, let’s think about that for a second. If I write my code with the intent that two chunks of the program will run in parallel, do I have any guarantee that will happen when the program is run? What happens if I run the code on a machine with only one core? Some may be thinking, It will run in parallel, but this isn’t true!

The chunks of our program may appear to be running in parallel, but they’re executing sequentially faster than is distinguishable. The CPU context switches to share time between different programs, and over a coarse enough granularity of time, the tasks appear to be running in parallel. If we were to run the same binary on a machine with two cores, the program’s chunks might be running in parallel.

This reveals a few interesting and important things. The first is that we do not write parallel code, only concurrent code that we hope will be run in parallel. Once again, parallelism is a property of the runtime of our program, not the code.

The second interesting thing is that we see it is possible—maybe even desirable—to be ignorant of whether our concurrent code is running in parallel. This is only made possible by the layers of abstraction that lie beneath our program’s model: the concurrency primitives, the program’s runtime, the operating system, the platform the operating system runs on (in the case of hypervisors, containers, and virtual machines), and ultimately the CPUs. These abstractions are what allow us to make the distinction between concurrency and parallelism, and ultimately what gives us the power and flexibility to express ourselves. We’ll come back to this.

CPS

A CSP stands for “Communicating Sequential Processes,” which is both a technique and the name of the paper that introduced it. In 1978, Charles Antony Richard Hoare published a paper in the Association for Computing Machinery (more popularly referred to as ACM).

In this paper, Hoare suggests that input and output are two overlooked primitives of programming—particularly in concurrent code. At the time Hoare authored this paper, research was still being done on how to structure programs, but most of this effort was being directed to techniques for sequential code: usage of the goto statement was being debated (yeah funny history), and the object-oriented paradigm was beginning to take root. Concurrent operations weren’t being given much thought. Hoare set out to correct this, and thus his paper, and CSP, were born.

In the 1978 paper, CSP was only a simple programming language constructed solely to demonstrate the power of communicating sequential processes; in fact, he even says in the paper:

Thus the concepts and notations introduced in this paper should … not be regarded as suitable for use as a programming language, either for abstract or concrete programming.

Hoare was deeply concerned that the techniques he was presenting did nothing to further the study of the correctness of programs, and that the techniques may not be performant in a real language based on his own. Over the next six years, the idea of CSP was refined into a formal representation of something called process calculus to take the ideas of communicating sequential processes and beginning to reason about program correctness. Process calculus is a way to mathematically model concurrent systems and also provides algebraic laws to perform transformations on these systems to analyze their various properties, e.g., efficiency and correctness

To support his assertion that inputs and outputs needed to be considered language primitives, Hoare’s CSP programming language contained primitives to model input and output, or communication, between processes correctly (this is where the paper’s name comes from). Hoare applied the term processes to any encapsulated portion of logic that required input to run and produced output other processes would consume. Hoare probably could have used the word “function” were it not for the debate on how to structure programs occurring in the community when he wrote his paper.

For communication between the processes, Hoare created input and output commands: ! for sending input into a process, and ? for reading output from a process. Each command had to specify either an output variable (in the case of reading a variable out of a process) or a destination (in the case of sending input to a process). Sometimes these two would refer to the same thing, in which case the two processes would be said to correspond. In other words, output from one process would flow directly into the input of another process.

History has judged Hoare’s suggestion to be correct; however, it’s interesting to note that before Go was released, few languages brought support for these primitives into the language. Most popular languages favor sharing and synchronizing access to the memory to CSP’s message-passing style. There are exceptions, but unfortunately, these are confined to languages that haven’t seen wide adoption. Go is one of the first languages to incorporate principles from CSP in its core, and bring this style of concurrent programming to the masses. Its success has led other languages to attempt to add these primitives as well.

`Goroutine`

The Goroutines are one of the most basic units of organization in a Go program, so it’s important we understand what they are and how they work. Every Go program has at least one goroutine: the main goroutine, which is automatically created and started when the process begins. In almost any program you’ll probably find yourself reaching for a goroutine sooner or later to assist in solving your problems. So what are they?

Goroutines are unique to Go (though some other languages have a concurrency primitive that is similar). They’re not OS threads, and they’re not exactly green threads—threads that are managed by a language’s runtime—they’re a higher level of abstraction known as coroutines. Coroutines are simply concurrent subroutines (functions, closures, or methods in Go) that are nonpreemptive—that is, they cannot be interrupted. Instead, coroutines have multiple points throughout which allow for suspension or reentry.

What makes goroutines unique to Go is their deep integration with Go’s runtime. Goroutines don’t define their suspension or reentry points; Go’s runtime observes the runtime behavior of goroutines and automatically suspends them when they block and then resumes them when they become unblocked. In a way, this makes them preemptable, but only at points where the goroutine has become blocked. It is an elegant partnership between the runtime and a goroutine’s logic. Thus, goroutines can be considered a special class of coroutine.

Coroutines, and thus goroutines, are implicitly concurrent constructs, but concurrency is not a property of a coroutine: something must host several coroutines simultaneously and allow each to execute—otherwise, they wouldn’t be concurrent.

Go’s mechanism for hosting goroutines is an implementation of what’s called an M: N scheduler, which means it maps M green threads to N OS threads. Goroutines are then scheduled onto the green threads. When we have more goroutines than green threads available, the scheduler handles the distribution of the goroutines across the available threads and ensures that when these goroutines become blocked, other goroutines can be run.

The go statement is how Go performs a fork, and the forked threads of execution are goroutines. Let’s return to our simple goroutine example:

sayHello := func() {
fmt.Println("hello")
}
go sayHello()

Here, the sayHello function will be run on its goroutine, while the rest of the program continues executing. In this example, there is no join point. The goroutine executing sayHello will simply exit at some undetermined time in the future, and the rest of the program will have already continued executing.

There is one problem with this example: as written, it’s undetermined whether the sayHello the function will ever be run at all. The goroutine will be created and scheduled with Go’s runtime to execute, but it may not get a chance to run before the main goroutine exits.

Indeed, because we omit the rest of the main function for simplicity, when we run this small example, it is almost certain that the program will finish executing before the goroutine hosting the call to sayHello is ever started. As a result, you won’t see the word “hello” printed to stdout. You could put a time.Sleep after you create the goroutine, but recall that this doesn’t actually create a join point, only a race condition.

To a create a join point, you have to synchronize the main goroutine and the sayHello goroutine. This can be done in a number of ways.

import (
 "fmt"
 "sync"
)
func main() {

 sayhello := func() {
 defer wg.Done()
 fmt.Print("hello")
 }
 go sayhello()
 wg.Add(1)
 wg.Wait()
}

hello

`sync`

The sync package contains the concurrency primitives that are most useful for low- level memory access synchronization.

`WaitGroup`

WaitGroup is a great way to wait for a set of concurrent operations to complete when you either don’t care about the result of the concurrent operation, or you have other means of collecting their results. If neither of those conditions is true, I suggest you use channels and a select statement instead. WaitGroup is so useful, I’m introducing it first so I can use it in subsequent sections. Here’s a basic example of using a WaitGroup to wait for goroutines to complete:

import (
 "fmt"
 "sync"
)
func main() {
 var wg sync.WaitGroup
 wg.Add(1)
 go func() {
 defer wg.Done()
 fmt.Print("1")
 }()

 wg.Add(1)
 go func() {
 defer wg.Done()
 fmt.Print("2")
 }()

 wg.Add(1)
 go func() {
 defer wg.Done()
 fmt.Print("3")
 }()
 wg.Wait()
}

The output will differ probably in your machine.

`Mutex` and `RWMutex`

Mutex stands for “mutual exclusion” and is a way to guard critical sections of your program. A critical section is an area of your program that requires exclusive access to a shared resource. A Mutex provides a concurrent-safe way to express exclusive access to these shared resources. To borrow a Goism, whereas channels share memory by communicating, a Mutex shares memory by creating a convention developer must follow to synchronize access to the memory. You are responsible for coordinating access to this memory by guarding access to it with a mutex. Here’s a simple example of two goroutines that are attempting to increment and decrement a common value; they use a Mutex to synchronize:

func main() {
 var count int
 var lock sync.Mutex
 increment := func() {
 lock.Lock()
 defer lock.Unlock()
 count++
 fmt.Printf("Incrementing: %d\n", count)
 }
 decrement := func() {
 lock.Lock()
 defer lock.Unlock()
 count--
 fmt.Printf("Decrementing: %d\n", count)
 }
 // Increment
 var arithmetic sync.WaitGroup
 for i := 0; i <= 5; i++ {
 arithmetic.Add(1)
 go func() {
 defer arithmetic.Done()
 increment()
 }()
 }

 // Decrement
 for i := 0; i <= 5; i++ {
 arithmetic.Add(1)
 go func() {
 defer arithmetic.Done()
 decrement()
 }()
 }
 arithmetic.Wait()
 fmt.Println("Arithmetic complete.")
}

Critical sections are so named because they reflect a bottleneck in your program. It is somewhat expensive to enter and exit a critical section, and so generally people attempt to minimize the time spent in critical sections. One strategy for doing so is to reduce the cross-section of the critical section. There may be a memory that needs to be shared between multiple concurrent processes, but perhaps not all of these processes will read and write to this memory. If this is the case, you can take advantage of a different type of mutex: sync.RWMutex. The sync.RWMutex is conceptually the same thing as a Mutex: it guards memory access; however, RWMutex gives you a little bit more control over the memory.

`Cond`

The comment for the Cond type does a great job of describing its purpose:

…a rendezvous point for goroutines waiting for or announcing the occurrence of an event.

In that definition, an “event” is any arbitrary signal between two or more goroutines that carries no information other than the fact that it has occurred. Very often you’ll want to wait for one of these signals before continuing execution on a goroutine. If we were to look at how to accomplish this without the Cond type, one naive approach is to use an infinite loop:

for conditionTrue() == false {
}

However, this would consume all cycles of one core. To fix that, we could introduce a time.sleep

time.Sleep:
for conditionTrue() == false {
time.Sleep(1*time.Millisecond)
}

This is better, but it’s still inefficient, and you have to figure out how long to sleep for: too long, and you’re artificially degrading performance; too short, and you’re unnecessarily consuming too much CPU time. It would be better if there were some kind of a way for a goroutine to efficiently sleep until it was signaled to wake and check its condition. This is exactly what the Cond type does for us. Using a Cond, we could write the example like:

c := sync.NewCond(&sync.Mutex{})
c.L.Lock()
for conditionTrue() == false {
c.Wait()
}
c.L.Unlock()

Let’s expand on this example and show both sides of the equation: a goroutine that is waiting for a signal, and a goroutine that is sending signals. Say we have a queue of fixed length 2, and 10 items we want to push onto the queue. We want to enqueue items as soon as there is room, so we want to be notified as soon as there’s room in the queue. Let’s try using a Cond to manage this coordination:

c := sync.NewCond(&sync.Mutex{})
queue := make([]interface{}, 0, 10)
removeFromQueue := func(delay time.Duration) {
 time.Sleep(delay)
 c.L.Lock()
 queue = queue[1:]
 fmt.Println("Removed from queue")
 c.L.Unlock()
 c.Signal()
}
for i := 0; i < 10; i++{
 c.L.Lock()
 for len(queue) == 2 {
 c.Wait()
 }
 fmt.Println("Adding to queue")
 queue = append(queue, struct{}{})
 go removeFromQueue(1*time.Second)
 c.L.Unlock()
}

We also have a new method in this example, Signal. This is one of two methods that the Cond type provides for notifying goroutines blocked on a Wait call that the condition has been triggered. The other is a method called Broadcast. Internally, the run-time maintains a FIFO list of goroutines waiting to be signaled; Signal finds the goroutine that’s been waiting for the longest and notifies that, whereas Broadcast sends a signal to all goroutines that are waiting. Broadcast is arguably the more interesting of the two methods as it provides a way to communicate with multiple goroutines at once.

KILL `Brodcast`

`Once`

Once is an object that will perform exactly one action. Sounds simple enough, what’s so useful about it then?

Well for some reason this isn’t particularly well documented, but a sync.Once will wait until the execution of .Do completes. This makes it incredibly useful when performing relatively expensive operations that you would typically cache in a map.

Say for example you have a popular website that hits a backend API that isn’t particularly fast, so you decide to cache API results in-memory with a map. A naive solution might look like this:

package main

var cache = make(map[string][]byte)
var mutex = new(sync.Mutex)

func DoQuery(name string) []byte {
 // Check if the result is already cached.
 mutex.Lock()
 if cached, found := cache[name]; found {
 mutex.Unlock()
 return cached, nil
 }
 mutex.Unlock()

 // Make the request if it's uncached.
 resp, err := http.Get("https://upstream.api/?query=" + url.QueryEscape(name))
 // Error handling and resp.Body.Close omitted for brevity.
 result, err := ioutil.ReadAll(resp)

 // Store the result in the cache.
 mutex.Lock()
 cache[name] = result
 mutex.Unlock()

 return result
}

Well what happens if there are two calls to DoQuery that happen simultaneously? The calls would race, neither would see the cache is populated, and both would perform the HTTP request to upstream.api unnecessarily, when only one would need to complete it.

Well, you can do something like this:

package main

type CacheEntry struct {
 data []byte
 wait <-chan struct{}
}

var cache = make(map[string]*CacheEntry)
var mutex = new(sync.Mutex)

func DoQuery(name string) []byte {
 // Check if the operation has already been started.
 mutex.Lock()
 if cached, found := cache[name]; found {
 mutex.Unlock()
 // Wait for it to complete.
 <-cached.wait // remember that when a channel is closed, you get the zero value without blocking.
 return cached.data, nil
 }

 wait := make(chan struct{})

 entry := &CacheEntry{
 data: result,
 wait: wait,
 }
 cache[name] = entry
 mutex.Unlock()

 // Make the request if it's uncached.
 resp, err := http.Get("https://upstream.api/?query=" + url.QueryEscape(name))
 // Error handling and resp.Body.Close omitted for brevity
 entry.data, err = ioutil.ReadAll(resp)

 // Signal that the operation is complete, receiving on closed channels returns immediately.
 close(wait)

 return result
}

That’s good and all but the code’s readability has taken a hit. It’s not immediately clear what’s going on with cached.wait and the flow of operations under different situations is not very intuitive.

Let's try again with sync.Once:

package main

type CacheEntry struct {
 data []byte
 once *sync.Once
}

var cache = make(map[string]*CacheEntry)
var mutex = new(sync.Mutex)

func DoQuery(name string) []byte {
 mutex.Lock()
 entry, found := cache[name]
 if !found {
 // Create a new entry if one does not exist already.
 entry = &CacheEntry{
 once: new(sync.Once),
 }
 cache[name] = entry
 }
 mutex.Unlock()

 entry.once.Do(func() {
 resp, err := http.Get("https://upstream.api/?query=" + url.QueryEscape(name))
 // Error handling and resp.Body.Close omitted for brevity
 entry.data, err = ioutil.ReadAll(resp)
 })

 return entry.data
}

That’s it. This achieves the same as the previous example, but is now much easier to understand (at least in my opinion). There is only a single return, and the code flows intuitively from top to bottom without having to read and understand what’s going on with the entry.wait channel as before.

Concurrency Patterns in Go

We’ve explored the fundamentals of Go’s concurrency primitives and discussed how to properly use these primitives. In this chapter, we’ll do a deep-dive into how to compose these primitives into patterns that will help keep your system scalable and maintainable.

However, before we get started, we need to touch upon the format of some of the pat‐ terns contained in this chapter. In a lot of the examples, we’ll be using channels that pass empty interfaces (interface{}) around.

Confinement

When working with concurrent code, there are a few different options for safe operation. We’ve gone over two of them:

Synchronization primitives for sharing memory (e.g., sync.Mutex)
Synchronization via communicating (e.g., channels)

However, there are a couple of other options that are implicitly safe within multiple concurrent processes:

Immutable data
Data protected by confinement

In some sense, immutable data is ideal because it is implicitly concurrent-safe. Each concurrent process may operate on the same data, but it may not modify it. If it wants to create new data, it must create a new copy of the data with the desired modifications. This allows not only a lighter cognitive load on the developer but can also lead to faster programs if it leads to smaller critical sections (or eliminates them altogether). In Go, you can achieve this by writing code that utilizes copies of values instead of pointers to values in memory.

Confinement is the simple yet powerful idea of ensuring information is only ever available from one concurrent process. When this is achieved, a concurrent program is implicitly safe and no synchronization is needed. There are two kinds of confinement possible: ad hoc and lexical.

Ad Hoc

Ad hoc confinement is when you achieve confinement through a convention whether it be set by the languages community, the group you work within, or the code-base you work within. In my opinion, sticking to convention is difficult to achieve on projects of any size unless you have tools to perform static analysis on your code every time someone commits some code. Here’s an example of ad hoc confinement that demonstrates why:

import "fmt"
func main() {
 data := make([]int, 4)
 loopData := func(handleData chan<- int) {
 defer close(handleData)
 for i := range data {
 handleData <- data[i]
 }
 }
 handleData := make(chan int)
 go loopData(handleData)
 for num := range handleData {
 fmt.Println(num)
 }
}

We can see that the data slice of integers is available from both the loopData function and the loop over the handleData channel; however, by convention we’re only accessing it from the loopData function.

Lexical

Lexical confinement involves using lexical scope to expose only the correct data and concurrency primitives for multiple concurrent processes to use. It makes it impossible to do the wrong thing.

package main

import (
 "fmt"
 "time"
)

func main() {
 chanOwner := func() <-chan int {
 results := make(chan int, 5)
 go func() {
 defer close(results)

 for i := 0; i <= 5; i++ {
 time.Sleep(1 * time.Second)
 results <- i
 }
 }()

 return results
 }

 consumer := func(results <-chan int) {
 fmt.Println(results)

 for result := range results {
 fmt.Printf("Received: %d\n", result)
 }

 fmt.Println("Done receiving!")
 }

 fmt.Println("initiate channel")
 results := chanOwner()

 fmt.Println("consumer ready - OK")
 consumer(results)
}

Why pursue confinement if we have synchronization available to us? The answer is improved performance and reduced cognitive load on developers. Synchronization comes with a cost, and if you can avoid it you won’t have any critical sections, and therefore you won’t have to pay the cost of synchronizing them.²

For-Select

Obviously.

Preventing Goroutine Leaks

When you are dealing with a memory leak in Go, there is a possability by 99% that your dealing with goroutines leak.

The goroutine has a few paths to termination:

When it has completed its work.
When it cannot continue its work due to an unrecoverable error.
When it’s told to stop working.

We get the first two paths for free—these paths are your algorithm—but what about work cancellation? This turns out to be the most important bit because of the network effect: if you’ve begun a goroutine, it’s most likely cooperating with several other goroutines in some sort of organized fashion. We could even represent this interconnectedness as a graph: whether or not a child goroutine should continue executing might be predicated on knowledge of the state of many other goroutines. The parent

goroutine (often the main goroutine) with this full contextual knowledge should be able to tell its child goroutines to terminate. Let’s start with a simple exam ple of a goroutine leak:

func main() {
 doWork := func(strings <-chan string) <-chan interface{} {
 completed := make(chan interface{})
 go func() {
 defer fmt.Println("doWork exited.")
 defer close(completed)
 for s := range strings {
 // Do something interesting
 fmt.Println(s)
 }
 }()
 return completed
 }
 doWork(nil)
 // Perhaps more work is done here
 fmt.Println("Done.")
 fmt.Println(runtime.NumGoroutine())
}

Here we see that the main goroutine passes a nil channel into doWork. Therefore, the strings channel will never actually gets any strings written onto it, and the goroutine containing doWork will remain in memory for the lifetime of this process (we would even deadlock if we joined the goroutine within doWork and the main goroutine).

In this example, the lifetime of the process is very short, but in a real program, goroutines could easily be started at the beginning of a long-lived program. In the worst case, the main goroutine could continue to spin up goroutines throughout its life, causing creep in memory utilization.

The way to successfully mitigate this is to establish a signal between the parent goroutine and its children that allows the parent to signal cancellation to its children. By convention, this signal is usually a read-only channel named done. The parent goroutine passes this channel to the child goroutine and then closes the channel when it wants to cancel the child goroutine. Here’s an example:

func main() {
 doWork := func(
 done <-chan interface{},
 strings <-chan string,
 ) <-chan interface{} {
 terminated := make(chan interface{})
 go func() {
 defer fmt.Println("doWork exited.")
 defer close(terminated)
 for {
 select {
 case s := <-strings:
 // Do something interesting
 fmt.Println(s)
 case <-done:
 return
 }
 }
 }()
 return terminated
 }
 done := make(chan interface{})
 terminated := doWork(done, nil)
 go func() {
 // Cancel the operation after 1 second.
 time.Sleep(1 * time.Second)
 fmt.Println("Canceling doWork goroutine...")
 close(done)
 }()
 <-terminated
 fmt.Println("Done.")
}

Notes

It is useful to use the buffered channel, but only when you have a good reason to (since they might help hiding race conditions)

KILL Rendezvous

Footnotes

There is an accepted proposal to allow the runtime to detect partial deadlocks, but it has not been implemented. For more information, see https://github.com/golang/go/issues/13759.

Note that lexical might abuse the memory usage in this example; for larger types (which should be passed as pointers)

Legacy Commentary

Tue, 20 Sep 2022 00:00:00 +0000

Legacy Commentary

[2026-03-18 Wed 07:16] Update and context

From August 2022 until July 2023, I used to note some internet content in what I called "commentary". Eventually, it developed to a website, a blog, diary, and all what we have in hands now. #Programming

I decided today to get this page back here, just for the historical purpose.

Click to hide dates

Because why not? I will not contribute to an awesome-prototype github repo anyways. side-note I usually archive (on the WaybackMachine) anything that I might think I will read again, so if you encounter with any broken url, check it on the WaybackMachine. Another side-note I'm adding posts in an ascending order (first are newest).

How GO Was Created - Less Is More "I do not think people who love rust could go to another language they're kind of sucked into rusthole" lmao. (2023/07/24)
Keep Linux Open and Free!!!! Oracle Dunks on IBM kek. (2023/07/12)
The Most Efficient Struct Configuration Pattern For Go. It's actually very useful pattern to use. I've used it a lot in Go, it was inspired to me from Lisp (I can tell that is one of the most common patterns in Lisp). I was thinking today if it will be possible to have a fantastic control-statement function in Go like Lisp's IF. (2023/06/30)
The Rust programming language absolutely positively sucks. I like the fact that they published it in r/rust. (2023/06/22)
Prompt Engineering is The New C++ (2023/06/19)
A Tale of Unwanted Disruption: My Week Without Amazon. Smart housing is one of the worst ideas that we have been through so far. Just as bad as thinking in the 90s that people in the next millennium would execute programs that they don't know how they are implemented. (2023/06/19)
Robot taxi killed dog Is rms' comment very irrelevant? (2023/06/18)
Editor/IDE Tier List "I've never met someone who used emacs that I'm not just impressed with". Okay he fixed it right away. (2023/06/13)
- Editor/IDE Tier List "I never opened it I never used it there was only that weird guy at work who uses it". This way to describe emacs hits me hard actually. (2023/06/13)
Interview with an Emacs Enthusiast in 2023 [Colorized]. "- So you are going to treat it as a text buffer? - I treat my whole life as a text buffer" lol. (2023/06/11)
I hate almost all software. Totally agree. This industry is just horrible. (2023/06/06)
drag gets all fucked to fuck when you click and drag and release outside of the slider shit · Issue #1631 · nolimits4web/swiper. This is how we handle technical documentation for bugs, ladies and gentlemen. (2023/06/06)
Israeli agents conducted targeted killings in West Bank, killing a child. I've studied some propaganda modules years ago that explained me much of what I'm seeing in the mass media, yet it is never enough to make you see what is going behind the scene that would make the washingtonpost publish such a report. (2023/05/30)
If Fight Club Was. (2023/05/30)
The Stack Overflow Survey. "I did do crystalmeth but that's different than crystal" this actually hits hard if you know that theprimeagen is an ex-crystalmeth addict. (2023/05/23)
DirectorZ333. Found this fan youtube channel today, seems that they used to make nice music videos for their favorite songs a decade ago. It's sad how such things being buried forever. (2023/05/20)
Episode 01: The Great Idea of Wisdom (2023/05/20)
Go job interview questions. Software industry is going always into worse and worse situation due to its dim hiring process. (2023/05/19)
Vim vs Emacs | Prime Reacts. "Those who run terminal emulator inside of their text editor have already screwed up" lmao. (2023/05/19)
Hero's journey - Wikipedia. I was much younger when I read Campell's "The hero with a thousand faces" for the first time. My thoughts now towards psychoanalyses are much developed compared to then, yet they are not decisive. I think I'm going to reread it to have more definitive view of psychoanalysis. (2023/05/19)
Why can't I land a job : cscareerquestions. "challenging challenges". Btw, let me put my opinion on language models here too. I don't think they are bad in general but in fact they solve only one problem; the bureaucratic writings. You can ask it to write you any useless load of "scalable", "ascendable" or whatever words the HR will be happy seeing while checking your resume. (2023/05/16)
Writing academic papers with org-mode. A thorough explanation. I feel confidence when I see this kind of intuition of teleportation; the explained workflow is very similar to what I've been doing, however I thought that what I'm doing is special workflow of mine. (2023/05/12)
Olympian frames: Frederic, Lord Leighton. (2023/05/06)
Poetry of Catullus — Wikipedia Republished // WIKI 2. (2023/05/05)

Prove that any palindrome with an even number of digits is divisible by 11 Was solving some euler problems today, found this interesting pattern in palindrome product:

3 digits: 913 x 993 = 906609, 7ms
4 digits: 9999 x 9901 = 99000099, 0ms
5 digits: 99681 x 99979 = 9966006699, 11ms
6 digits: 999999 x 999001 = 999000000999, 0ms
7 digits: 9997647 x 9998017 = 99956644665999, 812ms
8 digits: 99999999 x 99990001 = 9999000000009999, 0ms
9 digits: 999920317 x 999980347 = 999900665566009999, 508259ms
10 digits: 9999999999 x 9999900001 = 99999000000000099999, 0ms
11 digits: 99999943851 x 99999996349 = 9999994020000204999999, 420031ms
12 digits: 999999999999 x 999999000001 = 999999000000000000999999, 0ms
13 digits: ?
14 digits: 99999999999999 x 99999990000001 = 9999999000000000000009999999, 0ms

(2023/04/10)

kmx-io/repo: Source repository utilities in Common Lisp Sometimes all what you are missing is one piece. (2023/03/18)
Microsoft Excel as Lisp IDE Do people even hear themselves? (2023/03/17)
Let’s try ChatGPT. Is it any good?. A nice review. (2023/01/30)
Embedding Python in Go. (2022/12/22)
Why Go and not Rust? (2022/12/18)
The path towards decentralized moderation I wish if the web stayed like that, when everyone has its place that they really own and control. (2022/12/13)
Elite for Emacs (2022/12/09)
How To Become A Hacker Why this guide is not ubiquitous enough? I found it months ago when I was browsing Paul Geraham blog (he was arguing about an entry about Lisp here). I think it's a very suitable guide for everyone who is involved into using computer, it's a sad fact that even modern 'computer scientests' need such a guide. (2022/12/05)
I write, therefore I am I respect this place. (2022/12/01)
Why Lisp macros are cool, a Perl perspective (2022/11/26)
Go Web App Anti-Patterns (2022/11/22)
Poetry time! Go proverbs as limericks

There once was a programmer named Joe Who loved coding in Go, don't you know? He found it quite neat With concurrency sweet And a syntax that was oh so low-key

With goroutines running in parallel His code ran faster than a serial He could handle many tasks With ease and with panache Thanks to Go's ability to scale.

So if you want your code to be lean And run faster than you've ever seen Give Go a try And watch your code fly And see what it can do for your machine

(2022/12/18)

Bjarne Stroustrup: "I Did It For You All…" lmao. (2022/11/05)
Improving Firefox stability with this one weird trick This is funny. (2022/11/01)
Org-roam-bibtex - Quick Presentation. One of the best workflows I've ever seen. (2022/11/29)
What are your thoughts on ChatGPT? (2022/11/25)
How do you maintain a large code base? (2022/11/21)
Stop Writing Classes (2022/11/16)
Just In Time (JIT) Compilers (2022/11/12)
RubyConf 2017: 4 Programming Paradigms in 45 Minutes by Aja Hammerly (2022/11/08)
Embedding WebKit in Emacs: XWidgets+WebKit Feature Preview Seems very interesting. I used to think it's a hopeless technological when I tried it with M-x xwidget-webkit-browse-url, damn it I don't want even to remember. However I recently tried akirakyle/emacs-webkit and it rocks, I've been thinking of replacing chromium with it. Now, XWidgets seems very promising to me. I wish I had some free time to develop great things with it. (2022/11/04) (2022/12/19)
Three reasons YouTube loves #shorts (2022/09/20)

Effective Go: A Conclusion

Tue, 20 Sep 2022 00:00:00 +0000

Effective Go: A Conclusion

[2026-03-18 Wed 07:18] Important note

This page was a personal note, content is not original. I'm getting it out of the archive only a the historical purpose.

Reading the effective Go document.

So I'm currently reading the effective Go docs (as html, as pdf).

Years ago when I was learning C, I remember reading something similar, it was by google as well. And I think they used to name it 'effective' too. It was hosted on github pages by Google and was advocated as the "google-style guidelines". Moreover, it had the same problem that I'm facing with effective-go right now: there are many things that have nothing to do with the go programming language itself, but a general guidelines that you should probably have learned during the design principles class. I decided to filter out those irrelevant tips and distill a consultation, a recapitulation. So it might help someone.

References are used for non-tl;dr that might be interesting for nerds #The Go Programming Language.¹

Naming

Names are as important in Go as in any other language. They even have semantic effect: the visibility of a name outside a package is determined by whether its first character is upper case. It's therefore worth spending a little time talking about naming conventions in Go programs.

Packages

package in src/pkg/encoding/base64 is imported as "encoding/base64" but has name base64, not encoding_base64 and not encodingBase64. The importer of a package will use the name to refer to its contents (the import . notation is

Getters

Go doesn't provide automatic support for getters and setters. There's nothing wrong with providing getters and setters yourself, and it's often appropriate to do so, but it's neither idiomatic nor necessary to put Get into the getter's name. If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner. The use of upper-case names for export provides the hook to discriminate the field from the method. A setter function, if needed, will likely be called SetOwner. Both names read well in practice:

owner := obj.Owner()
if owner != user {
obj.SetOwner(user)
}

Interface (single-method)

By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.

There are a number of such names and it's productive to honor them and the function names they capture. Read, Write, Close, Flush, String and so on have canonical signatures and meanings. To avoid confusion, don't give your method one of those names unless it has the same signature and meaning. Conversely, if your type implements a method with the same meaning as a method on a well-known type, give it the same name and signature; call your string-converter method String not ToString.

MixedCaps

Finally, the convention in Go is to use MixedCaps or mixedCaps rather than underscores to write multiword names.

Comments

“Doc comments” are comments that appear immediately before top-level package, const, func, type, and var declarations with no intervening newlines. Every exported (capitalized) name should have a doc comment.

For syntax, read: https://go.dev/doc/comment#Syntax

Inside packages

Every package should have a package comment introducing the package. It provides information relevant to the package as a whole and generally sets expectations for the package. Especially in large packages, it can be helpful for the package comment to give a brief overview of the most important parts of the API, linking to other doc comments as needed.

If the package is simple, the package comment can be brief. For example:

// Package path implements utility routines for manipulating slash-separated
// paths.
//
// The path package should only be used for paths separated by forward
// slashes, such as the paths in URLs. This package does not deal with
// Windows paths with drive letters or backslashes; to manipulate
// operating system paths, use the [path/filepath] package.
package path

KILL Commands

`type`

A type's doc comment should explain what each instance of that type represents or provides. If the API is simple, the doc comment can be quite short. For example:

package zip
// A Reader serves content from a ZIP archive.
type Reader struct {
...
}

By default, programmers should expect that a type is safe for use only by a single goroutine at a time. If a type provides stronger guarantees, the doc comment should state them. For example:

package regexp
// Regexp is the representation of a compiled regular expression.
// A Regexp is safe for concurrent use by multiple goroutines,
// except for configuration methods, such as Longest.
type Regexp struct {
...
}

For a struct with exported fields, either the doc comment or per-field comments should explain the meaning of each exported field. For example, this type's doc comment explains the fields:

package io
// A LimitedReader reads from R but limits the amount of
// data returned to just N bytes. Each call to Read
// updates N to reflect the new amount remaining.
// Read returns EOF when N <= 0.
type LimitedReader struct {
R Reader // underlying reader
N int64 // max bytes remaining
}

As with packages (above) and funcs (below), doc comments for types start with complete sentences naming the declared symbol. An explicit subject often makes the wording clearer, and it makes the text easier to search, whether on a web page or a command line.

`func`

A func's doc comment should explain what the function returns or, for functions called for side effects, what it does. Named arguments or results can be referred to directly in the comment, without any special syntax like backquotes. (A consequence of this convention is that names like a, which might be mistaken for ordinary words, are typically avoided.) For example:

package strconv
// Quote returns a double-quoted Go string literal representing s.
// The returned string uses Go escape sequences (\t, \n, \xFF, \u0100)
// for control characters and non-printable characters as defined by IsPrint.
func Quote(s string) string {
...
}

`const`

Go's declaration syntax allows grouping of declarations, in which case a single doc comment can introduce a group of related constants, with individual constants only documented by short end-of-line comments. For example:

// The result of Scan is one of these tokens or a Unicode character.
const (
 EOF = -(iota + 1)
 Ident
 Int
 Float
 Char
 ...
)

Sometimes the group needs no doc comment at all. For example:

package unicode // import "unicode"
const (
MaxRune = '\U0010FFFF' // maximum valid Unicode code point.
ReplacementChar = '\uFFFD' // represents invalid code points.
MaxASCII = '\u007F' // maximum ASCII value.
MaxLatin1 = '\u00FF' // maximum Latin-1 value.
)

On the other hand, ungrouped constants typically warrant a full doc comment starting with a complete sentence. For example:

package unicode
// Version is the Unicode edition from which the tables are derived.
const Version = "13.0.0"

`var`

CHECK Errors

Error Strings

Error strings should not be capitalized (unless beginning with proper nouns or acronyms) or end with punctuation, since they are usually printed following other context. That is, use fmt.Errorf("something bad") not fmt.Errorf("Something bad"), so that log.Printf("Reading %s: %v", filename, err) formats without a spurious capital letter mid-message. This does not apply to logging, which is implicitly line-oriented and not combined inside other messages.

Other

Semicolons

Idiomatic Go programs have semicolons only in places such as for loop clauses, to separate the initializer, condition, and continuation elements. They are also necessary to separate multiple statements on a line, should you write code that way².

Declaring Variables

When declaring —but not initializing— a variable, use the keyword var
When declaring and initializing in the same time, use the short declaration form: :=

When declaring an empty slice, prefer

var t []string

over

t := []string{}

The former declares a nil slice value, while the latter is non-nil but zero-length. They are functionally equivalent—their len and cap are both zero—but the nil slice is the preferred style.

Note that there are limited circumstances where a non-nil but zero-length slice is preferred, such as when encoding JSON objects (a nil slice encodes to null, while []string{} encodes to the JSON array []).

When designing interfaces, avoid making a distinction between a nil slice and a non-nil, zero-length slice, as this can lead to subtle programming errors.

Context

Values of the context.Context type carry security credentials, tracing information, deadlines, and cancellation signals across API and process boundaries. Go programs pass Contexts explicitly along the entire function call chain from incoming RPCs and HTTP requests to outgoing requests.

Most functions that use a Context should accept it as their first parameter:

func F(ctx context.Context, /* other arguments */) {}

A function that is never request-specific may use context.Background(), but err on the side of passing a Context even if you think you don't need to. The default case is to pass a Context; only use context.Background() directly if you have a good reason why the alternative is a mistake.

Don't add a Context member to a struct type; instead add a ctx parameter to each method on that type that needs to pass it along. The one exception is for methods whose signature must match an interface in the standard library or in a third party library.

Don't create custom Context types or use interfaces other than Context in function signatures.

If you have application data to pass around, put it in a parameter, in the receiver, in globals, or, if it truly belongs there, in a Context value.

Contexts are immutable, so it's fine to pass the same ctx to multiple calls that share the same deadline, cancellation signal, credentials, parent trace, etc.

Rand

Do not use package math/rand to generate keys, even throwaway ones. Unseeded, the generator is completely predictable. Seeded with time.Nanoseconds(), there are just a few bits of entropy. Instead, use crypto/rand's Reader, and if you need text, print to hexadecimal or base64:

import (
 "crypto/rand"
 // "encoding/base64"
 // "encoding/hex"
 "fmt"
)

func Key() string {
 buf := make([]byte, 16)
 _, err := rand.Read(buf)
 if err != nil {
 panic(err) // out of randomness, should never happen
 }
 return fmt.Sprintf("%x", buf)
 // or hex.EncodeToString(buf)
 // or base64.StdEncoding.EncodeToString(buf)
}

func main() {
 fmt.Print(Key())
 }

357db26fc4003c331ce3253faed249b5

Import Blank

Packages that are imported only for their side effects (using the syntax import _ "pkg") should only be imported in the main package of a program, or in tests that require them.

Named Result Parameters

Consider what it will look like in godoc. Named result parameters like:

func (n *Node) Parent1() (node *Node) {}
func (n *Node) Parent2() (node *Node, err error) {}

will be repetitive in godoc; better to use:

func (n *Node) Parent1() *Node {}
func (n *Node) Parent2() (*Node, error) {}

On the other hand, if a function returns two or three parameters of the same type, or if the meaning of a result isn't clear from context, adding names may be useful in some contexts. Don't name result parameters just to avoid declaring a var inside the function; that trades off a minor implementation brevity at the cost of unnecessary API verbosity.

Return Values

If the receiver is a map, func or chan, don't use a pointer to them. If the receiver is a slice and the method doesn't reslice or reallocate the slice, don't use a pointer to it.
If the method needs to mutate the receiver, the receiver must be a pointer.
If the receiver is a struct that contains a sync.Mutex or similar synchronizing field, the receiver must be a pointer to avoid copying.
If the receiver is a large struct or array, a pointer receiver is more efficient. How large is large? Assume it's equivalent to passing all its elements as arguments to the method. If that feels too large, it's also too large for the receiver.
Can function or methods, either concurrently or when called from this method, be mutating the receiver? A value type creates a copy of the receiver when the method is invoked, so outside updates will not be applied to this receiver. If changes must be visible in the original receiver, the receiver must be a pointer.
If the receiver is a struct, array or slice and any of its elements is a pointer to something that might be mutating, prefer a pointer receiver, as it will make the intention clearer to the reader.
If the receiver is a small array or struct that is naturally a value type (for instance, something like the time.Time type), with no mutable fields and no pointers, or is just a simple basic type such as int or string, a value receiver makes sense. A value receiver can reduce the amount of garbage that can be generated; if a value is passed to a value method, an on-stack copy can be used instead of allocating on the heap. (The compiler tries to be smart about avoiding this allocation, but it can't always succeed.) Don't choose a value receiver type for this reason without profiling first.
Don't mix receiver types. Choose either pointers or struct types for all available methods.
Finally, when in doubt, use a pointer receiver.

KILL Interfaces

Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values. The implementing package should return concrete (usually pointer or struct) types: that way, new methods can be added to implementations without requiring extensive refactoring.

Footnotes

I also might use https://github.com/golang/go/wiki/CodeReview

One consequence of the semicolon insertion rules is that you cannot put the opening brace of a control structure ( if, for, switch, or select) on the next line. If you do, a semicolon will be inserted before the brace, which could cause unwanted effects. Write them like this

if i < f() {
g()
}

not like this

if i < f() // wrong!
{ // wrong!
g()
}

The Go language

Sun, 09 Jan 2022 00:00:00 +0000

The Go language

#The Go Programming Language

[2026-03-18 Wed 07:18] Important note

This page was a personal note, content is not original. I'm getting it out of the archive only a the historical purpose.

Misc

Notes

Reading from a nil channel would result in blocking forever.
Writing to a nil map will cause a panic.
Ranging over a nil slice will result in 0 iterations.
First is a type alias. Second is a new type.
```
type MyInt int
type YourInt = int
```
iota resets per const block. When you manually assign (C = 5), it doesn’t stop iota from incrementing in the background.
byte is an alias for uint8. rune is an alias for int32 (Unicode code point). string is a read-only slice of bytes, UTF-8 encoded. Iterating a string with for range gives runes, not bytes. But indexing a string with [i] gives bytes.

Here:

for i := 0; i < 3; i++ {
 defer func() { println(i) }()
}

This prints 3 3 3. Because i is captured by reference not by value.

defer might not be always useful inside a loop:
Go will try to store values in the stack, however, for long-lived variables, they will be stored in the heap. https://youtu.be/US3TGA-Dpqo?si=I6Hz_QN4oKU66T42&t=236
Closures in Go are lexically scoped. This means that any variables referenced within the closure from the "outer" scope are not a copy but are in fact a reference. A for loop actually reuses the same variable multiple times, so you're introducing a race condition between the read/write of the s variable. In general, it is a best practice to pass in any arguments you want so that you don't have references.

Closures capture variables, not values:

 funcs := []func(){}
 for i := 0; i < 3; i++ {
 funcs = append(funcs, func() { println(i) })
 }
 for _, f := range funcs {
 f()
 }

However; proposal #60078 changed loop variables to be per-iteration instead of per-loop.

https://youtu.be/K1hwpNnCJgY?si=bpv9n89CFbfF6m_o You need to keep locking/unlocking in the same order.
Do not forget the decision tree for using primitives vs. channels.

cond. Observe the example:

package main

import (
"fmt"
"sync"
"time"
)

type JobQueue struct {
mu sync.Mutex
jobs []string
cond *sync.Cond
}

func NewJobQueue() *JobQueue {
q := &JobQueue{}
q.cond = sync.NewCond(&q.mu)
return q
}

func (q *JobQueue) Add(job string) {
q.mu.Lock()
defer q.mu.Unlock()

q.jobs = append(q.jobs, job)
q.cond.Signal() // wake up one waiting worker
}

func (q *JobQueue) Get() string {
q.mu.Lock()
defer q.mu.Unlock()

// Wait until a job becomes available
for len(q.jobs) == 0 {
q.cond.Wait()
}
job := q.jobs[0]
q.jobs = q.jobs[1:]
return job
}

func main() {
q := NewJobQueue()

// worker
go func() {
for {
 job := q.Get()
 fmt.Println("Processing:", job)
 time.Sleep(time.Second)
}
}()

// producer
for i := 1; i <= 5; i++ {
time.Sleep(time.Millisecond * 500)
q.Add(fmt.Sprintf("job-%d", i))
}
}

`omitempty`

If you’ve worked with Go for sometime, you have probably encountered the omitempty tag, when trying to encode a struct to JSON.

When using Go to build web applications, or HTTP servers, there will eventually come a time when we need to encode some data as JSON. The problem here is that the JSON representation does not exactly match the way Go handles data.

One key difference, is that in a struct, there are always clearly defined fields, while in JSON there are not. For example, consider describing a dog as a struct in Go:

type Dog struct {
 Breed string
 WeightKg int
}

Now, if we were to initialize, encode to JSON, and print a sample dog :

func main() {
 d := Dog{
 Breed: "dalmation",
 WeightKg: 45,
 }
 b, _ := json.Marshal(d)
 fmt.Println(string(b))
}

We would get the output: {"Breed":"dalmation","WeightKg":45}

Now, a dog for whom we do not have the weight, would be slightly awkward to deal with:

func main() {
 d := Dog{
 Breed: "pug",
 }
 b, _ := json.Marshal(d)
 fmt.Println(string(b))
}

This prints {"Breed":"pug","WeightKg":0}, even though the weight of of pug was unknown. A better option would be to print "WeightKg":null, or to not have the WeightKg key at all.

This is where the omitempty tag helps us. Let’s add the omitempty tag to our Dog struct:

type Dog struct {
 Breed string
 // The first comma below is to separate the name tag from the omitempty tag
 WeightKg int `json:",omitempty"`
}

Now, if WeightKg is set to it’s default value (which is 0 for the int type), the key itself will be omitted from the JSON object.

The same will happen if a string is empty "", or if a pointer is nil, or if a slice has zero elements in it.

In cases where an empty value does not exist, omitempty is of no use. An embedded struct, for example, does not have an empty value:

import (
 "encoding/json"
 "fmt"
)

type dimension struct {
 Height int
 Width int
 }

type Dog struct {
 Breed string
 WeightKg int
 Size dimension `json:",omitempty"`
}

func main() {
 d := Dog{
 Breed: "pug",
 }
 b, _ := json.Marshal(d)
 fmt.Println(string(b))
}

{"Breed":"pug","WeightKg":0,"Size":{"Height":0,"Width":0}}

In this case, even though we never set the value of the Size attribute, and set its omitempty tag, it still appears in the output. This is because structs do not have any empty value in Go. To solve this, use a struct pointer instead :

type Dog struct {
 Breed string
 WeightKg int
 // Now `Size` is a pointer to a `dimension` instance
 Size *dimension `json:",omitempty"`
}

Custom Sort

To sort a slice in reverse order, you can use the Reverse() function along with StringSlice, IntSlice, and Float64Slice types. These types implement the Interface for comparision and swap defined in the sort package.

The Reverse() function returns the reverse order of data. Let’s look at an example of sorting a slice of strings, integers, and floats in reverse order:

package main

import (
 "fmt"
 "sort"
)

func main() {
 // Sorting a slice of Strings
 strs := []string{"quick", "brown", "fox", "jumps"}
 sort.Sort(sort.Reverse(sort.StringSlice(strs)))
 fmt.Println("Sorted strings in reverse order: ", strs)

 // Sorting a slice of Integers
 ints := []int{56, 19, 78, 67, 14, 25}
 sort.Sort(sort.Reverse(sort.IntSlice(ints)))
 fmt.Println("Sorted integers in reverse order: ", ints)

 // Sorting a slice of Floats
 floats := []float64{176.8, 19.5, 20.8, 57.4}
 sort.Sort(sort.Reverse(sort.Float64Slice(floats)))
 fmt.Println("Sorted floats in reverse order: ", floats)
}

Many times, you would want to sort a collection by something other than its natural order. For example, you would want to sort a slice of strings by their length, or you would want to sort a slice of users by their age.

For these usecases, you can use the Slice() and SliceStable() functions provided by the sort package. These are higher order functions that accept a less function as an argument:

package main

import (
 "fmt"
 "sort"
)

func main() {
 // Sorting a slice of strings by length
 strs := []string{"United States", "India", "France", "United Kingdom", "Spain"}
 sort.Slice(strs, func(i, j int) bool {
 return len(strs[i]) < len(strs[j])
 })
 fmt.Println("Sorted strings by length: ", strs)

 // Stable sort
 sort.SliceStable(strs, func(i, j int) bool {
 return len(strs[i]) < len(strs[j])
 })
 fmt.Println("[Stable] Sorted strings by length: ", strs)

 // Sorting a slice of strings in the reverse order of length
 sort.SliceStable(strs, func(i, j int) bool {
 return len(strs[j]) < len(strs[i])
 })
 fmt.Println("[Stable] Sorted strings by reverse order of length: ", strs)
}

Integer Values

uint8 : 0 to 255
uint16 : 0 to 65535
uint32 : 0 to 4294967295
uint64 : 0 to 18446744073709551615
int8 : -128 to 127
int16 : -32768 to 32767
int32 : -2147483648 to 2147483647
int64 : -9223372036854775808 to 9223372036854775807

Check if file exists

if _, err := os.Stat("/path/to/whatever"); errors.Is(err, os.ErrNotExist) {
 // path/to/whatever does not exist
}

Example for flag

package main

import (
 "flag"
 "fmt"
)

func main() {

 wordPtr := flag.String("word", "foo", "a string")

 numbPtr := flag.Int("numb", 42, "an int")
 forkPtr := flag.Bool("fork", false, "a bool")

 var svar string
 flag.StringVar(&svar, "svar", "bar", "a string var")

 flag.Parse()

 fmt.Println("word:", *wordPtr)
 fmt.Println("numb:", *numbPtr)
 fmt.Println("fork:", *forkPtr)
 fmt.Println("svar:", svar)
 fmt.Println("tail:", flag.Args())
}

Properly print errors

TL;DR; Neither. Use %w in 99.99% of cases. In the other 0.001% of cases, %v and
%s probably "should" behave the same, except when the error value is nil, but
there are no guarantees. The friendlier output of %v for nil errors may be
reason to prefer %v (see below).

From https://stackoverflow.com/a/61287626

YouTube Channels

Old

These are notes I wrote when I was still learning Go.

Introduction

Go programming language notes. Based on Adam Freeman's Pro Go, some https://go.dev/blog/ articles, and other online resources.

[basics] get-go

Open a command prompt, navigate to a convenient location, and create a folder named partyinvites. Navigate to the partyinvites folder and run the command shown in Listing 1-2 to start a new Go project.

go mod init partyinvites

The go command is used for almost every development task. This command creates a file named go.mod, which is used to keep track of the packages a project depends on and can also be used to publish the project, if required.

Go code files have a .go extension. Use your chosen editor to create a file named main.go in the partyinvites folder with the contents shown in Listing 1-3. If you are using Visual Studio Code and this is your first time editing a Go file, then you will be prompted to install the extensions that support the Go language.

package main
import "fmt"
func main() {
 fmt.Println("TODO: add some features")
}

TODO: add some features

The syntax of Go will be familiar if you have used any C or C-like language, such as C# or Java. I describe the Go language in depth in this book, but you can discern a lot just by looking at the keywords and structure of the code.

Features are grouped into packages, which is why there is a package statement in the previous block. Dependencies on packages are made using an import statement, which allows the features they use to be accessed in a code file. Statements are grouped in functions, which are defined with the func keyword. There is one function in the block which is named main. This is the entry point for the application, meaning that this is the point at which execution will begin when the application is compiled and run.

Even though the details may not be familiar, the purpose of the code in the block is easy to figure out: when the application is executed, it will write out a simple message. Run the command shown in the partyinvites folder to compile and execute the project. (Notice that there is a period after the word run in this command.)

go run .

The go run command is useful during development because it performs the compilation and execution tasks in one step. The application produces the following output:

TODO: add some features

Define a Data Type

The next step is to create a custom data type that will represent the RSVP responses, as shown:

type Rsvp struct {
 Name, Email, Phone string
 WillAttend bool
}

Go allows custom types to be defined and given a name using the type keyword. creates a struct data type named Rsvp. Structs allow a set of related values to be grouped together. The Rsvp struct defines four fields, each of which has a name and a data type. The data types used by the Rsvp fields are string and bool, which are the built-in types for representing a string of characters and Boolean values.

Next, I need to collect Rsvp values together. Later, I explain how to use a database in a Go application, but for this chapter, it will be enough to store the responses in memory, which means that responses will be lost when the application is stopped.

Go has built-in support for fixed-length arrays, variable-length arrays (known as slices), and maps that contain key-value pairs. the following block creates a slice, which is a good choice when the number of values that will be stored isn’t known in advance.

package main
import "fmt"
type Rsvp struct {
 Name, Email, Phone string
 WillAttend bool
}
var responses = make([]*Rsvp, 0, 10)
func main() {
 fmt.Println("TODO: add some features");
}

TODO: add some features

This new statement relies on several Go features, which are most readily understood by starting at the end of the statement and working backwards. Go provides built-in functions for performing common operations on arrays, slices, and maps. One of those functions is make, which is used in to initialize a new slice. The last two arguments to the make function are the initial size and the initial capacity.

I specified zero for the size argument create an empty slice. Slices are resized automatically as new items are added, and the initial capacity determines how many items can be added before the slice has to be resized. In this case, ten items can be added to the slice before it has to be resized.

The square brackets, [], denote a slice. The asterisk, *, denotes a pointer. The Rsvp part of the type denotes the struct type defined in Listing 1-6. Put together, []*Rsvp denotes a slice of pointers to instances of the Rsvp struct.

You may have flinched at the term pointer if you have arrived at Go from C# or Java, which do not allow pointers to be used directly. But you can relax because Go doesn’t allow the types of operations on pointers that can get a developer into trouble. The use of pointers in Go determines only whether a value is copied when it is used. By specifying that my slice will contain pointers, I am telling Go not to create copies of my Rsvp values when I add them to the slice.

The var keyword indicates that I am defining a new variable, which is given the name responses. The equal sign, =, is the Go assignment operator and sets the value of the responses variable to the newly created slice. I don’t have to specify the type of the responses variable because the Go compiler will infer it from the value that is assigned to it.

Using Go Tools

The go command provides access to all the features needed to compile and execute Go code and is used throughout this book. The argument used with the go command specifies the operation that will be performed, such as the run argument which compiles and executes Go source code. The Go command supports a large number of arguments; the following table describes the most useful ones

Argument	Description
`build`	The go build command compiles the source code in the current directory and generates an executable file, as described in the “Compiling and Running Source Code” section.
`clean`	The go clean command removes the output produced by the go build command, including the executable and any temporary files that were created during the build, as described in the “Compiling and Running Source Code” section.
`doc`	The go doc command generates documentation from source code. See the “Linting Go Code” section for a simple example.
`fmt`	The go fmt command ensures consistent indentation and alignment in source code files, as described in the “Formatting Go Code” section.
`get`	The go get command downloads and installs external packages
`install`	The go install command downloads packages and is usually used to install tool packages
`help`	The go help command displays help information for other Go features
`test`	The go test command executes unit tests
`version`	The go version command writes out the Go version number.
`vet`	The go vet command detects common problems in Go code

Creating a Go Project

Go projects don’t have an elaborate structure and are quick to set up. Open a new command prompt and create a folder named tools in a convenient location. Add a file named main.go to the tools folder with the content shown:

package main
import "fmt"
func main() {
 fmt.Println("Hello, Go")
}

Hello, Go

The first statement is the package declaration. Packages are used to group related features, and every code file has to declare the package to which its contents belong. The package declaration uses the package keyword, followed by the name of the package.

The next statement is the import statement, which is used to declare dependencies on other packages. The import keyword is followed by the name of the package, which is enclosed in double quotes, as shown. The import statement specifies a package named fmt, which is the built-in Go package for reading and writing formatted strings. Check all the built-in packages here: https://pkg.go.dev/std

The remaining statements in the main.go file define a function named main. When you define a function named main in a package named main, you create an entry point, which is where execution begins in a command-line application

Semicolons and Errors in Go Code

You may have noticed that I didn't append a semicolon in the previous code. Go has an unusual approach to semicolons: they are required to terminate code statements, but they are not required in source code files. Instead, the Go build tools figure out where the semicolons need to go as they process files, acting as though they had been added by the developer.

The result is that semicolons can be used in Go source code files but are not required and are conventionally omitted.

Some oddities arise if you don’t follow the expected Go code style. For example, you will receive compiler errors if you attempt to put the opening brace for a function or for loop on the next line, like this:

package main
import "fmt"
func main() {
 fmt.Println("Hello, Go")
}

Hello, Go

The errors report an unexpected semicolon and a missing function body. This is because the Go tools have automatically inserted a semicolon like this:

package main
import "fmt"
func main() {
 fmt.Println("Hello, Go")
}

Hello, Go

The error messages make more sense when you understand why they arise, although it can be hard to adjust to the expected code format if this is your preferred brace placement.

I have tried to follow the no-semicolon convention throughout this book, but I have been writing code in languages that require semicolons for decades, so you may find the occasional example where I have added semicolons purely by habit. The go fmt command will remove semicolons and adjust other formatting issues.

Defining a Module

The previous section demonstrated that you can get `tarted just by creating a code file, but a more common approach is to create a Go module, which is the conventional first step when starting a new project. Creating a Go module allows a project to easily consume third-party packages and can simplify the build process.

go mod init tool

This command adds a file named go.mod to the tools folder. The reason that most projects start with the go mod init command is that it simplifies the build process. Instead of specifying a particular code file, the project can be built and executed using a period, indicating the project in the current directory.

Linting Go Code

A linter is a tool that checks code files using a set of rules that describe problems that cause confusion, produce unexpected results, or reduce the readability of the code. The most widely used linter for Go is called golint, which applies rules taken from two sources. The first is the Effective Go document produced by Google (https://golang.org/doc/effective_go.html), which provides tips for writing clear and concise Go code. The second source is a collection of comments from code reviews (https://github.com/golang/go/wiki/CodeReviewComments).

The problem with golint is that it provides no configuration options and will always apply all the rules, which can result in warnings you care about being lost in a long list of warnings for rules you don’t care about. I prefer to use the revive linter package, which is a direct replacement for golint but with support for controlling which rules are applied. To install the revive package, open a new command prompt and run the command shown:

go install github.com/mgechev/revive@latest

On Linting

Linters can be a powerful tool for good, especially in a development team with mixed levels of skill and experience. Linters can detect common problems and subtle errors that lead to unexpected behavior or long-term maintenance issues. I like this kind of linting, and I like to run my code through the linting process after I have completed a major application feature or before I commit my code into version control.

But linters can also be a tool of division and strife when rules are used to enforce one developer’s personal preferences across an entire team. This is usually done under the banner of being “opinionated.” The logic is that developers spend too much time arguing about different coding styles, and everyone is better off being forced to write in the same way.

My experience is that developers will just find something else to argue about and that forcing a code style is often just an excuse to make one person’s preferences mandatory for an entire development team.

My advice is to use linting sparingly and focus on the issues that will cause real problems. Give individual developers the freedom to express themselves naturally and focus only on issues that have a discernible impact on the project. This is counter to the opinionated ethos of Go, but my view is that productivity is not achieved by slavishly enforcing arbitrary rules, however well-intentioned they may be.

Using the Linter

The main.go file is so simple that it doesn’t have any problems for the linter to highlight. Add the following statements, which are legal Go code that does not comply with the rules applied by the linter.

package main

import "fmt"

func main() {
 PrintHello()
 for i := 0; i < 5; i++ {
 PrintNumber(i)
 }
}

func PrintHello() {
 fmt.Print("Hello, Go")
}

func PrintNumber(number int) {
 fmt.Print(number)
}

Hello, Go01234

main.go:12:1: exported function PrintHello should have comment or be unexported
main.go:16:1: exported function PrintNumber should have comment or be unexported

functions whose names start with an uppercase letter are said to be exported and available for use outside of the package in which they are defined. The convention for exported functions is to provide a descriptive comment. The linter has flagged the fact that no comments exist for the PrintHello and PrintNumber functions.

package main

import "fmt"

func main() {
 PrintHello()
 for i := 0; i < 5; i++ {
 PrintNumber(i)
 }
}

// PrintHello Does staff
func PrintHello() {
 fmt.Print("Hello, Go")
}

// PrintNumber does staff
func PrintNumber(number int) {
 fmt.Print(number)
}

Hello, Go01234

Disabling Linter Rules

The revive package can be configured using comments in code files, disabling one or more rules for sections of code. I have used comments to disable the rule that causes the warning for the PrintNumber function.

package main

import "fmt"

func main() {
 PrintHello()
 for i := 0; i < 5; i++ {
 PrintNumber(i)
 }
}

// revive:disable:exported
func PrintHello() {
 fmt.Print("Hello, Go")
}

// revive:enable:exported
func PrintNumber(number int) {
 fmt.Print(number)
}

Hello, Go01234

The syntax required to control the linter is revive, followed by a colon, enable or disable, and optionally another colon and the name of a linter rule. So, for example, the revive:disable:exported comment prevents the linter from enforcing a rule named exported, which is the rule that has been generating warnings. The revive:enable:exported comment enables the rule so that it will be applied to subsequent statements in the code file.

Using code comments is helpful when you want to suppress warnings for a specific region of code but still apply the rule elsewhere in the project. If you don’t want to apply a rule at all, then you can use a TOML- format configuration file. Add a file named revive.toml to the tools folder with the content shown:

ignoreGeneratedHeader = false
severity = "warning"
confidence = 0.8
errorCode = 0
warningCode = 0
[rule.blank-imports]
[rule.context-as-argument]
[rule.context-keys-type]
[rule.dot-imports]
[rule.error-return]
[rule.error-strings]
[rule.error-naming]
#[rule.exported]
[rule.if-return]
[rule.increment-decrement]
[rule.var-naming]
[rule.var-declaration]
[rule.package-comments]
[rule.range]
[rule.receiver-naming]
[rule.time-naming]
[rule.unexported-return]
[rule.indent-error-flow]
[rule.errorf]

This is the default revive configuration described at https://github.com/mgechev/revive#recommended-configuration, except that I have put a # character before the entry that enables the exported rule.

Fixing Common Problems in Go

The go vet command identifies statements likely to be mistakes. Unlike a linter, which will often focus on style issues, the go vet command finds code that compiles but that probably won’t do what the developer intended.

I like the go vet command because it spots errors that other tools miss, although the analyzers don’t spot every mistake and will sometimes highlight code that isn’t a problem.

Look at the following example:

package main

import "fmt"

func main() {
 PrintHello()
 for i := 0; i < 5; i++ {
 i = i
 PrintNumber(i)
 }
}

func PrintHello() {
 fmt.Print("Hello, Go")
}

func PrintNumber(number int) {
 fmt.Print(number)
}

Hello, Go01234

The new statement assigns the variable i to itself, which is allowed by the Go compiler but is likely to be a mistake. To analyze the code, use the command prompt to run the command:

go vet main.go

# party
.\main.go:8:3: self-assignment of i to i

The warnings produced by the go vet command specify the location in the code where a problem has been detected and provide a description of the issue.

The go vet command applies multiple analyzers to code, and you can see the list of analyzers at https://golang.org/cmd/vet. You can select individual analyzers to enable or disable, but it can be difficult to know which analyzer has generated a specific message. To figure out which analyzer is responsible for a warning, run the command:

go vet -json .

# party
{
 "party": {
 "assign": [
 {
 "posn": "E:\\leet\\go\\DummyPrograms\\main.go:8:3",
 "message": "self-assignment of i to i"
 }
 ]
 }
}

Types, Values, Pointers

The folloing table puts the basic Go features in context.

Problem	Solution
Use a value directly	Use a literal value
Define a constant	Use the `const` keyword
Define a constant that can ve converted to a related data type	Create an untyped constant
Define a variable	Use the var keyword or the short declaration syntax
Prevent compiler errors for an unused variable	Use the blank identifier
Define a pointer	User the address operator
Follow a pointer	Use an asterisk with the pointer variable name

I've created this new main file:

package main

import (
 "fmt"
 "math/rand"
)

func main() {
 fmt.Println(rand.Int())
}

The code in the main.go file will be compiled and executed, producing the following output:

5577006791947779410

The output from the code will always be the same value.

Basic Data Types

Go provides a set of basic data types, which are described in the table. These types are the foundation of Go development, and many of the characteristics of these types will be familiar from other languages.

Name	Description
`int`	This type represents a whole number, which can be positive or negative. The int type size is platform-dependent and will be either 32 or 64 bits. There are also integer types that have a specific size, such as int8, int16, int32, and int64, but the int type should be used unless you need a specific size.
`uint`	This type represents a positive whole number. The uint type size is platform- dependent and will be either 32 or 64 bits. There are also unsigned integer types that have a specific size, such as uint8, uint16, uint32, and uint64, but the uint type should be used unless you need a specific size.
`byte`	This type is an alias for uint8 and is typically used to represent a byte of data.
`float32, float64`	These types represent numbers with a fraction. These types allocate 32 or 64 bits to store the value.
`complex64, complex128`	These types represent numbers that have real and imaginary components. These types allocate 64 or 128 bits to store the value.
`bool`	This type represents a Boolean truth with the values true and false.
`string`	This type represents a sequence of characters
`rune`	This type represents a single Unicode code point. Unicode is complicated, but—loosely—this is the representation of a single character. The rune type is an alias for int32.

Constants are names for specific values, which allows them to be used repeatedly and consistently. There are two ways to define constants in Go: typed constants and untyped constants. This is an example of typed constants:

package main
import (
 "fmt"
 //"math/rand"
)
func main() {
 const price float32 = 275.00
 const tax float32 = 27.50
 const quantity int = 2
 fmt.Println("Total:", quantity * (price + tax))
}

The difference between typed and untyped constants is that, and since go has a very strict rules about type conversions, untyped will have some kind of conversions. The above code should gives the following error:

.\main.go:12:26: invalid operation: quantity * (price + tax) (mismatched types int and float32)

package main
import (
    "fmt"
    //"math/rand"
)
func main() {
    const price float32 = 275.00
    const tax float32 = 27.50
    const quantity = 2
    fmt.Println("Total:", quantity * (price + tax))
}

Omitting the type when defining the quantity constant tells the Go compiler that it should be more flexible about the constant’s type. When the expression passed to the fmt.Println function is evaluated, the Go compiler will convert the quantity value to a float32. Compile and execute the code, and you will receive the following output:

Total: 605

Untyped constants will be converted only if the value can be represented in the target type. In practice, this means you can mix untyped integer and floating-point numeric values, but conversions between other data types must be done explicitly.

package main
import (
    "fmt"
    //"math/rand"
)
func main() {
    const price, tax float32 = 275, 27.50
    const quantity, inStock = 2, true
    fmt.Println("Total:", quantity * (price + tax))
    fmt.Println("In stock: ", inStock)
}

The const keyword is followed by a comma-separated list of names, an equal sign, and a comma separated list of values.

Untyped constants may seem like an odd feature, but they make working with Go a lot easier, and you will find yourself relying on this feature, often without realizing, because literal values are untyped constants, which means that you can use literal values in expressions and rely on the compiler to deal with mismatched types, as shown:

package main
import (
    "fmt"
    //"math/rand"
)
func main() {
    const price, tax float32 = 275, 27.50
    const quantity, inStock = 2, true
    fmt.Println("Total:", 2 * quantity * (price + tax))
    fmt.Println("In stock: ", inStock)
}

Variables

Variables are defined using the var keyword, and, unlike constants, the value assigned to a variable can be changed, as shown:

package main
import "fmt"
func main() {
    var price float32 = 275.00
    var tax float32 = 27.50
    fmt.Println(price + tax)
    price = 300
    fmt.Println(price + tax)
}

Variables are declared using the var keyword, a name, a type, and a value assignment, as illustrated:

package main

import "fmt"
func main() {
    var price float32 = 275.00
    var tax float32 = 27.50
    fmt.Println(price + tax)
    price = 300
    fmt.Println(price + tax)
}

The Go compiler can infer the type of variables based on the initial value, which allows the type to be omitted:

package main
import "fmt"
func main() {
    var price = 275.00
    var price2 = price
    fmt.Println(price)
    fmt.Println(price2)
}

Short Variable Declaration Syntax

The short variable declaration provides a shorthand for declaring variables, as shown:

package main
import "fmt"
func main() {
    price := 275.00
    fmt.Println(price)
}

Multiple variables can be defined with a single statement by creating comma-separated lists of names and values, as shown:

package main
import "fmt"
func main() {
    price, tax, inStock := 275.00, 27.50, true
    fmt.Println("Total:", price + tax)
    fmt.Println("In stock:", inStock)
}

Go doesn’t usually allow variables to be redefined but makes a limited exception when the short syntax is used. To demonstrate the default behavior, the following block uses the var keyword to define a variable that has the same name as one that already exists within the same function

package main
import "fmt"
func main() {
    price, tax, inStock := 275.00, 27.50, true
    fmt.Println("Total:", price + tax)
    fmt.Println("In stock:", inStock)
    var price2, tax = 200.00, 25.00
    fmt.Println("Total 2:", price2 + tax)
}

This gives:

.\main.go:10:17: tax redeclared in this block

However, redefining a variable is allowed if the short syntax is used, as shown as long as at least one of the other variables being defined doesn’t already exist and the type of the variable doesn’t change.

package main
import "fmt"
func main() {
    price, tax, inStock := 275.00, 27.50, true
    fmt.Println("Total:", price + tax)
    fmt.Println("In stock:", inStock)
    price2, tax := 200.00, 25.00
    fmt.Println("Total 2:", price2 + tax)
}

Blank Declaration

It is illegal in Go to define a variable and not use it:

  price, tax, inStock, discount := 275.00, 27.50, true, true
    var salesPerson = "Alice"
    fmt.Println("Total:", price + tax)
    fmt.Println("In stock:", inStock)

.\main.go:6:26: discount declared but not used
.\main.go:7:9: salesPerson declared but not used

One way to resolve this problem is to remove the unused variables, but this isn’t always possible. For these situations, Go provides the blank identifier, which is used to denote a value that won’t be used, as shown:

package main
import "fmt"
func main() {
    price, tax, inStock, _ := 275.00, 27.50, true, true
    var _ = "Alice"
    fmt.Println("Total:", price + tax)
    fmt.Println("In stock:", inStock)
}

It can be also used to ignore function return values:

package main

import (
 "fmt"
)

func main() {
 price4, _, _ := f()
 fmt.Println(price4)
}

func f() (int, int, int) {
 return 42, 53, 5
}

Pointers

Pointers are often misunderstood, especially if you have come to Go from a language such as Java or C#, where pointers are used behind the scenes but carefully hidden from the developer. To understand how pointers work, the best place to start is understanding what Go does when pointers are not used, as shown:

package main
import "fmt"
func main() {
    first := 100
    second := first;
    first++
    fmt.Println("First:", first)
    fmt.Println("Second:", second)
}

The previous code creates two variables. The value of the variable named first is set using a string literal. The value of the variable named second is set using the first value.

Go copies the current value of first when creating second, after which these variables are independent of one another. Each variable is a reference to a separate memory location where its value is stored

When I use the ++ operator to increment the first variable, Go reads the value at the memory location associated with the variable, increments the value, and stores it at the same memory location. The value assigned to the second variable remains the same because the change affects only the value stored by the first variable.

Pointers have a bad reputation because of pointer arithmetic. Pointers store memory locations as numeric values, which means they can be manipulated using arithmetic operators, providing access to other memory locations. You can start with a location that points to an int value, for example; increment the value by the number of bits used to store an int; and read the adjacent value. This can be useful but can cause unexpected results, such as trying to access the wrong location or a location outside of the memory allocated to the program.

Some Operators

Go doesn’t allow types to be mixed in operations and will not automatically convert types, except in the case of untyped constants. To show how the compiler responds to mixed data types, Following contains a statement that applies the addition operator to values of different types.

package main
import (
    "fmt"
//    "math"
)
func main() {
    kayak := 275
    soccerBall := 19.50
    total := kayak + soccerBall
    fmt.Println(total)
}

The literal values used to define the kayak and soccerBall variables result in an int value and a float64 value, which are then used in the addition operation to set the value of the total variable. When the code is compiled, the following error will be reported:

.\main.go:13:20: invalid operation: kayak + soccerBall (mismatched types int and float64)

For such a simple example, I could simply change the literal value used to initialize the kayak variable to 275.00, which would produce a float64 variable. But types are rarely as easy to change in real projects, which is why Go provides the features described in the sections that follow.

package main

import (
 "fmt"
 //math"
)

func main() {
 kayak := 275
 soccerBall := 19.50
 total := float64(kayak) + soccerBall
 fmt.Println(total)
}

Explicit conversions can be used only when the value can be represented in the target type. This means you can convert between numeric types and between strings and runes, but other combinations, such as converting int values to bool values, are not supported.

Flow Control

The flow of execution in a Go application is simple to understand, especially when the application is as simple as the example. The statements defined in the special main function, known as the application’s entry point, are executed in the order in which they are defined. Once these statements have all been executed, the application exits. Example:

import "fmt"
func main() {
 kayakPrice := 275.00
 if kayakPrice > 100 {
 fmt.Println("Price is greater than 100")
 }
}

Price is greater than 100

Go allows an if statement to use an initialization statement, which is executed before the if statement’s expression is evaluated. The initialization statement is restricted to a Go simple statement, which means—in broad terms—that the statement can define a new variable, assign a new value to an existing variable, or invoke a function

import (
 "fmt"
 "strconv"
)
func main() {
 priceString := "275"
 if kayakPrice, err := strconv.Atoi(priceString); err == nil {
 fmt.Println("Price:", kayakPrice)
 } else {
 fmt.Println("Error:", err)
 }
}

Price: 275

Loops

Three-component loop

sum := 0
for i := 1; i < 5; i++ {
 sum += i
}
fmt.Println(sum) // 10 (1+2+3+4)

While Loop

n := 1
for n < 5 {
 n *= 2
}
fmt.Println(n) // 8 (1*2*2*2)

For-each range loop

strings := []string{"hello", "world"}
for i, s := range strings {
 fmt.Println(i, s)
}

Collection Types

Go arrays are a fixed length and contain elements of a single type, which are accessed by index,

package main
import "fmt"
func main() {
    var names [3]string
    names[0] = "Kayak"
    names[1] = "Lifejacket"
    names[2] = "Paddle"
    fmt.Println(names)
}

Array types include the size of the array in square brackets, followed by the type of element that the array will contain, known as the underlying type.The length and element type of an array cannot be changed, and the array length must be specified as a constant. (Slices store a variable number of values.)

Arrays can be defined and populated in a single statement using the literal syntax:

package main
import "fmt"
func main() {
    names := [3]string { "Kayak", "Lifejacket", "Paddle" }
    fmt.Println(names)
}

When using the literal syntax, the compiler can infer the length of the array from the list of elements, like this:

names := [...]string { "Kayak", "Lifejacket", "Paddle" }

The explicit length is replaced with three periods (…), which tells the compiler to determine the array length from the literal values. The type of the names variable is still [3]string, and the only difference is that you can add or remove literal values without also having to update the explicitly specified length. I don’t use this feature for the examples in this book because I want to make the types used as clear as possible.

Arrays are enumerated using the for and range keywords:

package main

import (
 "fmt"
)

func main() {
 names := [2][2]string{{"QW", "wQ"}, {"WQ", "WQ"}}
 for i, v := range names {
 fmt.Println("I", i)
 fmt.Println("V", v)
 }
}

Slices

The best way to think of slices is as a variable-length array because they are useful when you don’t know how many values you need to store or when the number changes over time. One way to define a slice is to use the built-in make function

package main
import "fmt"
func main() {
    names := make([]string, 3)
    names[0] = "Kayak"
    names[1] = "Lifejacket"
    names[2] = "Paddle"
    fmt.Println(names)
}

The slice type in this example is []string, which denotes a slice that holds string values. The length is not part of the slice type because the size of slices can vary, as I demonstrate later in this section. Slices can also be created using a literal syntax

package main
import "fmt"
func main() {
    names := []string {"Kayak", "Lifejacket", "Paddle"}
    fmt.Println(names)
}

The combination of the slice type and the length is used to create an array, which acts as the data store for the slice. The slice is a data structure that contains three values: a pointer to the array, the length of the slice, and the capacity of the slice. The length of the slice is the number of elements that it can store, and the capacity is the number of elements that can be stored in the array. In this example, the length and the capacity are both 3:

package main
import "fmt"
func main() {
    names := []string {"Kayak", "Lifejacket", "Paddle"}
    names = append(names, "Hat", "Gloves")
    fmt.Println(names)
}

Creating and copying arrays can be inefficient. If you expect that you will need to append items to a slice, you can specify additional capacity when using the make function:

package main
import "fmt"
func main() {
    names := make([]string, 3, 6)
    names[0] = "Kayak"
    names[1] = "Lifejacket"
    names[2] = "Paddle"
    fmt.Println("len:", len(names))
    fmt.Println("cap:", cap(names))
}

As noted earlier, slices have a length and a capacity. The length of a slice is how many values it can currently contain, while the number of elements that can be stored in the underlying array before the slice must be resized and a new array created. The capacity will always be at least the length but can be larger if additional capacity has been allocated with the make function. The call to the make function creates a slice with a length of 3 and a capacity of 6.

Slices can be created using existing arrays, which builds on the behavior described in earlier examples and emphasizes the nature of slices as views onto arrays

package main
import "fmt"
func main() {
products := [4]string { "Shblanga", "Lifejacket", "Paddle", "Hat"}
someNames := products[2:4]
allNames := products[:]
fmt.Println("someNames:", someNames)
fmt.Println("allNames", allNames)
}

12
someNames: [Paddle Hat]
allNames [Shblanga Lifejacket Paddle Hat]

The Copy Function

package main
import "fmt"
func main() {
 products := [4]string { "Kayak", "Lifejacket", "Paddle", "Hat"}
 allNames := products[1:]
 someNames := make([]string, 2)
 copy(someNames, allNames)
 fmt.Println("someNames:", someNames)
 fmt.Println("allNames", allNames)
}

someNames: [Lifejacket Paddle]
allNames [Lifejacket Paddle Hat]

Functions

Functions are groups of statements that can be used and reused as a single action. To get started define a simple function:

package main
import "fmt"
func printPrice() {
 kayakPrice := 275.00
 kayakTax := kayakPrice * 0.2
 fmt.Println("Price:", kayakPrice, "Tax:", kayakTax)
}
func main() {
 fmt.Println("About to call function")
 printPrice()
 fmt.Println("Function complete")
}

About to call function
Price: 275 Tax: 55
Function complete

`defer`

The defer keyword is used to schedule a function call that will be performed immediately before the current function returns, as shown

package main
import "fmt"
func calcTotalPrice(products map[string]float64) (count int, total float64){
 fmt.Println("Function started")
 defer fmt.Println("First defer call")
 count = len(products)
 for _, price := range products {
 total += price
 }
 defer fmt.Println("Second defer call")
 fmt.Println("Function about to return")
 return
}
func main() {
 products := map[string]float64 {
 "Kayak" : 275,
 "Lifejacket": 48.95,
 }
 _, total := calcTotalPrice(products)
 fmt.Println("Total:", total)
}

Function started
Function about to return
Second defer call
First defer call
Total: 323.95

Struct

Custom data types are defined using the Go structs feature:

package main
import "fmt"
func main() {
 type Product struct {
 name, category string
 price float64
 }
 kayak := Product {
 name: "Kayak",
 category: "Watersports",
 price: 275,
 }
 fmt.Println(kayak.name, kayak.category, kayak.price)
 kayak.price = 300
 fmt.Println("Changed price:", kayak.price)
}

Kayak Watersports 275
Changed price: 300

Go doesn’t differentiate between structs and classes, in the way that other languages do. All custom data types are defined as structs, and the decision to pass them by reference or by value is made depending on whether a pointer is used. As I explained in Chapter 4, this achieves the same effect as having separate type categories but with the additional flexibility of allowing the choice to be made every time a value is used. It does, however, require more diligence from the programmer, who must think through the consequences of that choice during coding. Neither approach is better, and the results are essentially the same.

Interfaces

All the types we've looked at so far have been concrete types. A concrete type specifies the exact representation of its values and exposes the intrinsic operations of that representation, such as arithmetic for numbers, or indexing, append, and range for slices. A concrete type may also provide additional behaviors through its methods. When you have a value of a con- crete type, you know exactly what it is and what you can do with i

There is another kind of type in Go called an inferface type. An interface is an abstract type. It doesn't expose the representation or internal structure of its values, or the set of basic operations they support; it reveals only some of their methods. When you have a value of an interface type, you know nothing about what it is; you know only what it can do, or more precisely, what behaviors are provided by its methods.

Closures

https://youtu.be/US3TGA-Dpqo?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6

Packages

The first step for all the example projects in this book has been to create a module file, which was done with the command:

go mod init <name>

The original purpose of a module file was to enable code to be published so that it can be used in other projects and, potentially, by other developers. Module files are still used for this purpose, but Go has started to gain mainstream development, and as this has happened, the percentage of projects that are published has fallen. These days, the most common reason for creating a module file is that it makes it easy to install packages that have been published and has the bonus effect of allowing the use of the run command rather than having to provide the Go build tools with a list of individual files to compile.

That command created a file named go.mod in the packages folder, with the following content:

module pkg

go 1.18

The module statement specifies the name of the module, which was specified by the command in. This name is important because it is used to import features from other packages created within the same project and third-party packages, as later examples will demonstrate. The go statement specifies the version of Go that is used, which is 1.17 for this book.

Packages make it possible to add structure to a project so that related features are grouped together. Create the packages/store folder and add to it a file named product.go, with the contents shown in:

package store

type Product struct {
 Name, Category string
 price int
}

And use it in your main:

package main

import (
 "fmt"
 "packges/store"
)

func main() {
 pr := store.Product{
 Name: "o",
 Category: "fr",
 }
 fmt.Print(pr)
}

{o fr 0}

Packages can contain multiple code files, and to simplify development, access control rules and package prefixes do not apply when accessing features defined in the same package. Add a file named tax.go to the store folder with the contents shown:

package store
const defaultTaxRate float64 = 0.2
const minThreshold = 10
type taxRate struct {
    rate, threshold float64
}

func newTaxRate(rate, threshold float64) *taxRate {
    if (rate == 0) {
        rate = defaultTaxRate
    }
    if (threshold < minThreshold) {
        threshold = minThreshold
    }
    return &taxRate { rate, threshold }
}
func (taxRate *taxRate) calcTax(product *Product) float64 {
    if (product.price > taxRate.threshold) {
        return product.price + (product.price * taxRate.rate)
    }
    return product.price
}

All the features defined in the tax.go file are unexported, which means they can be used only within the store package. Notice that the calcTax method can access the price field of the Product type and that it does so without having to refer to the type as store.Product because it is in the same package:

...
func (taxRate *taxRate) calcTax(product *Product) float64 {
    if (product.price > taxRate.threshold) {
        return product.price + (product.price * taxRate.rate)
    }
    return product.price
}
...

Package Conflicts

When a package is imported, the combination of the module name and package name ensures that the package is uniquely identified. But only the package name is used when accessing the features provided by the package, which can lead to conflicts. To see how this problem arises, create the packages/fmt folder and add to it a file named formats.go with the code shown:

package fmt
import "strconv"
func ToCurrency(amount float64) string {
    return "$" + strconv.FormatFloat(amount, 'f', 2, 64)
}

This will never compile:

go run .
# packges
./main.go:5:2: fmt redeclared in this block
 ./main.go:4:2: other declaration of fmt
./main.go:5:2: imported and not used: "packges/fmt"

One way to deal with package name conflicts is to use an alias, which allows a package to be accessed using a different name, as shown:

package main
import (
    "fmt"
    "packages/store"
    currencyFmt "packages/fmt"
)
func main() {
    product := store.NewProduct("Kayak", "Watersports", 279)
    fmt.Println("Name:", product.Name)
    fmt.Println("Category:", product.Category)
    fmt.Println("Price:", currencyFmt.ToCurrency(product.Price()))
}

There is a special alias, known as the dot import, that allows a package’s features to be used without using a prefix, as shown:

import (
    "fmt"
    "packages/store"
    . "packages/fmt"
)
func main() {
    product := store.NewProduct("Kayak", "Watersports", 279)
    fmt.Println("Name:", product.Name)
    fmt.Println("Category:", product.Category)
    fmt.Println("Price:", ToCurrency(product.Price()))
}

Package Initialization

Each code file can contain an initialization function that is executed only when all packages have been loaded and all other initialization—such as defining constants and variables—has been done. The most common use for initialization functions is to perform calculations that are difficult to perform or that require duplication to perform, as shown:

package store
const defaultTaxRate float64 = 0.2
const minThreshold = 10
var categoryMaxPrices = map[string]float64 {
    "Watersports": 250 + (250 * defaultTaxRate),
    "Soccer": 150 + (150 * defaultTaxRate),
    "Chess": 50 + (50 * defaultTaxRate),
}
type taxRate struct {
    rate, threshold float64
}
func newTaxRate(rate, threshold float64) *taxRate {
    if (rate == 0) {
        rate = defaultTaxRate
    }
    if (threshold < minThreshold) {
        threshold = minThreshold
    }
    return &taxRate { rate, threshold }
}
func (taxRate *taxRate) calcTax(product *Product) (price float64) {
    if (product.price > taxRate.threshold) {
        price = product.price + (product.price * taxRate.rate)
    } else {
        price = product.price
    }
    if max, ok := categoryMaxPrices[product.Category]; ok && price > max {
        price = max
    }
    return
}

Import Package For Intialization

Go prevents packages from being imported but not used, which can be a problem if you rely on the effect of an initialization function but don’t need to use any of the features the package exports. Create the packages/ data folder and add to it a file named data.go.

package data
import "fmt"
func init() {
    fmt.Println(("data.go init function invoked"))
}
func GetData() []string {
    return []string {"Kayak", "Lifejacket", "Paddle", "Soccer Ball"}
}

The initialization function writes out a message when it is invoked for the purposes of this example. If I need the effect of the initialization function, but I don’t need to use the GetData function the package exports, then I can import the package using the blank identifier as an alias for the package name, as shown

package main
import (
    "fmt"
    "packages/store"
    . "packages/fmt"
    "packages/store/cart"
    _ "packages/data"
)
func main() {
    product := store.NewProduct("Kayak", "Watersports", 279)
    cart := cart.Cart {
        CustomerName: "Alice",
        Products: []store.Product{ *product },
    }
    fmt.Println("Name:", cart.CustomerName)
    fmt.Println("Total:",  ToCurrency(cart.GetTotal()))
}

Interface Composition

If you are used to languages such as C# or Java, then you will have created a base class and created subclasses to add more specific features. The subclasses inherit functionality from the base class, which prevents code duplication. The result is a set of classes, where the base class defines common functionality that is supplemented by more specific features in individual subclasses.

The starting point is to define a struct type and a method, which I will use to create more specific types in later examples. Create the composition/store folder and add to it a file named product.go with the content shown:

Because Go doesn’t support classes, it doesn’t support class constructors either. As I explained, a common convention is to define a constructor function whose name is New<Type>, such as NewProduct, as shown, and that allows values to be provided for all fields, even those that have not been exported. As with other code features, the capitalization of the first letter of the constructor function name determines whether it is exported outside of the package.

package store

type Product struct {
 Name, Category string
 price float64
}

func NewProduct(name, category string, price float64) *Product {
 return &Product{name, category, price}
}

func (p *Product) Price(taxRate float64) float64 {
 return p.price + (p.price * taxRate)
}

Constructor functions are only a convention, and their use is not enforced, which means that exported types can be created using the literal syntax, just as long as no values are assigned to the unexported fields. This shows the use of the constructor function and the literal syntax:

package main

import (
 "comps/store"
 "fmt"
)

func main() {
 kayak := store.NewProduct("Kayak", "Watersports", 275)
 lifejacket := &store.Product{Name: "Lifejacket", Category: "Watersports"}
 for _, p := range []*store.Product{kayak, lifejacket} {
 fmt.Println("Name:", p.Name, "Category:", p.Category, "Price:", p.Price(0.2))
 }
}

Constructors should be used whenever they are defined because they make it easier to manage changes in the way that values are created and because they ensure that fields are properly initialized. Using the literal syntax means that no value is assigned to the price field, which affects the output from the Price method. But, since Go doesn’t support enforcing the use of constructors, their use requires discipline.

Go supports composition, rather than inheritance, which is done by combining struct types. Add a file named boat.go to the store folder with the contents shown:

package store
type Boat struct {
 *Product
 Capacity int
 Motorized bool
}

KILL Concurrency

"Execution happens in some non-deterministic order", "Undefined out-of-order execution", "Non-sequential execution", "Parts of a program excute out-of-order or in partial order". All of those are valid definitions of concurrency. See Concurrency Patterns in Go

Goroutines

Go has excellent support for writing concurrent applications, using features that are simpler and more intuitive than any other language I have used. In this chapter, I describe the use of goroutines, which allow functions to be executed concurrently, and channels, through which goroutines can produce results asynchronously.

package main

import "strconv"

type Product struct {
 Name, Category string
 Price float64
}

var ProductList = []*Product{
 {"Kayak", "Watersports", 279},
 {"Lifejacket", "Watersports", 49.95},
 {"Soccer Ball", "Soccer", 19.50},
 {"Corner Flags", "Soccer", 34.95},
 {"Stadium", "Soccer", 79500},
 {"Thinking Cap", "Chess", 16},
 {"Unsteady Chair", "Chess", 75},
 {"Bling-Bling King", "Chess", 1200},
}

type ProductGroup []*Product
type ProductData = map[string]ProductGroup

var Products = make(ProductData)

func ToCurrency(val float64) string {
 return "$" + strconv.FormatFloat(val, 'f', 2, 64)
}
func init() {
 for _, p := range ProductList {
 if _, ok := Products[p.Category]; ok {
 Products[p.Category] = append(Products[p.Category], p)
 } else {
 Products[p.Category] = ProductGroup{p}
 }
 }
}

This file defines a custom type named Product, along with type aliases that I use to create a map that organizes products by category. I use the Product type in a slice and a map, and I rely on an init function, to populate the map from the contents of the slice, which is itself populated using the literal syntax. This file also contains a ToCurrency function that formats float64 values into dollar currency strings, which I will use to format the results in this chapter. Add another file called operation.go:

package main

import "fmt"

func CalcStoreTotal(data ProductData) {
 var storeTotal float64
 for category, group := range data {
 storeTotal += group.TotalPrice(category)
 }
 fmt.Println("Total:", ToCurrency(storeTotal))
}
func (group ProductGroup) TotalPrice(category string) (total float64) {
 for _, p := range group {
 total += p.Price
 }
 fmt.Println(category, "subtotal:", ToCurrency(total))
 return
}

The key building block for executing a Go program is the goroutine, which is a lightweight thread created by the Go runtime. All Go programs use at least one goroutine because this is how Go executes the code in the main function. When compiled Go code is executed, the runtime creates a goroutine that starts executing the statements in the entry point, which is the main function in the main package. Each statement in the main function is executed in the order in which they are defined. The goroutine keeps executing statements until it reaches the end of the main function, at which point the application terminates.

The goroutine executes each statement in the main function synchronously, which means that it waits for the statement to complete before moving on to the next statement. The statements in the main function can call other functions, use for loops, create values, and use all the other features. The main goroutine will work its way through the code, following its path by executing one statement at a time.

Follows adds a statement that writes out details of each product as it is processed, which will demonstrate the flow shown in the figure:

func (group ProductGroup) TotalPrice(category string) (total float64) {
 for _, p := range group {
 fmt.Printf(category, "product", p.Name)
 total += p.Price
 }
 fmt.Println(category, "subtotal:", ToCurrency(total))
 return
}

main function started
Soccer product: Soccer Ball
Soccer product: Corner Flags
Soccer product: Stadium
Soccer subtotal: $79554.45
Chess product: Thinking Cap
Chess product: Unsteady Chair
Chess product: Bling-Bling King
Chess subtotal: $1291.00
Watersports product: Kayak
Watersports product: Lifejacket
Watersports subtotal: $328.95
Total: $81174.40
main function complete

You may see different results based on the order in which keys are retrieved from the map, but what’s important is that all the products in a category are processed before execution moves onto the next category. The advantages of synchronous execution are simplicity and consistency—the behavior of synchronous code is easy to understand and predictable. The disadvantage is that it can be inefficient. Working sequentially through nine data items, as in the example, doesn’t present any issues, but most real projects have larger volumes of data or have other tasks to perform, which means that sequential execution takes too long and doesn’t produce results fast enough.

Go allows the developer to create additional goroutines, which execute code at the same time as the main goroutine. Go makes it easy to create new goroutines, as shown:

package main

import "fmt"

func CalcStoreTotal(data ProductData) {
 var storeTotal float64
 for category, group := range data {
 go group.TotalPrice(category)
 }
 fmt.Println("Total:", ToCurrency(storeTotal))
}
func (group ProductGroup) TotalPrice(category string) (total float64) {
 for _, p := range group {
 fmt.Printf(category, "product", p.Name)
 total += p.Price
 }
 fmt.Println(category, "subtotal:", ToCurrency(total))
 return
}

A goroutine is created using the go keyword followed by the function or method that should be executed asynchronously.

When the Go runtime encounters the go keyword, it creates a new goroutine and uses it to execute the specified function or method. This changes the program execution because, at any given moment, there are multiple goroutines, each of which is executing its own set of statements. These statements are executed concurrently, which just means they are being executed at the same time. In the case of the example, a goroutine is created for each call to the TotalPrice method, which means that the categories are processed concurrently.

Getting a result from a function that is being executed asynchronously can be complicated because it requires coordination between the goroutine that produces the result and the goroutine that consumes the result. To address this issue, Go provides channels, which are conduits through which data can be sent and received. I am going to introduce a channel into the example in steps:

package main

import "fmt"

func CalcStoreTotal(data ProductData) {
 var storeTotal float64
 for category, group := range data {
 var channel chan float64 = make(chan float64)
 go group.TotalPrice(category)
 }
 fmt.Println("Total:", ToCurrency(storeTotal))
}
func (group ProductGroup) TotalPrice(category string) (total float64) {
 for _, p := range group {
 fmt.Printf(category, "product", p.Name)
 total += p.Price
 }
 fmt.Println(category, "subtotal:", ToCurrency(total))
 return
}

Channels are strongly typed, which means that they will carry values of a specified type or interface. The type for a channel is the chan keyword, followed by the type the channel will carry. Channels are created using the built-in make function, specifying the channel type.

I used the full variable declaration syntax in this listing to emphasize the type, which is chan float64, meaning a channel that will carry float64 values.

The next step is to update the TotalPrice method so that it sends its result through the channel, as shown:

func (group ProductGroup) TotalPrice(category string, resultChannel chan float64)  {
    var total float64
    for _, p := range group {
        fmt.Println(category, "product:", p.Name)
        total += p.Price
        time.Sleep(time.Millisecond * 100)
    }
    fmt.Println(category, "subtotal:", ToCurrency(total))
    resultChannel <- total
}

By default, sending and receiving through a channel are blocking operations. This means a goroutine that sends a value will not execute any further statements until another goroutine receives the value from the channel. If a second goroutine sends a value, it will be blocked until the channel is cleared, causing a queue of goroutines waiting for values to be received. This happens in the other direction, too, so that goroutines that receive values will block until another goroutine sends one

package main
import (
    "fmt"
    "time"
)
func CalcStoreTotal(data ProductData) {
    var storeTotal float64
    var channel chan float64 = make(chan float64)
    for category, group := range data {
        go group.TotalPrice(category, channel)
    }
    time.Sleep(time.Second * 5)
    fmt.Println("-- Starting to receive from channel")
    for i := 0; i < len(data); i++ {
        fmt.Println("-- channel read pending")
        value :=  <- channel
        fmt.Println("-- channel read complete", value)
        storeTotal += value
        time.Sleep(time.Second)
    }
    fmt.Println("Total:", ToCurrency(storeTotal))
}
func (group ProductGroup) TotalPrice(category string, resultChannel chan float64)  {
    var total float64
    for _, p := range group {
        //fmt.Println(category, "product:", p.Name)
        total += p.Price
        time.Sleep(time.Millisecond * 100)
    }
    fmt.Println(category, "channel sending", ToCurrency(total))
    resultChannel <- total
    fmt.Println(category, "channel send complete")
}

The default channel behavior can lead to bursts of activity as goroutines do their work, followed by a long idle period waiting for messages to be received. This doesn’t have an impact on the example application because the goroutines finish once their messages are received, but in a real project goroutines often have repetitive tasks to perform, and waiting for a receiver can cause a performance bottleneck.

An alternative approach is to create a channel with a buffer, which is used to accept values from a sender and store them until a receiver becomes available. This makes sending a message a nonblocking operation, allowing a sender to pass its value to the channel and continue working without having to wait for a receiver. This is similar to Alice having an inbox on her desk. Senders come to Alice’s office and put their message into the inbox, leaving it for Alice to read when she is ready. But, if the inbox is full, then they will have to wait until she has processed some of her backlog before sending a new message.

It is possible to create bidirectional as well as uni-directional channels in golang. A channel can be created to which we can only send data, as well as a channel, can be created from which we can only receive data. This is determined by the direction of the arrow of the channel. The direction of the arrow for a channel specifies the direction of flow of data

chan :bidirectional channel (Both read and write)
chan <- :only writing to channel
<- chan :only reading from channel (input channel)

Receiving Without Blocking

The simplest use for select statements is to receive from a channel without blocking, ensuring that a goroutine won’t have to wait when the channel is empty.

package main
import (
    "fmt"
    "time"
)
// func receiveDispatches(channel <-chan DispatchNotification) {
//     for details := range channel {
//         fmt.Println("Dispatch to", details.Customer, ":", details.Quantity,
//             "x", details.Product.Name)
//     }
//     fmt.Println("Channel has been closed")
// }
func main() {
    dispatchChannel := make(chan DispatchNotification, 100)
    go DispatchOrders(chan<- DispatchNotification(dispatchChannel))
    // receiveDispatches((<-chan DispatchNotification)(dispatchChannel))
    for {
        select {
            case details, ok := <- dispatchChannel:
                 if ok {
                    fmt.Println("Dispatch to", details.Customer, ":",
                        details.Quantity, "x", details.Product.Name)
                } else {
                    fmt.Println("Channel has been closed")
                    goto alldone
                }
            default:
                fmt.Println("-- No message ready to be received")
                time.Sleep(time.Millisecond * 500)
        }
    }
    alldone: fmt.Println("All values received")
}

Error Handling

This file defines a custom type named Product, an alias for a slice of *Product values, and a slice populated using the literal syntax. I have also defined a function to format float64 values into dollar currency amounts.

package main

import "strconv"
import "fmt"

type Product struct {
 Name, Category string
 Price float64
}
type ProductSlice []*Product

var Products = ProductSlice{
 {"Kayak", "Watersports", 279},
 {"Lifejacket", "Watersports", 49.95},
 {"Soccer Ball", "Soccer", 19.50},
 {"Corner Flags", "Soccer", 34.95},
 {"Stadium", "Soccer", 79500},
 {"Thinking Cap", "Chess", 16},
 {"Unsteady Chair", "Chess", 75},
 {"Bling-Bling King", "Chess", 1200},
}

func ToCurrency(val float64) string {
 return "$" + strconv.FormatFloat(val, 'f', 2, 64)
}
func main() {
 categories := []string{"Watersports", "Chess"}
 for _, cat := range categories {
 total := Products.TotalPrice(cat)
 fmt.Println(cat, "Total:", ToCurrency(total))
 }
}
func (slice ProductSlice) TotalPrice(category string) (total float64) {
 for _, p := range slice {
 if p.Category == category {
 total += p.Price
 }
 }
 return
}

Watersports Total: $328.95
Chess Total: $1291.00

Go makes it easy to express exceptional conditions, which allows a function or method to indicate to the calling code that something has gone wrong. As an example this adds statements that produce a problematic response from the TotalPrice method

func main() {
 categories := []string{"Watersports", "Chess", "Running"}
 for _, cat := range categories {
 total := Products.TotalPrice(cat)
 fmt.Println(cat, "Total:", ToCurrency(total))
 }
}

Watersports Total: $328.95
Chess Total: $1291.00
Running Total: $0.00

KILL Go Modules

A module is a collection of Go packages stored in a file tree with a go.mod file at its root. The go.mod file defines the module’s module path, which is also the import path used for the root directory, and its dependency requirements, which are the other modules needed for a successful build. Each dependency requirement is written as a module path and a specific semantic version.

As of Go 1.11, the go command enables the use of modules when the current directory or any parent directory has a go.mod, provided the directory is outside $GOPATH/src. (Inside $GOPATH/src, for compatibility, the go command still runs in the old GOPATH mode, even if a go.mod is found. See the go command documentation for details.) Starting in Go 1.13, module mode will be the default for all development.

Creating a New Module

Create a new, empty directory somewhere outside $GOPATH/src, cd into that directory, and then create a new source file, hello.go:

package hello

func Hello() string {
 return "Hello, world."
}

Let’s write a test, too, in hello_test.go:

package hello

import "testing"

func TestHello(t *testing.T) {
 want := "Hello, world."
 if got := Hello(); got != want {
 t.Errorf("Hello() = %q, want %q", got, want)
 }
}

At this point, the directory contains a package, but not a module, because there is no go.mod file. If we were working in /home/gopher/hello and ran go test now, we’d see:

$ go test
PASS
ok _/home/gopher/hello 0.020s
$

The primary motivation for Go modules was to improve the experience of using (that is, adding a dependency on) code written by other developers.

Go Standard Library

DONE Go `fstream`

To work with files in Go, we use the os and ~ioutil~packages.

The os.Stat function returns the FileInfo structure describing the file.

Operate on Files

Checking if a File Exists

In the following example, we check if the given file exists:

package main

import (
 "errors"
 "fmt"
 "os"
)

func main() {

 _, err := os.Stat("words.txt")

 if errors.Is(err, os.ErrNotExist) {

 fmt.Println("file does not exist")
 } else {

 fmt.Println("file exists")
 }
}

file does not exist

We call the os.Stat function on the file. If the function returns the os.ErrNotExist error, the file does not exist.

Creating a File

package main

import (
 "fmt"
 "log"
 "os"
)

func main() {

 file, err := os.Create("empty.txt")

 defer file.Close()

 if err != nil {
 log.Fatal(err)
 }

 fmt.Println("file created")
}

file created

Delete a File

package main

import (
 "fmt"
 "log"
 "os"
)

func main() {

 err := os.Remove("words.txt")

 if err != nil {

 log.Fatal(err)
 }

 fmt.Println("file deleted")
}

Go File Size

package main

import (
 "fmt"
 "log"
 "os"
)

func main() {

 fInfo, err := os.Stat("words.txt")

 if err != nil {

 log.Fatal(err)
 }

 fsize := fInfo.Size()

 fmt.Printf("The file size is %d bytes\n", fsize)
}

Read File

package main

import (
 "fmt"
 "io/ioutil"
 "log"
)

func main() {

 content, err := ioutil.ReadFile("words.txt")

 if err != nil {
 log.Fatal(err)
 }

 fmt.Println(string(content))
}

List Files

package main

import (
 "fmt"
 "log"
 "os"
 "path/filepath"
)

func main() {

 var files []string

 root := "/home/janbodnar/Documents"

 err := filepath.Walk(root, func(path string, info os.FileInfo, err error) error {

 if err != nil {

 fmt.Println(err)
 return nil
 }

 if !info.IsDir() && filepath.Ext(path) == ".txt" {
 files = append(files, path)
 }

 return nil
 })

 if err != nil {
 log.Fatal(err)
 }

 for _, file := range files {
 fmt.Println(file)
 }
}

DONE String

The strings package provides a set of functions for processing strings. In the sections that follow, I describe the most useful features of the strings package and demonstrate their use.

Compare Strings

The strings packages provides comparison functions;

Function	Description
`Contains(s, substr)`	This function returns true if the string s contains substr and false if it does not.
`ContainsAny(s, substr)`	This function returns true if the string s contains any of the characters contained in the string substr.
`EqualFold(s1, s2)`	This function performs a case-insensitive comparison and returns true of strings s1 and s2 are the same.
`ContainsRune(s, rune)`	This function returns true if the string s contains a specific rune.
`HasPrefix(s, prefix)`	This function returns true if the string s begins with the string prefix.
`HasSuffix(s, suffix)`	This function returns true if the string ends with the string suffix.

Builder

type Builder struct {
 // contains filtered or unexported fields
}

A Builder is used to efficiently build a string using Write methods. It minimizes memory copying. The zero value is ready to use. Do not copy a non-zero Builder.

Example:

package main

import (
 "fmt"
 "strings"
)

func main() {
 var b strings.Builder
 for i := 3; i >= 1; i-- {
 fmt.Fprintf(&b, "%d...", i)
 }
 b.WriteString("ignition")
 fmt.Println(b.String())

}

3...2...1...ignition

Editing a String

Strings are immutable in Go, you have to convert it to runes then modify it then convert it back to a string.

func replaceAtIndex(in string, r rune, i int) string {
 out := []rune(in)
 out[i] = r
 return string(out)
}

String Mapping

package main

import (
 "fmt"
 "strings"
)

func main() {
 transform := func(r rune) rune {
 // Map uppercase A to underscore.
 if r == 'A' {
 return '_'
 }
 return r
 }

 input := "STARRY NIGHT, A PAINTING"
 fmt.Println(input)

 // Use Map() to run func on each rune.
 result := strings.Map(transform, input)
 fmt.Println(result)
}

STARRY NIGHT, A PAINTING
ST_RRY NIGHT, _ P_INTING

DONE Errors

An error is an abnormal, unexpected condition which occurs in the program. In programming, errors are often called bugs. The process of finding and resolving bugs is called debugging. Go provide tools for dealing with errors. Errors in Go are plain values. Therefore, errors can be stored in variables, passed as parameters to functions, or returned from functions.

Errors are represented using the built-in error type.

Most Go functions return an error value among its return values. (Go supports multiple return values.) It is our responsibility to check this error value. A value of nil means there is no error. By convention, the error value is the rightmost value among the returned values.

content, err := ioutil.ReadFile("thermopylae.txt")

if err != nil {
 log.Fatal(err)
}

The idiomatic way of handling errors is to check for error right after the function call.

A panic is a runtime-error that we are not prepared to handle gracefully. A panic can occur for example when we try to divide by zero or try to access non-existing array index.

A stack trace is a report of the active stack frames at a certain point in time during the execution of a program. A panic is Go prints the stack trace to the console, assisting us in debugging.

The idiomatic way of handling errors is to check for error right after the function call.

A panic is a runtime-error that we are not prepared to handle gracefully. A panic can occur for example when we try to divide by zero or try to access non-existing array index.

A stack trace is a report of the active stack frames at a certain point in time during the execution of a program. A panic is Go prints the stack trace to the console, assisting us in debugging.

Implementing Errors

To define a custom error, we implement the error interface.

package main

import (
 "fmt"
 "log"
)

func enterAge(age int) (string, error) {

 if age < 0 || age > 130 {

 return "", &wrongAge{age, "wrong age value"}
 }

 return fmt.Sprintf("processing %d age value", age), nil
}

type wrongAge struct {
 age int
 msg string
}

func (e *wrongAge) Error() string {

 return fmt.Sprintf("%d: %s", e.age, e.msg)
}

func main() {

 var age int = 18
 msg, err := enterAge(age)

 if err != nil {
 log.Fatal(err)
 }

 fmt.Println(msg)

 age = 178
 msg, err = enterAge(age)

 if err != nil {
 log.Fatal(err)
 }
 fmt.Println(msg)
}

Comparing Errors

Declaring an error, and comparing it with '==' (as in err == myPkg.ErrTokenExpired) is no longer the best practice with Go 1.13 (Q3 2019).

The right way is:

if errors.Is(err, io.ErrUnexpectedEOF)

DONE JSON

JSON is a lightweight data-interchange format. It is easily read and written by humans and parsed and generated by machines. The application/json is the official Internet media type for JSON. The JSON filename extension is .json.

package main

import (
 "encoding/json"
 "fmt"
 "log"
)

type User struct {
 Id int
 Name string
 Occupation string
}

func main() {
 u1 := User{1, "John Doe", "gardener"}
 json_data, err := json.Marshal(u1)
 if err != nil {
 log.Fatal(err)
 }

 fmt.Println(string(json_data))
 users := []User{
 {Id: 2, Name: "Roger Roe", Occupation: "driver"},
 {Id: 3, Name: "Lucy Smith", Occupation: "teacher"},
 {Id: 4, Name: "David Brown", Occupation: "programmer"},
 }

 json_data2, err := json.Marshal(users)

 if err != nil {

 log.Fatal(err)
 }

 fmt.Println(string(json_data2))
}

{"Id":1,"Name":"John Doe","Occupation":"gardener"}
[{"Id":2,"Name":"Roger Roe","Occupation":"driver"},{"Id":3,"Name":"Lucy Smith","Occupation":"teacher"},{"Id":4,"Name":"David Brown","Occupation":"programmer"}]

In the code example, we transform a Go struct and a slice of structs into JSON format.

type User struct {
 Id int
 Name string
 Occupation string
}

We decode a JSON string into a Go struct and a slice of structs.

data := []byte(`{
 "Id" : 1,
 "Name": "John Doe",
 "Occupation": "gardener"
}`)

DONE Object-Relational Mapper

I decided that ORMs suck, I'm going raw SQL, or using SQLBoiler.

KILL Compiler Options

KILL Logging

KILL Testing

Go Project Structure

If you are trying to learn Go or if you are building a PoC or a simple project for yourself this project layout is an overkill. Start with something really simple instead (a single main.gofile andgo.mod is more than enough). As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state. When you have more people working on the project you'll need even more structure. That's when it's important to introduce a common way to manage packages/libraries. When you have an open source project or when you know other projects import the code from your project repository that's when it's important to have private (aka internal) packages and code. Clone the repository, keep what you need and delete everything else! Just because it's there it doesn't mean you have to use it all. None of these patterns are used in every single project. Even the vendor pattern is not universal.

`/cmd`

Main applications for this project.

The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).

Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the /pkg directory. If the code is not reusable or if you don't want others to reuse it, put that code in the /internal directory. You'll be surprised what others will do, so be explicit about your intentions!

`/internal`

Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 release notes for more details. Note that you are not limited to the top level internal directory. You can have more than one internal directory at any level of your project tree.

`/pkg`

Library code that's ok to use by external applications (e.g., /pkg/mypubliclib). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the internal directory is a better way to ensure your private packages are not importable because it's enforced by Go. The /pkg directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The I'll take pkg over internal blog post by Travis Jeffery provides a good overview of the pkg and internal directories and when it might make sense to use them.

Paramater	Purpose	`DEAFULT`
`:key`	a function to apply to all elements	`identity`
`:test`	the test function for comparison	`eql`
`:from-end`	if true, work backwards	`nil`
`:start`	position at which start	`0`
`:end`	position, if any, at which to stop	`nil`

Blog on La Vita Nouva

Reading leaked Claude Code source code

Reading leaked Claude Code source code

The codename canary problem

goodClaude, bughunter and other internal commands

import I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS

Multi-Clauding analytics

2,600 lines of preventing rm -rf

YOLO

A complete Vim implementation, from scratch

If ye does not heed

You have a pet

Other things worth mentioning

Make macOS 26 consistently bad (unironically)

Make macOS 26 consistently bad (unironically)

Footnotes

Little Known Development Methods (2009)

Little Known Development Methods (2009)

Declaring Emacs Bankruptcy

Declaring Emacs Bankruptcy

The org-roam startup problem

The iCloud symlink bug

The ltex-ls completion conflict

The global-git-commit-mode error

I beg you to follow Crocker's Rules, even if you will be rude to me

I beg you to follow Crocker's Rules, even if you will be rude to me

More examples

Footnotes

musql

musql

I'm not consulting an LLM

I'm not consulting an LLM

Footnotes

References

On Object-Oriented Programming and Clean Code

On Object-Oriented Programming and Clean Code

Clean Code

Decomposition

Abstraction

Polymorphism

Performance

Proposal

Object-Oriented Programming

Methods

Inheritance

Encapsulation

Polymorphism

Nouns

What replaces OOP?

Functional Programming

Data-Oriented Design

Less

Furthers

Footnotes

Scala bounds and variance

Scala bounds and variance

A typed plugin system.

Adding variance

Consumers and Producers laws

Producer laws

Full Example

Enforcing invariants in Scala datatypes

Enforcing invariants in Scala datatypes

Invariant validation using runtime assertions

Enforcing invariants in a type-safe style

Escaping invariant validation in case class datatypes

Regaining the case class features

Opening this PNG in Chrome shows a different image than in Safari or any desktop app

Opening this PNG in Chrome shows a different image than in Safari or any desktop app

What's going on

Attempt 1: Strip Metadata and Fix Alpha

Attempt 2: Fix the Gamma

Attempt 3: Nuclear option

Attempt 4: Remove the gAMA Chunk

The Smoking Gun

What's Really Happening

Email as a universal feed reader

Email as a universal feed reader

Re: Programmers and software developers lost the plot on naming their tools

Re: Programmers and software developers lost the plot on naming their tools

`goodClaude`, `bughunter` and other internal commands

`import I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS`

`awk` is not a good name