3 ms·
> comic book readers You say that like reading comic books is an anti-intellectual crime. Getting to the point, look at these examples and tell me which one i
by 10098 13y ago
> comic book readers
You say that like reading comic books is an anti-intellectual crime.
Getting to the point, look at these examples and tell me which one is better from the readability perspective.
> for(std::vector<std::shared_ptr<MyClass> >::const_iterator it = v.begin(); it != v.end(); ++it)
or
> for(const auto &value : v)
Even in the case when the "value" variable's inferred type isn't apparent from the context, we can use
> for(const std::shared_ptr<MyClass> &value : v)
which is still much more readable than the monstrosity in the first example.
- jk4930 13y agoTo make your comparison more useful (and on-topic), you should compare this to a Pascal or an Ada program. You won't find such a syntax massacre there. In fact some verbosity is a design feature that actually helps programers maintaining large, long-living sytems.
- 10098 13y ago> In fact some verbosity is a design feature that actually helps programers maintaining large, long-living sytems. I completely agree with that. For example, static typing adds verbosity, but it also documents the program and makes figuring out a large codebase a lot easier. The "noise" can even be reduced in languages with type inference like D, Haskell or C++11. The thing is, unnecessary verbosity only crowds the code and doesn't add any value. Most of the keywords in "if ... then begin ... end else begin ... end" serve no real purpose and could be replaced with a symbol, like a curly brace.
- vidarh 13y agoI have pretty much the exact opposite view: I find type signatures add noise I don't want, while I find {} to be suboptimal for large blocks. I prefer the Ruby approach, where what you described would usually be: if ... else ... end So it cuts down on the clutter vs. Pascal, but sticks to words rather than single character symbols
- paulrademacher 13y agoWhat you call "noise" is the compiler catching a type-mismatch bug before it goes out into production.
- vidarh 13y agoType errors are typically trivially caught with units tests that are necessary to verify functionality anyway. I used to be a strong believer in static typing and insist that dynamic typing would be extremely error prone, but when I actually tried it, I found that the additional testing required is pretty much non-existent - if you test properly, you tend to cover types as a side effect. I'd still prefer static typing, but only if it doesn't get in the way. And that means minimal annotations, and minimal restrictions.
- pjmlp 13y agoWorking in the enterprise, with off-shored project modules, will restore your faith in static typing. :)