3 ms·

P vs NP is a pretty real problem, complexity theory is superimportant. People how can't do proper Big-O-analysis are forever doomed to suck at programming.

markessien 18y ago
That's like saying that people who suck at changing tires of cars can never design or build a car.
- globalrev 18y ago
  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".
  - markessien 18y ago
    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)
    - DarkShikari 18y ago
      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.
      - markessien 18y ago
        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.
- rgjm 18y ago
  No, it's like saying that people who suck at physics can never design or build a car.

markessien 18y ago

That's like saying that people who suck at changing tires of cars can never design or build a car.

globalrev 18y ago
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".
- markessien 18y ago
  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)
  - DarkShikari 18y ago
    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.
    - markessien 18y ago
      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.
rgjm 18y ago
No, it's like saying that people who suck at physics can never design or build a car.