Hacker News Reader

Comment by Lxr | Hacker News Reader

Instagram would disagree with you. Seriously, Python is an absolute pleasure for managing large web projects and the lack of static typing has never been an issue for my company (spend the time writing tests instead!)

View on HN

>(spend the time writing tests instead!)

Every sufficiently large test suite will contain an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a proper type system.

What's the point in testing types if the tests that check it works pass?

No, the claim is that the tests that "check it works" are really testing the types (as an ad-hoc type checker) and wouldn't need to be written if a sufficiently strict static type system were used instead.

Every sufficiently large statically-typed application will contain an ad-hoc, informally-specified, bug-ridden, verbose implementation of half of a decent dynamic language.

(I too enjoy a good pseudo-Greenspun)

More seriously something I've been pondering a lot recently watching the old pendulum swing back towards an enthusiasm for explicit typing is this:

* The advantages of static type systems are obvious and easy to articulate. * The disadvantages of static type systems are subtle and difficult to argue.

I started my career as a professional programmer when the pendulum was moving in the other direction. Essays by Paul Graham on Lisp and Python. The marvellous PJ Eby piece quoted above and Peter Norvig's "Design Patterns are artifacts of language flaws".

I just feel dynamic languages fit my brain better but maybe that's my own form of Stockholm Syndrome. Maybe I need to try a decent type system rather than the brain-damaged descendents of Java...

I think I've never really got the point of a good type system until I started using Elm and then wandered into the rest of the ML world, learning the so called "Type-Driven Development" method.

After some time doing that a Java project came up, so I grabbed Lombok, Vavr and started writing Java as if it was just another ML (immutability first, paying attention to side effects and so on) and the whole thing made sense. More sense than all those years of OOP teachings. The code was easy to debug, easy to reason about, easy to change. And it was Java. And that just stunned me for life.

Then of course, I started using TypeScript for React development and giggled like a little girl every time I had to refactor something, for I KNEW that it was very unlikely I'd have to stare at the debugger for long periods of time in a wild goose chase like I often had to with plain JS.

But the trick was to learn the way of doing things in the languages that really guide you towards that path.

I can definitely recommend that you try Elm if you're into frontend development, or something like F# if you want native. As far as docs go, the Elm guide and fsharpforfunandprofit.com are both great; the latter I can recommend regardless of your language choice for making typed functional programming make sense. I can also recommend the book Type-Driven Development with Idris, which has also been an invaluable resource to really understand that way of doing things.

That's one thing I don't understand. The argument I hear against static typing is that it's too much work to write all this type metadata. But if you have to make up the lack of compiler checks with lots of tests for things that wouldn't require tests in a static language, we are not saving any work.

That's because you're not testing things that wouldn't require tests in a static language.

You're testing things that need testing either way, and incidentally also testing the types.

No, you're testing types and verifying the implementation details of the language. It's rare that a test for logic "incidentally" tests the type system. Usually both the logic and type checks are tested. It's just obfuscated because the bulk of the test is for checking the types and it's easy to look past that.

Yes, it doesn't test the "type system" (whatever that even means).

However, it tests values for correctness. Values have types. So if you are testing whether something has the correct value, you are also testing implicitly that it has the correct type, because for the values to match, the types must also match.

I love Python but I also don’t mind static types. Maybe I will realize some day what this argument is really about, but I expected that day to come by now.

Yes let's waste our companies time and money by writing tests for things the compiler could guarantee for free!

Not for free. You have to think and write types, maybe add some code to cast values between them or implement the same function twice for two different type signatures. Sometimes it still gains time, sometimes it doesn't.

Anyway, I doubt that a VBA replacement would need types. The use case is small scripts.

Python is strongly typed. You still have to think about the types. Except now you have to think about them every time you work with the code, not just the first time.

I work with Python and Ruby (some Elixir.) They are strongly typed in the same way. I hardly think about types. The code just works. The only scenario in which I have to stop and think is when I get some input, for example some JSON. Is that value I have to add to this counter a string or an integer? I can cast it to integer and that's it. To be fair, sometimes an integer gets where there should be a string and boom. Still, I prefer that to having to write types again as I used to when working with C and Java. I fix the code and I don't write tests to check the types of function arguments. Maybe I could accept some type inference, but no more string, int, generics, etc.

You have to think about the types for some small pieces of your code where those types matter. That's what hints are for. Python lets you, through type hints, only care about the typing in those small cases where it actually matters, and ignore them the rest of the time.

Most of it is caught as incidentals of tests you have to write either way.

There's room for both paradigms - it's kinda silly to argue strict superiority of either because there's just no empirical evidence that having static typing or not drastically changes bug count.

If you take a look at some of the studies out there that do exist (which there are, admittedly, few, and it's a fundamentally tough thing to measure), e.g. [0], it usually tends to be the case the both typed and untyped languages show up in the realm of "least likely to produce bugs"

[0] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

I'd rather not write a bunch of tests that are really acting as a static type checker or, worse, testing the Python equivalent of compiler, linker and assembler output.

That's what the vast majority of testing is when it isn't simply testing mock code implementations.

Ah yes spend that valuable engineer time writing type validation tests a compiler could do instead of new features.

Put me with Op. I'll use Python for prototypes and small tools but get past that and I want a statically typed language. Not just for validation but also refactoring.

Reply on news.ycombinator.com