3 ms·
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#,
by d--b 11y ago
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"
- lmm 11y agoThere'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.
- d--b 11y agoThat'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.
- lmm 11y ago> 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.