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

41–50 of 286 posts

Re: Dynamic type systems are not inherently more open

#41

Post by fendy3002 »

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…

To add to this, dynamic typing is proper tool to use for API, because the input payload is just formatted text, without / with very few type definition. My experience said that it's hard to play with JSON on static typing, without adding a strict data validation / conversion at the start. Serialization comes with a set of strict rules that need to follow and state beforehand too.

The contrary, on dynamic typing language nested object as well as array can easily be parsed natively and be used immediately.

Re: Dynamic type systems are not inherently more open

#42

Post by slifin »

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.

Most Clojure teams I speak to spec their input using Clojure spec, then they get custom recursive error reporting, validation, coercion and generators

Clojure specifications can also be converted into other forms of specification like graphql schema, database schema, json schema etc

The best I've seen a type system do on user input is blow up at runtime and that's not good enough for me

Re: Dynamic type systems are not inherently more open

#43

Post by amelius »

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.

Re: Dynamic type systems are not inherently more open

#44

Post by zitterbewegung »

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.

Using Type inference[1] on a language could be able to figure out types in most situations.

[1] https://en.wikipedia.org/wiki/Type_inference

Re: Dynamic type systems are not inherently more open

#45

Post by simias »

pchiusano wrote: post #14
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. Th…

I haven't given Unison a try so I won't dismiss it outright but to me having to explicitly propagate your change to your entire codebase before you can run anything doesn't suck at all, it's actually the killer feature of statically typed languages.

I've written big applications in python, every time I made a significant architectural change (which might not even be huge code-wise, just far-reaching) I feel super uncomfortable. I know that I have to follow up with an intense testing session to make sure that I go through all code paths and everything still works correctly. Even then sometimes the testing is not thorough enough and you end up with a regression in production.

As a result I tend to avoid these types of changes as much as possible, even I believe that the application would benefit from them.

Meanwhile in Rust it's a breeze. Yesterday I decided to make a small but far-reaching change in an emulator I'm writing: instead of signaling interrupts by returning booleans, I'd return an "IrqState" enum with a Triggered and an Idle variants. It's more explicit that way, and I can mark the enum "must_use" so that the compiler generates a warning if some code forgets to check for an interrupt.

It's like 4 lines of code but it means making small changes all over the codebase since interrupts can be triggered in many situations. In Python that'd be a pain, in Rust I can just make the change in one place and then follow the breadcrumbs of the compiler's error messages. Once the code builds without warnings I'm fairly certain that my code is sound and I can move on after only very superficial testing.

Re: Dynamic type systems are not inherently more open

#46

Post by yakshaving_jgt »

pchiusano wrote: post #14
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. 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.

Re: Dynamic type systems are not inherently more open

#47

Post by thrwaway69 »

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…

> writing it in Rust, because why not

I think this is the problem rather than static typing or rust.

Can you tell me what do you want your ORM to do?

Re: Dynamic type systems are not inherently more open

#48

Post by amelius »

zitterbewegung wrote: post #44
amelius wrote: post #43

Earlier quoted context omitted.

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.

Using Type inference[1] on a language could be able to figure out types in most situations. [1] https://en.wikipedia.org/wiki/Type_inference

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

Re: Dynamic type systems are not inherently more open

#49

Post by yakshaving_jgt »

slifin wrote: post #42
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.

Most Clojure teams I speak to spec their input using Clojure spec, then they get custom recursive error reporting, validation, coercion and generators Clojure specifications can also be converted into other forms of specification like graphql schema, database schema, json schema etc The best I've seen a type system do on user input is blow up at runtime and that's not good enough for me

> The best I've seen a type system do on user input is blow up at runtime and that's not good enough for me

Then you haven’t been looking closely enough. The article addresses exactly this wrong argument.

Re: Dynamic type systems are not inherently more open

#50

Post by erdeszt »

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.
Post reply on HN