Hmmmm. It seems that James Oberg worked at NASA (in the Mission Control Center at JSC no less) at the same time, too. Who to believe?
I suspect it depends on whether you consider political pressure to be people from capitol hill calling up and saying "make sure you launch on time", or NASA bureaucrats saying to themselves "we'd better launch on time because otherwise I'll get calls from capitol hill". The former is direct pressure. The latter is bureaucrats covering their asses so that they don't face direct pressure (without necessarily knowing whether or not said pressure will occur).
No, it really isn't. Engineering is fundamentally a pragmatic approach to producing things that are "fit for purpose" (or, more generally, an approach to solving problems). Now, part of that pragmatism is the realization that applying knowledge from the sciences and from mathematics during the design process makes it much more likely that the resulting product will actually function that way it is intended to. Hence the importance of mathematics in the eductaion of engineers. But math (and science) is only one tool in the engineer's toolkit. Some things simply aren't (yet) understood well enough in a scientific or mathematical context to provide useful predictions of behavior. So engineers also use a lot of other tools to get their job done. These tools include empirical (but not necessarily scientific) experience, intuition, reuse of existing designs, and plain old trial and error.
Please note that this comment isn't intended to denigrate the importance of mathematics to engineering. In fact, I personally believe that the application of mathematics is quite neglected in some areas of engineering (especially software engineering). But the successful application of mathematics in engineering is unlikely if we don't properly understand the place of mathematics within the larger practice of engineering.
We had 2 color televisions with cable. "Why?," you ask? because there is literally NO OTHER WAY OF ESCAPE in a society that focuses around entertainment! A one-time cost of $200 and a monthly cost of $25 is damn reasonable...
No other way of escape? Isn't a library card free? Might help with that whole "education" thing too.
Please do not confuse "static type checking" with "explicit variable declaration". They are two different things. Languages such as Haskell and ML have an extremely strong static type system. However, they do not require explicit variable declarations, because they use Hindley-Milner type inference to determine the type of variables and functions.
As I said, different libertarians have different conceptions of what constitutes a "minimal" set of rules. What they are agreed on is that the goal to which we should be striving is to make the rule set as minimal as possible, as opposed to continually layering on more and more rules.
I think it's fair to say that traumatizing small children by firing a machine gun through a kindergarten, even if it didn't actually hit anyone, would count as something that might be considered as harm. And therefore leave the shooter open to prosecution. Not to mention that firing bullets into or through a private kindergarten without permission probably counts as criminal trespass in some libertarian legal philosophies. But, by all means, continue to pull out that hoary old example as a convenient strawman argument for why libertarians are all crackpots detached from reality.
As far as pollution goes, I fail to see how the scenario you outline is any different than what presently occurs. Pollution can't be stopped unless you know it's happening in the first place. That said, I doubt that pollution that "causes no noticeable harm" would be tolerated under most libertarian legal theories - it would most likely be considered (once detected) a violation of property rights, since it would devalue or damage other peoples property, even if it doesn't cause physical "harm". But again, don't let that stop you from pulling out silly strawman arguments...
IMHO the line you are trying to draw between preventive and retributive punishment is fuzzy at best. How do you propose to "prevent" pollution (as opposed to applying retributive measures)? By regulation? What possible reason do companies or individuals have for following those regulations? Could it be fear of retribution? The same goes for the shooting into kindergartens example. You could of course ban all guns. But anyone willing to disregard other laws may well be willing to disregard a gun ban as well. The only thing enforcing a gun ban, or a shooting at kindergartens ban, is fear of retribution.
Not all libertarians believe in having no government. Libertarians in general are for a "minimal" government. There's a lot of debate between the various stripes of libertarians (anarcho-capitalists, market anarchists, minarchists, etc.) as to what actually constitutes "minimal". Some think that they can get away with no government. Others want government limited to providing courts and police (and maybe some military for national self-defense). There's plenty of shades of gray in between. About the only thing I've really seen libertarians agree on is that power in the hands of a government tends to be misused and abused, so keeping that power as limited as possible (for some definition of possible) is a good thing.
The IEEE also provides LaTeX templates, and prefers stuff in LaTeX format. I think they also provide a Word template as well, but most everyone I know who writes for the IEEE uses the LaTeX templates. It wouldn't surprise me if the ACM was similar (although I haven't checked). I know that a lot of the big CS journals mandate LaTeX.
I beg to differ. In non-software disciplines, you suffer the "perversity of matter". Things will break apart, overheat, rust or degrade. You can design in margins and redundancy, give maintenance guidelines and take things out of service before they get unreliable and there will still be some risk of failure.
And, as others have pointed out, the software you develop most likely depends on other libraries or runtimes (which you may not understand correctly), and runs on hardware that suffers from the "perversity of matter". In both cases, it is highly unlikely that your specification will perfectly capture these issues - the software may be correct with respect to the spec (which is pretty much all we can ever hope for), but not correct with respect to the requirements of the system it is part of.
Perhaps more importantly, other disciplines are just as susceptible to the specification and design errors that result in bugs in software. I agree that software is in a much better position to produce "bug-free" designs than other disciplines. But the reality is that any complex system is going to have bugs, either due to specification errors, or due to design errors. We can do our utmost to reduce the probability that those errors exist. But guaranteeing that there are no errors is pretty much impossible.
Every one of the skills a good software engineer needs together forms a subset of the skills required by a good computer scientist.
I disagree with that assertion. But it may depend heavily on what our respective definitions of "computer scientist" and "software engineer" are.
How do you figure? As a developer of commercial embedded software, that hasn't been my experience. Teams usually consist of both...
Which is unusual. Software in many other application domains is developed almost exclusively by CS grads. Hence "embedded software [...] the software most likely to be written by people trained as engineers".
...but code written by Electrical Engineers, well, let's just say it's notorious.
Obviously, I can't speak to your personal experiences. I've seen some absolutely gawd-awful code written by graduates of "good" CS programmes and "good" engineering programmes.
Above all else, please save your judgement for the quality of particular education programs instead of blanketing an entire field with your views.
Fair enough. Perhaps I did generalize little much. In my defense, allow me to point out that these are not my views alone. See, for example, this article by Steve McConnell, or this article by David Parnas (I apologize for being unable to find a version available to non-IEEE members). Both of them make the same points about the differences between CS training and SE training that I have been attempting to make. It's not a question of whether or not CS grads can learn to do software engineering (they undoubtedly can, just as physicists can learn to be electrical engineers). It's a question of what the appropriate focus of the undergraduate programme is, and of whether we should assume that a CS programme is the correct preparation for industrial software developers.
I don't know how Praxis manages their low rate, and haven't read that article...
Perhaps you should. You may well learn something useful. As you correctly point out,
"The vast majority of bugs are instead misbehaviors. There is nothing wrong with the code, it just doesn't perform exactly in the manner expected in every circumstance. Often these bugs don't arise from the coding, but from the specifications or requirements."
The techniques used by Praxis are specifically intended to address specification and requirement errors before they can become bugs, and to catch potential misbehaviors before the code is even executed. That's how they manage their low defect rates: by directly addressing the issues you have identified as the root causes of bugs. Wouldn't you like to know how they do that?
Apparently you think that no research is done in industry. Do you think all new products are just put together out of off the shelf, or obvious techniques? Perhaps you think all new software products have their roots in academia?
Hmmmmm... I don't remember saying anywhere that there was no research in industry. But there is a difference between research, and industrial product development. CS programmes are (or should be) good preparation for research. Engineering programmes are (or should be) good preparation for product development (that being the essential purpose of engineering). That doesn't mean that CS grads shouldn't be employed in industry at all, just that the assumption that they are generally prepared for product development work isn't a good one. I'm sorry if I gave you a different impression with my earlier comments.
Of course, there is also a necessity for R&D work, which may well include both scientists and engineers. But this is, again, not the same as product development.
It's not screwed up. You only hear about or notice the bad software. Most industrial software is very high quality.
Perhaps. But I think it's worth noting that all of the examples you've given are embedded software, which I'll readily admit has much higher quality standards than you're likely to find in many other application domains. It's also the software most likely to be written by people trained as engineers (electrical or computer), rather than CS grads - in other words, people who's training focuses much more on product development and delivery. Which only emphasizes my original point.
Bad software being considered ubiquitous is a recent phenomenon that arrived with desktop computing.
Really? Then why are there references to a "software crisis" dating back to the 60's? Consider, for example, these quotes from the 1968 NATO Software Engineering Conference:
Kolence: The basic problem is that certain classes of systems are placing demands on us which are beyond our capabili-
ties and our theories and methods of design and production at this time. There are many areas where there is no
such thing as a crisis -- sort routines, payroll applications, for example. It is large systems that are encountering
great difficulties. We should not expect the production of such systems to be easy.
David and Fraser: Particularly alarming is the seemingly unavoidable fallibility of large software, since a malfunction
in an advanced hardware-software system can be a matter of life and death.
Dijkstra: The dissemination of knowledge is of obvious value -- the massive dissemination of error-loaded software
is frightening.
Graham: Today we tend to go on for years, with tremendous investments to find that the system, which was not well
understood to start with, does not work as anticipated. We build systems like the Wright brothers built airplanes
-- build the whole thing, push it off the cliff, let it crash, and start over again.
These quotes are (depressingly) still relevant almost 40 years later...
I think you'll find that Praxis has a similar attitude. My understanding is that they follow the Jackson approach to understanding requirements: "requirements" represent things the customers wants changed about the world, "specifications" define what the design should do in order to make those changes happen, and the "design" provides a method of doing the things defined in the specification. You might find Jackson's publications on requirements and specification interesting.
And one thing I don't want to see is formal programming CS programs which produce CS professors exclusively... though some of my CS academic aquaintences dislike me saying so, from what I see, few of their graduates go into coding in industry. That's a pretty unfortunate thing for the world. To be ultimately useful, these skills need to become things which take people out of college, into industry, and successfully into challenging industry projects.
Maybe we could start by not assuming that CS grads should be going into industry. CS programmes should be teaching Computer Science - you know, the stuff that prepares you for a career in research. Industrial coders should be going through a software engineering program, in which they learn how to apply the results of scientific research to practical real world problems.
Just as with other sciences and engineering disciplines, there will likely be a lot of overlap in subject matter. But the fundamental focus is entirely different: there will be material covered in one programme that isn't covered in another, and the perspective taken on the overlap material will be quite different.
Sadly, many developers are graduates from CS programmes instead of engineering programmes, and too many of the "software engineering" programmes out there have little resemblance to the engineering training found in other disciplines - which is, IMHO, one of the reasons the world of industrial software development is so screwed up.
Let's see them do this after taking over a half-coded project with minimal design requirements, a hard deadline, and a budget that can be cut by governmental forces at will.
Which is precisely the kind of project they avoid, because it's a disaster waiting to happen. Praxis caters to customers who want quality, and are willing to do what it takes to get it.
Yes, yes, open source projects fix bugs for free. The point is that they can afford to do that, because they have so many volunteers to do the bug-fixes. Praxis doesn't have volunteers, so the only way they can afford to do bug-fixes for free is by having a very low number of bugs.
But, what kind of logical constructs would you use to define the expected output for any input, in a logical manner, instead of just lining them up? Hey, that's the program itself.
No, that's the specification. The program is the method for performing that actual mapping from input to output. The two are not the same. I can tell you how to recognize a square root when you see one (e.g. sqrt(x) is y such that y*y = x), without actually telling you how to construct a square root (there are, of course, several possible methods for doing so). The former is a specification. The latter is a program.
But what very many bugs boil down to, when not typos (which is surprisingly common) is: "Hey, I didn't think about that ever happening, and that it would have those consequences."
Which is why the Praxis approach includes some extremely good requirements elicitation, to understand the problem domain as completely as possible, and rigorous specification using notations that are amenable to formal analysis, so that those "Hey I didn't think of that" situations can be found and fixed, often before a line of code has been written.
Except that the articles in question aren't about finding and removing bugs in already-implemented code, they are about a method that allows one to construct code that doesn't have bugs in the first place.
Linux, Firefox, and OpenOffice are some of the best software on the planet. I think is a good practical testament to the OSS philosophy.
And yet they all still suffer from a metric crapload of bugs. Praxis produces software with so few bugs that they are willing to provide a warranty that says they'll fix any bug found within the first 10 years, for free. If their software had the defect rate of Firefox or OpenOffice they'd be bankrupt in short order.
Did you actually bother to RTFA? Oh yeah, this is/. - stupid question. Allow me to suggest that you make an exception, and actually take the time to read TFA in this case. Praxis does not claim no bugs, they claim significantly lower defect rates than development using other methods. Which in turn means much greater confidence that the system will work as desired.
No one can ever make something that is completely "bug-free" - even in traditional, non-software disciplines. All you can do is make the probability that the system will work as high as possible. Praxis has some techniques that can help developers create software with a much higher probability of working correctly than it would otherwise have. That's a good thing, even if it doesn't result in perfection.
Its buffer overflows and flawed design that has not been tested with every concievable input/output that causes most serious bugs in medical and aerospace applications.
It's the fact that Praxis relies on static checking far beyond anything you've ever seen (using a carefully designed subset of Ada that can be statically checked in all sorts of interesting ways) that helps to ameliorate this problem, since the static check is effectively equivalent to an exhaustive input/output test.
With the resources available to the government, would an alternative "G-Internet" have been infeasible?
The DOD already operates a separate internet for classified material. It's known as the Secret Internet Protocol Router Network, or SIPRNet. So yes, an alternative "G-Internet" is more than feasible - it already exists.
Slashdot Mirror
Hmmmm. It seems that James Oberg worked at NASA (in the Mission Control Center at JSC no less) at the same time, too. Who to believe?
I suspect it depends on whether you consider political pressure to be people from capitol hill calling up and saying "make sure you launch on time", or NASA bureaucrats saying to themselves "we'd better launch on time because otherwise I'll get calls from capitol hill". The former is direct pressure. The latter is bureaucrats covering their asses so that they don't face direct pressure (without necessarily knowing whether or not said pressure will occur).
Maybe the problem was that Lim played Sulu too informally. Or did you mean formerly?
No, it really isn't. Engineering is fundamentally a pragmatic approach to producing things that are "fit for purpose" (or, more generally, an approach to solving problems). Now, part of that pragmatism is the realization that applying knowledge from the sciences and from mathematics during the design process makes it much more likely that the resulting product will actually function that way it is intended to. Hence the importance of mathematics in the eductaion of engineers. But math (and science) is only one tool in the engineer's toolkit. Some things simply aren't (yet) understood well enough in a scientific or mathematical context to provide useful predictions of behavior. So engineers also use a lot of other tools to get their job done. These tools include empirical (but not necessarily scientific) experience, intuition, reuse of existing designs, and plain old trial and error.
Please note that this comment isn't intended to denigrate the importance of mathematics to engineering. In fact, I personally believe that the application of mathematics is quite neglected in some areas of engineering (especially software engineering). But the successful application of mathematics in engineering is unlikely if we don't properly understand the place of mathematics within the larger practice of engineering.
No other way of escape? Isn't a library card free? Might help with that whole "education" thing too.
Please do not confuse "static type checking" with "explicit variable declaration". They are two different things. Languages such as Haskell and ML have an extremely strong static type system. However, they do not require explicit variable declarations, because they use Hindley-Milner type inference to determine the type of variables and functions.
As I said, different libertarians have different conceptions of what constitutes a "minimal" set of rules. What they are agreed on is that the goal to which we should be striving is to make the rule set as minimal as possible, as opposed to continually layering on more and more rules.
As far as pollution goes, I fail to see how the scenario you outline is any different than what presently occurs. Pollution can't be stopped unless you know it's happening in the first place. That said, I doubt that pollution that "causes no noticeable harm" would be tolerated under most libertarian legal theories - it would most likely be considered (once detected) a violation of property rights, since it would devalue or damage other peoples property, even if it doesn't cause physical "harm". But again, don't let that stop you from pulling out silly strawman arguments...
IMHO the line you are trying to draw between preventive and retributive punishment is fuzzy at best. How do you propose to "prevent" pollution (as opposed to applying retributive measures)? By regulation? What possible reason do companies or individuals have for following those regulations? Could it be fear of retribution? The same goes for the shooting into kindergartens example. You could of course ban all guns. But anyone willing to disregard other laws may well be willing to disregard a gun ban as well. The only thing enforcing a gun ban, or a shooting at kindergartens ban, is fear of retribution.
Not all libertarians believe in having no government. Libertarians in general are for a "minimal" government. There's a lot of debate between the various stripes of libertarians (anarcho-capitalists, market anarchists, minarchists, etc.) as to what actually constitutes "minimal". Some think that they can get away with no government. Others want government limited to providing courts and police (and maybe some military for national self-defense). There's plenty of shades of gray in between. About the only thing I've really seen libertarians agree on is that power in the hands of a government tends to be misused and abused, so keeping that power as limited as possible (for some definition of possible) is a good thing.
The IEEE also provides LaTeX templates, and prefers stuff in LaTeX format. I think they also provide a Word template as well, but most everyone I know who writes for the IEEE uses the LaTeX templates. It wouldn't surprise me if the ACM was similar (although I haven't checked). I know that a lot of the big CS journals mandate LaTeX.
And, as others have pointed out, the software you develop most likely depends on other libraries or runtimes (which you may not understand correctly), and runs on hardware that suffers from the "perversity of matter". In both cases, it is highly unlikely that your specification will perfectly capture these issues - the software may be correct with respect to the spec (which is pretty much all we can ever hope for), but not correct with respect to the requirements of the system it is part of.
Perhaps more importantly, other disciplines are just as susceptible to the specification and design errors that result in bugs in software. I agree that software is in a much better position to produce "bug-free" designs than other disciplines. But the reality is that any complex system is going to have bugs, either due to specification errors, or due to design errors. We can do our utmost to reduce the probability that those errors exist. But guaranteeing that there are no errors is pretty much impossible.
I disagree with that assertion. But it may depend heavily on what our respective definitions of "computer scientist" and "software engineer" are.
How do you figure? As a developer of commercial embedded software, that hasn't been my experience. Teams usually consist of both...
Which is unusual. Software in many other application domains is developed almost exclusively by CS grads. Hence "embedded software [...] the software most likely to be written by people trained as engineers".
Obviously, I can't speak to your personal experiences. I've seen some absolutely gawd-awful code written by graduates of "good" CS programmes and "good" engineering programmes.
Above all else, please save your judgement for the quality of particular education programs instead of blanketing an entire field with your views.
Fair enough. Perhaps I did generalize little much. In my defense, allow me to point out that these are not my views alone. See, for example, this article by Steve McConnell, or this article by David Parnas (I apologize for being unable to find a version available to non-IEEE members). Both of them make the same points about the differences between CS training and SE training that I have been attempting to make. It's not a question of whether or not CS grads can learn to do software engineering (they undoubtedly can, just as physicists can learn to be electrical engineers). It's a question of what the appropriate focus of the undergraduate programme is, and of whether we should assume that a CS programme is the correct preparation for industrial software developers.
Perhaps you should. You may well learn something useful. As you correctly point out,
The techniques used by Praxis are specifically intended to address specification and requirement errors before they can become bugs, and to catch potential misbehaviors before the code is even executed. That's how they manage their low defect rates: by directly addressing the issues you have identified as the root causes of bugs. Wouldn't you like to know how they do that?Hmmmmm... I don't remember saying anywhere that there was no research in industry. But there is a difference between research, and industrial product development. CS programmes are (or should be) good preparation for research. Engineering programmes are (or should be) good preparation for product development (that being the essential purpose of engineering). That doesn't mean that CS grads shouldn't be employed in industry at all, just that the assumption that they are generally prepared for product development work isn't a good one. I'm sorry if I gave you a different impression with my earlier comments.
Of course, there is also a necessity for R&D work, which may well include both scientists and engineers. But this is, again, not the same as product development.
It's not screwed up. You only hear about or notice the bad software. Most industrial software is very high quality.
Perhaps. But I think it's worth noting that all of the examples you've given are embedded software, which I'll readily admit has much higher quality standards than you're likely to find in many other application domains. It's also the software most likely to be written by people trained as engineers (electrical or computer), rather than CS grads - in other words, people who's training focuses much more on product development and delivery. Which only emphasizes my original point.
Bad software being considered ubiquitous is a recent phenomenon that arrived with desktop computing.
Really? Then why are there references to a "software crisis" dating back to the 60's? Consider, for example, these quotes from the 1968 NATO Software Engineering Conference:
These quotes are (depressingly) still relevant almost 40 years later...I think you'll find that Praxis has a similar attitude. My understanding is that they follow the Jackson approach to understanding requirements: "requirements" represent things the customers wants changed about the world, "specifications" define what the design should do in order to make those changes happen, and the "design" provides a method of doing the things defined in the specification. You might find Jackson's publications on requirements and specification interesting.
Maybe we could start by not assuming that CS grads should be going into industry. CS programmes should be teaching Computer Science - you know, the stuff that prepares you for a career in research. Industrial coders should be going through a software engineering program, in which they learn how to apply the results of scientific research to practical real world problems.
Just as with other sciences and engineering disciplines, there will likely be a lot of overlap in subject matter. But the fundamental focus is entirely different: there will be material covered in one programme that isn't covered in another, and the perspective taken on the overlap material will be quite different.
Sadly, many developers are graduates from CS programmes instead of engineering programmes, and too many of the "software engineering" programmes out there have little resemblance to the engineering training found in other disciplines - which is, IMHO, one of the reasons the world of industrial software development is so screwed up.
Which is precisely the kind of project they avoid, because it's a disaster waiting to happen. Praxis caters to customers who want quality, and are willing to do what it takes to get it.
Yes, yes, open source projects fix bugs for free. The point is that they can afford to do that, because they have so many volunteers to do the bug-fixes. Praxis doesn't have volunteers, so the only way they can afford to do bug-fixes for free is by having a very low number of bugs.
No, that's the specification. The program is the method for performing that actual mapping from input to output. The two are not the same. I can tell you how to recognize a square root when you see one (e.g. sqrt(x) is y such that y*y = x), without actually telling you how to construct a square root (there are, of course, several possible methods for doing so). The former is a specification. The latter is a program.
But what very many bugs boil down to, when not typos (which is surprisingly common) is: "Hey, I didn't think about that ever happening, and that it would have those consequences."
Which is why the Praxis approach includes some extremely good requirements elicitation, to understand the problem domain as completely as possible, and rigorous specification using notations that are amenable to formal analysis, so that those "Hey I didn't think of that" situations can be found and fixed, often before a line of code has been written.
Uh, did you RTFA(s)? They are using automatic verification - take a look at their SPARK Ada toolkit.
See also this comment, from further down the page.
Linux, Firefox, and OpenOffice are some of the best software on the planet. I think is a good practical testament to the OSS philosophy.
And yet they all still suffer from a metric crapload of bugs. Praxis produces software with so few bugs that they are willing to provide a warranty that says they'll fix any bug found within the first 10 years, for free. If their software had the defect rate of Firefox or OpenOffice they'd be bankrupt in short order.
No one can ever make something that is completely "bug-free" - even in traditional, non-software disciplines. All you can do is make the probability that the system will work as high as possible. Praxis has some techniques that can help developers create software with a much higher probability of working correctly than it would otherwise have. That's a good thing, even if it doesn't result in perfection.
Its buffer overflows and flawed design that has not been tested with every concievable input/output that causes most serious bugs in medical and aerospace applications.
It's the fact that Praxis relies on static checking far beyond anything you've ever seen (using a carefully designed subset of Ada that can be statically checked in all sorts of interesting ways) that helps to ameliorate this problem, since the static check is effectively equivalent to an exhaustive input/output test.
And yet the reports I've seen on Praxis claim costs and schedules the same or less than the development of software of similar complexity...
Wow. I mean... just... wow. I can't believe they granted that patent. What a sad indictment of the USPTO.
The DOD already operates a separate internet for classified material. It's known as the Secret Internet Protocol Router Network, or SIPRNet. So yes, an alternative "G-Internet" is more than feasible - it already exists.