Hacker News Reader

Comment by rhaps0dy | Hacker News Reader

This is not exactly the point the article talks about, but it's irked me for quite some time. When you see the documentation for a library in a dynamic language, it looks the same as if the language was static: the class of all the arguments and what the functions return is specified. So in the end you end up using it just like you would a static language, but with all the type checks done at runtime instead of before.

This doesn't make much sense if you want to avoid errors.

View on HN

That's an overly broad generalization, and doesn't line up with my experience.

For example I don't see much about "classes" in MDN:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...

"Window.location returns a Location object" "you can also assign a DOMString to it" "The parseInt() function parses a string argument and returns an integer" "If string is not a string, then it is converted to one"

Seems like this documentation talks about little else than types to me?

> "The parseInt() function parses a string argument and returns an integer"

This seems... factually incorrect? Shouldn't it say "a double"? (or a "number", which just means "double" in JS)

It might ignore any characters after a ".", but it's impossible to return an integer in JS...

No, it returns an integer. ECMAScript doesn't officially have a distinct integer type, but the number returned will still be an integer. Incidentally, most JavaScript implementations actually do have an internal integer representation, even though typeof will still just say it's a number.

string: The value to parse. If string is not a string, then it is converted to one [...]

radix: An integer between [...]

The Window.location read-only property returns a Location object

You gave supporting evidence for my point.

Take PHP or Python's standard library. Both are built around types, yet this is legal:

   $foo = "hello, world!";
   $foo = 12;

When you use a string-related function in Python, you expect the parameters to be strings, yet there's no type-safety enforced until runtime.

This is legal in Haskell:

    let foo = "hello, world"
     in let foo = 12
         in foo

Whether bindings can be shadowed has nothing to do with whether typing is static or dynamic.

"So in the end you end up using it just like you would a static language, but with all the type checks done at runtime instead of before" When I first worked on a JavaScript project I found that there were explicit unit tests that just checked for types. I wasn't expecting that. You have to write more code than in a statically typed codebase. Dynamically typed languages are not for lazy programmers!

Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. They have a lot of abstractions that are not even necessary in dynamic languages.

The gymnastics part is correct. You have to convince the compiler the code you are producing is correct, even if it may be correct already. However, this makes your code way more unlikely to crash or be incorrect.

The "lot of abstractions" is the distinction between type and class the article addresses, I guess?

> static languages often require a bunch of gymnastics to get the compiler to accept valid code

I'd rather do the gymnastic and have the compiler tell me where I screw up right away. That's a tighter, more accurate feedback loop than a REPL. (Source: trying to implement a simple depth first search in both Lua and Ocaml.)

And of course, you can still have the repl :D

> Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code.

There's really two problems hidden in that that deserve to be considered:

(1) Static languages with insufficiently-expressive type systems may require more complex code (in terms of actual operations, not just type declarations) for the code to be valid when compared to dynamic languages (or static languages with sufficiently-expressive type systems.), and

(2) static languages may, depending on the situation and the completeness of their type inference system, require arcane incantations to the type system before it accepts that correct code is, in fact, correctly typed.

Some statically-typed languages are good on one or both of these measures, and so make less of one or both types of problems (Haskell, IMO, is pretty good on both, as static languages go, but lots of more popular static languages are really bad at one or both.)

Reply on news.ycombinator.com