Live data from Hacker News

Why don't more languages offer flow typing?

ayazhafiz.com

1–10 of 127 posts

Re: Why don't more languages offer flow typing?

#4
This is not a complete answer, but covers some languages. If you program too exclusively in dynamically-typed languages, you can be too used to not thinking about how physically large your types are, because you work in a world where everything is boxed, and allocations so plentiful you don't even hardly have a way of thinking about them because your language does them at the drop of a hat, and so on.

But there are many strongly-typed languages that look at types at compile time and decide how large they are, by which I mean, how many bytes of physical RAM they take. These languages have gotten better and better over time at the APIs they offer that give the benefits of this without incurring the programmer costs, but under the hood, no matter how slick they've gotten, there is still a mapping of type -> size & layout. In these languages, this sort of narrowing is a great deal more complicated, because it implies a new type, which will probably require more allocation. For instance, in the example given between a "string" and a "number", that definitely looks like two differently-sized types to me. This would become very complicated very quickly as you start having to allocate these things in ways that can't be transparent to the user, you have to pass these types around, etc. etc.

One would expect that the affordances of statically-typed languages would end up being very different. And in fact, they are. Many modern statically-typed languages can solve the same problems outlined in the post, they just solve it in a different way. In this case, an Either, or more generally, a sum type. Then "getViewsOf" returns a value of that sum type and you can switch on it based on the value. It isn't exactly the same, in fact I'm not sure there's one aspect of it that's the same let alone the whole, but it solves the same problems.

So my suggestion would be that there are in fact a lot of languages that essentially have the same feature. They just don't call it "flow typing" and it's not spelled the same way.

Re: Why don't more languages offer flow typing?

#6
post #4

This is not a complete answer, but covers some languages. If you program too exclusively in dynamically-typed languages, you can be too used to not thinking about how physically large your types are, because you work in a world where everything is boxed, and allocations so plentiful you don't even hardly have a way of thinking about them because your language does them at the drop of a hat, and so on. But there are m…

Yeah, I hadn't heard the term "flow typing" before but I thought the same thing, in other languages I've used you'd use a Result type and a switch to do what the author was doing.

Re: Why don't more languages offer flow typing?

#9
post #7

Dart does this, or at least something very similar, and it is really nice. It's most useful for narrowing nullable types to their non-nullable counterparts after a null-check, but the subclass case works too.

As your sibling allready stated, in Kotlin it is known as smart casting. Good to see that the article allready recognizes the prior art from ML which was conceived in 1971.

Re: Why don't more languages offer flow typing?

#10
post #7

Dart does this, or at least something very similar, and it is really nice. It's most useful for narrowing nullable types to their non-nullable counterparts after a null-check, but the subclass case works too.

Dart’s “..” operator, which allows void-returned function calls to be chained, adds no performance cost to the code and is one of my favorite pieces of Dart.
Post reply on HN