5 ms·
>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wro
by enraged_camel 9y ago
>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments.
People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.
- 201709User 9y agoYes, why do something automatically when you can do manual work!
- icebraining 9y agoI think the idea is that you have to write tests anyway.
- whyever 9y agoNo, you don't have to write tests for invariants enforced by the type system.
- ubernostrum 9y agoI think the bigger idea is that people who've never actually written serious code in a dynamically-typed language assume that people who do always write a bunch of extra unit tests to assert correct types, assert behavior on incorrect types, etc. etc., and that programs crashing due to type errors is a super frequent occurrence. None of those things are true.
- tome 9y agoAnd yet there are dynamic language proponents in this very subthread suggesting that's exactly what everyone should do.
- andrewaylett 9y agoWhy would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.
- enraged_camel 9y agoYou don't write test cases specifically to check types. Your existing cases, if they are robust and thorough, will simulate your runtime and check those for you as a side effect.
- andrewaylett 9y agoMy existing test cases, robust and thorough though they are, only test what happens when I feed in a correctly typed object. Because I can't write a test that exercises my code on an incorrectly typed input: the type system prevents that.
- metaphorm 9y agoyou're already writing the test cases to ensure correct behavior with typical input, and predictable exceptional input. putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead to writing the tests you were already writing.
- macspoofing 9y ago>putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead Yes. We call that 'typing'.
- discreteevent 9y agoAnd it takes less typing (keyboard) than the assert, and you get free documentation inline with the code!
- dep_b 9y agoWell if you don't need to write that particular test you have more time writing tests that are actually useful, like validating your logic (and dare I say: more fun to write).
- rbobrowicz 9y agoPersonal anecdote: I worked on a small Python project some years ago and we had a type error in production despite having tests. We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return a list of one element, as we expected, but a scalar value. So the rest of the code was expecting a list and when it encountered a scalar it blew up. You can blame it on us for having insufficient test cases, or not coding defensively enough, or not reading the source code of the library we used, or the author of the library for bad design, but ultimately, this bug would not have been possible in a statically typed language. So just saying "have test cases" is not good enough. Your test cases can be not exhaustive, but a good static type system and type checker is.
- crdoconnor 9y ago>or the author of the library for bad design That's the one. That's a damned stupid decision.
- UncleMeat 9y agoYeah and a static type system refuses to let you make such a stupid decision. When interoperating with code I didn't write, knowing that the code is guaranteed to conform to some specification is valuable.
- berdario 9y agoI cannot reply to cdoconnor (probably some downvotes), so I'll write here: That's the whole point: as it's often said "type checking keeps you honest" I stumbled time and time again upon badly designed libraries... With a static type system, the painfulness will be obvious and felt the first time you'll try to build your code with dynamic types, the pain might not be felt at all, until a crazy bit of code will be invoked, sometimes at the most unfortunate of times
- cm2187 9y agoIf you have to write a test for every line of code you write, the "chatty" argument against static typing goes away.
- senorjazz 9y agoand not just that, but for every possible case for the line you can think of. Like the post above, testing the results of a function returns a list for 1 item, or many items... I see all too often, java bad, just look at how many lines you need to write to get "hello world". Who cares, the IDE generates that for you, but if you don't understand static void main as a beginner... again who cares, just put it in and ignore it until you need to understand it. Also read that dynamic languages are so productive, but they never mention you need to then write tests to detect what the compiler would catch for free. Yes good code needs tests, but the compiler IMO is a damn good built in test suite for catching many classes of errors
- Silhouette 9y agoBugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you. What's wrong with relying on the compiler? Bugs like that will be caught immediately by a good static type system, so you don't have to rely on your test cases to catch them for you. Relying on a test suite to verify basic properties that could be enforced automatically through a type system means you're only checking some cases instead of all cases. It also means you're cluttering your test suite with boilerplate about language mechanics instead of writing high value tests that verify the real operational behaviour of your system. There are pros and cons to static vs. dynamic typing in general, but in this particular respect, static typing is strictly more powerful, less verbose and more efficient.
- AsyncAwait 9y agoHaving a compiler catch this for you means having to write less test cases.