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

Re: Dynamic type systems are not inherently more open

#71

Post by pchiusano » Sun, Jan 19, 2020, 2:38 PM UTC

simias wrote: post #45

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…

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

I’d read through the link and see what you think, but TL;DR is that you can still propagate a change everywhere in Unison (and Unison tracks this for you), but even if you’ve partially propagated, you can run all the code that you’ve upgraded so far. So if a change has 500 transitive dependents and you upgrade 7 of them, you can run those 7 (and this might help you figure out that you want to do the change a bit differently) Whereas you’d typically need to upgrade “the whole codebase” before being able to run anything, including code unrelated to the change being made.

Re: Dynamic type systems are not inherently more open

#72

Post by andybak » Sun, Jan 19, 2020, 2:39 PM UTC

Having moved from Python to C# I'm still coming to terms with how I feel.

It's really hard to express but I do have a nagging feeling that something has been lost that other commentators haven't quite put into words either. You just write different code in dynamic languages - even ignoring type declarations. And in many cases it feels like better, more humane code.

One piece of evidence for this elusive difference is my observation that API's in Python tend to much nicer and much less verbose (again - ignoring the obvious differences based directly on type declarations). APIs tend to feel like they were designed for usability rather than mapping directly on to library code and user be damned.

Is this a cultural difference or does something about static typing lead to different patterns of thought?

Re: Dynamic type systems are not inherently more open

#73

Post by dboreham » Sun, Jan 19, 2020, 2:39 PM UTC

yakshaving_jgt wrote: post #56

fendy3002 wrote: post #41

Earlier quoted context omitted.

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

This is absolutely false. Not a single word you have written in this comment is true. This is a pervasive myth that you are perpetuating. If you had read the article, you would know that what you have said is demonstrably false. There is nothing stopping you from operating on arbitrary JSON in Haskell. Literally nothing.

I suspect the parent wants to convert between JSON and typed records without needing the JSON to conform to the type.

Re: Dynamic type systems are not inherently more open

#74

Post by yakshaving_jgt » Sun, Jan 19, 2020, 2:40 PM UTC

amelius wrote: post #48

zitterbewegung wrote: post #44

Earlier quoted context omitted.

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

In my experience (currently writing Haskell professionally, previously writing Ruby professionally) prototyping is easier in Haskell.

How many systems have you prototyped in Haskell?

Re: Dynamic type systems are not inherently more open

#75

Post by sethammons » Sun, Jan 19, 2020, 2:41 PM UTC

fendy3002 wrote: post #41

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

We switched out some API code from Perl and Python to Go. JSON has been a pain at times for sure. Arbitrary nesting, values that are sometimes strings or sometimes integers (3 vs "3"), dynamic keys, and null vs zero value. These JSON structures were much easier to deal with before because we could be sloppy. Having to have a typed schema was a pain at first, but we love it after. And better yet, we can be confident of the values that we emit and our customers (internal and external) can be now use something statically typed if they like as we did all the heavy lifting.

Re: Dynamic type systems are not inherently more open

#76

Post by mmis1000 » Sun, Jan 19, 2020, 2:42 PM UTC

Ari_Rahikkala wrote: post #4

"Nitpickers will complain that this isn’t the same as pickle.load(), since you have to pass a Class token to choose what type of thing you want ahead of time. However, nothing is stopping you from passing Serializable.class and branching on the type later, after the object has been loaded." Is that actually true in Java? It seems to me that the way that you'd implement that load() method is by using generics to inspe…

Java will crash if type actually does not match at runtime. You can do whatever cast you want to it ,but it is not necessary to work.

And kotlin even includes a key word to say: if cast does not work, just return null.

Re: Dynamic type systems are not inherently more open

#77

Post by thrwaway69 » Sun, Jan 19, 2020, 2:42 PM UTC

brainbag wrote: post #62

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?

Not GP but I am guessing Apollo/express + typeorm and typegrapqhl

Or something like prisma - https://github.com/prisma/prisma2

Re: Dynamic type systems are not inherently more open

#78

Post by galangalalgol » Sun, Jan 19, 2020, 2:42 PM UTC

caseymarquis wrote: post #39

david_draco wrote: post #10

Earlier quoted context omitted.

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…

I think at that point you probably need a major refactor, regardless of the language being used. While I don't want to be in that situation, I'll typically use a helper class if I'm forced to pass something through 13 layers (a class containing all the arguments). However, that's pretty much the textbook example for designing with dependency injection in mind. Static typing won't fix a terrible architecture.

I haven't read that textbook. Do you have a good reference. I may have been intentionally been using an anti pattern. I often have a POD class that gets passed down a processing chain.

Re: Dynamic type systems are not inherently more open

#79

Post by fctorial » Sun, Jan 19, 2020, 2:42 PM UTC

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…

What problems did you encounter while writing your app in rust?

Re: Dynamic type systems are not inherently more open

#80

Post by zitterbewegung » Sun, Jan 19, 2020, 2:43 PM UTC

amelius wrote: post #48

zitterbewegung wrote: post #44

Earlier quoted context omitted.

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

What would be neat is if you could take a Python program and run type inference on the program and it would output a type annotated version of the code.