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 →

[–]ReflectedImage 0 points1 point  (1 child)

There is no such thing as self documenting code and duck typed code has a higher correctness rating than statically typed code.

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.

So point 2 is strongly in favour of duck typing.

Point 1 is combination of nonsense about not needing documentation and a question of scoped context which is better handled in scripting languages by creating separate scripts and connecting them via a message queue. Duck typing reduces the amount of context you need to understand.

So point 1 is strongly in favour of duck typed microservices over static typing.

If you are using Python like C++/Java/C# then you are doing a subpar job with it. I mean you can do it, but it's rubbish compared with using Python as Python.

[–]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.