4 ms·
The fact that strong static types makes the code self-documenting is the reason I vastly prefer it. It makes me so much more productive, by orders of magnitude
by magicalhippo 3y ago
The fact that strong static types makes the code self-documenting is the reason I vastly prefer it.
It makes me so much more productive, by orders of magnitude. And I say this as someone who has worked extensively in several different languages which covers large parts of this spectrum, like C, C++, Java, Python, JavaScript, TCL and others.
It makes it much easier for me to reason about code I have not recently worked on, be it in the current project or in dependencies. It also means I can be way more focused on the problem at hand, since I'm not constantly having to go on tangent goose chases to figure out what exactly I can do with this object that some function returns.
Sure there's the good, fuzzy feeling when the compile doesn't error out. But that's secondary.
- ReflectedImage 3y agoStatements like: "The fact that strong static types makes the code self-documenting is the reason I vastly prefer it." is exactly the reason why you shouldn't be use static typing. We have a developer here who doesn't document any of their code and thinks that a good thing. Whereas in the dynamic typing world, they would be forced to use the good practice of documenting their code. Code is never self-documenting, there are research studies on it.
- magicalhippo 3y agoYou misunderstand. I'm not advocating you shouldn't comment or document your code. Sure I can see you multiplied that gross weight by a factor of two, but why? That usually needs to be documented. But the types provides for let's say code-level self-documentation. I can look at a function definition and see it returns an IReadOnlyStream. Well if I'm familiar with IReadOnlyStream I already know what I can do with that. If not I can quickly find the declaration, and based on that I can get a good overview of what I can do. If not I have something explicit to search the documentation for. With languages such as JavaScript I learn nothing by looking at the function definition, and almost always have to dig deeper. If it's an unfamiliar code-base, then often much, much deeper.
- ReflectedImage 3y agoYeah but IReadOnlyStream relies on the developer knowing what an IReadOnlyStream actually is. You would be better off using dynamic typing and returning an Iterator. The dynamic typing route of a small number of language defined types is far better than any developer declaring their own types whenever they want. Why? Because it's simpler and simpler code is faster to write and easier to test.
- magicalhippo 3y ago> You would be better off using dynamic typing and returning an Iterator. The point is that most of the time I wouldn't know it's returning an Iterator, because it's poorly or not document. At least that is my experience. Anyway, I was only speaking for myself. And my personal experience is exactly the opposite: I'm far less productive in dynamic languages when working on any non-trivial codebase, for the reasons I stated.
- ReflectedImage 3y agoYes but if you were Tabula Rasa you would ship out software features 3x faster with significantly less bugs using dynamic typing than if you used static typing.
- magicalhippo 3y agoThat is quite frankly a ridiculous, unsubstantiated statement.
- mpweiher 3y agoSmalltalk’s Proven Productivity https://medium.com/smalltalk-talk/smalltalk-s-proven-productivity-fe7cbd99c061 https://medium.com/smalltalk-talk/smalltalk-s-proven-product... http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...
- freilanzer 3y agoSo you would rather work on undocumented code in a dynamic language than undocumented code in a static language? That makes no sense at all.