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

Applying “make invalid states unrepresentable”

kevinmahoney.co.uk

Post reply on HN
Print view View original

11–20 of 193 posts

Re: Applying “make invalid states unrepresentable”

#11

Post by lmm »

etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

> I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context.

I think that's exactly backwards. This kind of overcomplicated representation usually happens because people put too much effort into designing their representations up front. If you follow story-oriented development and only implement the parts they actually need to get the current task done, you never end up with these wasteful extra states because you never actually needed them. But people think that planning before coding is somehow virtuous, and then they're tied to following those plans.

Re: Applying “make invalid states unrepresentable”

#12

Post by leoc »

I appreciate what people are getting at with “make invalid states unrepresentable”, but it can't be the best description of what the true objective is. After all, the first language to make invalid states unrepresentable was probably TECO https://en.wikipedia.org/wiki/TECO_(text_editor)#As_a_progra... ...

Re: Applying “make invalid states unrepresentable”

#13

Post by joosters »

choeger wrote: post #10
joosters wrote: post #4

The time period example seems to miss an obvious weakness in the described Time Period 'object' - it's implied that the end date should be >= the start, but if you are representing a time period with ( Date, Date ) then you are still allowing invalid states to be represented - yet this is what the writer is trying to avoid. Likewise, a timeline split into contiguous periods can still represent out-of-order Dates. a T…

You should re-read the article. The author explicitly mentions to use sets of dates. Hence the ordering is implicit. For an interval you can do the same and use either a set or an unordered pair.

A set doesn't necessarily imply an ordering (unless this article is about some specific programming language, but it seemed fairly generic to me). e.g. Java and C++ have many Set implementations, some sorted (e.g. a TreeSet) and some not (e.g. HashSet)

Re: Applying “make invalid states unrepresentable”

#16

Post by [deleted] »

joosters wrote: post #4

The time period example seems to miss an obvious weakness in the described Time Period 'object' - it's implied that the end date should be >= the start, but if you are representing a time period with ( Date, Date ) then you are still allowing invalid states to be represented - yet this is what the writer is trying to avoid. Likewise, a timeline split into contiguous periods can still represent out-of-order Dates. a T…

[deleted]

Re: Applying “make invalid states unrepresentable”

#17

Post by matsemann »

joosters wrote: post #13
choeger wrote: post #10

Earlier quoted context omitted.

You should re-read the article. The author explicitly mentions to use sets of dates. Hence the ordering is implicit. For an interval you can do the same and use either a set or an unordered pair.

A set doesn't necessarily imply an ordering (unless this article is about some specific programming language, but it seemed fairly generic to me). e.g. Java and C++ have many Set implementations, some sorted (e.g. a TreeSet) and some not (e.g. HashSet)

That's the point. There's no ordering of the items. So the representation can never have an error like [yesterday, tomorrow, today]. It's just a set of (yesterday, tomorrow, today).

Re: Applying “make invalid states unrepresentable”

#18

Post by acidbaseextract »

lmm wrote: post #11
etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

> I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. I think that's exactly backwards. This kind of overcomplicated representation usually happens because people put too much effort into designing their representations up front. If you follow story-oriented development and only implement the parts…

The representational debt the parent comment is referring to is akin to that quip, "if I had more time, I would have written a shorter letter."

I find that both types of representational debt are common.

Re: Applying “make invalid states unrepresentable”

#19

Post by VBprogrammer »

jxf wrote: post #6
joosters wrote: post #4

The time period example seems to miss an obvious weakness in the described Time Period 'object' - it's implied that the end date should be >= the start, but if you are representing a time period with ( Date, Date ) then you are still allowing invalid states to be represented - yet this is what the writer is trying to avoid. Likewise, a timeline split into contiguous periods can still represent out-of-order Dates. a T…

I think you misunderstood the author's point: time periods aren't explicitly represented as (Date: start, Date: end). Instead they're a set of dates. The time periods are then implied by the set, making "end date before start date" impossible.

It also deals with the problem of the bounds on the ranges (open-closed, open-open etc) implicitly in a way which is harder to mess up.

One complication it's potentially missing is exactly who's days we are talking about i.e. is it days starting in GMT or UTC or EST or whatever the 'suppliers' or the 'customers' timezone is, are we actually talking about some day concept perhaps from start of business. Representing this as a datetime start / end certainly makes it possible to represent these concepts, if perhaps not making anything else particularly easier.

Re: Applying “make invalid states unrepresentable”

#20

Post by matsemann »

wa1987 wrote: post #2

Related video on this subject: https://www.youtube.com/watch?v=IcgmSRJHu_8

I thought about that video today when integrating with an old SOAP API. I need to find the name+some property of some persons. Instead of having a list with [(name1, prop1), (name2, prop2),...], I get two distinct lists of [name1, name2,..] and [prop1, prop2,..]. In practice I think the lists will always match. But there is nothing stopping them from not being the same length, or even worse: one having a gap..
Post reply on HN