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

Dynamic type systems are not inherently more open

lexi-lambda.github.io

Post reply on HN
Print view View original

11–20 of 286 posts

Re: Dynamic type systems are not inherently more open

#11

Post by zozbot234 »

phoe-krk wrote: post #3

Disclosure: dynamic typer here. The way I understand it, a part of the issue is about possibly deferring the time at which the type of data is known to the time at which the data is operated upon, since calling a numeric addition function on not-numbers, e.g. strings, is a type violation, no matter which programming language you are writing in. The question is where you want your parsing-or-validating to occur, since…

The author actually argues against Haskell as an example of their philosophy, because Haskell has poor support for open static types. They generally have to be faked in unintuitive ways by relying on the typeclasses feature, and something like OCaml's support for structural, extensible records and variants seems to be entirely off limits out-of-the-box.

Re: Dynamic type systems are not inherently more open

#12

Post by roenxi »

The_rationalist wrote: post #8
ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

According to this, languages statically typed but offering a dynamic type (any in typescript) allow best of both world. And using the right types is a matter of refactoring.

Which is entirely plausible. If all the decisions about what data should be flowing where in a program have been made there is no particular reason not to have static typing. It won't make things worse, will enforce discipline and will probably catch bugs.

As far as static types are feasible they are great to have. Clojure's spec is the gold standard I work to; if anyone has a better system it needs a lot more publicity.

Re: Dynamic type systems are not inherently more open

#13

Post by tsimionescu »

Ari_Rahikkala wrote: post #4

"Nitpickers will complain that this isn’t the same as pickle.load(), since you have to pass a Class token to choose what type of thing you want ahead of time. However, nothing is stopping you from passing Serializable.class and branching on the type later, after the object has been loaded." Is that actually true in Java? It seems to me that the way that you'd implement that load() method is by using generics to inspe…

Hmm, that may be true for JSON, but I think that Java binary serialization holds enough information about the original types to allow deserialization without having to explicitly pass the expected class (though what the runtime system does behind the scenes may be equivalent).

Re: Dynamic type systems are not inherently more open

#14

Post by pchiusano »

ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

It’s true that with static typing, you are usually forced to propagate your changes to “your whole codebase” to get it compiling before you can run any of it. That stinks. However, it turns out you can lift this restriction in static languages, and this is what Unison does:

https://www.unisonweb.org/docs/refactoring

In Unison you can implement a change and propagate it just far enough to run one little experiment. There’s no need to upgrade all your code at once.

Re: Dynamic type systems are not inherently more open

#15

Post by toastal »

david_draco wrote: post #10
ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

Interesting, I would have said static typing allows more technical debt. Illustrating example: Lets say you pass a double variable from some part of your code through 13 layers of APIs until it is actually looked at and acted upon. Now you realise that you not only need a double, but also a boolean. In dynamic typing, you can make a tuple containing both and only modifying the beginning and end points. In static typi…

And on layer 10 you missed that you were using and treating the argument as if it were the double. Now you have a bug that the type system would have solved. Or you can alias that input early if you know with a good certainty it has possiblity to change, and now you just update the alias and everything gets checked all the way down without a refractor.

Re: Dynamic type systems are not inherently more open

#16

Post by MaxBarraclough »

youerbt wrote: post #7

This "be liberal in what you accept" idea, applied to modern programming, always struck me as strange. Yes, taking an unknown structure in your program is the easy part. Programming against an unknown structure is where the problem lies. I'd love to hear more examples of programming against such input that are beneficial over "parse don't validate" idea.

> This "be liberal in what you accept" idea, applied to modern programming, always struck me as strange.

Agreed. There's a reason that serious correctness-oriented languages, like Ada, do not use this approach.

Re: Dynamic type systems are not inherently more open

#17

Post by rightbyte »

ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

You could to a temporary inherited class and later delete it and merge the change into the parent class, in a static OOP language.

Re: Dynamic type systems are not inherently more open

#18

Post by zozbot234 »

The_rationalist wrote: post #8
ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

According to this, languages statically typed but offering a dynamic type (any in typescript) allow best of both world. And using the right types is a matter of refactoring.

The hard part is not offering a "dynamic" type (which is generally just a variant type with a bunch of RuntimeType cases) but making the "static" and "dynamic" portions of the language truly, tightly interoperable. Generally, this implies that the compiler and runtime system should be able to correctly assign "blame" to some dynamic part of the program for a runtime type error that impacts "static" code, and this can be quite non-trivial in some cases.

Re: Dynamic type systems are not inherently more open

#19

Post by codeflo »

david_draco wrote: post #10
ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

Interesting, I would have said static typing allows more technical debt. Illustrating example: Lets say you pass a double variable from some part of your code through 13 layers of APIs until it is actually looked at and acted upon. Now you realise that you not only need a double, but also a boolean. In dynamic typing, you can make a tuple containing both and only modifying the beginning and end points. In static typi…

It’s often considered bad practice to pass around raw values for that very reason. Introduce a (minimal) abstraction, that is, give the thing you’re passing through those layers a name. Then you can change the endpoints at will and still get static checking (as a plus, you can‘t accidentally pass the wrong bool, or mix up the tuple order).

I agree with the GP‘s point that static typing forces you to do that kind of design work earlier.

(Edit: You raise a good point, though. I think a lot of people run into this kind of problem with static typing.)

Re: Dynamic type systems are not inherently more open

#20

Post by k__ »

toastal wrote: post #15
david_draco wrote: post #10

Earlier quoted context omitted.

Interesting, I would have said static typing allows more technical debt. Illustrating example: Lets say you pass a double variable from some part of your code through 13 layers of APIs until it is actually looked at and acted upon. Now you realise that you not only need a double, but also a boolean. In dynamic typing, you can make a tuple containing both and only modifying the beginning and end points. In static typi…

And on layer 10 you missed that you were using and treating the argument as if it were the double. Now you have a bug that the type system would have solved. Or you can alias that input early if you know with a good certainty it has possiblity to change, and now you just update the alias and everything gets checked all the way down without a refractor.

AFAIK, the problem here isn't "bad static typing" but "bad type inference"

If you only have to write the type once at the top of the 10 layer, you don't have to do much to change it.

Post reply on HN