Dynamic type systems are not inherently more open • Hacker News Board

Re: Dynamic type systems are not inherently more open

#121

Post by scarmig » Sun, Jan 19, 2020, 3:47 PM UTC

pizlonator wrote: post #99

Dynamic type systems are inherently more open. This article really bends over in strange ways to say otherwise. Fact is: dynamic typing is all about making fewer claims in your code about what you expect about the world around you. With dynamic types, to load a property you might just have to say the property name and receiver. With static types, you usually also have to say the type of all other properties of the re…

Structural static typing lets you do exactly what you claim static type systems are incapable of letting you do. It's fair to say those systems are not common--Typescript is the only one I know of--and I wonder why that is, but it's not an inherent failure of static type systems.

Re: Dynamic type systems are not inherently more open

#122

Post by UglyToad » Sun, Jan 19, 2020, 3:48 PM UTC

nhumrich wrote: post #116

UglyToad wrote: post #29

I think there's a perhaps irreconcilable disconnect between 2 camps here, but I also think that's ok and different people are allowed to like different things. My experience, having gone from dynamic typing to static typing and now pining for more expressive type features in my chosen language is that static typing changes where you have to spend the cognitive complexity budget. To my mind if I return to a piece of d…

Your comment is spot on. But the opposite can also be true. I totally have the same issues you do at times by trying to understand types (which I feel type hinting, editors, and good variables names go a long way to help with). But I also find myself using a lot of cognitive load trying to get a correct type definition, etc (for the non simple tasks). Whether its trying to figure out how to get a certain object, beca…

Agreed, perhaps it's something like the difference between top-down vs bottom-up learning in teaching. People don't all use the same mental models and allowances need to exist for both groups. But I suspect this is true of most contentious topics in programming.

For what it's worth I definitely agree there can be a lot of overhead added by typed code especially in Java or C#, but I suspect it might have less to do with the type system and more with the enterprise-ness or otherwise of those code-bases. Designing a good typed API for other people maintaining the same code-base is difficult

Re: Dynamic type systems are not inherently more open

#123

Post by andrepd » Sun, Jan 19, 2020, 3:51 PM UTC

rwmj wrote: post #57

amelius wrote: post #48

Earlier quoted context omitted.

Yes, some programming languages take this approach but I don't think that prototyping is as easy in such languages as it is in a dynamically typed language (e.g. Haskell vs Python).

When writing OCaml, if I'm unsure of the type I set the type to some impossible value, compile it, and the compiler tells me what the type really is.

Alternatively, merlin can tell you the type of the expression under your cursor, besides also flagging type mismatches like your situation.

Re: Dynamic type systems are not inherently more open

#124

Post by ukj » Sun, Jan 19, 2020, 3:55 PM UTC

yakshaving_jgt wrote: post #88

ukj wrote: post #82

This is so predictable. 1. Author attacks premise of dynamic type systems argument. 2. Author presents premise for static type system (which is practically confluent/equivalent/equifinal to premise he just undermined). >static type systems allow specifying exactly how much a component needs to know about the structure of its inputs, and conversely, how much it doesn’t. Indeed, in practice static type systems excel at…

This is so predictable. 1. HN commenter misses the point of the article. 2. HN commenter even misgenders the article's author.

At #1 you were stretching for a retort. At #2 it became apparent you've run out of relevant critique.

Re: Dynamic type systems are not inherently more open

#125

Post by sweeneyrod » Sun, Jan 19, 2020, 3:59 PM UTC

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…

You could also only modify the endpoints in a statically typed language with type inference.

Re: Dynamic type systems are not inherently more open

#126

Post by nearbuy » Sun, Jan 19, 2020, 4:02 PM UTC

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…

The trade-off is that the bugs flagged by static type checking are usually quick to fix (eg: function expected an int but was passed a float). With dynamic typing, the subtle bug that arises from the function unexpectedly truncating your float could take an hour to track down and outweigh any time saved from dynamic typing. This applies even when trying out new experimental features.

Re: Dynamic type systems are not inherently more open

#127

Post by iamflimflam1 » Sun, Jan 19, 2020, 4:03 PM UTC

I have developed and maintained several large systems in both dynamic and statically typed languages.

From a maintenance point of view, the statically typed ones definitely win out.

Trying to reason about bits of code with no idea what was supposed to be passed in. Working out which bits of code are actually dead and can be safely removed. Refactoring bits of code. All incredibly difficult in the dynamically typed systems.

Given the choice, I would not embark on a large complex system without the benefit of a strongly typed language.

Re: Dynamic type systems are not inherently more open

#128

Post by sweeneyrod » Sun, Jan 19, 2020, 4:07 PM UTC

I don't think it makes much sense to compare between static and dynamic typing in general. Given the choice between static typing as in e.g. Java and dynamic typing in Python, I'd pick Python almost every time, because Java is just too verbose and the type system is kind of bad so the benefits are minimal anyway. But that's a false dichotomy: you can have static typing without the verbosity and with more significant benefits (like no null pointer exceptions) by using something like OCaml.

Re: Dynamic type systems are not inherently more open

#129

Post by samatman » Sun, Jan 19, 2020, 4:09 PM UTC

This is a decent description of how to handle unwrapping a payload in a language with ADTs.

The swipe at Rich Hickey at the beginning is ill-considered, however. This is the sort of use case that clojure.spec is designed for, and it can, and does, handle validation at an equivalent level of detail.

You can watch him building his speaking career on the emotional appeal of specifying the types of your payloads here: https://vimeo.com/195711510

Re: Dynamic type systems are not inherently more open

#130

Post by cobbzilla » Sun, Jan 19, 2020, 4:12 PM UTC

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.

Who’s applying Postel’s Law to programming? Citation please.

It was intended for network protocols/distributed systems communications — situations with extremely loose coupling between components. It’s useful in this very specific paradigm, not for arbitrarily programming anything.