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

101–110 of 286 posts

Re: Dynamic type systems are not inherently more open

#101

Post by hopia »

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…

To be fair most of the time that type change propagation is just manual work guided by the compiler. Some smart IDE would even be able to make the changes for you.

Re: Dynamic type systems are not inherently more open

#102

Post by pron »

capableweb wrote: post #100
pron wrote: post #95

Earlier quoted context omitted.

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…

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…

Java's JML contract system [1] allows you to explicitly state which mutations a method performs as part of its contract.

[1]: https://www.openjml.org/

Re: Dynamic type systems are not inherently more open

#103

Post by hopia »

chongli wrote: post #92
hopia wrote: post #87

Earlier quoted context omitted.

On what editor setup you get this kind of functionality with Haskell? I mean the auto-insert of the inferred types.

I’ve been out of the game for a number of years but I used something called ghc-mod [1] with its associated vim plugin [2] to get this functionality. Moving forward, it seems that all of the effort has moved over to Haskell IDE Engine [3]. It looks like this exact feature hasn’t been brought over yet but it is planned. In the mean time you could still use ghc-mod though. [1] https://github.com/DanielG/ghc-mod [2] htt…

Thanks for the tip! Haskell IDE engine is exactly what I've been using til now and would've been very pleased to find out it had such a convenient feature.

Ghcide is on my list to try next as it's gotten a lot of attention lately.

Re: Dynamic type systems are not inherently more open

#104

Post by hopia »

danidiaz wrote: post #98
hopia wrote: post #87

Earlier quoted context omitted.

On what editor setup you get this kind of functionality with Haskell? I mean the auto-insert of the inferred types.

It seems that "ghcide" can do this: https://twitter.com/chris__martin/status/1218331415869190144 https://github.com/digital-asset/ghcide

Template Haskell not working on ghcide has sadly been holding me back with it. I've heard great things about it otherwise

Re: Dynamic type systems are not inherently more open

#105

Post by papito »

We are seeing a natural evolution where the size and complexity of software is making strong typing almost a necessity. Python now has a type hint system. Types can be checked with external tools but Python 4.x may (?) have that built in.

Ruby is also moving in the same direction, as far as I know.

Re: Dynamic type systems are not inherently more open

#106

Post by hopia »

jmull wrote: post #97

The author doesn’t really address the issue raised in the first (longer) quoted post. Given a set of reasonable requirements I think pretty much no one would claim a general-purpose language couldn’t satisfy them without too much trouble. In fact, that might be a fair definition of a general-purpose language. I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as…

Wouldn't that boil down to the communication between the distributed components? I think this author's solution to that is well detailed in his post "parse, don't validate".

Re: Dynamic type systems are not inherently more open

#107

Post by wereHamster »

yakshaving_jgt wrote: post #89
youerbt wrote: post #58

Earlier quoted context omitted.

But I believe this is also with the spirit of the article. Your functions still assume something about input and are polymorphic over everything else in it. AFAIK this can also be done in a type safe manner in languages which support extensible records/row polymorphism.

You don't need row polymorphism to write a function which operates on a collection of key/value pairs and expects a specific key to exist at runtime. This works in Haskell, just as it does in Clojure.

Please write the Haskell type signature of such a function, as an example.

Re: Dynamic type systems are not inherently more open

#108

Post by pron »

chongli wrote: post #52
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.

This already exists in Haskell. Firstly, Haskell has type inference so you can write entire programs without any type annotations. Second of all, since type annotations actually help to document your code, it’s recommended as good Haskell style to annotate all top-level definitions. To aid you in the latter task, you can press a key in your editor to fetch an automatically-inferred type for the name under the cursor…

Type inference does not automatically "typify" your code. The type system -- whether the type annotations are explicit or the types are inferred -- determines which expressions are "well-formed" (i.e. syntactically correct), and so you can't write arbitrary code. E.g., in Haskell, you can know for a fact that at one call site a Maybe instance is Just, but whether you annotate your types or rely on inference, the type system will still force you to match on the constructor even though you don't really have to from a correctness perspective.

Re: Dynamic type systems are not inherently more open

#109

Post by mirekrusin »

Structural typing is extremly helpful/practical, it lowers "type-friction" a lot. I have a dream that flow/ts will be lifted up to js spec one day (yes, I know, that's why I said "dream"). With this the language would be open to things like multiple dispatch a'la julia/traits/typeclasses and/or pattern matching - which would (imho) place the language at the top for couple of decades. This kind of stuff is unfortunatelly outside of scope of flow/ts as it would require runtime support, which flow/js explicitly don't provide (ie. stripped types makes valid js, all type-stuff happens at "compile" time only, without access to runtime at all).

But flow/ts is major step towards practical solution, it covers something like 65% of properly typed language (properly = algebra on types, structural+nominal typing, opaque types, nullability exposed at type level, aggressive inferrence etc.)

Re: Dynamic type systems are not inherently more open

#110

Post by yakshaving_jgt »

capableweb wrote: post #100
pron wrote: post #95

Earlier quoted context omitted.

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…

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…

> Clojure for example, goes beyond types with it's abstractions (like seq, that can be applied to strings, lists, maps and so on)

Goes beyond types? Statically-typed languages can have polymorphism.

Post reply on HN