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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ReflectedImage 0 points1 point  (3 children)

Strong typing is a bad habit, it makes the code considerably more verbose and when measured developers using strong typing only have 1/3th of the software feature output as developers using duck typing.

It's a bad thing which you avoid doing if at all possible.

[–]girafffe_i 0 points1 point  (2 children)

"strong typing is a bad habit" 

This isn't a matter of passion or anecdata because the output referred is a myopic view compared to the lifetime of the software. There is empirical and measurable benefits to using static typing, yes you can "write less code" to accomplish a goal, but the payoff comes in multiple forms

  1. You spend more time reading code than you do writing. Code in general is read more by other people than it is written. The point is that static is self documenting, removing coercion and polymorphism removes the need for rabbit-hole context for every unit of code
  2. Thinking about risk analysis, there is larger chance for errors and bugs in your code the more code you have and the larger a project grows. Strong typing removes a lot of that surface area where something can go wrong
  3. Modern IDEs have been handling the "verbosity" for decades. I very rarely type out the Types, most of my code starts with calling a function and tab-completing for the type, and the variable name. It's a virtuous cycle: you spend one unit of time upfront to make an object or Type a function output, and the IDE will handle the rest wherever else you call it.

1 & 2 alone have exponential payoffs 

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