Re^3: Learning Fundamentals: Data Structures and Algorithm Analysis in Perl

[BrowserUk]

but a very large fraction are unaware of the formal definition

I think far too much is made about "formal definitions". Back when I did my formal CS education, I chose a multi-part long questionon big-O as my optional question. I passed the exam with distinction. Of course they don't tell you anything more than the overall scores, but I think I would probably have had to have scored perfectly on the four compulsuries to achieve that if I'd totally flunked the optional. Back then I could have, and probably did, give a formal definition of big-O and big Omega.

But over a 25 year career, I never once needed to repeat it. And nor has it ever been useful to me. But the education means that I do have a way of informally discussing algortihmic complexity in terms that many other programmers recognise and understand. So in that sense the knowledge of it is useful.

But in the real-world, when, as you point out, an O(n^2) algorithm in one language can out perform an O(n log n) in another; when memory allocation/reallocation costs can render a formally faster algorithm slower than a formally slower algorithm, because the latter is more cache friendly (eg. Mergesort versus QuickSort); and given multi-tasking OSs and mutli-core hardware renders static formal analysis iffy at best and an outright lie at worst; the usefulness of big-O is pretty much limited to discussion purposes only. A benchmark run many times under real-world or realistic conditions renders it mostly redundant.

A starting point, and a means of informal discussion, but little more.

[tilly]

When I speak of a significant portion of hackers, I am not speaking of any particular one. I am not surprised that you'd have learned the formal definition.

Although I have to disagree on how extreme your dismissal is. Absolutely big-O is useful as a starting point and means of informal discussion. However it also provides a framework for how to think about performance, and that can go a lot farther. Being aware of big-O has helped me predict how well real systems will scale, understand bottlenecks, and multiple times has given me a sense as to whether a given implementation's performance is reasonable, or whether a performance mistake needs to be tracked down.

[BrowserUk]

My point wasn't that I know it. More that I knew it once, but probably could not have recalled it accurately for most of of my career and never missed the absence of the recall. I've never had the need to establish the formal, algorithmic complexity of any given algorithm in the real-world, since I learnt the formal methods involved. But the informal appreciation of what the notation means has allowed me to discuss algorithms without worrying too much about the fine distinctions.