I wish to subscribe to your newsletter - how can you prove that a real life bridge will stay up? You can never know all the details of the land surrounding it, nor the weather it will face, nor even the materials it will be constructed from.
And that is something we have been building for millennia! The best you can do is to "assume a spherical chicken", and say if the material used has a less than 50% deviation from typical strength, and the weather is similar to what we have seen in the last 100 years, and the soil is similar in important respects to the last bridge we built, it will stay up. But we cannot even know what important things we may have missed - there are always unknown, unknowns!
Engineering is working through the known known (the things you know you know), finding out about the known unknowns (the things you know that you don't know), and praying about (adding margin for) the unknown unknowns (the things that you don't know that you don't know).
That's why rockets explode - there are still a lot of unknown unknowns, so it is not possible to eliminate errors. As we fly them more often, the unknown unknowns become known unknowns and then quickly become known knowns... and the failure rate goes down. That's why it makes the news when a bridge fails - but they still fail from time to time.
OK, I agree with almost everything you said as far as it goes...
They didn't decide that merge sort was a correct sorting algorithm by coding it up and running it a million times. A mathematical proof was given.
Excellent example - that is, indeed, "computer science". That is also not software engineering. Software engineering is taking that sort, and using it to solve a problem. There are an infinite set of provably correct sorting programs - deciding which one to use is software engineering, not "computer science". In my experience, computer scientists are essentially useless outside of the university - though, of course, there they are essential. (Maybe if you were constantly running into new and unusual computing issues, but lets face it, 99.9999% of the programming that happens today is deciding which tools to use where - not creating new tools...)
In addition, "computer science" is not a science! You do not come up with experiments to prove various things incorrect - you work by mathematical proofs. So it should be called "computer math", not "computer science". But that does not mean that software engineering doesn't exist - it means that software engineering is not computer science. And we need a lot more software engineers than computer scientists, just like we need a lot more building engineers than physicists.
I really wish the paper had been about the mechanics of that - to me, that is the missing link. But I have to admit, I'm not sure such a thing can be taught.
I agree - I only say stuff like that to people that seem to only value such statements.
Even more ridiculous, is making such statements on a psuedo-anonymous web site like this one! (I mean really, how does anyone here know what I am really doing? Maybe if they are stalking me they will note a certain consistency in my posts, and that I seem to know more about aircraft/space vehicle design than most, but I could be anybody!
For all your posturing, you sure don't seem to be thinking all that clearly about these issues.
Interestingly enough, I am actually more explaining the current state of the art... I guess you just disagree with all us dummies;}
Once the hardware is as good as can be done, it will still have errors. And there is still the trade-off between giving the hardware another 9 in reliability, and writing the software to get around it.
Precisely - except that in this type of programming, the system has been greatly simplified in order to make it easy to program. We only use a single interrupt, that fires off a timer. The very first thing that happens is that we reset the stack (if applicable), and clear the interrupt flags so that the interrupt can fire again. Then the program flows from most important tasks (for example, the check "if engine=explode then fuel=stop") to the less important tasks (update the nav computer display to show random facts about the closest nav point). That way, if we are currently passing through the South Atlantic Anomaly and the computer is resetting 50 times a second because of a solar flare, the nav system may be toast but the engines won't explode.
I agree that many people that are called software engineers aren't, but not all...
(My joke about the halting problem is silly, but consider trying to prove that a loop will exit under the assumption that another process [gamma rays] is continuously overwriting your variables)
This is true in some cases, it is not true in others.
For example, the class of craft I am currently working on typically has at least one hardware error every 30 minutes of so... so you better be planning for it.
But that is where I disagree - when I am programming the avionics computer, for example, I need to know that the CPU that it is running on will occasionally lock up (gamma ray hits the output buffer transistor) x% of the time. I need to know that the memory cells may change at any time - and the aircraft better not fall out of the sky. I need to know that the total processing speed is limited and somewhat variable - so I better have the important stuff done early in the processing cycle.
Just because you do not need to know such things, does not mean I don't. Software engineering DOES exist - you just don't do it.
When was the last time you looked-up the tensile strength of steel
Interestingly enough, this morning at approximately 10 AM...
considered the maximum temperature of a resistor
Well, that's probably been a few days - the ignitors are actually working...
a bomb blows-up next to your CPU missile-launching card
Would you include a rocket engine hard start scenario? That would be this morning as well... go to be sure that aircraft remains flyable in the event of catastrophic engine failure...
Probably never because software guys only care about the pure math that makes-up their programs
Since it is not never, do you agree that your point is invalid?
I can see the usefulness of considering your program a proof - but he never talked about that in the paper. I also think that considering your program a proof makes it much harder to program, and so not all programs should be done that way (do a cost/benefit analysis first). In addition, there are very easy ways to avoid complexity in many applications... which again makes the proof argument overkill.
As an engineer, I know about that tool - and I can decide if that is the proper tool. For flight control systems, it probably is. For engine avionics, it isn't.
Why do you think that ever problem has the same solution (mathematical proofs)? What is the difference between the engineering of a Mach 25 aircraft and the engineering of it's flight control systems?
then you can't depend on your if-statements branching to the correct location
You're right. You can't.
And so you have to develop code that will work, as often as possible, as close as correctly as possible, even though your hardware will not function per design. If statements fair better than loops in these situations - I have discussed why in moderate details elsewhere in this thread.
I have... No clue - It's used in vital logic for failover between redundant controllers.
OK, perhaps I should have mentioned "in the context of avionics systems." A watchdog timer is a timer that resets a CPU system if a timeout is reached. It is a way of attempting to achieve reliability in the presence of less reliable hardware.
No clue
Obviously;)
Do you believe that flying above the atmosphere changes your variables?
Do you believe it doesn't? The atmosphere stops gamma rays from hitting your equipment. These gamma rays change the value of variables (as in, the gamma ray flips the DFF circuit to the opposite value in your CPU). That means you cannot rely on variables to make sure your loop exits. Therefor loops are bad.
I think you are just spouting random gibberish.
I have a multimillion dollar budget that says I am not - how about you?
Well, I am not arguing about his teaching techniques - the paper did not seem to go into any detail about that, except to say that analogies are bad.
What I am arguing about (mainly) is his statement that there is no such thing as software engineering - indeed, I am sure he would similarly say that there is no such thing as network engineering. That is just silly.
I taught myself to think, so I can't really compare to his methods as you describe it. I do know that the way I think is very different from most people, but beyond that I don't think I could help you - but to be honest, people who talk about how they can see from an "abstract view" tend to 1) be good, but not great, and 2) very stuck up about themselves.
Of course, I don't know you - you are probably just trying to explain a thought process, something very difficult to do in the best of circumstances.
You could say the same for practically every device built by man - but it wouldn't make software engineers into mathematicians any more than it would make aerospace engineers into mathematicians.
After all, in the car and out of the car are simply mathematical states.
And anyway, 2^800000 is an amazingly large number of possible programs - and that is only using 100MB. It might as well be an infinite set - no one outside of a mathematics department will ever know. Reminds me of that story - an engineer and a mathematician are told that they can go get a cake 2 steps away, but each step they take must be only half the distance of the first. The mathematician doesn't try, saying that only a fool would attempt such a thing. The engineer takes 3 steps, says "that's close enough" and eats the cake;-)
An FPGA reads a binary stream of data, and "wires" the interconnect based on that. I think it is a bit of a stretch to call that "interpreting a mathematical description."
But I suppose that I will never convince you. So, yes, call it whatever you want.
A program is nothing without the computer it runs on.
Disagree.
Well, OK... but now you are arguing through redefinition. You are essentially saying that formulas (math stuff done by humans) is the same as programs (math stuff done by computers). And I can prove it because I can take the instructions for the computer, and execute them myself.
Obviously true, but pointless - I mean, we did design the computers after all...
Explain how this is different than describing an airplanes wing with math? We call that engineering, not because magic is involved, but because we are using formulas to solve problems.
(And yes, we can work the number for airflow over a wing by hand also - but that does not make aerospace engineering into mathematics.)
OK, and I don't want you working on avionics, thanks!
There are several ways to deal with the problems presented - apparently you are not intelligent enough to judge that the industry-wide best practices for avionics software engineering are good.
Learn what a watchdog timer is, and why it is a bad idea for avionics, and why loops in avionics controls are bad before telling me that I "don't understand how to prove a loop will exit."
(Hint: Avionics often flies above the atmosphere - variables do not necessarily keep the values you given them)
When designing avionics software, the halting problem is a real problem;-}
So to get around that, you write all software as a (very long) series of if statements in an interrupt routine. So what happens is the interrupt fires, and the list of instructions starts to execute... eventually, the interrupt fires again, restarting the process.
The reason to do this: By putting instructions higher in the list, those instructions are run first - so you are able to put the "don't kill us" calculations before the "avoid turbulence" calculations. As an example of this saving lives, the computer in the Apollo 11 moon lander ran into trouble just a few feet above the lunar surface - pretty much a worst case scenario. Because the computer was designed like this, although they lost some functions they did not lose the ability to land the spacecraft - and Niel Armstrong made history as the first man to walk on the moon rather than die on it.
In many software engineering applications, you must consider the failure modes of the hardware you are using - not the theory of programming formulas. Software that is proven correct but then doesn't run properly is useless.
The reason I bring this up is that you assumed that using a gazillion if statements is a bad approach, because you are optimizing expression efficiency and treating the program as a formula. This is not the proper response in many cases, and an engineer would know that - that's why you are proving my point.
That is precisely what a theoretical guy says - but I'm an electrical engineer, so I have designed CPUs... a program is a set of states you want the hardware to go through, not a formula. Look at assembly language - it is a much further stretch to call it a formula than to call a hardware state lists. And when designing it, we definitely treat it as a hardware state list.
So is it not programming to write the software for a machine that is not turing complete? How about FPGA - where software and hardware are truely blended? What about DSPs, where branching is impossible?
I think engineering covers a lot more of software development than "formulating" does.
Slashdot Mirror
I wish to subscribe to your newsletter - how can you prove that a real life bridge will stay up? You can never know all the details of the land surrounding it, nor the weather it will face, nor even the materials it will be constructed from.
And that is something we have been building for millennia! The best you can do is to "assume a spherical chicken", and say if the material used has a less than 50% deviation from typical strength, and the weather is similar to what we have seen in the last 100 years, and the soil is similar in important respects to the last bridge we built, it will stay up. But we cannot even know what important things we may have missed - there are always unknown, unknowns!
Engineering is working through the known known (the things you know you know), finding out about the known unknowns (the things you know that you don't know), and praying about (adding margin for) the unknown unknowns (the things that you don't know that you don't know).
That's why rockets explode - there are still a lot of unknown unknowns, so it is not possible to eliminate errors. As we fly them more often, the unknown unknowns become known unknowns and then quickly become known knowns... and the failure rate goes down. That's why it makes the news when a bridge fails - but they still fail from time to time.
OK, I agree with almost everything you said as far as it goes...
They didn't decide that merge sort was a correct sorting algorithm by coding it up and running it a million times. A mathematical proof was given.
Excellent example - that is, indeed, "computer science". That is also not software engineering. Software engineering is taking that sort, and using it to solve a problem. There are an infinite set of provably correct sorting programs - deciding which one to use is software engineering, not "computer science". In my experience, computer scientists are essentially useless outside of the university - though, of course, there they are essential. (Maybe if you were constantly running into new and unusual computing issues, but lets face it, 99.9999% of the programming that happens today is deciding which tools to use where - not creating new tools...)
In addition, "computer science" is not a science! You do not come up with experiments to prove various things incorrect - you work by mathematical proofs. So it should be called "computer math", not "computer science". But that does not mean that software engineering doesn't exist - it means that software engineering is not computer science. And we need a lot more software engineers than computer scientists, just like we need a lot more building engineers than physicists.
Teach them how to see the solution
I really wish the paper had been about the mechanics of that - to me, that is the missing link. But I have to admit, I'm not sure such a thing can be taught.
I agree - I only say stuff like that to people that seem to only value such statements.
Even more ridiculous, is making such statements on a psuedo-anonymous web site like this one! (I mean really, how does anyone here know what I am really doing? Maybe if they are stalking me they will note a certain consistency in my posts, and that I seem to know more about aircraft/space vehicle design than most, but I could be anybody!
For all your posturing, you sure don't seem to be thinking all that clearly about these issues.
Interestingly enough, I am actually more explaining the current state of the art... I guess you just disagree with all us dummies ;}
Once the hardware is as good as can be done, it will still have errors. And there is still the trade-off between giving the hardware another 9 in reliability, and writing the software to get around it.
Good point - but the same is true about a bridge design. We can prove that it will fail, but we can't prove it will stay up.
Would that we could - that would save many, many lives.
Engineers have to deal with uncertainty, in software as well as in hardware.
Precisely - except that in this type of programming, the system has been greatly simplified in order to make it easy to program. We only use a single interrupt, that fires off a timer. The very first thing that happens is that we reset the stack (if applicable), and clear the interrupt flags so that the interrupt can fire again. Then the program flows from most important tasks (for example, the check "if engine=explode then fuel=stop") to the less important tasks (update the nav computer display to show random facts about the closest nav point). That way, if we are currently passing through the South Atlantic Anomaly and the computer is resetting 50 times a second because of a solar flare, the nav system may be toast but the engines won't explode.
I agree that many people that are called software engineers aren't, but not all...
(My joke about the halting problem is silly, but consider trying to prove that a loop will exit under the assumption that another process [gamma rays] is continuously overwriting your variables)
This is true in some cases, it is not true in others.
For example, the class of craft I am currently working on typically has at least one hardware error every 30 minutes of so... so you better be planning for it.
But that is where I disagree - when I am programming the avionics computer, for example, I need to know that the CPU that it is running on will occasionally lock up (gamma ray hits the output buffer transistor) x% of the time. I need to know that the memory cells may change at any time - and the aircraft better not fall out of the sky. I need to know that the total processing speed is limited and somewhat variable - so I better have the important stuff done early in the processing cycle.
Just because you do not need to know such things, does not mean I don't. Software engineering DOES exist - you just don't do it.
When was the last time you looked-up the tensile strength of steel
Interestingly enough, this morning at approximately 10 AM...
considered the maximum temperature of a resistor
Well, that's probably been a few days - the ignitors are actually working...
a bomb blows-up next to your CPU missile-launching card
Would you include a rocket engine hard start scenario? That would be this morning as well... go to be sure that aircraft remains flyable in the event of catastrophic engine failure...
Probably never because software guys only care about the pure math that makes-up their programs
Since it is not never, do you agree that your point is invalid?
I can see the usefulness of considering your program a proof - but he never talked about that in the paper. I also think that considering your program a proof makes it much harder to program, and so not all programs should be done that way (do a cost/benefit analysis first). In addition, there are very easy ways to avoid complexity in many applications... which again makes the proof argument overkill.
As an engineer, I know about that tool - and I can decide if that is the proper tool. For flight control systems, it probably is. For engine avionics, it isn't.
Why do you think that ever problem has the same solution (mathematical proofs)? What is the difference between the engineering of a Mach 25 aircraft and the engineering of it's flight control systems?
Big rockets - basically light aircraft that can go from Chicago to Shanghai in 50 minutes. We'll see how it goes...
The CEO of AIG does not have a multimillion dollar avionics design budget.
I probably know a great deal more about avionics systems than him.
then you can't depend on your if-statements branching to the correct location
You're right. You can't.
And so you have to develop code that will work, as often as possible, as close as correctly as possible, even though your hardware will not function per design. If statements fair better than loops in these situations - I have discussed why in moderate details elsewhere in this thread.
Nah, I'm getting tired of programs - I'm building rockets now. Wave of the future, man, wave of the future!
considering that he is one of the fathers of modern computing, his revenue generated far exceeds your own
Nah, he's just older ;} I am creating new industries as well - give em time!
what problems are you talking about?
Achieving higher than normal reliability.
I have... No clue - It's used in vital logic for failover between redundant controllers.
OK, perhaps I should have mentioned "in the context of avionics systems." A watchdog timer is a timer that resets a CPU system if a timeout is reached. It is a way of attempting to achieve reliability in the presence of less reliable hardware.
No clue
Obviously ;)
Do you believe that flying above the atmosphere changes your variables?
Do you believe it doesn't? The atmosphere stops gamma rays from hitting your equipment. These gamma rays change the value of variables (as in, the gamma ray flips the DFF circuit to the opposite value in your CPU). That means you cannot rely on variables to make sure your loop exits. Therefor loops are bad.
I think you are just spouting random gibberish.
I have a multimillion dollar budget that says I am not - how about you?
Well, I am not arguing about his teaching techniques - the paper did not seem to go into any detail about that, except to say that analogies are bad.
What I am arguing about (mainly) is his statement that there is no such thing as software engineering - indeed, I am sure he would similarly say that there is no such thing as network engineering. That is just silly.
I taught myself to think, so I can't really compare to his methods as you describe it. I do know that the way I think is very different from most people, but beyond that I don't think I could help you - but to be honest, people who talk about how they can see from an "abstract view" tend to 1) be good, but not great, and 2) very stuck up about themselves.
Of course, I don't know you - you are probably just trying to explain a thought process, something very difficult to do in the best of circumstances.
Oh, and by the way - I was self taught.
Your inability to explain yourself, and blaming my "upbringing" has really explained it all. To everyone.
And yet somehow I have managed to create hundreds of millions of dollars of value in the software systems I have designed, and he hasn't.
Isn't that odd?
You are totally correct, but give no insight.
You could say the same for practically every device built by man - but it wouldn't make software engineers into mathematicians any more than it would make aerospace engineers into mathematicians.
After all, in the car and out of the car are simply mathematical states.
And anyway, 2^800000 is an amazingly large number of possible programs - and that is only using 100MB. It might as well be an infinite set - no one outside of a mathematics department will ever know. Reminds me of that story - an engineer and a mathematician are told that they can go get a cake 2 steps away, but each step they take must be only half the distance of the first. The mathematician doesn't try, saying that only a fool would attempt such a thing. The engineer takes 3 steps, says "that's close enough" and eats the cake ;-)
FPGAs aren't really any different.
An FPGA reads a binary stream of data, and "wires" the interconnect based on that. I think it is a bit of a stretch to call that "interpreting a mathematical description."
But I suppose that I will never convince you. So, yes, call it whatever you want.
A program is nothing without the computer it runs on.
Disagree.
Well, OK... but now you are arguing through redefinition. You are essentially saying that formulas (math stuff done by humans) is the same as programs (math stuff done by computers). And I can prove it because I can take the instructions for the computer, and execute them myself.
Obviously true, but pointless - I mean, we did design the computers after all...
Explain how this is different than describing an airplanes wing with math? We call that engineering, not because magic is involved, but because we are using formulas to solve problems.
(And yes, we can work the number for airflow over a wing by hand also - but that does not make aerospace engineering into mathematics.)
OK, and I don't want you working on avionics, thanks!
There are several ways to deal with the problems presented - apparently you are not intelligent enough to judge that the industry-wide best practices for avionics software engineering are good.
Learn what a watchdog timer is, and why it is a bad idea for avionics, and why loops in avionics controls are bad before telling me that I "don't understand how to prove a loop will exit."
(Hint: Avionics often flies above the atmosphere - variables do not necessarily keep the values you given them)
When designing avionics software, the halting problem is a real problem ;-}
So to get around that, you write all software as a (very long) series of if statements in an interrupt routine. So what happens is the interrupt fires, and the list of instructions starts to execute... eventually, the interrupt fires again, restarting the process.
The reason to do this: By putting instructions higher in the list, those instructions are run first - so you are able to put the "don't kill us" calculations before the "avoid turbulence" calculations. As an example of this saving lives, the computer in the Apollo 11 moon lander ran into trouble just a few feet above the lunar surface - pretty much a worst case scenario. Because the computer was designed like this, although they lost some functions they did not lose the ability to land the spacecraft - and Niel Armstrong made history as the first man to walk on the moon rather than die on it.
In many software engineering applications, you must consider the failure modes of the hardware you are using - not the theory of programming formulas. Software that is proven correct but then doesn't run properly is useless.
The reason I bring this up is that you assumed that using a gazillion if statements is a bad approach, because you are optimizing expression efficiency and treating the program as a formula. This is not the proper response in many cases, and an engineer would know that - that's why you are proving my point.
That is precisely what a theoretical guy says - but I'm an electrical engineer, so I have designed CPUs... a program is a set of states you want the hardware to go through, not a formula. Look at assembly language - it is a much further stretch to call it a formula than to call a hardware state lists. And when designing it, we definitely treat it as a hardware state list.
So is it not programming to write the software for a machine that is not turing complete? How about FPGA - where software and hardware are truely blended? What about DSPs, where branching is impossible?
I think engineering covers a lot more of software development than "formulating" does.