5 ms·

What I have learned is: * Typed languages while more complex are worth it (circa 12 years ago I was a heavy scripting language fan) * Unit tests that heavily

What I have learned is: * Typed languages while more complex are worth it (circa 12 years ago I was a heavy scripting language fan) * Unit tests that heavily use Mocks are almost always a bad sign. Brittle tests suck. Don't increase coverage for the sake of it. * Get it done and move on. Try not to obsess on little details that add no value. * "It depends" * NIH (not invented here) is not always bad. In general it actually is often better (ie invented here). Respect the previous engineers when you move to a new company. There is a reason why things were built the way they are. * Almost everything can be done in Bash :)

flavio81 9y ago
This is interesting. I have programmed in typed languages for most of my life, including C/C++/Java/C#, but when I went to Python, i did not feel any problem with lack of static typing. Or perhaps you mean "strong typing"? Because Python is a "strongly typed" language: It does not do automatic conversion of types, if types are incompatible, an error will be raised. Which I agree with. But it is a dynamically typed language: You don't need to declare types, and, most importantly of ALL, functions and containers (lists, etc) are not bound to a specific input data type. I do think the combination of strong typing + dynamic typing is a great combination. Also, amen brother on your thoughts about Unit tests. They have been greatly overblown these last years.
- agentgt 9y ago
  > This is interesting. I have programmed in typed languages for most of my life, including C/C++/Java/C#, but when I went to Python, i did not feel any problem with lack of static typing. I have heard this a couple of times from some developers with similar backgrounds and I have typically found that either these emacs/vim developers are very disciplined and/or have not really worked with large teams. Or the language hits their problem domain so well that the benefits of productivity and terseness outweigh safety (ie research/scientific computing) and or the projects are small. But having had 15 or so developers working on a project before Typescript was invented I can tell you the pain was tremendous.
quantumhobbit 9y ago
Definitely true about mocks in unit tests. I've seen some nightmare projects where >50% of the code is just setting up mocks for unit tests.

flavio81 9y ago

This is interesting. I have programmed in typed languages for most of my life, including C/C++/Java/C#, but when I went to Python, i did not feel any problem with lack of static typing. Or perhaps you mean "strong typing"? Because Python is a "strongly typed" language: It does not do automatic conversion of types, if types are incompatible, an error will be raised. Which I agree with. But it is a dynamically typed language: You don't need to declare types, and, most importantly of ALL, functions and containers (lists, etc) are not bound to a specific input data type. I do think the combination of strong typing + dynamic typing is a great combination. Also, amen brother on your thoughts about Unit tests. They have been greatly overblown these last years.

agentgt 9y ago
> This is interesting. I have programmed in typed languages for most of my life, including C/C++/Java/C#, but when I went to Python, i did not feel any problem with lack of static typing. I have heard this a couple of times from some developers with similar backgrounds and I have typically found that either these emacs/vim developers are very disciplined and/or have not really worked with large teams. Or the language hits their problem domain so well that the benefits of productivity and terseness outweigh safety (ie research/scientific computing) and or the projects are small. But having had 15 or so developers working on a project before Typescript was invented I can tell you the pain was tremendous.

quantumhobbit 9y ago

Definitely true about mocks in unit tests. I've seen some nightmare projects where >50% of the code is just setting up mocks for unit tests.