4 ms·

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

by d--b 11y ago

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.

victorNicollet 11y ago
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: https://news.ycombinator.com/item?id=6912474 https://news.ycombinator.com/item?id=6912474
Singletoned 11y ago
> These idioms have a complete disregard towards performance. As they should. "Premature optimization is the root of all evil".
- thejaredhooper 11y ago
  The actual quote is "premature emphasis on efficiency is a big mistake which may well be the source of most programming complexity and grief." The 'summarized' catch-phrase always bothers me; the choice between optimized code and inefficient code is always clear to me.
  - user51442 11y ago
    The "premature optimization" quote is from Knuth's Turing Award lecture: http://delivery.acm.org/10.1145/370000/361612/a1974-knuth.pdf http://delivery.acm.org/10.1145/370000/361612/a1974-knuth.pd... "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."
    - user51442 11y ago
      ..as well as "Structured Programming with go to Statements".
- d--b 11y ago
  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.
lmm 11y ago
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.
- d--b 11y ago
  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.
  - lmm 11y ago
    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.
    - falcolas 11y ago
      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.
    - 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"

by d--b 11y ago

victorNicollet 11y ago

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: https://news.ycombinator.com/item?id=6912474 https://news.ycombinator.com/item?id=6912474

Singletoned 11y ago

> These idioms have a complete disregard towards performance. As they should. "Premature optimization is the root of all evil".

thejaredhooper 11y ago
The actual quote is "premature emphasis on efficiency is a big mistake which may well be the source of most programming complexity and grief." The 'summarized' catch-phrase always bothers me; the choice between optimized code and inefficient code is always clear to me.
- user51442 11y ago
  The "premature optimization" quote is from Knuth's Turing Award lecture: http://delivery.acm.org/10.1145/370000/361612/a1974-knuth.pdf http://delivery.acm.org/10.1145/370000/361612/a1974-knuth.pd... "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."
  - user51442 11y ago
    ..as well as "Structured Programming with go to Statements".
d--b 11y ago
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.

lmm 11y ago

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.

d--b 11y ago
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.
- lmm 11y ago
  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.
  - falcolas 11y ago
    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.
  - 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"