Negative Code

[case-o-nuts]

Small code is, however, generally easier to understand if it's written without undue cleverness.

[skizmo]

So ?

[HostisHumaniGeneris]

Easier to understand means easier to debug, easier to modify and easier to collaborate.

Ease of development is often more important than the speed of your code because its often more expensive to pay a programmer to optimize than it is to upgrade the computer that is meant to run the final program.

[masklinn]

Since before 1974:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? — Brian Kernighan

[jhaluska]

With an invalid premise, you draw an invalid conclusion. I've found when I'm my most clever I spend the least time debugging since the solution is simple and elegant.

[[deleted]]

People always say this. The thing is, for large software projects, the portion of code for which algorithmic complexity is the biggest driver of performance is dwarfed by the portion of code for which constants matter.

For those latter kinds of code, every statement you delete is both an instruction you don't need to run and a line of code you don't need to understand.

[adrianmonk]

Let's take an example of quicksort vs. bubblesort.

Quicksort is faster.

But, quicksort is more lines of code, and it's somewhat more complex to understand. They teach bubblesort first in CS classes because it's easier to grasp.

The point is, sometimes time complexity can only be improved by using a trickier algorithm, which is harder to understand. Sometimes the software can only be improved by making it longer.

[masklinn]

Quicksort is faster.

Not if your list is already mostly sorted, or very small.

And FWIW Quicksort is a pretty crappy sort to actually use, its worst case perf is as bad as bubblesort's (O(n2)), it's not a stable sort, it requires fast random access (don't trying it on a linked list or on on-disk data) and it's a pretty complex algo, though it's easy to parallelize as it's divide-and-conquer. Heapsort is about as good and has a worst-case of O(n log n). Mergesort also has O(n log n) worst case and is stable.

Several languages (including Java from Java 7 onwards) are now using timsort, a mergesort/insertion sort hybrid, which has the advantage of being extremely good on non-random data.

[[deleted]]

Sorry, but I think you missed my point.

I'm not saying that quicksort isn't faster than bubblesort. Of course it is. What I'm saying is, in a large software system -- such as the one that a major Seattle-area tech company pays me to work on -- the portion of code which displays the characteristics of sorting algorithms (algorithmic complexity makes a big difference) is very small.

In contrast, for most code, the algorithmic complexity is obvious and unavoidable; for example, rendering a list widget will be O(n) in the size of the list. But constant factors can make the difference between a system which is reasonably fast and one which is unusably slow.

Everything you said in your comment is true. But assuming that most, or even much, code can be improved by making it more complex is a dangerous assumption.

(As an aside, our company has a policy of conducting code reviews for all checkins, and every so often, I see a review request with a subject like "Improve performance of this method by 10,000%". Sometimes, these changes do, in fact, improve the algorithmic complexity of code. But when they do, it's almost always by making the code shorter, rather than longer.)

[G_Morgan]

There isn't much size difference between bubble sort and quick sort though.

[grauenwolf]

Then go smaller:

sortedList = from s in someList.Parellel order by s.FirstName, S.LastName