If you don't undertand complexity and algorithms you will likely run in t huge performance problems at some point and that will make your whole program useless.

No matter the type of programming complexity and algorithms is involved.

So it is more like saying "not understanding how a car works will make it very hard for you to design or build one".

You're completely wrong there. Most programmers will never have to deal with performance as an issue, because most programmers don't work on web based systems, or centralised systems where huge loads impact a single server

And for such programmers that do, the real key to performance lies in getting multiple computers to work together, and not in fine tuning algorithms.

Most people can intuitively understand the factor by which a linear search is different from a binary search, without any particularly in depth study of complexity theory.

This P vs NP thing is just a way for CS students to show off with letters that make their craft seem mysterious. In the real world, one can come through without understanding this.

Not understand how a car works? That's really silly. Understanding the speed of algorithms is important, but it's a tiny tiny part of writing large complex programs. Most parts of a programs are not about number crunching, but about information management.

(Obviously, I've got an computer engineering degree, and I learned all this, I'm just pointing out that in general and in the real world it has very rarely been neccessary to know this)

What you really mean is "in my job, I haven't had to use these particular concepts," which is of course completely anecdotal, and, given the response (and voting) of other HN users, probably not a very common situation.

In my business, the difference between polynomial and NP is the difference between a thousand clocks and a million clocks, the difference between a practical quantization optimization algorithm and a totally useless one. And if you don't understand that before trying to write it, you're going to waste days of coding time on a pipedream.

NP problems are incredibly common in almost all fields one could imagine. Not being able to identify them before wasting time trying to optimally solve them is a recipe for disaster and the sign of a completely incompetent programmer.

The voting of HN users will never be relevant to my opinions.

I have needed to use the concepts in my job, and I'm pointing out that these are really not what computer science is about. Anybody who focuses on algorithmic efficiency based off speed is looking at the bark of a tree and failing to recongize that the forest is being cut down.

Our problems with CS have become wider and bigger and different. We are having to deal with abstractions of very complex behaviour, and N vs NP, even though it should be understood, is not something that needs to be focused on in-depth in most programming activities today.

NP problems are not 'incredibly common' in most programming activities. They are common in most programming fields, just as molecules are common in most human beings, but it does not mean that all human beings have to bio scientists.

The reason I am arguing against this N-NP name dropping is that I believe that to properly evolve in computer science, we need to abstract away the details and focus on the bigger picture. For that to happen, we WILL need a generation of programmers that should not need to know this stuff. Just like many new programmers do not know assembler.

You're obviously preaching to the choir here, so lots of people will agree with you. But I am convinced that the only path forward we have is by wrapping complexity in aggregates, so that programmers can create even more complex machines. We need to get rid of the details for a certain class of high level programmers, otherwise we will not be able to break out of the existing models we have.

I think we turned what was an innocent and perhaps true remark to a certain degree(people like to namedrop it) into a quarrel here.

I'm not saying that computer science is all day P vs NP philosophy. I'm just saying that you have to know complexity and algorithm theory to work in the field just as you have to understand the hardware, you might get by most of the time without it but when you don't, if you don't even know where to start, you'll have a mountain to climb rather than a little tree.

* However your remark about how this should be abstracted away and people shouldn't have to know it in the same way people don't have to know assembler now, that's not the same thing at all.

Well, what I've learned from this is that people are really sensitive about their P-NP knowledge. Look at the scale of the down-moding I'm getting :)

I think I'd better stop making trying to make my point now, it apparently is not being understood.

I'm guessing most of the downvotes are due to the confusion between software engineering and computer science.

From wikipedia:

Computer science (or computing science) is the study and the science of the theoretical foundations of information and computation and their implementation and application in computer systems.

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

--

I think you are talking about software engineers and everyone else is defending computer scientists.

The excessive downvoting has become something of a recent fad here. I'd have put your comments to -1, but not further, because I do, like apparently many, believe that your notions are fundamentally flawed.

Complexity theory isn't hand-wavey-ultra-complicated-irrelevant CS; it's first / second semester stuff. It's fundamental enough that it's a cognate for most lots of physics, math and engineering students. That's to say, that it's relevant enough that if you're even doing something moderately related to computer science that it's worth knowing.

Are there a lot of jobs where you don't need to know this stuff? Well, I think there are a lot of jobs where you can get by without knowing basic CS, but it'd still benefit you from time to time to be able to apply these sorts of abstractions.

"Why is this function so slow?"

"Its runtime is quadratic."

"Huh?"

In my particular case, not knowing fundamentals of CS theory would cut me out of being able to work on precisely the problems that I find most interesting in programming.

I understand the theory perfectly, having a pretty good degree in CE. My argument has nothing to do with my personal situation, I'm running an argument based on a theoretical situation.

If you look at any other field containing "engineers", the mathematical basics are not abstracted away over time. Mechanical engineers have taken courses in math and physics; that part never goes away. Technicians are the guys who may have impressive technical knowledge and skills but never learned the theory behind it. From the perspective of the old-fashioned engineers, if a programmer calls himself a "Software Engineer" instead of a "Computer Programmer", he'd better have some fundamentals to back it up. (Of course not all programmers need to be engineers -- technicians are great. But somebody in the building needs to known why things work they way they do.)

Actually, you're right. My study is in Computer Engineering with focus on robotics, so my focus has been different so far.

Search engines and scientific computing spend a lot of time searching for more efficient algorithms and more efficient approximations of algorithms when the size of the data sets become ridiculously large. They might not be "real world" enough for you, but I would like to work at a search engine after I graduate.

What is this "bigger picture"? So far you've offered a smaller picture, by telling us what should not be learned. What should be learned instead?

No, it's like saying that people who suck at physics can never design or build a car.