I have never had a real-life use case for Big-O notation, except in interviews. Nor had a real-life use case for caring about sort algorithms. I mean, not once.
That is frightening. I can't think of any function I write without taking a second to think about what the Big-O would be.
And I don't even know how I could do things like parse input without knowing how to structure it so that look-ups never take more than log N time. And I don't know how I could do that without knowing sorting algorithms intimately.
And I am not writing codecs or kernel code, mostly it has been high performance and some soft real time, but I've also worked in back end web development.
Everything in your second paragraph I fully endorse, but your first paragraph is terrifying. I'm terrified I'll run into someone like you some day, clearly smart, clearly experienced and without a clue as to why I'm concerned about the Big-O of his implementation of something.
Some people know the computational complexity of something they write without knowing it in terms of Big O. Before my CS degree, I understood that looping through a list and for each item, looping through the same list again was not optimal. And someone only needs to write an O(n^3) algorithm once to realize that it's a very bad idea for any but the smallest amounts of data. Knowing about Big O is nice though, if only to understand documentation (realizing that O(nlogn) is better than O(n^2)).
I don't think he formally uses big-O but understands if something he is writing is linear (iterating over an array), exponential or O(1).
People have to get rid of their big hard on for Big-O, a useful concept that takes a couple hours to learn. It isn't a difficult thing that only the true macho programmers can know. I'd wish it was traditionally in starting programming books in the 'optimization & profiling' chapter and we wouldn't be having big fights about it.
>someone like you ... without a clue as to why I'm concerned about the Big-O
Except that's not what he said. He clearly does have a clue, he just hasn't actually needed it. And for application development, where most of the work is wiring together libraries, that's sounds about right.
Everyone writing code for a living has internalized when to use a map vs a vector. If that is the bar for "fundamental", then this whole discussion is pointless.
Comments
I have never had a real-life use case for Big-O notation, except in interviews. Nor had a real-life use case for caring about sort algorithms. I mean, not once.
That is frightening. I can't think of any function I write without taking a second to think about what the Big-O would be.
And I don't even know how I could do things like parse input without knowing how to structure it so that look-ups never take more than log N time. And I don't know how I could do that without knowing sorting algorithms intimately.
And I am not writing codecs or kernel code, mostly it has been high performance and some soft real time, but I've also worked in back end web development.
Everything in your second paragraph I fully endorse, but your first paragraph is terrifying. I'm terrified I'll run into someone like you some day, clearly smart, clearly experienced and without a clue as to why I'm concerned about the Big-O of his implementation of something.
Some people know the computational complexity of something they write without knowing it in terms of Big O. Before my CS degree, I understood that looping through a list and for each item, looping through the same list again was not optimal. And someone only needs to write an O(n^3) algorithm once to realize that it's a very bad idea for any but the smallest amounts of data. Knowing about Big O is nice though, if only to understand documentation (realizing that O(nlogn) is better than O(n^2)).
I don't think he formally uses big-O but understands if something he is writing is linear (iterating over an array), exponential or O(1).
People have to get rid of their big hard on for Big-O, a useful concept that takes a couple hours to learn. It isn't a difficult thing that only the true macho programmers can know. I'd wish it was traditionally in starting programming books in the 'optimization & profiling' chapter and we wouldn't be having big fights about it.
>someone like you ... without a clue as to why I'm concerned about the Big-O
Except that's not what he said. He clearly does have a clue, he just hasn't actually needed it. And for application development, where most of the work is wiring together libraries, that's sounds about right.
Everyone writing code for a living has internalized when to use a map vs a vector. If that is the bar for "fundamental", then this whole discussion is pointless.