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

Why don't more languages offer flow typing?

ayazhafiz.com

Post reply on HN
Print view View original

101–110 of 127 posts

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

#101

Post by [deleted] »

masklinn wrote: post #72
jerf wrote: post #69

Earlier quoted context omitted.

I'm not sure what you mean by "not gaining anything of significance." Go without interfaces (and for simplicity let's ignore 1.18's generics for a moment) would not be a useful language at any significant scale. You'd end up with a lot of "by hand" interfaces of structs full of function pointers (or method closures), only without the compiler support. Nor am I sure exactly what "confusion" is being increased.

> I'm not sure what you mean by "not gaining anything of significance." Go without interfaces (and for simplicity let's ignore 1.18's generics for a moment) would not be a useful language at any significant scale. Why would go not have interfaces? Where did you make that up from? Go would have nominative interfaces Like most other languages.

[deleted]

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

#102

Post by ljloisnflwef »

kragen wrote: post #94

Hafiz writes: > almost every enterprise Java codebase I've had to work with has observed this pattern of testing whether an object is an instance of particular subclass, and using that to drive further computation. Even in the presence of such tests, Java demands that the author cast their objects appropriately. Of course you can always introduce an intermediate variable after the test, but I argue that this is still…

In this example, it's why Java added sealed interfaces, otherwise left with ∞ - 1 possibilities.

  if (!(node instanceof DomNode.Element)) {
    return new RenderNode.Noop(/* ... */);
  }
  Layout layout = node.layout;
  return new RenderNode.Styled(layout, /* ... */);

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

#103

Post by kragen »

ljloisnflwef wrote: post #102
kragen wrote: post #94

Hafiz writes: > almost every enterprise Java codebase I've had to work with has observed this pattern of testing whether an object is an instance of particular subclass, and using that to drive further computation. Even in the presence of such tests, Java demands that the author cast their objects appropriately. Of course you can always introduce an intermediate variable after the test, but I argue that this is still…

In this example, it's why Java added sealed interfaces, otherwise left with ∞ - 1 possibilities. if (!(node instanceof DomNode.Element)) { return new RenderNode.Noop(/* ... */); } Layout layout = node.layout; return new RenderNode.Styled(layout, /* ... */);

It's true that we return a `RenderNode.Noop` in ∞ - 1 cases, but that's okay because we're not making any demands of `node` there.

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

#104

Post by [deleted] »

epolanski wrote: post #95
xg15 wrote: post #55

Earlier quoted context omitted.

For consts and function arguments yes, I think. But you could have some mutable variable or field whose value depends on runtime state. In that case, you could have an actual polymorphic type.

But the previous example isn't that case. if (c.type === 'a') { /* c is of type A here */ } This is dynamic typing, this code is checked at runtime, and it's leveraged statically.

[deleted]

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

#105

Post by simulate-me »

xg15 wrote: post #98
epolanski wrote: post #95

Earlier quoted context omitted.

But the previous example isn't that case. if (c.type === 'a') { /* c is of type A here */ } This is dynamic typing, this code is checked at runtime, and it's leveraged statically.

Yes, that's correct. In the GP example, c was const, so the type can be determined at compile time.

I was writing TypeScript, where const just means the variable is not reassigned. For instance this is valid:

    const c: C = Math.random()

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

#106

Post by whimsicalism »

_old_dude_ wrote: post #41
valenterry wrote: post #12

The answer is simple: because other languages don't need it - they have different features to deal with it. The author even mentions it: pattern matching. Just that he picks a language that doesn't support union-types. But that doesn't mean that flow typing would be necessary here - it means that the language(s) should support union-types and extend their pattern matching accordingly. In fact, I would say that flow t…

You need flow typing when you do pattern matching on generalized abstract data type (GADT). Here is an example in Java sealed interface Foo permits Impl {} // union type record Impl() implements Foo {} // product type T m(Foo foo) { return switch(foo) { case Impl impl -> "hello"; // flow typing T=String }; }

that's not the same as what is defined in the article, and it is supported by plenty of languages

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

#107

Post by fourteenminutes »

jerf wrote: 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…

I entirely agree with you! And all of these are things covered in the post.

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

#108

Post by runald »

noveltyaccount wrote: post #35
cmrdporcupine wrote: post #29

So I've been working on a personal project which is in a mix of C++ and TypeScript -- partially because of practicality and partially to learn TypeScript, and I'm really liking the language. One question I have is whether there's any possibility that TypeScript could, in the long run, gain performance advantages over pure JS? That the compiler could leave behind some type information artifacts so that V8 (or similar)…

I really enjoy Typescript, but every time I use it I think to myself, this would be so much better if were built on top of something other than JavaScript. Maybe AssemblyScript or some other TS to WASM target will come along with a better underlying type system and a good standard library. Dare to dream.

Not quite what you are dreaming for, but there's https://typescripttolua.github.io/

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

#109

Post by alduin32 »

masklinn wrote: post #82
alduin32 wrote: post #71

Earlier quoted context omitted.

This is amazing, but I don't understand the justification : > Since their types specify the same length, the type-checker knows we can ignore the 'zip Nil Cons' or 'zip Cons Nil' cases. Specifically, I have trouble understanding "their types specify the same length". Whose types ?

The types of the vectors: the length is a generic parameter to the type. So a Vec 4 Int and a Vec 5 Int are different types .

Oh right, the output is parametrized by the input. I suppose this is what dependent types are.

That's really awesome. Thanks for the explanation.

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

#110

Post by cannabis_sam »

cmrdporcupine wrote: post #97
cannabis_sam wrote: post #70

Earlier quoted context omitted.

My view might of course be a bit outdated, do you have any examples? (Specifically for this point: “and follow them for typing”)

The example in TFA. TypeScript.

So my point stands…?
Post reply on HN