Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. Also, C++ and Java have each evolved some rudimentary type inference, which improves ergonomics (although I think excessive type inference a la Haskell actually makes it harder to debug issues--the sweet spot seems to be function-scoped type inference).

View on HN

Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles.

Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.)

The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ultimately you need to backstop your software with testing, QA, and observability infrastructure to actually execute it and validate it. At that point, the question is what marginal gains remain from catching a subset of those problems at complile time, also incorporating a potential a false sense of security which may lead to less actual execution validation, and more user-facing issues. The other potential tradeoff of static typing is if the software design and architecture changes for better or worse, or if the velocity of shipping changes changes. I believe there isn't yet any hard evidence of which way this tilts in either case.

There's also a lot of innovation in the area of validation-by-execution as well, and so I think that will result in continual debate: state-of-the-art static typing may benefit compared to yesterday's testing/fuzzing tools, but may not compared to state-of-the-art testing/fuzzing tools, for example.

One of the greatest boons of static typing is formal documentation of data structures and interfaces. Catching errors early is a bonus :)

I'm not disagreeing per se, but at least in the Elixir community I get the impression that using Dialyzer (the wonderfully cryptic TS-ish gradual typing solution) and typespecs is increasingly advised and there's a thirst for a better solution. But static typing comes up a lot.

We're doing fine without, but it's definitely a sore point and I'm one of those developers who has become more and more fond of static typing.

Python is trending toward types via support for type annotations. My extensive experience with Python and Go leads me to the conclusion that it’s very difficult to write even moderately complex and maintainable Python code at scale. This doesn’t mean that no one can make money with Python—far from it—only that they would make even more money via Go (iterate faster and spend less time fixing bugs). Of course this can’t necessarily be extended to other languages. C++ and Rust would not be as productive up front than Python and C++ would probably not save you any time fixing bugs. A lisp might be faster to develop in than Go and Python without incurring too many type errors. There are too many variables to make sweeping statements, but all else equal, in my experience, static typing is better than dynamic typing. But again, there are many other variables that can cause a dynamically typed language to outperform a statically typed language for iteration velocity or bug reduction.

The trend toward static typing is a fad, like NoSQL in the early 2010s. Who knows what the next fad will be. Perhaps correctness proofs will make a comeback.

Yea, this is why I posted it. To me it seems:

- Small codebase. Fine, use both.

- Medium codebase. Fine, use both.

- Large codebase. You're definitely going to have some typing bugs with dynamically typed languages.

- Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.

I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.

Can’t you write the Python functions to force check the input parameter for its type? And error out if not.

This should enable you to catch most errors immediately during development.

Yes, but easier to just write tests.

And easier still just to use static types.

Often not, if the overhead of adding them outweighs their utility for the project.

No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error.

What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)

I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted.

This is not a Python problem, per se. It is a developer problem. It is a human problem.

However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests.

The unit tests are good, as they give you evidence that you did cover those corner cases.

However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.

well, sure. certainly one of the costs of a dynamic language is the possibility of typing bugs, and those will likely grow linearly with the size of the code base.

the question is if those programs were written in statically typed languages, how the world would differ, in-full. for example, they may have been built faster or sloer. or they may have better or worse test coverage, affecting severe defect count overall. or you may have had to hire a different team, with tradeoffs. hard to say.

Reply on news.ycombinator.com