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

181–190 of 286 posts

Re: Dynamic type systems are not inherently more open

#181

Post by hhas01 »

brabel wrote: post #166
hhas01 wrote: post #150

Earlier quoted context omitted.

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

If you think it helps to quickly write some code without types (I don't really agree with that in general, maybe in some specific cases), but you want to, when you're happy with the design, just add the types, there are many languages that support that! On the top of my head: * Dart (just don't give a type and the variable is dynamic) * Groovy (add @CompileStatic or @TypeChecked when you're ready) * Racket (start usi…

Yeah, it’s not a new idea; but I’d say “some” languages rather than “many”. Dylan’s another case; great pity it didn’t fare better. (I’d much rather be using it than Swift.)

Also, none of them are in the mainstream, which creates general challenges to adoption. Fortune favors the entrenched.

...

Another thing worth considering IMO is structural rather than nominal typing, which fits more with the “if a value looks right, it is” philosophy that untyped language aficionados enjoy without going for full-on pants-down duck-typing. ML favors this, IIRC (I really must learn it sometime).

I find nominal typing can get a bit excessively OCD, demanding so much additional annotation as to obscure the code as much as clarify (“Hi, Swift stdlib!”).

I also wouldn’t mind being able to define sets of permitted type mappings in advance, and letting the compiler figure out where in the code to insert (implicit) casts. For instance, if I’m passing a variable typed as integer where a float/string is expected, it really wouldn’t kill it to promote it automatically; most are perfectly happy to promote integer literals where a float is required after all. (And if I do want to know about it, which I usually don’t, I can always turn warnings/errors on.)

Re: Dynamic type systems are not inherently more open

#182

Post by mpweiher »

brabel wrote: post #166
hhas01 wrote: post #150

Earlier quoted context omitted.

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

If you think it helps to quickly write some code without types (I don't really agree with that in general, maybe in some specific cases), but you want to, when you're happy with the design, just add the types, there are many languages that support that! On the top of my head: * Dart (just don't give a type and the variable is dynamic) * Groovy (add @CompileStatic or @TypeChecked when you're ready) * Racket (start usi…

* Objective-C

Re: Dynamic type systems are not inherently more open

#183

Post by Silhouette »

pron wrote: post #95
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…

Not all untyped languages are the same. E.g. Clojure now encourages specifying assumptions with spec annotations, some of them are stronger than those that can be expressed by Haskell's type system: i.e. they can succinctly express more about the "entire code" than Haskell's types. Types are not the only way to write formal assertions and assumptions about code. The difference between the two is in the level of sound…

My guess is that types would be better for enforcing code organization and for tooling ... while contracts are better for correctness

I see what you're getting at, but there is one other crucial difference: the types we're talking about here are usually checked at compile time, whereas the contracts we're talking about here are usually checked at run time. Although the latter may be more expressive if other things are equal, other things are very much not equal in this respect.

How much that matters depends on the nature of the software and how it is to be deployed and used. If you're writing a program for your own use, it might not matter much at all. If you're writing a program that is going to control a satellite and software maintenance after launch is extremely expensive if not impossible, it might matter a great deal.

Re: Dynamic type systems are not inherently more open

#184

Post by dllthomas »

hopia wrote: post #119
capableweb wrote: post #100

Earlier quoted context omitted.

Also, the following part isn't necessarily because of dynamic typing vs static > what types all the variables are, what expectations are attached to them, what mutation, if any, each method call performs But more about what the language offers. Clojure for example, goes beyond types with it's abstractions (like seq, that can be applied to strings, lists, maps and so on) and normally stays away from mutation, but when…

What do you mean with going beyond types? Is it possible to define some unique compile time constraints on Clojure not related to the type system?

When spec was proposed I remember some talk of compile-time checking of some annotations. I don't know whether anything came of that, but in theory it would allow what you're talking about. That has no relation to seq, though, which is the kind of thing supported by many statically typed languages.

Re: Dynamic type systems are not inherently more open

#185

Post by haizan »

falcolas wrote: post #132

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…

It seems to me that your user agent example fits better on the structural/nominal typing dichotomy, rather than static/dynamic.

Re: Dynamic type systems are not inherently more open

#186

Post by dllthomas »

yakshaving_jgt wrote: post #74
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).

In my experience (currently writing Haskell professionally, previously writing Ruby professionally) prototyping is easier in Haskell. How many systems have you prototyped in Haskell?

> prototyping is easier in Haskell

That's very much my experience, as well. Assuming - and it's a very big assumption - that your use case has equivalent library support.

Re: Dynamic type systems are not inherently more open

#187

Post by dllthomas »

hopia wrote: post #96
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).

Productivity can be really subjective. Those that are used to modeling the problem domain with the type system find that their most productive approach, even with prototyping.

Right, and the type system is such a big help in refactoring - especially in small projects - that you don't have to be all that right in your first N cuts at the model. You can write code and find out where you're wrong, and fix it fast.

Re: Dynamic type systems are not inherently more open

#188

Post by dllthomas »

hnra wrote: post #70
rwmj wrote: post #57

Earlier quoted context omitted.

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.

You can also do this with values, asking "what goes here?" - it's great.

Re: Dynamic type systems are not inherently more open

#189

Post by sethev »

svat wrote: post #90

Six notable things I took away from this post: - Structural typing, i.e. instead of "you eagerly write a schema for the whole universe", just limit to what you need (basically, encode only the same kinds of assumptions you would make in a dynamically-typed language). - It’s easy to discover the assumptions of the Haskell program [...] In the dynamically-typed program, we’d have to audit every code path — Left implici…

I thought the article was good and addressed a real point of confusion, as evidenced by the two included comments (from Reddit and HN). You can consume arbitrary data using a program written in a statically typed or dynamically typed language. Whether it's decoupled from changes in the data depends on how the code is written and the data model, which have nothing to do with static vs dynamic typing.

To me the stronger argument is that the boundary between programs is dynamically typed (interpreted and checked at runtime). This is true in the statically typed example as well - the JSON is interpreted and checked at runtime, not at compile time. There's nothing your compiler can prove in advance about what's in the JSON that you'll receive at runtime.

If systems that extend beyond a single program require dynamic typing, doesn't it make sense to invest more in ways to do dynamic typing better?

Re: Dynamic type systems are not inherently more open

#190

Post by yakshaving_jgt »

samatman wrote: post #140
yakshaving_jgt wrote: post #49

Earlier quoted context omitted.

> 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?

The article demonstrated that with Haskell — as with just about any other language — you can choose to silently ignore malformed input. There is absolutely no fundamental necessity to "blow up at runtime" as the parent comment erroneously posited.
Post reply on HN