Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf] • Hacker News Board

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#11

Post by jnbiche » Sun, Aug 06, 2017, 1:56 AM UTC

KMag wrote: post #7

jnbiche wrote: post #3

Yeah, it was pretty clear from the outset that the author(s) had a biased view against static typing when they describe static type "fanatics" versus dynamic type "advocates", and go on to discuss all the ways static types are unfeasible whereas dynamic types are "indispensable". I enjoy programming in Python and JavaScript sometimes, but dynamic typing is never "needed". Furthermore, no static type aficionado that I…

I'm a fan of static typing and I only have a cursory understanding of Godel's incompleteness theoroms, but > but dynamic typing is never "needed". my understanding is that it's not possible to construct a single static type system that simultaneously accepts all correctly typed programs and rejects all incorrectly typed programs. In practice, most sound static type systems minimize the corner cases where they reject…

Yes, it's not possible to construct a static type system that accepts all correctly-typed programs. They only accept correctly-typed programs within their type system.

So just because you can't devise a type system that accepts all correctly-typed programs doesn't mean that a statically-typed language can't create equivalents to any dynamically-typed program, assuming it's Turing complete. That's a misconception.

What falls under correctly-typed within most modern type systems is more than enough to write expressive programs. In fact, sometimes a static type system can be even more expressive than even the most expressive dynamic one (as is the case with Haskell, for example). As some evidence for this, I assert that one can re-create any dynamic type system within a Haskell program, using simple algebraic data types.

That's what I meant about dynamic typing not being needed. Yes, even languages like Haskell have runtime typing "escape hatches" but they're never necessary except for use with FFIs (ie, other languages) and are definitely a major code smell if you use them for normal coding. They're just not necessary.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#12

Post by ridiculous_fish » Sun, Aug 06, 2017, 2:40 AM UTC

jnbiche wrote: post #11

KMag wrote: post #7

Earlier quoted context omitted.

I'm a fan of static typing and I only have a cursory understanding of Godel's incompleteness theoroms, but > but dynamic typing is never "needed". my understanding is that it's not possible to construct a single static type system that simultaneously accepts all correctly typed programs and rejects all incorrectly typed programs. In practice, most sound static type systems minimize the corner cases where they reject…

Yes, it's not possible to construct a static type system that accepts all correctly-typed programs. They only accept correctly-typed programs within their type system. So just because you can't devise a type system that accepts all correctly-typed programs doesn't mean that a statically-typed language can't create equivalents to any dynamically-typed program, assuming it's Turing complete. That's a misconception. Wha…

What do you do about runtime environments that may diverge from the static environment? For example, your code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. How would you gracefully handle that without dynamic types?

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#13

Post by ridiculous_fish » Sun, Aug 06, 2017, 2:49 AM UTC

jlarocco wrote: post #5

The argument over static and dynamic typing is so boring at this point. It's semi-intellectual "bike shedding". Practically speaking it doesn't make much difference one way or the other. I wish the industry as a whole would get over it and focus on bigger issues.

It matters a lot! The fact that ObjC, Java, and JS have dynamic type system is what enables iOS, Android, and web browsers to be revved independently from the apps that use them. This is a key feature that languages without dynamic types cannot provide.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#14

Post by kazinator » Sun, Aug 06, 2017, 3:37 AM UTC

jnbiche wrote: post #3

Yeah, it was pretty clear from the outset that the author(s) had a biased view against static typing when they describe static type "fanatics" versus dynamic type "advocates", and go on to discuss all the ways static types are unfeasible whereas dynamic types are "indispensable". I enjoy programming in Python and JavaScript sometimes, but dynamic typing is never "needed". Furthermore, no static type aficionado that I…

A good compiler for a dynamic language can also be a wonderful tool and ally.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#15

Post by yoklov » Sun, Aug 06, 2017, 3:53 AM UTC

ridiculous_fish wrote: post #13

jlarocco wrote: post #5

The argument over static and dynamic typing is so boring at this point. It's semi-intellectual "bike shedding". Practically speaking it doesn't make much difference one way or the other. I wish the industry as a whole would get over it and focus on bigger issues.

It matters a lot! The fact that ObjC, Java, and JS have dynamic type system is what enables iOS, Android, and web browsers to be revved independently from the apps that use them. This is a key feature that languages without dynamic types cannot provide.

JS is the only one of those that has dynamic typing, at least by the conventional meaning of the term.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#16

Post by Retra » Sun, Aug 06, 2017, 4:13 AM UTC

ridiculous_fish wrote: post #12

jnbiche wrote: post #11

Earlier quoted context omitted.

Yes, it's not possible to construct a static type system that accepts all correctly-typed programs. They only accept correctly-typed programs within their type system. So just because you can't devise a type system that accepts all correctly-typed programs doesn't mean that a statically-typed language can't create equivalents to any dynamically-typed program, assuming it's Turing complete. That's a misconception. Wha…

What do you do about runtime environments that may diverge from the static environment? For example, your code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. How would you gracefully handle that without dynamic types?

If the APIs are different, they are differently typed. You still don't need dynamic types, you need to correctly account for both APIs.

Doing it gracefully requires that you say what 'graceful' means in this context. It may or may not mean doing it correctly.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#17

Post by ridiculous_fish » Sun, Aug 06, 2017, 4:15 AM UTC

yoklov wrote: post #15

ridiculous_fish wrote: post #13

Earlier quoted context omitted.

It matters a lot! The fact that ObjC, Java, and JS have dynamic type system is what enables iOS, Android, and web browsers to be revved independently from the apps that use them. This is a key feature that languages without dynamic types cannot provide.

JS is the only one of those that has dynamic typing, at least by the conventional meaning of the term.

Do you mean it's the only one without static types? All three are dynamically typed to some degree. For example, in ObjC, messages dispatch on the dynamic type of the object.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#18

Post by jnbiche » Sun, Aug 06, 2017, 4:49 AM UTC

ridiculous_fish wrote: post #12

jnbiche wrote: post #11

Earlier quoted context omitted.

Yes, it's not possible to construct a static type system that accepts all correctly-typed programs. They only accept correctly-typed programs within their type system. So just because you can't devise a type system that accepts all correctly-typed programs doesn't mean that a statically-typed language can't create equivalents to any dynamically-typed program, assuming it's Turing complete. That's a misconception. Wha…

What do you do about runtime environments that may diverge from the static environment? For example, your code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. How would you gracefully handle that without dynamic types?

> code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs.

If you are referring to an second API that is differently typed, what happens if you do use a dynamically-typed language there? Then you're running under the assumption of one type when you actually are getting another? Your program is in an inconsistent state. Very often, at least in languages like JavaScript and Python, that means that very strange and obscure bugs will eventually start popping up.

Unfortunately, the same can happen with static typed languages receiving data from an external API unless you're doing runtime checks of external APIs (which is often a good idea).

So the ideal thing to do is to runtime validate external APIs and account for any differences that turn up in the APIs. Ignoring the differences in any language is very often the start of downstream bugs, not a graceful way of handling the problem.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#19

Post by ridiculous_fish » Sun, Aug 06, 2017, 4:55 AM UTC

Retra wrote: post #16

ridiculous_fish wrote: post #12

Earlier quoted context omitted.

What do you do about runtime environments that may diverge from the static environment? For example, your code may typecheck in the browser you tested, but it has to run in other browsers which have differences in their APIs. How would you gracefully handle that without dynamic types?

If the APIs are different, they are differently typed. You still don't need dynamic types, you need to correctly account for both APIs. Doing it gracefully requires that you say what 'graceful' means in this context. It may or may not mean doing it correctly .

Having a single static type system that captures all differences across all versions of all browsers is not realistic. But even if it were, there's a bigger problem: static type checking happens too early. The browser can rev and change its APIs after your static type checking is performed.

You want to type check with the actual runtime environment, not just a static guess at it.

I guess by "graceful," not segfaulting would be a good start.

Re: Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]

#20

Post by always_good » Sun, Aug 06, 2017, 6:40 AM UTC

rajangdavis wrote: post #9

Quick question: is it enough to create guards/checks in languages like Ruby or Javascript to make sure that a parameter that is passed in is the type you expect? I try to set default values in the method/function declarations to at least return an empty set if I can live with it. Only time I have had a dynamic language do weird things is with PHP, but that was due to my lack of understanding of how PHP handles empty…

One problem with runtime checks is that they of course only work at runtime but you also must manually assert against them. A bulk of your test suite now exists just to execute runtime paths through your code to trigger your guards at all. Then your tests often have to duplicate the very assertions that you already specified in your guards.

Another problem is that your runtime guards are often ad-hoc and can drift from your data model, turning into debt that you need to manually reevaluate and clean up. In my experience, there's nothing quite so permanent as a defensive nil guard that everyone is too timid to remove.

But it's not clear what you mean by "is it enough". I definitely use runtime asserts in dynamically-typed languages like Javascript to try and fail as fast as possible in critical functions.