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

Re: Dynamic type systems are not inherently more open

#21

Post by radicalbyte » Sun, Jan 19, 2020, 1:08 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…

It's not so much allowing debt, it's that the barrier to entry is extremely low. You can hack around and get a feature "working" without having a great understanding of what you're actually doing.

Statically typed languages will confront you with a lot of obscure errors and just generally get in the way.

Eventually the good developers will eventually learn the language and get burnt by float32 / sql injection / xss / dates / not validating input and they'll learn enough to become extremely productive.

Static languages have evolved a lot; now the standard error messages are far better and the tooling is amazing. At the same time a lot of dynamic features - usually reflection based - have come along and provided their own breed of arcane and nutty rules and errors which seem designed to catch out only the strongest developers (the ones which break SOLID are the best!).

Re: Dynamic type systems are not inherently more open

#22

Post by falcor84 » Sun, Jan 19, 2020, 1:09 PM UTC

roenxi wrote: post #12

The_rationalist wrote: post #8

Earlier quoted context omitted.

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 public…

>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.

But this is exactly the GP's argument, no? According to the agile philosophy (and my personal experience), we don't have enough information at the start of the project to make right decisions about all parts of the implementation - so we try to decide about just the most crucial architectural aspects and make the rest as easy to change at possible, learning as we go.

From this perspective, the argument is that dynamic languages make it easier to postpone some decisions and allow us to quickly experiment with the things we've left flexible. And then, over time, once we're more confident in our decisions, we can put in the effort to repay this technical debt and lock things down to some desired level.

Re: Dynamic type systems are not inherently more open

#23

Post by thrwaway69 » Sun, Jan 19, 2020, 1:09 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…

One point based on my observation. Programmers coming from languages with good type system seems to have low probability of being a glueman. While good type system doesn't need to have static typing, in general they tend to have a way to explicitly declare things when you need to.

The current dynamic language ground is riddled with linters and additional tooling that static languages have solved already. This costs developer time (god, the amount of time people spend on writing an eslint config and selling it.)

Re: Dynamic type systems are not inherently more open

#24

Post by yen223 » Sun, Jan 19, 2020, 1:10 PM UTC

MaxBarraclough wrote: post #16

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.

In fairness, there's also a reason why correctness-oriented languages don't see a lot of use in the industry.

Re: Dynamic type systems are not inherently more open

#25

Post by mosselman » Sun, Jan 19, 2020, 1:11 PM UTC

I don’t like these types of articles. It feels like a straw man argument. Technically someone could have stated the claims made that are then refuted, because in today’s social media world there is always someone who has claimed something, but what is the value?

“No OOP is not dead because of Trump, here is why”

“No hacker news is not the new platform of the alt right, read why”

Re: Dynamic type systems are not inherently more open

#26

Post by bitwize » Sun, Jan 19, 2020, 1: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.

It's called Postel's law, and it's one of the burdensome idiocies Unix programmers have saddled us with, along with text-file formats and protocols, null-terminated strings, fork(2), and the assumption that I/O is synchronous by default.

Of course, once you adopt a "follow the spec or GTFO" stance, you reap other benefits as well; for example you are free to adopt a sensible binary format :)

Re: Dynamic type systems are not inherently more open

#27

Post by paganel » Sun, Jan 19, 2020, 1:13 PM UTC

MaxBarraclough wrote: post #16

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.

Almost nobody uses Ada, though, while one of the most read programming language-related websites (lambda-the-ultimate) is written in a dynamic language. Also, in the day-to-day interactions of the real world we almost never carry out “validation”, we stop at “parsing” most of the time, otherwise almost nothing will ever be done.

In other words “walks like a duck/quacks like a duck” is enough for most of the open world operations, no need for Platonic-like ideals or Aristotle-like categorizations. In the real world we can still use any piece of wood or stone as a table as long as food doesn’t fall off it, because said piece of wood/stone quacks and walks like a table, while Plato or Aristotle or most of the static type proponents would argue that we shouldn’t do that as that piece of stone or wood doesn’t have 4 legs and as such is not really a table/doesn’t correspond to the idea/type of a real table.

Re: Dynamic type systems are not inherently more open

#28

Post by bitwize » Sun, Jan 19, 2020, 1:13 PM UTC

yen223 wrote: post #24

MaxBarraclough wrote: post #16

Earlier quoted context omitted.

> 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.

In fairness, there's also a reason why correctness-oriented languages don't see a lot of use in the industry.

Because most programmers are sloppy.

When you can't afford to be sloppy -- when human lives are literally on the line -- correctness-oriented programming comes roaring back into vogue.

Re: Dynamic type systems are not inherently more open

#29

Post by UglyToad » Sun, Jan 19, 2020, 1:16 PM UTC

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 dynamically typed code written any time other than in the same session I have to load a whole mental model of the entire code, what types all the variables are, what expectations are attached to them, what mutation, if any, each method call performs. I suppose the trade-off is that advocates say you can prototype things more easily when requirements are not known.

With static typing I only need to load 2 things, the high level goal, what I need to achieve, and the local context where I need to make the change. The rest is taken care of by static typing, I can encode all that cognitive complexity in the types and I never need to think about it again. But as I say, that's how my brain works, yours might work differently and that's fine.

Re: Dynamic type systems are not inherently more open

#30

Post by nickik » Sun, Jan 19, 2020, 1:17 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.

In Clojure you generally accept any kind of map, do some operation and return 'copy' of that map, or pass it on.

A simple example is a ring web stack, where request flow threw different functions that transform the http request.

Each function just assumes the keys its needed are there, or to do input validation, you just validate that the incoming map has the keys that you require but does not care what else is in there. Clojure Spec will also do validation of the value in that key, even if it is an arbitrary complex map.

What this gets you is that you can pass around generic structures, that can be used with all standard Clojure functions and most libraries, validation is applied as needed on those keys that you need.