> 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…
> 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…
The comments in the article you linked dismantle most of the arguments made. From one of the comments: https://dev.to/aussieguy/the-non-broken-promise-of-static-ty... > The article covers a study of the same name. In…
> 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…
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…
K, I'll take your word for it.
Think about that for another second and see if you can spot the obvious huge flaw there.
> 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…
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.
The issue is you think you know what you're talking about, but it's painfully obvious you don't. > Errors that would be caught by static type checking are exceptionally rare when you do commerical development in…
How are the interfaces between these microservices defined? Without types? Lol
> 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…
You have no idea what you're talking about.
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…
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.
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.…
'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…
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…
> 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…
Everytime I bypass some stupid process or break glass, I now just put 'bias for action' as the reason. Ahahaha I don't give a shit anymore.
> 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,…
Interesting, I was told the opposite by my managers...
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.
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.
> 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…
> 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…
The comments in the article you linked dismantle most of the arguments made. From one of the comments: https://dev.to/aussieguy/the-non-broken-promise-of-static-ty... > The article covers a study of the same name. In…
> 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…
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…
K, I'll take your word for it.
Think about that for another second and see if you can spot the obvious huge flaw there.
> 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…
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.
The issue is you think you know what you're talking about, but it's painfully obvious you don't. > Errors that would be caught by static type checking are exceptionally rare when you do commerical development in…
How are the interfaces between these microservices defined? Without types? Lol
> 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…
You have no idea what you're talking about.
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…
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.
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.…
'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…
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…
> 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…
Everytime I bypass some stupid process or break glass, I now just put 'bias for action' as the reason. Ahahaha I don't give a shit anymore.
> 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,…
Interesting, I was told the opposite by my managers...
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.
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.