←back to thread

42 points todsacerdoti | 1 comments | | HN request time: 0.207s | source
Show context
js8 ◴[] 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. sevensor ◴[] No.42193619[source]
Although I have my frustrations with Python’s bolted-on type checking, particularly how clunky the type annotations can be at runtime (this type is just the string “Foo | Bar | int”, good luck!), I think the pragmatic approach is working out pretty well on the nominal versus structural front. I.e. I can make it an error to assign a number in radians to a variable of type meters (NewType), but I can also construct a dictionary of the right shape and have it satisfy a TypedDict annotation. Or I can write a Protocol, which is the biggest hammer in the type system.