Hacker News Reader

Comment by jernfrost | Hacker News Reader

I disagree, I warmed to dynamic typing specifically due to the experience of working with 2-3 million lines of C++ code. The problem with static typing at that size is that you very frequent impedance mismatch. A lot of the code you write ends up being about translating from one type to another which is almost identical.

You also get dependency problems you don't have with dynamic languages because you aren't required to import type definitions to use an object from somewhere else. Your code easily get tightly coupled. You end up with a nightmare of compile times.

The couplings get so intricate over time that it becomes and almost intractable problem to figure out how to take it apart.

That is much easier in a dynamic language. You can tackle problem far more independently from each other because dynamic languages don't impose as much dependencies between types.

View on HN

> You also get dependency problems you don't have with dynamic languages because you aren't required to import type definitions to use an object from somewhere else

The dependency is still there, you are using that object in your code.

Dynamically typed language gives you the worst of both worlds: same dependencies and zero discoverability.

> You can tackle problem far more independently from each other because dynamic languages don't impose as much dependencies between types.

This doesn't make sense. The code is exactly the same except that you don't have type annotations with dynamically typed languages. In other words, you can't tell exactly how the code you're looking at interacts with the rest of the code base.

Which makes it impossible to untangle when it grows and also for automated tools to figure out what these dependencies are.

> The code is exactly the same except that you don't have type annotations with dynamically typed languages.

No they are not the same.

Here's some key differences:

- If at runtime an execution doesn't even reach the code, then it doesn't matter at all for that particular execution whether the types were "correct". With static typing you need to get it right for all possible executions before you can even compile, regardless of how unlikely or unimportant those executions are. In practice, having to get it all right for all executions before you can even run one is a massive productivity loss in a lot of scenarios.

- Not only might a "type" of something in a dynamic language not be expressible statically (at least in majority of static languages) in the first place, dynamic code is never dependent on any particular type. You might get an unintended "type" in and the code can still work. There is a dependency on infinite amount of unexpressible "types".

You are completely ignoring the point of dynamic typing and you are using it as if it were static typing without annotations, by your own admission. But that's your problem. Similarly I could also use statically typed language as if it were dynamic and then claim that static typing is exactly the same as dynamic except more verbose.

> You are completely ignoring the point of dynamic typing and you are using it as if it were static typing without annotations

That's exactly what it is.

What is your definition of a dynamically typed language?

So I just told you about a few things that are physically impossible in static languages, therefore dynamic language cannot be a static language subset. For example, you first need to prove that it's possible to tell a static language that "for now, for this execution, I don't care about these 3150935031 trillion code paths being correct, just these 123 code paths, so just compile and do it". Without that you are just trolling.

    x = 3
    print(x)
    x = "hello"
    print(x)

Not possible with static typing and type inference (which is static typing without annotation) but done all the time with dynamic typing. (Though still not a good idea, in my mind, but to each their own.)

Reply on news.ycombinator.com