chris_armstrong

I like the Sydney one (the jacarandas are a nice touch; a banksias or wattle option would add an interesting local touch).

For any city, a thunderstorm or light drizzle option would be very moody.

I think the problem can be traced back to the fact that we've failed to develop a popular design language since pre-WW2^1.

That in itself could be traced back to the professionalization of building manufacturing - the small-scale building and design that happened before this industrialisation of construction did away with all the little vernacular architectural decisions that would have been part of a building's design. Far more of the labour-force was involved in building construction, and less was done with pre-fabricated materials (probably just bricks and mortar), and certainly not as much was done on a mass-scale with the same homogenous approach^2, and with much less concern for the labour costs associated with those little details that add "character" to an older building^3.

I'm starting to find small examples of lower-scale construction projects in my home city (Sydney) that seem to return some interesting elements to newer building construction, like variation in materials such as perforated shading or different colours or textures of prefab cladding, using brick for feature walls in other pre-fabricated concrete buildigs, more external hanging gardens, etc). This is better, and I'm happy to see it, because while the older federation terraces in Sydney are nice to look at, they're hopelessly underdesigned for the climate (too hot in summer, too cold in winter, too dark in a country that is blessed with natural light, and often with damp and mould problems that shouldn't exist on a building post 1900).

^1 popular in the sense that its widespread amongst the general population, not the way modernism is popular with architects, both for its cost and the way its become part of the popular taste of architects as a profession

^2 the treasured old neighbourhoods in cities that are preserved and made "heritage" are the results of hundreds of individual decisions by dozens of individual builders and tradespeople, which although similar, contain enough difference to convey a sense of character. Compare that with a small team of planners working for a single construction company remaking a block or entire suburb.

^3 I could be wrong, but I would have thought labour costs were a much lower component of building construction then, or at least there was far more labour hours that go into a building's construction, allowing more time for the little details that give an older building its little characteristics like lacing, fancy brickwork or unusual reliefs.

A similar design trend of using terracotta everywhere in the 1990s permeated Australian housing design that was similarly ugly and monotonous. I'm only slowly undoing the damage to mine now.

breaking this by putting it in earshot of a lyrebird

This one resonates hard. So many companies are rushing headstrong into automating everything with AI, risking their ability to reproduce the critical skills their organisation needs that are experiential and social.

(And yes, it's telling that the author has clearly used AI to generate the argument, because not only does it weaken their argument, I think they miss the point slightly because of their reliance on it.)

They focus on safety-critical systems in aviation, which is narrow part of all industries, when the bigger issue is organisational resiliency and reproduction. The skills that allow an organisation to weather change and disruptive market conditions are not tied up in proprietary information, but are captured as unwritten social rules and context that isn't passed on when labour is outsourced, either off-shore or via computerisation.

The problem is particularly acute in software development, because software engineers not only make the system that encodes proprietary knowledge and organisation advantage, they maintain it, and without a continual replacement of labour that understands the system and the reasons for the system's behaviour, the ability to extend it or fix it is lost.

This problem predates AI, and even software, where organisations die because they outsourced too much of their critical internal function. It eventually manifests at an industry level, where the critical knowledge to do a certain thing is lost (see, for example, the ability to produce new IMAX projectors as a microcosm, but also the loss of machine tooling skills, etc.) - at the heart of why some countries subsidise inefficient industries because the firms within them have no incentive to preserve themselves but their skills are invaluable to preserving national autonomy.

I can appreciate the pain of trying to bind against GTK4 with a functional language. You definitely get a lot of difficult-to-verify and special-case boilerplate C code.

Reinforced continuously toward a fixed goal is not an incentive, it doesn’t lead to a creative process

A small bone to pick, but describing an AI that is operating autonomously as creative seems wrong - at best, this process is accretive, because the AI is adding and adding, but has no ability or incentive to shape its output toward something a human would find of value. Value is subjective (individual), changing over time. An AI doesn't know when it needs to be taking away - removal is a key part of the creative process.

I interpreted this as being a little tongue-in-cheek - reflecting the obscurity of CL and the way the expressiveness of a lisp can make you feel powerful that others will struggle to understand

I didn't interpret it as an argument about layers of abstraction. You need to be in the detail at the level you're writing (and it's certainly advantageous to know some of the detail of the abstractions below) because you're building abstractions on top of that, because the details subtly change at the base level you're building at, impacting the level that you're building to.

It might just be me, but I find his baroque style very readable. Despite using a vocabulary much broader than mine (irritating but admirable), he at least seems to have read his prose aloud, and considered how it's meter makes its meaning fluent.

I agree that many writers fill their works with needless diversions and unnecessary expositions on their life that add nothing to their text, but this is different from a "baroque style".

I'm working on ocgtk, which are GTK4+ bindings for OCaml.

My current focus is adding support for signals, amongst other things: https://www.chrisarmstrong.dev/posts/ocgtk-development-updat...

Not yet - it's mostly a build tool, but package management abilities (which is otherwised covered by opam) is being added to it^1. It's currently usable for some projects (and worth trying out), but still in preview mode.

^1: https://dune.readthedocs.io/en/stable/tutorials/dune-package...

Installing via opam and using the cygwin method is supported and should be working fine (cygwin is just used for build - binaries still just link with mingw).

That specific combination (ocaml + mingw) has a known problem with ocamlfind that's still awaiting a new release (see https://github.com/ocaml/ocamlfind/pull/112). ocamlfind underpins quite a bit of the package ecosystem, so this one is annoying, as the mingw workflow is otherwise quite good.

I completely forgot about Wolverine, but you've reminded me I was using that back in the day to read my mail from Fidonet point (as well as Bluewave).

“cognitive surrender”

It’s maddening, because you can’t reason with a person who won’t even think for themselves

The answer, as always, is to write a compelling story about it, and make the front page of ‘new’.

No where in Australia would you expect a fridge to be supplied as part of a tenancy. It does restrict what you can buy, as may removalists will not touch move a fridge if there’s too many stairs or if you can’t get it in the door

I would say Australian English relies on this negation even more than British English, to the point of being confusing without more cultural context.

Genuine independence is almost impossible at this size, because you need a strong internal discipline to only rely on small donors, and not bend your organisation’s mission to keep larger donors

I think this because nonprofits are subject to a similar market discipline as companies: they compete for funding, relevance, market share etc.

And their board composition converges similarly as those same people are relied upon for their connections to fundraise, hire, etc. They don’t want to be seen taking an unusual strategy as it would be perceived as risky and jeopardising precious donated funds, so the same groupthink emerges.

Even if someone outside these circles was hired, they’d be knocked down with the smallest misstep, with the veiled criticism they weren’t suitable for the position (ie someone with better connections should have been chosen), so even they will fall into line.

Non profit organisations trying to remain relevant (or just survive) behave this way because they arent much different from companies operating in a market for profit.

Their leadership is often not that much different, with similar people working in similar jobs educated in the same institutions and walking in the same social circles, producing the same solutions to the existential problem of organisational survival.

I stand corrected - there’s so little known about it that it’s probably some strange labor of love from recent centuries

It was discovered in the 1800s, the shell grotto is much much older and probably built over a very long period of time

This is probably the highlight of a visit to an otherwise unremarkable English seaside town. The chambers are very old (even by English standards) and so unlike anything else medieval that is still around.

It's interesting reading many of the associated comments, because there is a genuinely active effort to address many of the pain points of the language:

* Windows support has improved to the point where you can just download opam, and it will configure and set up a working compiler and language tools for you[^1]. The compiler team treat Windows as an first tier target. opam repository maintainers ensure new libraries and library versions added to the opam repository are compiled and tested for Windows compatibility, and authors are encouraged to fix it before making a release if its reasonably straightforward

* debugger support with gdb (and lldb) is slowly being improved thanks to efforts at Tarides

* opam is relatively stable (I've never found it "buggy and surprising"), but there are aspects (like switches that behave more like python venvs) which don't provide the most modern behaviour. dune package management (which is still in the works) will simplify this considerably, but opam continues to see active development and improvement from release to release.

* the platform team (again) are working on improving documentation with worked recipes and examples for popular uses cases (outside of the usual compiler and code generation cases) with the OCaml Cookbook: https://ocaml.org/cookbook

There are other things I find frustrating or that I work around, or are more misperceptions:

* there isn't a builtin way to copy files because the standard library is deliberately very small (like Rust), but there is a significant ecosystem of packages (this is different to other languages which cram a lot into their standard library). The result is a lot of friction for newcomers who have to install something to get what they need done, but that's valued by more experienced developers who don't want the whole kitchen sink in their binary and all its supply chain issues.[^2]

* the type inference can be a bit of a love/hate thing. Many people find it frustrating because of the way it works, and start annotating everything to short-circuit it. I've personally found it requires a bit of work to understand what it is doing, and when to rely on it, and when not to (essentially not trying to make it do things it simply will never be able to do).[^3]

* most people use singly-linked lists because they work reasonably well for their use cases and don't get in their way. There are other data structures, they work well and have better performance (for where it is needed). The language is pragmatic enough to offer mutable and immutable versions.

* ocamlformat is designed to work without defaults (but some of them I find annoying and reconfigure)

Please don't take this as an apology for its shortcomings - any language used in the wild has its frustrations, and more "niche" languages like OCaml have more than a few. But for me it's amazing how much the language has been modernised (effects-based runtime, multicore, etc) without breaking compatibility or adding reams of complexity to the language. Many of these things have taken a long time, but the result is usually much cleaner and better thought out than if they were rushed.

[^1] This in itself is not enough, and still "too slow". It will improve with efforts like relocatable OCaml (enabling binary distribution instead of compiling from source everywhere) and disentangling the build system from Unixisms that require Cygwin.

[^2] I particularly appreciate that the opam repository is actively tested (all new package releases are tested in a CI for dependency compatibility and working tests), curated (if its too small to be library, it will probably be rejected) and pruned (unmaintained packages are now being archived)

[^3] OCaml sets expectations around its type inference ("no annotations!") very high, but the reality is that it relies on a very tightly designed and internally coherent set of language constructs in order to achieve a high level of type inference / low level of annotation, but these are very different to how type inference works in other languages. For example, I try and avoid using the same field name in a module because of the "flat namespace" of field names used to infer record types, but this isn't always possible (e.g. generated code), so I find myself compensating by moving things into separate modules (which are relatively cheap and don't pollute the scope as much).

I also find languages like OCaml avoid a lot of this nonsense in their libraries because the ability to build layers and layers of complex abstraction isn’t there in the same way as Haskell, Rust, or any of the LISPs

This resonates. I spent a fair bit of time thinking about library design for an OCaml library that didn’t directly expose more complicated language features (like functors and first class modules) where they weren’t needed.

(I presented on it recently: https://www.chrisarmstrong.dev/posts/icfp-wrapup-2025-10-18)

The ICFP/SPLASH papers are now starting to find their way to HN.

This was a HUGE combined programming conference with several competing tracks over 7 days. You can find the program here ^1 (you can often find a link to the abstract or full paper if you click on it)

Streams from the sessions will also show up here^2 (you’ll need to match the day and room and ff to the time it appeared)

^1: https://conf.researchr.org/program/icfp-splash-2025/program-...?

^2: https://youtube.com/playlist?list=PLyrlk8Xaylp5ihrTVeOSaylaB...

zig has a cross-compiler frontend (zig cc) which can be used as a drop-in replacement for a custom sysroot + binutils + gcc for several platforms. I've used it to build OCaml cross-compilers that only depend on zig itself (https://www.chrisarmstrong.dev/posts/ocaml-cross-compilation...).

There are other projects that have used it in a similar way too.

[1] https://actually.fyi/posts/zig-makes-rust-cross-compilation-... [2] https://jcbhmr.com/2024/07/19/zig-cc-cmake/