Maybe I've been spoiled by all the good blog posts I'm exposed to here, but the writing style of this article is atrocious.
Some parts are broken up into single paragraph sections (which are frequently much too long), the headings add no value at all, and the content itself is a rambling drunkards walk through only loosely related ideas.
If there was ever a case for "reprocessing" someone else's work as a value add - this is it.
Maybe it pays to be a nut in this business, especially now that the computer industry is looking for an effective solution to the parallel programming problem. Being nutty helps you see things that normal folks can't see.
I should expand upon my comment. Anyone who claims that, "I will argue further that moving to a signal-based, synchronous software model will not only result in an improvement of several orders of magnitude in productivity, but also in programs that are guaranteed free of defects, regardless of their complexity" is not to be taken seriously.
Anyone who is really interested in this model of computation would be far better off reading this: http://jpaulmorrison.com/fbp/
At least J. Paul Morrison doesn't claim that his approach is infallible. Indeed he goes to some length to point out the troublesome areas and techniques to address them.
Does it also pay to think Revelations contains secret truths about biology/physics and that almost all the great physicists of the 20th century were crackpots?
http://www.rebelscience.org/Crackpots/nasty.htm
Savain has been promoting COSA for years, yet he refuses to implement it or even give precise semantics for it. Even giving him the maximum benefit of the doubt, the best thing you could say about COSA is that it's interesting; there's no evidence that it works or that it has any benefits.
Also, calling him a crackpot doesn't help, since it just reinforces his persecution complex.
The fact that he holds hardware design up as some sort of perfect ideal makes me suspicious. The fact that he's advocating a visual programming language makes me more suspicious. Not only is typing much faster than clicking and dragging, but you can't search.
Even worse is his hatred for the phrase "no silver bullet". When people say that, they aren't saying that writing good software is impossible, they're saying that there is no substitute for working hard and paying attention to what you're doing, that mechanically copying strategies, processes, tools, etc., is not a panacea.
"But he acknowledges that, he's saying that it restricts the scope of improvements to evolutionary ones." No he's not, he's misunderstanding the problem. The problem isn't how to make reliable software, it's how to best understand a problem and describe a solution. That is going to be hard and error prone forever, just go ask a hardware designer.
9 comments
[ 2.7 ms ] story [ 33.5 ms ] threadSome parts are broken up into single paragraph sections (which are frequently much too long), the headings add no value at all, and the content itself is a rambling drunkards walk through only loosely related ideas.
If there was ever a case for "reprocessing" someone else's work as a value add - this is it.
Anyone who is really interested in this model of computation would be far better off reading this: http://jpaulmorrison.com/fbp/
At least J. Paul Morrison doesn't claim that his approach is infallible. Indeed he goes to some length to point out the troublesome areas and techniques to address them.
The author of the OP, Louis Savain, has some other strange ideas also: http://scienceblogs.com/strangerfruit/2008/01/laugh_along_wi...
Also, calling him a crackpot doesn't help, since it just reinforces his persecution complex.
Even worse is his hatred for the phrase "no silver bullet". When people say that, they aren't saying that writing good software is impossible, they're saying that there is no substitute for working hard and paying attention to what you're doing, that mechanically copying strategies, processes, tools, etc., is not a panacea.
"But he acknowledges that, he's saying that it restricts the scope of improvements to evolutionary ones." No he's not, he's misunderstanding the problem. The problem isn't how to make reliable software, it's how to best understand a problem and describe a solution. That is going to be hard and error prone forever, just go ask a hardware designer.