←back to thread

Nominal for Storing, Structural for Manipulating

(welltypedwitch.bearblog.dev)
42 points todsacerdoti | 2 comments | 20 Nov 24 02:50 UTC | HN request time: 0.414s | source
Show context
js8 ◴[20 Nov 24 11:55 UTC] No.42193035[source]▶
The nominal vs structural distinction (in both programming and math) goes beyond types. Should names in programs matter?

Consider two functions, say copySurname and copyStreetName. They do same exact thing, but in different context. No sane person would call copySurname for the street, even though the function is the same.

So there is this tension, should name of the function (or of the type) only reflect it's internal structure (structuralism), or should it also reflect the intended domain application (nominalism)?

There is a formalism school of mathematics that is pretty much the hardcore structuralist, i.e. names of the objects don't matter, only their relationships. But most mathematicians (and all programmers) reject that view.

replies(3): >>42193526 #>>42193619 #>>42193719 #
1. bheadmaster ◴[20 Nov 24 12:55 UTC] No.42193526[source]▶
In real-world software writing, there's a huge pull towards nominalism (i.e. naming code parts by their domain purpose), but in my experience, the most useful way is to have structural names for internal mechanisms, then use their interfaces in nominal way by describing their role in the business logic.

That way, all nominalism is simply a descriptive wrapper over structuralism.

replies(1): >>42193950 #
2. js8 ◴[20 Nov 24 13:55 UTC] No.42193950[source]▶
That's very similar to what the article is advocating.