Dynamic type systems are not inherently more open

Post by leshow » Sun, Jan 19, 2020, 5:48 PM UTC

arminiusreturns wrote: post #148

chongli wrote: post #67

Earlier quoted context omitted.

It isn’t even a benefit, really. Statically typed languages don’t force you to model things with types; you’re completely free to use strings and doubles everywhere and take on all the technical debt you want. People who are only used to dynamic languages may feel like a static language’s type checker is an overbearing teacher (from the 1950s) standing over your shoulder, just waiting to jump on you for every silly m…

What about JIT things like lisps? Maybe the benefits of dynamic typing are more geared towards things with a repl in particular?

Post by azhenley » Sun, Jan 19, 2020, 5:50 PM UTC

leshow wrote: post #160

azhenley wrote: post #83

Earlier quoted context omitted.

Yes, but "Type inference has usability problems". http://web.eecs.utk.edu/~azh/blog/typeinference.html

I'm curious why you quote this like it's a fact when it's an opinion. The understanding of type inference used as the basis for making the argument in that blog post is superficial. Type inference doesn't just allow you to leave off type information from variables. A good inference engine will infer the most generic type for variables (and functions!), it's a discovery that you can query the compiler for in order to…

Post by _8ljf » Sun, Jan 19, 2020, 5:53 PM UTC

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

Post by PhineasRex » Sun, Jan 19, 2020, 6:01 PM UTC

pron wrote: post #108

chongli wrote: post #52

Earlier quoted context omitted.

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…

Post by iamaelephant » Sun, Jan 19, 2020, 6:02 PM UTC

beders wrote: post #134

NicoJuicy wrote: post #40

Earlier quoted context omitted.

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.