Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Your Type System

dzombak.com

Post reply on HN
Print view View original

61–70 of 357 posts

Re: Use Your Type System

#61

Post by ho_schi »

Jtsummers wrote: post #33
ho_schi wrote: post #18

I'm not familiar with Go. Please correct me, but this reads like object oriented programming i.e. OOP for every kind of data? Coming from C++, this kind of types with classes make sense. But also are a maintenance task with further issues, were often proper variable naming matters. Likely a good balance is the key.

This isn't an OO thing at all. In C, to contrast with Go, a typedef is an alias. You can use objects (general sense) of the type `int` interchangeably with something like `myId` which is created through `typedef int myId`. That is, this is perfectly acceptable C: int x = 10; myId id = x; // no problems In Go the equivalent would be an error because it will not, automatically, convert from one type to another just bec…

Thank you for answer :)

This helped me! Especially because you started with typedef from C. Therefore I could relate. Others just downvote and don't explain.

Re: Use Your Type System

#62

Post by SideburnsOfDoom »

jjice wrote: post #5

Does anyone know the term for this? I had "Type Driven Development" in my head, but I don't know if that's a broadly used term for this. It's a step past normal "strong typing", but I've loved this concept for a while and I'd love to have a name to refer to it by so I can help refer others to it.

You're correct that this is far from a new idea.

Relevant terms are "Value object" (1) and avoiding "Primitive obsession" where everything is "stringly typed".

Strongly typed ids should be Value Objects, but not all value objects are ids. e.g. I might have a value object that represents an x-y co-ordinate, as I would expect an object with value (2,3) to be equal to a different object with the same value.

1) https://martinfowler.com/bliki/ValueObject.html

https://en.wikipedia.org/wiki/Value_object

Re: Use Your Type System

#63

Post by bcrosby95 »

abraxas wrote: post #37

An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it. Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the…

I think most complaints about checked exceptions in Java ultimately boil down to how verbose handling exceptions in Java is. Everytime the language forces you to handle an exception when you don't really need to makes you hate it a bit more.

First, the library author cannot reasonably define what is and isn't a checked exception in their public API. That really is up to the decision of the client. This wouldn't be such a big deal if it weren't so verbose to handle exceptions though: if you could trivially convert an exception to another type, or even declare it as runtime, maybe at the module or application level, you wouldn't be forced to handle them in these ways.

Second, to signature brittleness, standard advice is to create domain specific exceptions anyways. Your code probably shouldn't be throwing IOExceptions. But Java makes converting exceptions unnecessarily verbose... see above.

Ultimately, I love checked exceptions. I just hate the ergonomics around exceptions in Java. I wish designers focused more on fixing that than throwing the baby out with the bathwater.

Re: Use Your Type System

#64

Post by alphazard »

I've seen experienced programmers do this a lot. It's the kind of thing that someone thinks is annoying, without realizing that it was preventing them from doing something incorrect.

Re: Use Your Type System

#65

Post by default-kramer »

tyleo wrote: post #39

In C#, I often use a type like: readonly struct Id32 { public readonly int Value { get; } } Then you can do: public sealed class MFoo { } public sealed class MBar { } And: Id32 x; Id32 y; This gives you integer ids that can’t be confused with each other. It can be extended to IdGuid and IdString and supports new unique use cases simply by creating new M-prefixed “marker” types which is done in a single line. I’ve als…

I've done something like that too. I also noticed that enums are even lower-friction (or were, back in 2014) if your IDs are integers, but I never put this pattern into real code because I figured it might be too confusing: https://softwareengineering.stackexchange.com/questions/3090...

Re: Use Your Type System

#66

Post by dgb23 »

recursivedoubts wrote: post #17

Type systems, like any other tool in the toolbox, have an 80/20 rule associated with them. It is quite easy to overdo types and make working with a library extremely burdensome for little to no to negative benefit. I know what a UUID (or a String) is. I don't know what an AccountID, UserID, etc. is. Now I need to know what those are (and how to make them, etc. as well) to use your software. Maybe an elaborate type sy…

I think the example is just not very useful, because it illustrates a domain separation instead of a computational one, which is almost always the wrong approach.

It is however useful to return a UUID type, instead of a [16]byte, or a HTMLNode instead of a string etc. These discriminate real, computational differences. For example the method that gives you a string representation of an UUID doesn't care about the surrounding domain it is used in.

Distinguishing a UUID from an AccountID, or UserID is contextual, so I rather communicate that in the aggregate. Same for Celsius and Fahrenheit. We also wouldn't use a specialized type for date times in every time zone.

Re: Use Your Type System

#67

Post by Izkata »

jjice wrote: post #5

Does anyone know the term for this? I had "Type Driven Development" in my head, but I don't know if that's a broadly used term for this. It's a step past normal "strong typing", but I've loved this concept for a while and I'd love to have a name to refer to it by so I can help refer others to it.

It's taking the original idea behind Hungarian notation (now called "Apps Hungarian notation" to distinguish from "Systems Hungarian notation" which uses datatype) and moving it into the type system.

To keep building on history, I'd suggest Hungarian types.

Re: Use Your Type System

#68

Post by vemv »

Jtsummers wrote: post #54
vemv wrote: post #52

Most static type systems that I know of disappear at runtime. You literally cannot "use" them once deployed to production. (Typescript's Zed and Clojure's Malli are counterexamples. Although not official offerings) Following OP's example, what prevents you from getting a AccountID parsed as a UserID at runtime, in production? In production it's all UUIDs, undistinguishable from one another. A truly safe approach woul…

> Most static type systems that I know of disappear at runtime. You literally cannot "use" them once deployed to production. That's part of the point of being static. If we can statically determine properties of the system and use that information in the derived machine code (or byte code or whatever), then we may be able to discard that information at runtime (though there are reasons not to discard it). > Following…

There are infinitely many runtime properties that are simply impossible to determine statically.

Static typing is just a tool, aiming to help with a subset of all possible problems you may find. If you think it's an absolute oracle of every possible problem you may find, sorry, that's just not true, and trivially demonstrable.

Your example already is a runtime check that makes no particular use of the type system. It's a simple "set contains" check (value-oriented, not type-oriented) which also is far more expensive than simply verifying the string prefix of a Slack-style object identifier.

Ultimately I'm not even saying that types are bad, or that static typing is bad. If you truly care about correctness, you'd use all layers at your disposition - static and dynamic.

Re: Use Your Type System

#69

Post by gfairbanks »

jjice wrote: post #5

Does anyone know the term for this? I had "Type Driven Development" in my head, but I don't know if that's a broadly used term for this. It's a step past normal "strong typing", but I've loved this concept for a while and I'd love to have a name to refer to it by so I can help refer others to it.

The overall idea of using your type system to enforce invariants is called typeful programming [1]. The first few sentences of that paper are:

"There exists an identifiable programming style based on the widespread use of type information handled through mechanical typechecking techniques. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-oriented, and algebraic programming, and it is not incompatible with relational and concurrent programming."

[1] Luca Cardelli, Typeful Programming, 1991. http://www.lucacardelli.name/Papers/TypefulProg.pdf

[2] https://news.ycombinator.com/item?id=18872535

Re: Use Your Type System

#70

Post by codr7 »

default-kramer wrote: post #53
abraxas wrote: post #37

An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it. Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the…

I think checked exceptions were maligned because they were overused. I like that Java supports both checked and unchecked exceptions. But IMO checked exceptions should only be used for what Eric Lippert calls "exogenous" exceptions [1]; and even then most of them should probably be converted to an unchecked exception once they leave the library code that throws them. For example, it's always possible that your DB cou…

Sometimes I feel like I actually wouldn't mind having any function touching the database tagged as such. But checked exceptions are such a pita to deal with that I tend to not bother.
Post reply on HN