Where it does make you a worse programmer however, is when you don't realize that using the join method on an iterator means that you are going to concatenate a whole lot of strings, while in most cases, you actually could know the size of the final string from the beginning, and you don't need to allocate a whole bunch of arrays in the process.
These idioms have a complete disregard towards performance.
Many operations are optimized for typical use cases, for instance calling C# `string.Join` on short iterators will allocate no memory beyond that of the final string. The definition of "short" may be obscure (result is less than ~350 characters), but the optimization exists and is documented for anyone who cares enough about the tools in their toolbox.
I do agree with your general point, though. I remember a one-line change in a Haskell function that led to a 10x increase in performance:
If you don't profile your code automatically on every build then you have no business even thinking about such things. And if you do, that will alert you as to whether it's a problem or not. Let the computer do the bookkeeping for you, that's what being a programmer is.
I am simply saying that automatically choosing the nicer looking code just because it's nicer is not always the proper option. Being a good developer implies knowing when you're making a readability / performance tradeoff. If using idioms makes you lazy to the point that you no longer want to write more efficient code, then yes, it's making you a worse developer.
Laziness is one of the three cardinal virtues of a programmer. In my experience thinking you know the performance characteristics of any given piece of code is always a mistake. It's certainly not true that functional idioms in general perform worse - e.g. map/reduce style can be automatically parallelized, making it more efficient on modern multicore machines than explicit loops. If you know you're writing for a specific computer you can no doubt do better by using assembly, but functional code in general is more adaptable to the unknown future, because it tends to require specifying less of the details.
Look, I am not here to say that functional programming is bad, I really enjoy using these idioms. I am just speaking from experience. Since Linq has come to C#, I see things like this in my workplace:
VeryLargeList.Select(x => x.Blah).ToArray()
And people are wondering why they get OutOfMemoryException.
Before linq, people would just loop, and the array would not have to be allocated dynamically.
All I am saying is "more abstraction may lead to performace issue, and people should be aware of it"
There's no reason that should use any more memory than an explicit loop. Maybe the particular implementation in C# does, but that's an implementation problem, not a language problem.
That's my point: the language cleanliness may obfuscate dirty implementation details, and a good developer should know what these are.
Another example, when you do this:
SuperLargeList.Where(x => x.Blah).ToArray()
There is no way for the compiler to know whether the output array will have a small size or a large size, and so it will choose one or the other assumption (dynamic vs fixed allocation). The language chooses for you how it implements things, and this is all fine as long as you know about it, and as long as you can do something about it in the case when you need to optimize.
> That's my point: the language cleanliness may obfuscate dirty implementation details, and a good developer should know what these are.
So what, we should write everything as CPU microops? A good developer should be capable of looking at that level, sure, but it shouldn't be the default; most of the time the computer is better at judging these questions than the developer.
map can only be automatically parallelized if the function has no side effects. Most languages are incapable of identifying if this is the case, so the compilers can not automatically parallelize such code.
I strongly disagree. Automatic profiling only helps when you have a high-performance module and you want to prevent random commits from hurting that performance.
If you write a module with no regard for performance, because automatic profiling is still "in the green", you will spend your entire time budget (milliseconds-per-frame, milliseconds-per-request, milliseconds-per-megabyte, etc.) in the first half of your project and slowly realize that it's getting harder and harder to add new features without going into orange or even red territory. Sure, you can shave off 10% or 20% in "quick wins" with a bit of profiling, but nothing short of a rewrite can save you from inefficiency by a thousand cuts.
This doesn't matter if the module is not performance-critical, obviously. But when it is, then you should either plan for performance from the very start, or plan for a rewrite.
What I am pointing out is that by his own admission, the OP is likely to _never_ think about writing the code in a more efficient manner. He has _no_ _idea_ of the difference. Premature optimization may very well be the root of all evil, but knowingly ignoring the physical constraints of a computer is not great either.
"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming."
These idioms have a complete disregard towards performance.