> I think the structural type approach leans heavily into the "computation is just data and its transformations"

But it's never "just data". My password is different in many ways than my username. Don't you ever log/print it by accident! So even if structurally the same, we MUST treat it different. Hence any approach that always only looks at things structurally is deeply flawed in the context of safe software development.

Yeah you bring up a good point. A { name: string } dict needs to be treated differently from a { user_pw: string } dict. The difference is that happens in the domain layer instead of the type layer.

That's no difference than using newtype structs. If you remove the extra layer you are left with `string` for both of them.

> The difference is that happens in the domain layer instead of the type layer

This view greatly reduces the usefulness of the type layer though, as that's the only automated tool that can help the domain layer with handling cases like this.

It's not really automated though, it's just another layer of code written by a human, prone to the same types of human error.

Bugs in the typechecker are rare (it's widely exercised if the language is at all popular) and generally fixed quickly. If you have an expression of type A you can be pretty confident you're getting a value that's passed through a constructor for type A.

Can a human encode something different by that than what they intended to encode? Certainly. But it's got the highest cost-benefit of any approach to double-checking your code I've found.

That's not what I mean. It's trivial to encode your types in such a way that it incorrectly implements domain logic and there is no meta-meta language enforcing correctness there.

How so? To the extent that you use your types with your code, getting your types wrong will lead to either type errors in correct code (in which case you notice and fix them) or overly loose types that will allow incorrect code to pass (in which case you don't get an actual bug unless you make a corresponding mistake in your code).

> The difference is that happens in the domain layer instead of the type layer.

What's those layers you are talking about? In my domain-logic code I use types of course so there is no dedicated "type layer".

Depending on the language, you can define a PasswordString type that is entirely distinct from the string type. Perhaps it can be explicitly converted to a string (perhaps given a capability token). Then you have:

a { user_pw: PasswordString}

This is what it means to model the domain using types. It is not a separate layer, it is actually using the type system to model domain entities.

Structurally typed languages can still support information hiding.

   type PasswordString struct {
      pw string
   }
   func(p PasswordString) String(token string) { ... }

I guess the point is that you can model your domain using data as well as types.

> Structurally typed languages can still support information hiding.

But you haven't hidden the information, it's still a string. You can put the string in a wrapper struct but in a structural system that's not really any different from putting it a list or map - the data is still exposed, and if someone writes code to e.g. log objects by just enumerating all their fields (which is a very natural thing to do in those systems) then it will naturally print out your password and there's not really any way to make it ever not.

> I guess the point is that you can model your domain using data as well as types.

You want both in your toolbox though. Restricting yourself to only having types that are essentially lists, maps, or a handful of primitives has most of the same downsides as restricting yourself to not using types at all.

You can implement the Stringer interface for the type which prevents it from being logged and since it's private, code from outside of the module can't enumerate it. Of course it's still accessible via reflection or memory dumps etc, but isn't that the case with Java etc? Storing a plain text password like this is a bad idea anyways.

I guess my point is that a structural type system can still allow for encapsulation.

> You can implement the Stringer interface for the type which prevents it from being logged and since it's private, code from outside of the module can't enumerate it.

Those sound like decidedly non-structural features. And couldn't you undermine them by passing it to a function that expects a different `struct { pw string }` and logs its contents?

Only in the same module. Outside, it's effectively hidden.

And yeah, structurally typed languages often have nominal features. They come in useful in a lot of scenarios! Unless you're talking about something like Clojure which is not statically typed.

> I'm not saying the nominal approach to types is wrong or bad, I just find my way of thinking is better suited for structural systems. I'm thinking less about the semantics around product_id vs user_id and more about what transforms are relevant - the semantics show up in the domain layer.

But that domain layer should make use of the type system! That's where the type system is most useful!

I've seen this debate play out before. Often the type theory people and the domain modeling people end up talking past each other.

I think type-theoretic safety is a completely different thing to the use of types (and names) in software-as-domain-modeling (for example, but not necessarily OO modelling). At different times, for different people, one perspective is more important than the other. It is important not to confuse the perspectives, and to value both of them, but also to recognise their strengths and weaknesses.

One theme that sometimes emerges is that the type theory people don't care about names at all. Not even field names. Taken to the extreme Customer( name: str; age: int) is just a Tuple[str, int]. The words "Customer", "name", "age" have no place in the code base.

My take is that when you are dealing with computer-scientific abstract things, e.g. a List of T, then there is no need to reference the domain entities; placeholder names like T, x, xs make sense. On the other hand, if you're writing an application that models domain semantics (eg. business rules), writing software amounts to modelling the domain, it should be easy to correlate software entities with the real-world entities that they model. To do this we use descriptive words, including names, domain events, activities and so on. e.g. List[Customer] not List[Tuple[str, int]]. Then again, you could replace all of the type names with A, B, C, ... and all the variable names with w, x, y, .... The example would end up as X[Y[Z,W]], the software would work exactly the same, and you might get some insights into the structure of the system. However, if you're in the business of building a user management system in general this is not going to fly for very long with your workmates or your client. You will have trouble onboarding new developers.

I think this is a superb point. If you look at Clojure and Rich Hickey's justifications for it's design, he talks a lot about designing systems that work with a world that is changing constantly, interfacing with systems where you can't always guarantee a stable contract, solving problems that use non-elegant models, dealing with state and time, and change in ways you can't predict. Eric Normand wrote a great article on this and he comes from a dual Haskel/Clojure background [1]. Nominal static type systems absolutely have their place, especially with closed systems where the abstractions are different.

1: https://ericnormand.me/article/clojure-and-types

I'm not sure which side you're putting me on, because I think named types are important for exactly the same reason that named fields are. A customer should not just be a pair of str, int in the same way that an age should not just be an int and a name should not just be a string (and using an int field called "age" is a poor substitute for using an actual age type).

I was thinking of you as on the domain modelling side (same side I am usually on).

You are right, I should have gone further with the example and used Customer{ age: Age, name: PersonName}.

Why not go further? Customer should be a subtype of Human, which contains subtypes DoesInteractWithCompany and HasNeverHeardOfUs. Customer should have subtypes for each country they live in, and PersonName should probably be split into FullName<FirstName, LastName> for flexibility.

The purpose of a model is to represent salient features of a domain (both the data, behavior, constraints.) In the context of this discussion we are particularly interested in modelling behavior and constraints. As your examples illustrate, it is possible to do a poor job, e.g. model at the incorrect level of abstraction (Human is not salient unless you have a concrete need to model Customer's of other Species), or to introduce specious abstractions. The fact that forming useful domain models is non-trival does not render it worthless.