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

141–150 of 286 posts

Re: Dynamic type systems are not inherently more open

#141

Post by marcosdumay »

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…

Yet, dynamic types make it much more to refactor your software. So that technical debt costs way more to fix.

Re: Dynamic type systems are not inherently more open

#142

Post by samatman »

IceDane wrote: post #131
samatman wrote: post #129

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: ht…

I don't think this is a swipe at Rich Hickey, unless it's considered a swipe to call someone out for repeatedly making misinformed statements about things they don't understand properly.. which is what Hickey does a lot in his talks, about Haskell's type system in particular.

The author says that Rich Hickey has built a speaking career on emotional appeals to the superiority of dynamic types.

I would prefer to say that Rich Hickey has built a dynamic programming language which includes a powerful typing system and that he's largely responsible for its design.

It's difficult to reconcile those two statements.

Re: Dynamic type systems are not inherently more open

#143

Post by throwaway17_17 »

EDIT: I was in a snarky mood earlier when I wrote this comment, I was tempted to just delete it, but I’ll leave the text as a reminder to myself to find better wording for comments despite my personal mood in the future.

I clearly do not understand the overwhelmingly dedication type system proponent have against dynamic languages, particularly as evidenced by the previous comments in this thread. I would note that it seems to be the same, but reversed, for proponents of dynamic languages. Other than two or three mentions of Rust, all the examples and discussions have been about primarily interpreted or JIT languages with extensive runtimes. So there is little argument that these type systems are saving users (and I mean developers) from “memory safety” bugs or potential vulnerability exposing errors (those would tend to be problems with the interpreter/runtime implementation).

Maybe I’m missing something, but if we are talking about managed language runtimes and, again based on the languages dominating the discussion, are nearly universally garbage collected, who cares what, if any, type system is in use for a given program?

I don’t know for certain (I don’t do any web based work) but I can’t recall ever reading about using typescript to boost speed or memory efficiency over vanilla JS. There is some performance benefit to say compiled Haskell vs interpreted Python, but that is apples and oranges, but based on a limited amount of googling, it looks like Clojure and Haskell are reasonably close for performance concerns.

Also, most of the type systems being discussed are complex and high level, so where does C and C++ fit into this topic? They are statically typed languages (I am aware the type systems used are fundamentally weaker than those of HM type systems) but no one seems to be arguing that they are good examples of why static typing is beneficial. Rust, while a more typical functional programming style type system, is still not really being discussed. I know that the article doesn’t address these areas or languages, but for those advocating so strongly for types, why no present something other than technical debt, easier reading, and organizational benefits. For dynamic proponents, why not address the lack of user visible benefits, i.e. no real performance win in common usage scenarios, the lack of assistance weaker type systems give to protect from differing types of errors, etc.

All I can tell is that some people like types and some people don’t. And most of the discussion seems to center on your standard CRUD app, web based applications, does it even matter?

Re: Dynamic type systems are not inherently more open

#144

Post by cryptica »

cryptica wrote: post #35

>> but they simultaneously advance an implicit belief: that dynamically typed languages can process data of an unknown shape. The real difference is that dynamic type systems don't pretend to. Static type systems have a way of putting developers at ease on auto-pilot. Arguments which compare dynamic type systems with static type systems should be more focused on reality rather than hypothetical, idealized use cases w…

>> I would even argue that dynamic typing can encourage worse design

I meant static typing... By making it easy to keep track of interfaces/types, it creates incentives to create more different kinds of abstractions.

Re: Dynamic type systems are not inherently more open

#145

Post by _pmf_ »

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…

> 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 typing you have to alter/refactor the type everywhere.

Adding a double and boolean field to a Context object, I don't have to touch anything at the intermediary API layers. Just as with your tuple/dict.

Re: Dynamic type systems are not inherently more open

#146

Post by iovrthoughtthis »

I would posit that, the more specific the rules of a system, the fewer behaviours can be expressed by it.

When a language restricts the usage of things by the type of thing being used, it restricts the set if behaviours that can be expressed in that language.

You can get around this by adding more rules to specify the behaviours needed. (Boilerplate?)

In this way, a dynamic language permits more behaviours with less rules. It is more “expressive”.

This can be good and bad, some of those behaviours are probably unwanted!

And this is just a theory.

Re: Dynamic type systems are not inherently more open

#147

Post by dboreham »

nearbuy wrote: post #126
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.

You're supposed to have written a test that catches that bug. Which of course also takes more time and effort than simply using a type checker in the compiler of a typed language..

Re: Dynamic type systems are not inherently more open

#148

Post by arminiusreturns »

chongli wrote: post #67
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 isn’t even a benefit, really. Statically typed languages don’t force you to model things with types; you’re completely free to use strings and doubles everywhere and take on all the technical debt you want. People who are only used to dynamic languages may feel like a static language’s type checker is an overbearing teacher (from the 1950s) standing over your shoulder, just waiting to jump on you for every silly m…

What about JIT things like lisps? Maybe the benefits of dynamic typing are more geared towards things with a repl in particular?

Re: Dynamic type systems are not inherently more open

#149

Post by jmull »

yakshaving_jgt wrote: post #117
jmull wrote: post #97

The author doesn’t really address the issue raised in the first (longer) quoted post. Given a set of reasonable requirements I think pretty much no one would claim a general-purpose language couldn’t satisfy them without too much trouble. In fact, that might be a fair definition of a general-purpose language. I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as…

> I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as you use it in a distributed environment: the guarantees are static. They pertain only to your little binary and don’t say anything about the rest of the system. To argue that a static type system is not valuable because it doesn't enforce constraints on other external systems it doesn't know about is a pret…

> To argue that a static type system is not valuable

I didn’t.

Re: Dynamic type systems are not inherently more open

#150

Post by hhas01 »

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…

Yep. Being able to work fast and dirty is a huge boon when testing ideas and figuring out the initial design, and it is deeply annoying that so many typed languages refuse to permit this. The faster you can write code, the faster you can throw it away again; and arriving at good code almost invariably requires† writing lots of bad code first. If writing bad code is made expensive (another example of Premature Optimization), authors may be reluctant to try different ideas or throw anything away.

Ideally, you want a language that starts out completely untyped, efficient for that initial “sketching in code” phase. Then, as your program takes shape, it can start running type inference with warnings only, to flag obvious bug/coverage issues without being overly nitpicky. Then finally, as you refine your implementation and type-annotate your public APIs (which does double-duty in documenting them too), it can be switched to reporting type issues as errors.

Unfortunately, a lot of typed languages behave like martinets, and absolutely refuse to permit any such flexibility, dragging the entire process of development down their level of pedantry and generally making early development an almighty ballache. Conversely, untyped languages provide sod all assistance when tightening up implementation correctness and sharpening performance during late-stage development; it’s pure pants-down programming right to the bitter end.

Mind you, I think this says a lot more about programmers (particularly ones who make programming languages) than it does about languages themselves.

--

† (Unless, like, you’re Donald Knuth.)

Post reply on HN