I have to be honest in that, while I think duck typing should be embraced, I have a hard time seeing how people are actually able to deal with large-scale pure Python projects, just because of the dynamic typing. To me, it makes reading code so much more difficult when I can’t just look at a function and immediately see the types involved.
Because of this, I also have a small hangup with examples in some C++ libraries that use auto. Like sure, I’m happy to use auto when writing code, but when reading an example I would very much like to immediately be able to know what the return type of a function is. In general, I think the use of auto should be restricted to cases where it increases readability, and not used as a lazy way out of writing out the types, which I think is one of the benefits of C++ vs. Python in large projects.
I have to be honest in that, while I think duck typing should be embraced, I have a hard time seeing how people are actually able to deal with large-scale pure Python projects, just because of the dynamic typing. To me, it makes reading code so much more difficult when I can’t just look at a function and immediately see the types involved.
Because of this, I also have a small hangup with examples in some C++ libraries that use
auto
. Like sure, I’m happy to useauto
when writing code, but when reading an example I would very much like to immediately be able to know what the return type of a function is. In general, I think the use ofauto
should be restricted to cases where it increases readability, and not used as a lazy way out of writing out the types, which I think is one of the benefits of C++ vs. Python in large projects.Generally speaking, I like duck typing for function inputs, but not as much for function outputs (unless the functions are pure mathematics).