Notices by Wilfred Hughes (wilfredh@mastodon.social)

There are *so many* ways that reading a text file can fail.

Maybe it doesn't exist, it's a broken symlink, it's actually a directory, it's not the encoding you expected, or perhaps you just don't have the correct permissions.

Reporting good errors is surprisingly labour intensive.

Overall it seems like the Rust for Linux is making huge strides. Greg KH is super supportive of it[1] and the wider Linux community is pretty positive[2] (see all the quotes at the end of the slides).

1: https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/
2: https://fosdem.org/2025/schedule/event/fosdem-2025-6507-rust-for-linux/

"Example Driven Development" using Glamorous and Pharo Smalltalk: https://medium.com/feenk/an-example-of-example-driven-development-4dea0d995920

Tests returning values and composing is a really interesting model. It establishes structure and shows which test failure is the most 'fundamental'.

TIL Advent of Code and Project Euler will deliberately look for puzzles where the naive solution is worse than quadratic.

This ensures that people can solve them with any programming language. You don't want fast languages to be able to use the naive solution.

I love how the CommonMark Spec has a test suite that's just a JSON array. It's really easy to test a library for compliance, and I've seen developers nerd-sniped into full compliance.

https://spec.commonmark.org/0.31.2/spec.json

@amszmidt there's at least one user! https://difftastic.wilfred.me.uk/fossil.html

I'm not a Fossil user myself so I can't say how well it works with difftastic though.

I'd heard the conventional wisdom that UX research states that mice are more efficient than keyboards, but turns out there's virtually no research on this!

https://danluu.com/keyboard-v-mouse/

I'm intrigued to see that Google has quantified that new code is generally buggier and less secure than code that has existed in your codebase for longer: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

An ad hoc, informally-specified, bug-ridden, slow implementation of half of a text adventure game -- or as I like to call it, a compiler.

Difftastic is written in Rust, so I was surprised to get a user report of a segfault.

After some investigation, it turns out that it's a segfault in git itself, which has existed since 2014! https://lore.kernel.org/git/CAFXAjY7XcL1APhLRXU8TO96z=f7957f2ieK56dHVsXUay55vpg@mail.gmail.com/T/#u

(Upstream has already kindly written a patch.)

Running a package manager host for a popular language is really expensive. TIL that Python costs several million dollars per year!

I've released difftastic 0.49! In this release:

* LaTeX support
* Smarter diffing in languages that prefer the outer delimiter (JSON, Lisps)
* Improved parsing for C, C++, Java and Haskell

https://github.com/Wilfred/difftastic/releases/tag/0.49.0

I've been thinking about making difftastic smarter about context. In principle it understands structure, so I could limit context to the enclosing definition.

However, sometimes it's nice to see surrounding code. Line 644 isn't useful, but maybe 655 is. Opinions?

A great deep dive on building GitHub's code view, optimising React, scaling to thousands whilst supporting both Ctrl-F and syntax highlighting: https://github.blog/2023-06-21-crafting-a-better-faster-code-view/

Steve Jobs famously asked for smooth scrolling (i.e. not line-by-line) in a Smalltalk demonstration and they changed the UI live.

Here's a lovely 2 minute YouTube video demonstrating that modification: https://www.youtube.com/watch?v=eEz08IlcNMg

I've just added closure support to my toy programming language: https://github.com/Wilfred/garden/commit/d1fb4566a2187dfe98fb1d2278a7a0d2acd8059e

Closures are more fiddly than I expected, but I now have a much better understanding of what downward/upward funargs are :)

(Downward: passing a closure, upward: returning a closure)

Rust has an elegant solution to testing private functions: you put the test in the file that defines the function. It generally works well.

I've even seen people argue that it makes mocking much less necessary! I've not felt the need to mock in Rust so far.

Advice from one of the authors of Common Lisp on PL work: established languages tend to win in their domain. It really helps if you enjoy working in this space.

(There is a ton of PL skill and insight in the smaller languages IME.)

https://pldb.com/posts/scottFalhmanInterview.html

Tired:
Unexpected IndexError

Wired:
Tried to access index 10 in a 4 item list ["x", "y", "z", ""]