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

61–70 of 286 posts

Re: Dynamic type systems are not inherently more open

#61

Post by sethammons »

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'd love Perl. Just pass @_ through your callstack. Want a new value available 20 functions deep that is available at the top? Just toss it in @_ at the top and you are done.

The problem? Every one of your 20 levels of functions/subroutines has an unnamed grab bag of variables. You get to keep that in your head. If you want to know if you have a value in a given branch of code, your best bet, aside from reading the code of the entire callstack, is to dump @_ in a print statement and run the entire program and get it to call the function you are in. Oh, and if one of those values contains a few screens worth of data, you will need to filter that out manually. Even "documentation" in the form of comments or tests will be unreliable due to comment-rot or mocked test assumptions.

Even in Python, I'll often have to go up the callstack to know what a named parameter actually is. And if similar shenanigans are going on, I again have to pull out a debugger or print statements to know what I can do with an argument.

With a static type, I see plain as the text on my screen what type I have as a parameter and I immediately know what I can do with it. As weak as Go's type system is, it is worlds better than Perl and Python for maintaining and creating large, non-trivial codebases. The price is passing it around at the time of writing.

Re: Dynamic type systems are not inherently more open

#62

Post by brainbag »

alerighi wrote: post #33

Recently I worked on a project where initially we though about writing it in Rust, because why not, it seemed initially a good idea. It turned out to be a completely wrong idea. The project was a simple web API, nothing fancy, GraphQL and a SQL database. After a lot of frustrations we decided it to rewrite everything in TypeScript and did that in a week. TypeScript gives you the benefit of statically typed languages…

Which particular TypeScript ORM and web stack did you go with?

Re: Dynamic type systems are not inherently more open

#63

Post by wizzwizz4 »

yakshaving_jgt wrote: post #46
pchiusano wrote: post #14

Earlier quoted context omitted.

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

It stinks how? You can see those type errors at compile time, or your users can see those type errors at runtime. One of those is worse.

This is talking about the case where you're just testing something out – prototyping it for a few branches before implementing it for the whole thing. In this case, _you_ are your own user, so it doesn't matter if you see the type errors.

Re: Dynamic type systems are not inherently more open

#66

Post by ken »

amelius wrote: post #43
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…

Yes. Perhaps this is an indication that we actually need automated type annotation. E.g. you initially write/prototype your program in a dynamically typed form, then you click a "magic" button, and a tool converts your program into statically typed style.

You mean a compiler?

Re: Dynamic type systems are not inherently more open

#67

Post by chongli »

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 mistake! While that feeling is common and valid as you’re learning the language, when you become fluent you see the compiler as more of an ally. You can call on it with a keystroke and it will find many problems that would otherwise only happen at runtime, possibly months or even years in the future!

Moreover, in more advanced languages (such as dependent typed languages), the compiler can actually infer the body of your functions which leads to a totally different style of programming that feels like a snippet plugin on steroids.

Re: Dynamic type systems are not inherently more open

#68

Post by thrwaway69 »

erdeszt wrote: post #50
alerighi wrote: post #33

Recently I worked on a project where initially we though about writing it in Rust, because why not, it seemed initially a good idea. It turned out to be a completely wrong idea. The project was a simple web API, nothing fancy, GraphQL and a SQL database. After a lot of frustrations we decided it to rewrite everything in TypeScript and did that in a week. TypeScript gives you the benefit of statically typed languages…

Why did you decide to use a system programming language to build a web api? That's 100% the wrong tool for the job.

In their defence, rust is alright to spin up simple APIs or even complex backends. It wouldn't take me more than a few hours to write a small graphql api in rust.

If they decided to write an API in rust just because, chances are it's not anything important (I hope). From their post, it seems like lack of familiarity is the core issue.

Re: Dynamic type systems are not inherently more open

#69

Post by yakshaving_jgt »

wizzwizz4 wrote: post #63
yakshaving_jgt wrote: post #46

Earlier quoted context omitted.

It stinks how? You can see those type errors at compile time, or your users can see those type errors at runtime. One of those is worse.

This is talking about the case where you're just testing something out – prototyping it for a few branches before implementing it for the whole thing. In this case, _you_ are your own user, so it doesn't matter if you see the type errors.

If I’m making a potentially wide-reaching change, I’d want to test it against everything else so I know for sure that it’s actually viable in the context of every instance of its use.

Also, some statically-typed languages (like Haskell) allow you to defer type errors to runtime if you really want.

Re: Dynamic type systems are not inherently more open

#70

Post by hnra »

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.

I Haskell you simply put a "_" in the annotation and the compiler suggests the correct type.
Post reply on HN