A lot of commenters here seem to be (incorrectly) conflating code which DOES math with code BEING math. Yes there's a lot of products that need high math (i.e. simulations) but there's also a lot of products that are successful when they do extremely complex data movement and organization but very little mathematical transformations.
If programming was so close to math, wouldn't people who are really good at math write the best code? Maybe that's a straw man statement, but in my experience, the people who are really REALLY good at math (e.g. the radio frequency signals processing guys) happen to write the worst code I've ever seen. I've spent much of my career taking prototypes written by DSP engineers and making them go 10 to 100 times faster and use a tenth as much memory. That's not belittling their skills! They did something absolutely amazing that I cannot do, coming up with the steps and crazy weird math required to process signals. (And often, even though I make their code go way faster, I still don't really understand the math behind it when I'm done.) Their code just happens to not take proper advantage of the hardware or other resources. They do the equations so it *functions*, but they don't know how to make it *fast*.
The real skill comes from being able to picture the structure of the data in your mind as complex interconnecting shapes and mentally animate the movement and transformation of data in as few steps as possible without redundancy or useless or redundant transformations; and in many cases, being able to picture multiple workers doing their work in parallel is a plus. I'm not saying every great programmer uses their visual cortex, just that they can keep track of a lot of moving pieces in their mind.
This isn't math. This is more like a visual/spatial skill, like a mechanical engineer designing a complex machine with a lot of moving parts that have to fit together perfectly and move through each other's space in perfect timing. I think it's a different part of the brain from either math OR language.
I have to agree with Kun that complexity analysis (big-O) is absolutely mandatory, though. Saying complexity analysis is "pretty much meaningless" is the dumbest part of Mei's article. Kun also makes good points about recent innovations in DSP, machine learning, etc come from math--but only the *theory* part. You still need people good at the mechanics of programming to *implement* that theory in a productizeable way.
I would like to ask a stupid question. If my employer is doing this, and I'm using Chrome to look at, say, https://mail.google.com/, when I click on the little green lock next to the URL to view the Certificate Information, and my company's name is NOT present (the cert path is GeoTrust Global / Google Internet Authority / mail.google.com) can trust that to mean my company is not intercepting that traffic? Or can my company make it appear this way and still be intercepting my traffic?
I suspect there are a number of people who would like to know the answer to this. I'm hoping it's not as stupid a question as it sounds.
Exactly. This was posted on gizmodo last week, and the site crashed shortly after that due to the click load. The comment I made at the time was:
It is one thing to build a nice web site with a nice interface. It is quite another to build a nice web site that talks to a real database. It is quite a third thing to build a nice web site that talks to a real database and can handle a thousand users. It is quite a fourth thing to build a nice web site that talks to a real database and can handle a million users. It is quite a fifth thing to build a nice web site that talks to a real database and can handle a hundred million users. It is a sixth thing to do all that and talk to 50 databases. It is a seventh thing to do all that and talk to 50 databases managed by a hundred different state agencies and insurance companies who can't all seem to read an API spec the same way.
My biggest problem in getting my patent applications approved has always been "enforceability." One example was a method for maximizing PCI bus utilization in a many-board CompactPCI cage (it was a sort of token-distribution method for preventing wait-cycles and bus-to-bus bridge fifo overruns, kind of silly in retrospect). The patent review board looked at the stuff I've written and says "yeah, that's a really good idea, but how would you ever detect that a competitor's product is violating it?" Which is a good point, about the only way you'd know is by connecting PCI analyzers to the backplanes of every PCI product known to man and spending hours on each one analyzing traffic trying to figure out if they're distributing tokens or somesuch.
So based purely on the grounds of the idea, they would have been willing to pursue it, but given that we never would have been able to tell if someone else's PCI-based product was doing it, they didn't think it would be worth spending the tens of thousands of dollars it would have taken to push the application through.
It wasn't long after that that I realized the flipside of the coin is also true. If I am coding something like this, how would I know that someone already has a patent on it? There's a million different ways to describe it (anything from "token flow control method on a shared memory bus" to "method to increase multiple queue throughput") and many may apply without even using the words "PCI" or "flow control" or "token" -- so how would you ever possibly do an exhaustive search of the literally millions of SW patents out there? The answer is, you don't. You just have a large well-paid legal staff that can fight off any tom dick or jane who thinks their poorly-worded patent somehow can be twisted into applying to your product. I'm pretty sure the average developer writes at least one thing every month of their careers which violates some interpretation of some patent somewhere.
The patent system exists for the purpose of encouraging creative people to come up with creative ideas, and then protect and profit from those ideas. Given the limitations of the software patent, and the vague genericness of ridiculous software patents, it is obvious that software patents are completely incapable of meeting those goals. Smart people don't file for patents for creative things they done. SW patents have completely degenerated into handguns & bullets for large companies : when a company wants to (indiscriminately) impact the pocketbook of another company, they just load up some random SW patent and pull the trigger. They're not used for protecting creativity. They're used to force a court to force a competitor that they don't like to cough up huge wads of money.
As the piston goes up and down, the piston's angle with respect to the piston rod is changing. Before the piston reaches top-dead-center (on the upswing) the piston is pressing mostly against one side of the cylinder. After top-dead-center, it rocks over on the wrist pin so on the down-swing it is now pressing mostly on the other side of the cylinder. I always thought knocking was because this transition was more violent due to the early combustion increasing the amount of pressure on the piston too early.
Slashdot Mirror
A lot of commenters here seem to be (incorrectly) conflating code which DOES math with code BEING math. Yes there's a lot of products that need high math (i.e. simulations) but there's also a lot of products that are successful when they do extremely complex data movement and organization but very little mathematical transformations.
If programming was so close to math, wouldn't people who are really good at math write the best code? Maybe that's a straw man statement, but in my experience, the people who are really REALLY good at math (e.g. the radio frequency signals processing guys) happen to write the worst code I've ever seen. I've spent much of my career taking prototypes written by DSP engineers and making them go 10 to 100 times faster and use a tenth as much memory. That's not belittling their skills! They did something absolutely amazing that I cannot do, coming up with the steps and crazy weird math required to process signals. (And often, even though I make their code go way faster, I still don't really understand the math behind it when I'm done.) Their code just happens to not take proper advantage of the hardware or other resources. They do the equations so it *functions*, but they don't know how to make it *fast*.
The real skill comes from being able to picture the structure of the data in your mind as complex interconnecting shapes and mentally animate the movement and transformation of data in as few steps as possible without redundancy or useless or redundant transformations; and in many cases, being able to picture multiple workers doing their work in parallel is a plus. I'm not saying every great programmer uses their visual cortex, just that they can keep track of a lot of moving pieces in their mind.
This isn't math. This is more like a visual/spatial skill, like a mechanical engineer designing a complex machine with a lot of moving parts that have to fit together perfectly and move through each other's space in perfect timing. I think it's a different part of the brain from either math OR language.
I have to agree with Kun that complexity analysis (big-O) is absolutely mandatory, though. Saying complexity analysis is "pretty much meaningless" is the dumbest part of Mei's article. Kun also makes good points about recent innovations in DSP, machine learning, etc come from math--but only the *theory* part. You still need people good at the mechanics of programming to *implement* that theory in a productizeable way.
I would like to ask a stupid question. If my employer is doing this, and I'm using Chrome to look at, say, https://mail.google.com/, when I click on the little green lock next to the URL to view the Certificate Information, and my company's name is NOT present (the cert path is GeoTrust Global / Google Internet Authority / mail.google.com) can trust that to mean my company is not intercepting that traffic? Or can my company make it appear this way and still be intercepting my traffic? I suspect there are a number of people who would like to know the answer to this. I'm hoping it's not as stupid a question as it sounds.
Exactly. This was posted on gizmodo last week, and the site crashed shortly after that due to the click load. The comment I made at the time was: It is one thing to build a nice web site with a nice interface. It is quite another to build a nice web site that talks to a real database. It is quite a third thing to build a nice web site that talks to a real database and can handle a thousand users. It is quite a fourth thing to build a nice web site that talks to a real database and can handle a million users. It is quite a fifth thing to build a nice web site that talks to a real database and can handle a hundred million users. It is a sixth thing to do all that and talk to 50 databases. It is a seventh thing to do all that and talk to 50 databases managed by a hundred different state agencies and insurance companies who can't all seem to read an API spec the same way.
My biggest problem in getting my patent applications approved has always been "enforceability." One example was a method for maximizing PCI bus utilization in a many-board CompactPCI cage (it was a sort of token-distribution method for preventing wait-cycles and bus-to-bus bridge fifo overruns, kind of silly in retrospect). The patent review board looked at the stuff I've written and says "yeah, that's a really good idea, but how would you ever detect that a competitor's product is violating it?" Which is a good point, about the only way you'd know is by connecting PCI analyzers to the backplanes of every PCI product known to man and spending hours on each one analyzing traffic trying to figure out if they're distributing tokens or somesuch. So based purely on the grounds of the idea, they would have been willing to pursue it, but given that we never would have been able to tell if someone else's PCI-based product was doing it, they didn't think it would be worth spending the tens of thousands of dollars it would have taken to push the application through. It wasn't long after that that I realized the flipside of the coin is also true. If I am coding something like this, how would I know that someone already has a patent on it? There's a million different ways to describe it (anything from "token flow control method on a shared memory bus" to "method to increase multiple queue throughput") and many may apply without even using the words "PCI" or "flow control" or "token" -- so how would you ever possibly do an exhaustive search of the literally millions of SW patents out there? The answer is, you don't. You just have a large well-paid legal staff that can fight off any tom dick or jane who thinks their poorly-worded patent somehow can be twisted into applying to your product. I'm pretty sure the average developer writes at least one thing every month of their careers which violates some interpretation of some patent somewhere. The patent system exists for the purpose of encouraging creative people to come up with creative ideas, and then protect and profit from those ideas. Given the limitations of the software patent, and the vague genericness of ridiculous software patents, it is obvious that software patents are completely incapable of meeting those goals. Smart people don't file for patents for creative things they done. SW patents have completely degenerated into handguns & bullets for large companies : when a company wants to (indiscriminately) impact the pocketbook of another company, they just load up some random SW patent and pull the trigger. They're not used for protecting creativity. They're used to force a court to force a competitor that they don't like to cough up huge wads of money.
As the piston goes up and down, the piston's angle with respect to the piston rod is changing. Before the piston reaches top-dead-center (on the upswing) the piston is pressing mostly against one side of the cylinder. After top-dead-center, it rocks over on the wrist pin so on the down-swing it is now pressing mostly on the other side of the cylinder. I always thought knocking was because this transition was more violent due to the early combustion increasing the amount of pressure on the piston too early.