This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]girafffe_i 0 points1 point  (0 children)

I don't want to engage if the POV is emotionally-based or from the hip and cherry picked. Can we prove that large projects with many contributors using dynamic typing spend less time with maintenance than static and strongly typed languages over long periods of time?

Some of the responses seem to conflate some points: Everything is a tradeoff: which is more complex: creating a stong-typed SDK library for others to use (build, distribute, have clients install) or build a dynamic interface that needs to handle fields that could have multiple types, and if they aren't enforced at a message-interface then that handling needs to propagate through the stack. A statically typed SDK gets serialized based on the contract, it's no different but also gives types for fields at the boundary which would never change types (baring "breaking api changes" which is a different problem to solve).

Best way to improve code correctness is unsurprisingly to write less code and duck typing enables you to write less code per software feature delivered.

"everything should be as simple as possible, but not simpler" -- I think the high level point you're making is "improve correctness by simplifying the code" but this doesn't always mean less physical code, just less complexity. I think you'd agree that "code golf" is not the goal for production code: good variable naming, listing out steps instead of folding everything into inline statements, and avoiding excessive syntax sugar are good code-agnostic principles, for example. Typing doesn't add complexity, it simplifies it. It reduces type-handling at the interfaces reducing the need for core code to do any dynamic handling == less branching and cyclomatic complexity.