Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

types are not interfaces.

interfaces describe behavior, types describe shape and structure. the difference is subtle but important.



> interfaces describe behavior, types describe shape and structure

Shape and structure are behavior. There's more to behavior than "abstractly produces X result". Behavior is "produces X result in Y form given Z in W form".


Shape and structure are behavior.

They shouldn't be. Conflating two things that can be separated is just compounding complexity. You don't need to know how a database lays out memory or the structure behind a web server.


> You don't need to know how a database lays out memory

You do, however, need to know what logical columns are in a table and the types of those columns to be able to effectively query against the table. And you need to know what the types of the inputs to a query wrapper function are to be able to call it properly.

Memory layout has nothing to do with type, because physical memory layout is completely separate from the semantic logical layout and form represented by the bits. You now appear to be the one conflating two unrelated things.

That something is treated as an integer fundamentally matters to its use. That the thing comprises some number of adjacent bits in big/little-endian arrangement is a very unrelated implementation detail.


And you need to know what the types of the inputs to a query wrapper function are to be able to call it properly.

That's the interface.

Memory layout has nothing to do with type,

So float, int, unint64, int8 and a vector/array don't have specific memory layouts?

the semantic logical layout and form represented by the bits

This is nonsense and doesn't mean anything.


> So float, int, unint64, int8 and a vector/array don't have specific memory layouts?

The memory layouts don't need to be known to the user. Different hardware architectures can have the concept of floats and ints and code can be written using them the same way while the underlying representations are distinct. I promise that IEEE754 is not the only way to represent floating point values handed down from god to man on a golden scroll.

> > And you need to know what the types of the inputs to a query wrapper function are to be able to call it properly.

> That's the interface.

Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure". Now you acknowledge that the interface necessarily includes the types of the arguments?


The memory layouts don't need to be known to the user.

This isn't relevant one way or another.

Different hardware architectures can have the concept of floats and ints

This also isn't relevant. Data types aren't expected to be cross platform unless they are specifically made for that, like file formats.

Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure"

I never said that.

Also just because two things work together doesn't mean they are the same thing.


> > The memory layouts don't need to be known to the user.

> This isn't relevant one way or another.

What needs to be known to the user of an interface is the most relevant aspect of describing that interface.

> Data types aren't expected to be cross platform unless they are specifically made for that, like file formats.

It's going to be difficult to reconcile that position with https://en.wikipedia.org/wiki/Abstract_data_type

Data types can optionally specify machine representation but need not. They specify behavior (i.e. possible values and operations) first and foremost. In programming, nearly every use of data type is in the abstract, entirely separate from its hardware representation. The "Int", the "Bool", the "2", the "UTCTime" being specified in TFA don't care about bit arrangements. They're describing valid values and operations, not hardware.

> I never said that.

You're right. Apologies. It was the other poster at the top of the thread. But it still seems apt to the thread and to your specific portrayal.


don't care about bit arrangements.

Not every scenario cares about bit arrangements but they are still there.

You seem to just be shifting around and coming up with new, more abstract arguments that drift further from whatever point you originally had.

You said

"Shape and structure are behavior."

One is data, one is execution. These are two different things.

The more they are conflated together, the more problems people have with their programs.

Not separating them and letting them mix is a huge part of bad software architecture and leads to lots of unnecessary complexity.


Interfaces are usually understood as a subset of types. Interfaces specifically describe method signatures. Nevertheless, the distinction is murky because any structure can be interpreted in terms of getters and setters which can be considered methods.


In Haskell behavour is type-directed (type classes) and they describe both.


Depends on the language. In typescript and interface can absolutely encode shape. In C# you can encode shape in interfaces via properties. Interfaces don’t even describe behavior, it’s just that we typically associate them with a man implicit contract. Strictly speaking they are just a shape.


fair, maybe i should have said "protocols define behavior" instead of interface




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: