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

131–140 of 286 posts

Re: Dynamic type systems are not inherently more open

#131

Post by IceDane »

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.

Re: Dynamic type systems are not inherently more open

#132

Post by falcolas »

Every time this comes up, I think about how the pendulum swings back and forth. For example, if we take static and dynamic type systems in a slightly larger scope, we’ve just recently moved from a static system to a dynamic system, because the static system was being mis-used by “libraries”.

I’m speaking of the recent move to deprecate user agent strings, and the pushing of “feature detection”.

It’s just human nature in the end. We’re not computer. We will never use a static spec to its full potential; we’ll break a type system wide open the moment we get to our limit of tolerance for not getting the job done.

We need type inference more. The computer has built the AST, why do compliers seem so incapable of traversing that tree and finding the type errors for us?

Re: Dynamic type systems are not inherently more open

#133

Post by weberc2 »

sweeneyrod wrote: post #128

I don't think it makes much sense to compare between static and dynamic typing in general. Given the choice between static typing as in e.g. Java and dynamic typing in Python, I'd pick Python almost every time, because Java is just too verbose and the type system is kind of bad so the benefits are minimal anyway. But that's a false dichotomy: you can have static typing without the verbosity and with more significant…

It’s fine to compare static and dynamic, but it’s important to understand the things you are comparing so you don’t make silly (and very common) false dichotomies like the one you point out. The problem isn’t the comparison, but laziness.

Re: Dynamic type systems are not inherently more open

#134

Post by beders »

NicoJuicy wrote: post #40
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 actually rely on static typing to make architectural code changes. Why I would want to go to dynamic typing is beyond me. My performance/efficiency would greatly decrease. . The next change I will implement will likely be to not allow null in a property, which can be done in c# 8

The idea is that you wouldn't need large refactorings in more dynamic languages in the first place since you are operating on a different abstraction level.

Re: Dynamic type systems are not inherently more open

#135

Post by ookdatnog »

pizlonator wrote: post #99

Dynamic type systems are inherently more open. This article really bends over in strange ways to say otherwise. Fact is: dynamic typing is all about making fewer claims in your code about what you expect about the world around you. With dynamic types, to load a property you might just have to say the property name and receiver. With static types, you usually also have to say the type of all other properties of the re…

> Static type systems will typically require you to state the full type of o.

This is not the case for languages with support for structural typing (as the article mentions in the appendix), and most modern statically typed languages have some degree of support for abstract interfaces of some sort which also support writing functions with only partially known information about the type.

I think one of the core insights in the article is that your code will always make at least some assumptions about what it is processing (unless you're implementing the identity function, or a function which does not inspect its argument at all), and these assumptions are your type. So if you expect "o" to have a field called "f", and this field should return something on which a "+" operator is defined, then these properties form your type (in structural typing this is easy and boilerplate-free to express, with interfaces there's some boilerplate but it's definitely expressible).

In that light, the difference between static and dynamic typing isn't how many assumptions you make in your code, but rather how explicit you are about them, and to what extent you make your assumptions amenable to automated reasoning.

Re: Dynamic type systems are not inherently more open

#136

Post by kazinator »

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…

If you don't have to think about what mutation each method performs, if any, when switching to static typing, you're not just switching to static typing.

Re: Dynamic type systems are not inherently more open

#137

Post by ronanyeah »

thrwaway69 wrote: post #68
erdeszt wrote: post #50

Earlier quoted context omitted.

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.

I went from Node.js to Rust and this is what it sounds like to me.

Re: Dynamic type systems are not inherently more open

#138

Post by fanf2 »

bitwize wrote: post #26
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 :)

Posted was not a Unix programmer when he formulated his law

Re: Dynamic type systems are not inherently more open

#139

Post by duckerude »

zitterbewegung wrote: post #80
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).

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.

I don't have experience with it, but pytype can do that: https://github.com/google/pytype

After typechecking it leaves provisional stubs in .pytype/pyi/, and it has a tool to merge them into the original code.

mypy has stubgen: https://mypy.readthedocs.io/en/latest/stubgen.html

As far as I know it's less powerful since mypy isn't really built for unannotated code and pytype is.

Re: Dynamic type systems are not inherently more open

#140

Post by samatman »

yakshaving_jgt wrote: post #49
slifin wrote: post #42

Earlier quoted context omitted.

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.

Does it?

What happens to the example code if UserName is an Int?

Post reply on HN