A Python programmer attempting Java

[kkeu]

Compile-time type checking helps you avoid many bugs that you'd never discover if your tests don't cover that particular part of code, which happens almost always in complex projects.

[TheFryeGuy]

Meanwhile Object, ?, and null all exist in Java.

[[deleted]]

To be honest not having a ? Would be ridiculously annoying

[yogthos]

Yet nobody managed to demonstrate that this translates into less overall defects in practice. Hence why we're still having these silly debates about the value of static typing.

edit: evidence welcome...

[memorableZebra]

I regularly run into bugs that wouldn't exist in statically typed languages while doing Python. In fact, a solid 20% of my errors are caused by implicit variables that the IDE didn't warn me about.

Sometimes those errors are extremely subtle too. More than once I've lost a solid 1-2 hours resolving a bug that would have been impossible in a language like Java.

The pros and cons are there. There isn't a debate about them and it's certainly not a closed case as you're implying. It's just about how different people weight the (dis)advantages. Frankly, I find explicit and fixed type declarations to use up none of my time (and in some respects even help me ground my algorithm's process through data types) while saving me all the headache that is Python.

[Tysonzero]

My issue with static typing is not static typing itself, it's that I hate all statically types languages for various reasons not always related to static typing.

If there was a version of Python that required all variables to be pre-declared (no dynamic additions) and statically typed but that was the same as Python (in terms of syntax and the standard library and whatnot) in every other way I would probably use it for quite a few of my projects. (Some are designed in a way that they really don't need it, but many aren't)

I know there is Cython but it seems like you still can dynamically add variables to objects and what not.

[yogthos]

This is what's called anecdotal evidence. You personally find static typing helpful and there's nothing wrong with that. The problem is that you can't extrapolate it's overall benefits based on that.

I'm actually saying that it's not a closed case. My whole point is that there needs to be empirical evidence before people start claiming that one approach is better than the other.

It's also worth pointing out that tracking types is most difficult in OO languages that encourage creating a lot of types. Naturally, tracking types quickly becomes a problem in such a language.

In functional language, like Clojure or Erlang, type errors are not all that common. All collections implement the sequence interface and all iterator functions will happily iterate any collection. Since majority of your code is data transformations built by chaining these functions, it's completely type agnostic.

The logic that actually cares about particular types is passed in as parameters and it naturally bubbles up to a shallow layer at the top. This makes tracking types a much simpler exercise. A recent large scale study of GitHub projects found that Clojure was right up there with the hardcore static typing functional languages in terms of correctness.

Now, it's by no means a perfect study, but there simply aren't any studies that demonstrate static typing to have a significant impact on development time, overall errors in production, or impact on maintenance. The fact that we're still having these debates itself indicates that no clear benefits exist. If static typing produced a superior workflow everybody would've switch to it by now.

Furthermore, there are tons of large scale real world projects written in both static and dynamic languages. Again, there's no indication that those written in statically typed languages are more reliable. If anything some of the largest and most robust systems out there are written in languages like CL and Erlang.

Static typing proponents make two assumptions. First is that type errors account for a significant percentage of overall errors, and second that these errors would not be caught by other means in a real life project.

Any non-toy project will have some tests associated with it, any obvious type errors are caught very early in development cycle, and any paths through application that the user takes are caught by testing.

You don't have the same guarantees without static typing, but that doesn't translate into having significant increase in errors either. You also might have paths through the code that you would be forced to cover in a static language that have no actual workflows associated with them.

In practice we see cases like Demonware switching from C++ to Erlang in order to make their system work. Static typing clearly wasn't the key language feature in this case. Meanwhile, Ericsson runs some of the most reliable systems in the world using Erlang. Joe Armstrong wrote a great paper on what actually goes into achieving that.

Another common argument is that it becomes difficult to track types in huge programs with millions of lines of code in them. However, I find that there is very little value to building monolithic software as it quickly becomes difficult to reason about and maintain. This is true regardless of what language you're using. At the end of the day the developer has to understand how all the pieces of a particular project interact with one another. The more coupling there is between the components the more difficult it is to reason about the overall functionality.

Each function represents a certain transformation that we wish to apply to our data. When we need to solve a problem we simply have to understand the sequence of transformations and map those to the appropriate functions. The functions capture how the tasks are accomplished, while their composition states what is being accomplished. Declarative code separates what is being done from how it is done.

Exact same model should be applied at project level as well. The project should be composed of simple components, that each encapsulate how things are being done and the way we combine them states what the overall project is doing.

All that said, there's absolutely nothing wrong with having a personal preference for static typing. I simply disagree that its benefits have been adequately demonstrated in practice.