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

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

#21

Post by rajangdavis » Sun, Aug 06, 2017, 7:09 AM UTC

always_good wrote: post #20

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

I meant "enough" as to ask "do I need to do more than writing a check?".

You do bring up a good point with testing (which I don't always do, but I try to at least do runtime checks).

I follow you on the data model part. I think that's where a test framework is super handy.

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

#22

Post by sds2 » Sun, Aug 06, 2017, 8:23 AM UTC

ridiculous_fish wrote: post #17

yoklov wrote: post #15

Earlier quoted context omitted.

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.

Both Objective-C and Java are statically and strongly typed. What you're thinking about is probably a runtime-reflection mechanism. The JVM, java's host is capable of supporting dynamic languages through 'invokevirtual' but it doesn't make java dynamically typed.

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

#23

Post by sds2 » Sun, Aug 06, 2017, 8:32 AM UTC

ridiculous_fish wrote: post #19

Retra wrote: post #16

Earlier quoted context omitted.

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

> Having a single static type system that captures all differences across all versions of all browsers is not realistic.

Why? Standards and abstractions are useful.

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

At that case your program's behaviour may become inconsistent

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

That's not typechecking and there's no guarantee that your program will work with dynamic typing if the API changes.

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

Is runtime type error better? If the type of your value changes and your assumption was false about the type then it can fail anyway with an incorrect function call.

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

#24

Post by yawaramin » Mon, Aug 07, 2017, 5:14 PM 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…

Actually, my reading is that they are ultimately pretty set on static typing and want to use a strong static typing base and build in some dynamic components:

Static typing is a powerful tool to help programmers express their assumptions about the problem they are trying to solve and allows them to write more concise and correct code. Dealing with uncertain assumptions, dynamism and (unexepected) change is becoming increasingly important in a loosely couple [sic] distributed world.

Where they go wrong is that they are lax in their understanding of 'a well-typed program cannot go wrong' (at runtime). They use the example of reading query resultsets, but those resultset reader methods are wrongly typed because they don't account for the possibility of error. So that's really a strawman.

But it's interesting to see their idea about what essentially became Scala's (and potentially OCaml's) typeclass machinery (using implicit witnesses). I guess a lot of people were thinking about typeclasses and implicits around that time.