"I will never use Python in production ever again" | Hacker News Reader

"I will never use Python in production ever again"

onebigfluke.com

14 pointsbslatkin15 comments

>Static typing doesn't ensure correctness for languages like C++ and Java.

Types provide a pretty high amount of proof towards correctness, in theory and in practice.

In my experiences working with Haskell (and its type-system), I've found the amount of runtime bugs I hit to be almost non-existent, because usually the type system catches all my stupidity beforehand. It's weird, because the type of runtime bugs I get in other languages (like Python) are rarely type-related issues, but for some reason it seems to help a lot.

The arguments for dynamic typing are very less convincing when you start getting into systems with very expressive type systems such as Haskell.

There are so few use-cases of un-type-able code out there that it really shouldn't be as demanding, but unfortunately people have conflated typing with verbosity and uselessness, instead of things that can work extremely well as proofs of some amount of correctness.

The ideal: "if it compiles it is guaranteed to work as you intended when writing it".

Reality: "Type systems don't keep you from writing wrong logic, they only forbid you to write inconsistent logic."

If such a language existed, you wouldn't need to write any function body, all the code you need would be encoded in types. However, even the most advanced Turing complete type systems make for terrible sources, so it's probably not an ideal we should strive for.

The quote:

> Why didn't you have tests that caught the syntax errors? Static typing doesn't ensure correctness for languages like C++ and Java.

It seems like they is saying: "you have to write more tests, yes, but you have to write tests, anyway!" So if I have to write 20 tests in one language, and 200 in another, the difference in effort is negligible because I need to write tests anyway? So if you can express something in 10 times less code in one language compared to another, it doesn't really matter since "you would have to write some code, anyway!". I really don't get this 'you were going to write tests anyway [says who?], so you might as well write it for any possible unintended null-value, value-was-string-but-should-have-been-char, too long argument tuple in function call....."

> All other things being equal, I expect the total time spent in Python will be lower than C++.

I hear this a lot, and for the most part, I don't really understand it. I know Python and C++ at about the same level and for a lot of things I find myself taking less time in C++, particularly with Boost giving me a bunch of handy tools in my toolbox. I don't find static typing onerous, and it does save my bacon more often than it gets in my way.

Nits about C++ aside, since there does exist the general perception of C++ as having those problems, wouldn't a fairer comparison be Scala or C# as it pertains to statically typed languages? (I don't know Scala great yet, but I find myself able to build good, reliable code fairly quickly--although sometimes, due to unfamiliarity, I end up writing code that's too clever and it's hard to read afterwards--and I am ridiculously more productive in C# than Python. The miracle of a good IDE...)

He picked comparison that would make Python look good[-ish]. Or he is ignorant about modern C#/Scala capabilities.

That was what I was driving at, yeah.

This has nothing to do with tests. Tests would catch this, but so would sensible development practices like running your code at least once before deploying it.

In this case I believe it was a dynamic import of a module that was not used in local development. Reasonable tests would have caught this.

Possibly, though it is just as likely that the tests would still not catch the problem in a local dev environment if that module is not used there, right?

To avoid problems like that, you probably want your dev environment as close as possible to your production environment. You probably also want to be testing your production specific code/logic (especially if you're not doing that on your local).

That would catch the SyntaxError instances he mentioned but certainly not every case of AttributeError or ValueError exception. Even good testing would not catch all of them.

Indeed, regression tests are not a silver bullet. It's a patch for dynamic type system.

I once ran into an issue where a base class's method's signature changed thus breaking some subclasses. No compiler warning but also no refactoring support either. If you ran tests only on the base class you would be fine. Especially if different people were responsible for the base class and subclasses.... Wonder if Python tools have refactoring support...

Reply on news.ycombinator.com