5 ms·
Whenever I hear someone promote static typing for the type of thing you'd use JavaScript for, my first thought is: they aren't testing [properly]. I think stat
by latch 8y ago
Whenever I hear someone promote static typing for the type of thing you'd use JavaScript for, my first thought is: they aren't testing [properly].
I think static typing unquestionably helps if you have a young and undisciplined team. There are a couple indicators that this is a problem for AirBnB. We know their switch from PG to MySQL was at least partially due to lack of discipline. They're also rely on strict linting, which in my experience, a well gelled well led team doesn't need.
UPDATE: My mistake. I confused AirBnB with Uber for the DB switch.
- bearjaws 8y agoLinting and code formatting checks should be strict to help keep people writing to one standard. I don't think its a matter of engineer experience, its more related to 1) time wasted in code reviews because of trivial errors. 2) Scaling a team can be done far more quickly if you aren't having to explain what should be commented, what spacing to use etc.
- lallysingh 8y agoIn terms of mistakes caught, type checking can catch errors far before (and far cheaper) than a test can.
- latch 8y agoI don't think you're wrong, but if you believe (like I do) that tests are a time saver, even in the short term, once you have good tests, typing doesn't save 38% anymore..it saves, maybe 1%. I'll add that, in my experience, in an untyped language, you don't need more or even different tests. Why? Because your in either world your boundaries are untrusted (and more than likely untyped) and then everything internal you can trust. User data, external systems, possibly internal systems, queues, storage..all that data is going to be varying degrees of unsafe and untyped. Those entry/exit points need to be fuzzed, unit and integration tested. Again, I don't you're wrong, I just think you want/need the tests anyways (because typing isn't remotely enough).
- nicoburns 8y ago> then everything internal you can trust I'd argue that what an expressive type system gives you is precisely this trust that internal data is passed around correctly. In a dynamic langauge it's much easier to pass the wrong argument to a function, and I'd probably want to test for that...
- je42 8y agobut these errors are usually so trivial, that any good integration test would find them any way...
- DCoder 8y agoHow long does your integration test take to run and report failures? Compared to instant feedback while you're writing the code, that's glacial.
- je42 8y agoi assume, so you are doing then doing manual tests after you are done coding ?
- scrollaway 8y agoDo you write tests for every single function call? Every single variable assignment? You don't. Even 100% coverage isn't enough to map all the potential issues with incorrect types being passed around. Types are a highly compact way of adding tests and documentation to your code that automatically integrates with everyone's IDEs and your CI pipeline. I don't know why you wouldn't use it if you think these things are useful. "No thanks, I'd rather spend all my time writing these things I could write much faster using simple types."
- je42 8y agotypes also don't cover all issues. otherwise your types proof your code is 100% correct.
- abhorrence 8y agoCould you link to some information about the database switch?
- latch 8y agoI was looking for a link to add to my post....that I couldn't find it should have set off alarms. My mistake, I mixed up Uber with AirBnB. I updated my post.
- dasil003 8y agoWhenever I hear this type of argument I assume it’s from someone in a stable shop with a clear mandate and low headcount. Hyper growth startups don’t allow for this kind of stability, tooling scales infinitely better than just training everyone to do the right thing, especially when the problems you face are rapidly evolving.
- chriswarbo 8y agoTests and types are complementary. In fact, testing becomes much more useful when dealing with static types. As a simple illustrative example, if a function argument is type-checked as a boolean then we can write two tests (one for `true`, one for `false`) which cover all possible executions (note that this is far stronger than merely code coverage). This isn't ever possible in an untyped language, since arguments can have any value, and the number of possible values is countably infinite.
- AnaniasAnanas 8y agoTests and types can be complementary but this is not always the case. If you use a language with dependent types you can prove that your functions are correct, making tests redundant.
- machiaweliczny 8y agoCan you recomend some good language with depended types to try?
- AnaniasAnanas 8y agoAgda if you want to write proofs, Idris if you want to write programs. There is also Coq which is more popular but I would not suggest it to a beginner. (note: both Agda and Idris can be used for both proofs and programs, it's just that each have their own focus)
- chriswarbo 8y ago> Tests and types can be complementary but this is not always the case. I never said it was? > If you use a language with dependent types you can prove that your functions are correct Yes, for certain values of "prove" and "correct". Even if we ignore the cost of figuring out the proofs, it can be tricky to encode our mental models into formal statements. Automated tests are useful for checking the correctness of our implementation and our specification. > making tests redundant Not at all, in the same way that lorries don't make bicycles redundant. In fact, I like to use dependent type checkers to run my tests, e.g. test_Foo : Bool test_Foo = foo bar > 0 run_Foo : Equal test_Foo True run_Foo = refl This way, automated tests are run as part of the compilation process; and the build will fail if any of the tests fail (we can also use fancier encodings than Bool, to get nicer error messages, etc.).
- BMorearty 8y ago> They're also rely on strict linting, which in my experience, a well gelled well led team doesn't need. This may be true of a _small_ well gelled well led team. But I work at Airbnb and we're too big to rely on just gelling with each other and having good leadership for consistency anymore. In my experience when you have hundreds of developers it ends up being more cost-effective to decide on some style rules and then have a linter check them and remind people when they accidentally stray. It also helps keep code reviews focused on content, not style. (This used to be a problem at Airbnb but as far as I can tell is mostly not anymore, because of linting.)