> Passing the wrong type is considerably rarer than the wrong value so need not be considered.
Passing the wrong value doesn't just happen randomly. It happens because of errors in logic many of which can be caught with a strong static type system.
You're not going to cover all of the correct behavior in any nontrivial software with unit tests unless you plan to spend 99% of your time writing unit tests. Static typing gives a good baseline of correctness.
> Static typing gives a good baseline of correctness.
Not really. Lets say you have an `add(a, b)` function. Static typing can guarantee that the function returns a number, but not that it returns the correct number. So you need unit tests anyway.
A unit test `assert_equal(4, add(2, 2))` actually tells you something about the correctness about the function, and it implicitly also verifies that it returns a number. So static typing does not save you anything.
Static typing does have advantages, for example for documentation and for automated refactoring. But it doesn't replace any unit tests.
Sure, in this trivial example there may not be clear benefit, but with more complicated code, operations on complicated structures, with potential state changes, etc. there are many benefits. Even in your trivial example you don't cover the correctness or correct usage of your function - since it's dynamically typed it could be called with non-integer arguments - what's the expected behaviour in those cases?
Static typing certainly have many benefits, just as it has a number of drawbacks. But I'm not making a general argument about static versus dynamic typing, I'm just rejecting the specific argument that static typing saves you from writing any unit tests.
Nobody made the argument that static typing removes the need for unit tests. It does check for many conditions that would have to be unit tested otherwise, such as calling functions with the wrong types.
I'm saying static type checking does not replace any unit tests, because you wouldn't write tests which only checks for "the wrong types" in the first place. You should check for valid behavior - i.e. is the output correct, not just of the expected type. Types are just an implementation detail. But if the tests verify that the output is correct, then it implicitly follows that the types are correct, so you get type checking for free.
No, as I've pointed out - even in your trivial example you're not testing for all correct behaviour. What's the correct behaviour when the function is called with invalid argument types?
> But if the tests verify that the output is correct, then it implicitly follows that the types are correct, so you get type checking for free.
Your unit test checks the correct behaviour for one out of infinite possible inputs. You don't 'get type checking for free' , what you get is no type checking at all.
This is true - unit tests generally does not test all possible inputs. They test some representative examples and edge cases. In most cases there are infinitely many possible inputs, and you get diminishing returns the more cases you test.
If I understand you correctly, you a suggesting unit tests in a dynamic language should test all possible invalid inputs. Since statically typed languages eliminate a subset of invalid inputs (because they won't compile), statically typed languages saves you from writing some of these tests.
My argument is that you wouldn't write such tests in the first place since they provide little to no value.
If function `foo()` calls function `bar()` you want to ensure that foo passes the correct arguments. You don't do that by checking that bar() rejects all possible invalid types. You do it by checking that foo() actually works and provide the correct result. The types involved are an implementation detail.
> You do it by checking that foo() actually works and provide the correct result.
But you're testing a tiny subset of possible scenarios of behaviour of the function. If you can anticipate all possible input types and value ranges, maybe unit tests are enough, but that's not realistic in a dynamic language/program where complex values are non-deterministically generated at runtime - based on user input, db, file, etc.
In any statically typed language I know, it is possible to create invalid values which looks correct to the type checker. E.g. if a function takes an interface as parameter type, you can create a dummy implementation which throw exceptions for any operation. So basically you have the same problem as you describe for dynamic languages.
If you are talking about untrusted external input then yes, you need to carefully validate and reject invalid input. If you receive JSON or a CSV file or whatever, there are an infinite number of valid inputs and an infinite number of invalid inputs. But this is the same for statically typed languages, and the type-checker will not help you, since a valid JSON string and an invalid JSON string look exactly same to the type checker.
> E.g. if a function takes an interface as parameter type, you can create a dummy implementation which throw exceptions for any operation. So basically you have the same problem as you describe for dynamic languages
That's not at all the same problem, because here you're intentionally writing code that throws exceptions for some reason? Also, many languages, such as Java will not allow you to throw a checked exception that's not declared on the interface method - such issues will be statically checked and caught - thanks for proving my point ;)
> of valid inputs and an infinite number of invalid inputs. But this is the same for statically typed languages, and the type-checker will not help you, since a valid JSON string and an invalid JSON string look exactly same to the type checker.
Not at all, in a statically typed language the JSON would typically be deserialized into a structured type with all the benefits of type checking, validation and usage of the resulting values. Of course it's possible to just use a JSON string directly, but that's not idiomatic and generally not the way it's done in quality codebases.
This kind of thing is really what contract-based programming is meant for; it shouldn't properly be a test, except that we have to resort to that for the lack of language support for DbC.
I really disagree with this. I use static types as a quick correctness check.
I've added types to large python projects to reduce the complexity of reasoning about the code base, and the typing does not make it run faster (actually, the opposite).
I've got lots of experience in developing with both static and dynamically typed languages, I know the differences and it has very little to do with anything you are talking about.
Dynamically typed languages tend to be simpler and easier to use. This means on the whole they have less bugs than their static typed counter parts.
The real issue with dynamically typed languages is that their performance sucks.
(That and according to this thread people not having a clue on how they are properly used. You can't just use the same development techniques as you use in a statically typed language. It's different.)
> I've got lots of experience in developing with both static and dynamically typed languages
And yet your comments demonstrate the opposite.
> Dynamically typed languages tend to be simpler and easier to use.
Very debatable.
> This means on the whole they have less bugs than their static typed counter parts.
Not at all.
> The real issue with dynamically typed languages is that their performance sucks
Every time you say something like this it just makes it obvious you have no idea what you're talking about. You can write almost completely typeless, highly performant, c and assembly code, while high level languages with advanced type systems are generally not the most performant.
You seen to be confused about interpreted/jit/compiled languages and static/dynamic typing - which are not the same thing.
> The article covers a study of the same name. In it, researchers looked at 400 fixed bugs in JavaScript projects hosted on GitHub. For each bug, the researchers tried to see if adding type annotations (using TypeScript and Flow) would detect the bug. The results? A substantial 15% of bugs could be detected using type annotations. With this reduction in bugs, it's hard to deny the value of static typing.
> Yes, I'm sure the LOAD instructions take pictures of cats as operands via their typeless instruction sets... What in earth are you on??
Have you written any assembly? Assembly generally has no or very rudimentary type checking, you're generally dealing with words/bytes and addresses, you can arithmetically add parts of strings, divide pointers, etc. Errors due to these operation will surface at runtime, not be typechecked.
> well once someone does that let me know.
You can use void pointers as return types and arguments for all functions in c code. The effect is significantly less type checking while having equivalent performance.
"A substantial 15% of bugs could be detected using type annotations. With this reduction in bugs, it's hard to deny the value of static typing."
Actually, that makes it really easy to deny the value of static typing. If the total number of bugs in dynamic and static code is the same. But some bugs in dynamic code would be caught by static typing checking.
We most conclude that adding static typing results in a large number of non-typing related bugs being added to the code base. It's simple maths.
"Have you written any assembly?" Yes, I'm an emulator author, thank you very much.
The registers and opcodes are typed with things such as u8, u16, u32, u64, i32, i64 and only work with data of the right type.
"arithmetically add parts of strings, divide pointers" You mean standard C stuff, you know the statically typed language.
"You can use void pointers as return types and arguments for all functions in c code"
Dynamic types is not the same thing as type eraser. That void pointer doesn't carry the information that it points to a picture of a cat for example.
The fact you don't understand the difference between a void pointer and dynamic typing doesn't exactly surprize me. It's more like a giant vtable.
> If the total number of bugs in dynamic and static code is the same.
Completely baseless assumption.
> Yes, I'm an emulator author, thank you very much.
Ahahaha let's have a link then.
> The registers and opcodes are typed with things such as u8, u16, u32, u64, i32, i64 and only work with data of the right type.
Those are sizes, not types, and the same opcode generally applies to signed and unsigned integers. You consider that to be a static type system and you think the purpose is performance and not correctness? Lol
> You mean standard C stuff, you know the statically typed language.
You're trying to debate against the need for static typing by pointing out unsafe parts of c? Ahaha
> That void pointer doesn't carry the information that it points to a picture of a cat for example.
First of all you can totally carry around runtime type info and value with a single void pointer. Not to mention many dynamically typed languages have type erasure and many statically typed languages have runtime type info. Also, you've claimed multiple times that there's no need for type checking whatsoever. You need runtime type information at runtime now?
Not sure what 'num' means in buzz exactly, but it could be something like a Haskell class, choosing the specific instance/implementation automatically, while also allowing explicit specialization if needed.
> Maybe so, but don't you think I talk to new employees?
Everyone below a certain level talks to new employees. Do I believe you take their concerns seriously and actively try to help? Based on my own experience with PEs as well as your comment history I think you absolutely do not.
In general my experience with PEs at Amazon led me to conclude that the vast majority of them are:
- entitled
- lazy
- egotistical
- less technically useful than the average l5 engineer
> On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process
Oh yeah I love the multiple hours we have spend every week 'introspecting' processes, just to throw out one of the dozen we'd already defined and add another one. And this 'introspection' typically boils down to the loudest, most ambitious mouthbreathers forcing their BS down everyones throats so that they can jot down their amazing process contributions in their promo doc. Brutal is the right word.
But it's the difference between an individual carpenter making a rocking chair for himself and his family, or maybe making a couple to sell to his friends, and being a structural engineer.
Bikeshedding is not a necessary antipattern to the process, but large software projects absolutely need group collaboration, and a discussion of processes, tools, and best practices.
'Buidling things with code' is not just coding. It can include design, architecture, collaboration, planning etc. There are many high quality, highly complex, open source projects that don't rely on many of the 'processes', meetings, toxic competiveness, thought-policing, and beuracracy found in AWS.
Based on your comment history (which is consists of about 0% technically interesting topics, and about 100% pro-amazon 'tales from a super-senior principal engineer guyyyss') tells me you don't like engineering, you like politics and beuracracy. Which is okay!
Yup, and the other flipside is devs being extremely nitpicky and regurgitating irrelevant Amazon principles BS in code reviews because they're trying to get promoted.
That one is my favorite. At Amazon, "bias for action" is a knee-jerk managerial phrase that typically means, "I'm going to spew ambiguous/ignorant bullshit into the room and you do something meaningful with it."
Or you reach out to the owning teams/oncalls and half the time they have no idea how their own code/product works for anything nontrivial because most of it was written several generations of attrition ago.
Completely agree. Interesting how the internal dev satisfaction polling always shows that the vast majority of devs just absolutely love the internal tooling and processes. Might have something to do with the polls not actually being anonymous. When hr/polling teams are asked about anonymity they generally skirt or ignore the question, but I've learned that enough metadata is collected to identify any responder in pretty much any internal poll.
There is very little transparency as to how the polling data is used. I'm sure many employees don't feel comfortable giving honest answers on many of the questions. Also the surveys go far beyond tooling question - they ask about future career plans, happiness with the company, happiness with management, whether employees are interviewing for other jobs, etc. It's not hard to see how certain answers to those questions could color the responder in a very bad light from managements perspective.
that can't be right (but i have no idea). In the new group, nobody has any desire to at least do a reference check with the previous group? That would be the first thing as a hiring manager i would try to check for, say "this person is a d-bag that the entire group hated, and we were about to pip him/her anyway"? That would be kind of an equivalent of an approval, even if there is no formal approval.
I mean, yes, having your manager say "I will destroy your career if you think about leaving" would be a kind of approval needed, but short of that level of viciousness it sounds like no?
Not familiar with Amazon culture so I don't know if that'd be considered acceptable behavior. I hope not!
> have you considered that the manager may rightly have bad things to say? or that is just never warranted.
The manager should put those bad things _in writing_ during performance reviews instead of trying to prevent their employees from leaving by dunking on them after they are informed about the fact.
Unless you’re in Focus or Pivot, you’re a free agent. When Amazon is performance managing you in any sense it isn’t up to your existing manager if you can move, it would be an L10 (VP) exception on the receiving side to allow you to move, even if the hiring manager thinks you’re great.
