The real problem with Behe's "argument" is the final link in the chain.
He sets up these criteria like "irreducible complexity" and then argues that "irreducible complexity" implies "could not have arisen by evolution."
Which is a strawman representation of evolution, which has to start simple and change only in a straight line from simple-->complex. Ignoring the fact that simple-->complex-->still complex but very different is much more likely.
There are at least two ways I know of in which irreducible complexity could result from evolution.
1) "Scaffolding": a complicated system evolves, typically by jury-rigging pre-existing mechanism together in a novel way, but then, as evolutionary pressure refines the mechanism to perform their new role more efficiently, the extra functionality is lost piece by piece until only the central function remains.
2) "Duplication and divergence" This is the theory behind blood clotting: that originally one protein was involved, but through genetic duplication, redundant versions of the gene developed. These then diverged in ways that created a chain-reaction mechanism: A evolved to AA evolved to AAA... evolved to AAB, then ABC, then BC, or whatever.
The evidence for these changes is mostly indirect, because the original forms died off long ago without leaving DNA behind for study.
In any case, these mean that pseudo-analytical criteria like "irreducible complexity" don't offer evidence against evolution. Just against simple-minded evolution.
An increase in number of Dells coming in for service could *also* indicate that Dell is selling many more computers of roughly equal quality into the market of people that come to you for service.
If they got to 100% market share, every one of the broken computers you would work on would be Dells, no matter how good their build quality.
You miss the point entirely. (Or, you fail to understand that 99.99% != 1)
One cannot, in principle PROVE accuracy in any sense. Because ANY proof technique requires an assumption that your technique is reliable. How do you PROVE a technique reliable? You come up with some other proof, which might or might not be reliable, and so on. It's turtles all the way down.
The only recourse is a pragmatic "belief" that there is some estimated likelihood of error for some things that I am NEVER going to get around to checking.
I cannot spend my life double- and triple- checking things that were compiled or constructed by careful experts who were basically less likely to make a mistake in their work than *I* am likely to make a mistake in verifying it.
A table of prime numbers in a well-respected mathematical handbook, for instance, is less likely to have mistakes in it than a quickly-hacked together primality testing algorithm that I whip up to "check" it. Because the poople who put it together probably spent weeks (perhaps longer) coding, checking, rechecking, and checking again.
I can't justify spending weeks of my life doing careful coding and cross-checking simply to increase my confidence in Abramowitz & Stegun's list of primes. On the other hand, if I need to code the algorithm for some other purpose, I can use A&S to check my work, increasing my confidence close to (but not above) that of the handbook when extended beyond the limits of that table.
See, this is the key to human civilization: I sometimes put faith in other people to do a good job, and not screw it up. So, yes, I do believe certain books to be basically 99.99% correct WITHOUT wasting my life double-checking EVERY damn thing.
Now, wikipedia demonstrates OVER and OVER that it is vulnerable to all kinds of subtle and not-so-subtle screwups, and that the people who take the *most* care to do a good job are the *least* likely to have their particular version up at any given instant. So I HAVE to double-check it, so I might as well skip that step and find the source I would have double-checked with, and forget about wikipedia at all.
Can you be a little more specific about what you mean by "cell phone" technology out of Bell Labs?
I know they were working on RF/microwave technology, for *stationary* microwave relays, but to me "cell phone" = "wireless phone sets, being handed between multiple base stations without dropping calls"
I don't think Bell Labs was working on that in the 1930s.
99.99% accuracy is quite achievable. I believe, for instance, the table of prime numbers in the handbook on my desk to have fewer than one error in 10000 entries. I believe my computer can test primeness of integers (that fit in my computer memory) with fewer than one error in 10000.
Yes, it is true that no source of information could be guaranteed 100% accurate. Cosmic rays can cause my computer to produce unreliable results. Even the simplest things like 1+1=2 could be changed tomorrow, for all we know. The sun could rise in the west. (I estimate the chances of these events to be *far* lower than 0.01%, by the way.)
That doesn't mean in a practical sense we disbelieve *everything*, because there is no point in doing so. You have to do *something* in the face of uncertainty. One has to make some kind of risk-reward calculation: I could decide to trust this source, and believe the likelihood of being wrong to be X%, and if I am wrong it will have a cost C.
Now, I could decide to double-check (or triple- or quadruple-check) any result using another source. This could result in several outcomes:
1) The new source has a different answer than my original source. 1a) The new source is right, and my original source was wrong. 1b) The new source is wrong, my original source was right. 1c) *Both* sources are wrong, in different ways.
2) The new source has the same answer 2a) Both are right 2b) Both are still *wrong*
The various outcomes have likelihoods that depend basically on the "reliability" of the various sources. Is the extra effort and potential benefit worth the cost and the risk that I could actually get worse information?
A crappy source laden with typos and inaccuracies gets thrown in the trash can in favor of a high-quality proven source. For good reason.
If I have a resource that I believe to be accurate 99.99% of the time, it is much less necessary to be double-checking than a source I believe to be accurate only 50% of the time, assuming what I am looking up has roughly equal value riding on the correctness of the information.
What is it with you people that "everything might have mistakes" becomes equivalent to "oh, mistakes don't matter"?
Guess what. If you pay money for Encyclopedia Britannica, and you have a doubt about some point, you can write a letter to them and, last I heard, they'll unloose a U. of Chicago grad student on the problem to investigate it for you and write a response. As in somebody trained to do research, with the resources of a university library at their disposal, without a particular axe to grind on the issue, who presumably has agreed to undertake the task while meeting certain standards.
And they will respond to you with something like this:
Whereas, if you have a question about the accuracy of a Wikipedia, you've got to do the grunt work yourself, AND you have to be willing to jump into the mosh pit of reversions and edits and vandalism to get the fix to be made and to stick.
Who the hell can even know whether the Wikipedia listing of "corrections" to EB is accurate? It is certainly self-serving.
Unchanging does not mean that the article is factually accurate, informative, or well-written. It just means that it hasn't attracted the attention of people motivated to change it.
Yes, people sometimes take what they read as accurate when it is demonstrably false. But the probability of that occuring is hugely dependent on the amount of error in the work in question!
The fact that people are generally gullible does not lessen the burden on the providers of information to avoid error; in fact, it is *increased.*
I suppose you keep poisons well within the reach of children, because, hey, you know, people drink polluted water all the time in the third world, so we shouldn't worry about them drinking drain cleaner.
Ah, yes, don't let the best be the enemy of the good.
All human activity includes the possibility of error. That doesn't mean that we completely abandon error as a criterion.
A work that is jam-packed with deliberate or easily avoidable errors has less value than a work that has been carefully and professionally reviewed to detect and prevent error.
We shouldn't have to prove that something can be error-free before we say errors are a bad thing.
Now, I don't play any of these games (I waste enough time on Slashdot), but it seems that "aimbot" is a very dangerous name from the vendor's point of view: the presence of such a name calls the integrity of the game system into question.
I think they have a pretty strong basis for rejecting such names.
Yes, but "analog" halftone screening and digital raster printing are different technologies altogether. A raster of 150 DPI will make total garbage out of a 150 LPI halftone screen. Black-and-white vs. color printing is also a whole different ballgame. Color vision has much poorer spatial resolution than "black&white" i.e. light & dark contrast vision.
Read my post again, dimwit. I said LIKE the first Apple LaserWriter. Laserprinters existed before the LaserWriter; 300 DPI was the emerging standard at the time PostScript was developed. Font hinting, for instance, made 300 DPI barely acceptable typographically. 72 DPI printing is just a bad joke.
Nobody in their right mind was using Postscript to drive a 72 DPI printer. Postscript used up a lot of CPU in those days, anyway. You needed the equivalent of a $3000 computer at the time to run it; who the hell pays $3000 extra to use a 72 DPI printer?
PostScript was designed around the 72 DPI printers
This is complete BS. Postscript was designed around 300 DPI desktop printers like the first LaserWriter, with the idea that the same graphics could also be output on a 2400 DPI Linotronic imagesetter when you wanted something that was actual print-quality, as opposed to "better looking than dot-matrix."
300 DPI is tolerable, but still noticeably lower quality than conventional offset printing. 72 DPI is 10--12 dots per line of text; dot-matrix land.
Reading on a backlit LCD or CRT screen is far different from reading on a reflective medium in available light.
Let's see: there's development and maintenance of the Perl script, and the backing database of IP addresses, which has to be linked to the subscriber database, so that they can find when numbers become available again, there's the training of the sales guy to click the right button to execute the Perl script.
That's ON TOP OF the cost burden because all the network maintenance and upgrades have to be compatible with your fixed IP configuration.
That all sounds like labor to me. Things don't run themselves.
What I do see is a bunch of people saying "Anything you can do in Lisp can be done better in $LANGUAGE" without having any clue at all about what Lisp actually IS, and Lispers doing their best to respond. "Macro spaghetti" is an obviously judgmental term. One of the Viaweb guys of course wrote the damn book on Lisp macros, so if you look down on his code, you must have something other than programmer talent in mind.
There are ALWAYS external factors, which eventually dominate decisions, largely independent of computer language. But those non-linguistic reasons aside, it's hard to come up with a computer language that dominates Lisp for purely linguistic reasons.
>> who can't figure what the foot pedal is supposed to do > The what?
The "foot pedal" is the classic help-line plot device in which the new computer user figures this oval-shaped thing with a long cord with switches on one end looks just like the foot pedal she used with her trusty electric sewing machine, so she puts it on the floor and puts her foot on top.
That aside, I've contemplated buying some foot pedals to support Shift, Control, Alt, and mouse click as a way to mitigate repetitive strain. There *do* exist USB foot pedals for such operations as medical transcription or industrial environments, where some aspect of the computer has to be controlled in a hands-free way.
The point of the Yahoo! merchant system example is that a small crew of people was able to develop the system (and Lisp was a huge advantage against their competition), and sell it off to Yahoo for big bucks.
Yahoo's decision to rewrite it doesn't change the original win. How many programmers is Yahoo using now compared to how many were needed to develop it? What else did they give up in the translation?
Likewise, ITA solved what was previously believed to be an *intractable problem*. And they used Lisp to do so. And, surprise, they are apparently able to get money from Orbitz because they did it.
A charitable guess is that Bani is looking at Lisp from an academic functional-language perspective, in which case Lisp is no longer in the forefront of academic language research. Nobody is doing projects to implement Lisp dialects with, just to guess at what is going on, more elaborate type systems, or more purity in functional aspects, or whatever.
Certainly, if I were an academic looking at programming languages from some kind of purist perspective, Common Lisp would look dirty, grungy, without any prospect that it would get "cleaned up" anytime soon.
Meantime, people who want to deliver powerful, novel applications with maximum leverage of programmer talent, can go to a commercial Lisp vendor, and say "gimme some of that Lisp goodness" and actually do real-world development, academic purity be damned.
That's the only reason I can see for a Haskell guy to accuse any other language of not being "successful."
I see Common Lisp and Scheme as the only dialects of other than historical interest.
Lisp Machine Lisp, MACLisp, NIL, InterLisp, Symbolics Lisp, and others I've probably never heard of, all either flowed into Common Lisp or have died out by not doing so. Lisp 1.5 is a museum curiosity. Are you counting T? Previous revisions of the Scheme standard? MDL? I'm still missing 20 or so dialects from your count.
(And, BTW, I can write Lisp on the whiteboard just fine. It just doesn't execute very fast.)
"*" doesn't count as punctuation: it's a freaking function!
And you should at least count the carriage return at the end of the Python example as punctuation. Isn't the white-space significant?
Plus, you have to use the redundant word "return". Think about why it is not simply
def square(x) x*x
Which is the Lisp example where white-space punctuation replaces explicit parenthesis punctuation.
In any case, the original poster was comparing to C++. Python and Lisp are pretty much on the same side of this debate: use a single consistent punctuation scheme instead of trying to use lots of punctuation to distinguish shades of meaning.
Slashdot Mirror
The real problem with Behe's "argument" is the final link in the chain.
... evolved to AAB, then ABC, then BC, or whatever.
He sets up these criteria like "irreducible complexity" and then argues that "irreducible complexity" implies "could not have arisen by evolution."
Which is a strawman representation of evolution, which has to start simple and change only in a straight line from simple-->complex. Ignoring the fact that simple-->complex-->still complex but very different is much more likely.
There are at least two ways I know of in which irreducible complexity could result from evolution.
1) "Scaffolding": a complicated system evolves, typically by jury-rigging pre-existing mechanism together in a novel way, but then, as evolutionary pressure refines the mechanism to perform their new role more efficiently, the extra functionality is lost piece by piece until only the central function remains.
2) "Duplication and divergence" This is the theory behind blood clotting: that originally one protein was involved, but through genetic duplication, redundant versions of the gene developed. These then diverged in ways that created a chain-reaction mechanism: A evolved to AA evolved to AAA
The evidence for these changes is mostly indirect, because the original forms died off long ago without leaving DNA behind for study.
In any case, these mean that pseudo-analytical criteria like "irreducible complexity" don't offer evidence against evolution. Just against simple-minded evolution.
An increase in number of Dells coming in for service could *also* indicate that Dell is selling many more computers of roughly equal quality into the market of people that come to you for service.
If they got to 100% market share, every one of the broken computers you would work on would be Dells, no matter how good their build quality.
You miss the point entirely. (Or, you fail to understand that 99.99% != 1)
One cannot, in principle PROVE accuracy in any sense. Because ANY proof technique requires an assumption that your technique is reliable. How do you PROVE a technique reliable? You come up with some other proof, which might or might not be reliable, and so on. It's turtles all the way down.
The only recourse is a pragmatic "belief" that there is some estimated likelihood of error for some things that I am NEVER going to get around to checking.
I cannot spend my life double- and triple- checking things that were compiled or constructed by careful experts who were basically less likely to make a mistake in their work than *I* am likely to make a mistake in verifying it.
A table of prime numbers in a well-respected mathematical handbook, for instance, is less likely to have mistakes in it than a quickly-hacked together primality testing algorithm that I whip up to "check" it. Because the poople who put it together probably spent weeks (perhaps longer) coding, checking, rechecking, and checking again.
I can't justify spending weeks of my life doing careful coding and cross-checking simply to increase my confidence in Abramowitz & Stegun's list of primes. On the other hand, if I need to code the algorithm for some other purpose, I can use A&S to check my work, increasing my confidence close to (but not above) that of the handbook when extended beyond the limits of that table.
See, this is the key to human civilization: I sometimes put faith in other people to do a good job, and not screw it up. So, yes, I do believe certain books to be basically 99.99% correct WITHOUT wasting my life double-checking EVERY damn thing.
Now, wikipedia demonstrates OVER and OVER that it is vulnerable to all kinds of subtle and not-so-subtle screwups, and that the people who take the *most* care to do a good job are the *least* likely to have their particular version up at any given instant. So I HAVE to double-check it, so I might as well skip that step and find the source I would have double-checked with, and forget about wikipedia at all.
Can you be a little more specific about what you mean by "cell phone" technology out of Bell Labs?
I know they were working on RF/microwave technology, for *stationary* microwave relays, but to me "cell phone" = "wireless phone sets, being handed between multiple base stations without dropping calls"
I don't think Bell Labs was working on that in the 1930s.
What kind of world are you living in?
99.99% accuracy is quite achievable. I believe, for instance, the table of prime numbers in the handbook on my desk to have fewer than one error in 10000 entries. I believe my computer can test primeness of integers (that fit in my computer memory) with fewer than one error in 10000.
Yes, it is true that no source of information could be guaranteed 100% accurate. Cosmic rays can cause my computer to produce unreliable results. Even the simplest things like 1+1=2 could be changed tomorrow, for all we know. The sun could rise in the west. (I estimate the chances of these events to be *far* lower than 0.01%, by the way.)
That doesn't mean in a practical sense we disbelieve *everything*, because there is no point in doing so. You have to do *something* in the face of uncertainty. One has to make some kind of risk-reward calculation: I could decide to trust this source, and believe the likelihood of being wrong to be X%, and if I am wrong it will have a cost C.
Now, I could decide to double-check (or triple- or quadruple-check) any result using another source. This could result in several outcomes:
1) The new source has a different answer than my original source.
1a) The new source is right, and my original source was wrong.
1b) The new source is wrong, my original source was right.
1c) *Both* sources are wrong, in different ways.
2) The new source has the same answer
2a) Both are right
2b) Both are still *wrong*
The various outcomes have likelihoods that depend basically on the "reliability" of the various sources. Is the extra effort and potential benefit worth the cost and the risk that I could actually get worse information?
A crappy source laden with typos and inaccuracies gets thrown in the trash can in favor of a high-quality proven source. For good reason.
Except for the "usually" part.
If I have a resource that I believe to be accurate 99.99% of the time, it is much less necessary to be double-checking than a source I believe to be accurate only 50% of the time, assuming what I am looking up has roughly equal value riding on the correctness of the information.
What is it with you people that "everything might have mistakes" becomes equivalent to "oh, mistakes don't matter"?
Guess what. If you pay money for Encyclopedia Britannica, and you have a doubt about some point, you can write a letter to them and, last I heard, they'll unloose a U. of Chicago grad student on the problem to investigate it for you and write a response. As in somebody trained to do research, with the resources of a university library at their disposal, without a particular axe to grind on the issue, who presumably has agreed to undertake the task while meeting certain standards.
And they will respond to you with something like this:
http://hamsa.org/britannica.htm
Whereas, if you have a question about the accuracy of a Wikipedia, you've got to do the grunt work yourself, AND you have to be willing to jump into the mosh pit of reversions and edits and vandalism to get the fix to be made and to stick.
Who the hell can even know whether the Wikipedia listing of "corrections" to EB is accurate? It is certainly self-serving.
Unchanging does not mean that the article is factually accurate, informative, or well-written. It just means that it hasn't attracted the attention of people motivated to change it.
Unchanging crap would still be crap.
Yes, people sometimes take what they read as accurate when it is demonstrably false. But the probability of that occuring is hugely dependent on the amount of error in the work in question!
The fact that people are generally gullible does not lessen the burden on the providers of information to avoid error; in fact, it is *increased.*
I suppose you keep poisons well within the reach of children, because, hey, you know, people drink polluted water all the time in the third world, so we shouldn't worry about them drinking drain cleaner.
Ah, yes, don't let the best be the enemy of the good.
All human activity includes the possibility of error. That doesn't mean that we completely abandon error as a criterion.
A work that is jam-packed with deliberate or easily avoidable errors has less value than a work that has been carefully and professionally reviewed to detect and prevent error.
We shouldn't have to prove that something can be error-free before we say errors are a bad thing.
Now, I don't play any of these games (I waste enough time on Slashdot), but it seems that "aimbot" is a very dangerous name from the vendor's point of view: the presence of such a name calls the integrity of the game system into question.
I think they have a pretty strong basis for rejecting such names.
Only if you consider a web page to be an "article manufactured or sold". That will take some lawyers to puzzle out.
Steam-methane reformation CH4 + 2 H2O --> 4 H2 + CO2 (and requires 1100 deg C processing with catalysts).
Yes, but "analog" halftone screening and digital raster printing are different technologies altogether. A raster of 150 DPI will make total garbage out of a 150 LPI halftone screen. Black-and-white vs. color printing is also a whole different ballgame. Color vision has much poorer spatial resolution than "black&white" i.e. light & dark contrast vision.
Read my post again, dimwit. I said LIKE the first Apple LaserWriter. Laserprinters existed before the LaserWriter; 300 DPI was the emerging standard at the time PostScript was developed. Font hinting, for instance, made 300 DPI barely acceptable typographically. 72 DPI printing is just a bad joke.
Nobody in their right mind was using Postscript to drive a 72 DPI printer. Postscript used up a lot of CPU in those days, anyway. You needed the equivalent of a $3000 computer at the time to run it; who the hell pays $3000 extra to use a 72 DPI printer?
PostScript was designed around the 72 DPI printers
This is complete BS. Postscript was designed around 300 DPI desktop printers like the first LaserWriter, with the idea that the same graphics could also be output on a 2400 DPI Linotronic imagesetter when you wanted something that was actual print-quality, as opposed to "better looking than dot-matrix."
300 DPI is tolerable, but still noticeably lower quality than conventional offset printing. 72 DPI is 10--12 dots per line of text; dot-matrix land.
Reading on a backlit LCD or CRT screen is far different from reading on a reflective medium in available light.
Let's see: there's development and maintenance of the Perl script, and the backing database of IP addresses, which has to be linked to the subscriber database, so that they can find when numbers become available again, there's the training of the sales guy to click the right button to execute the Perl script.
That's ON TOP OF the cost burden because all the network maintenance and upgrades have to be compatible with your fixed IP configuration.
That all sounds like labor to me. Things don't run themselves.
I don't see anyone calling Lisp a "magic bullet."
What I do see is a bunch of people saying "Anything you can do in Lisp can be done better in $LANGUAGE" without having any clue at all about what Lisp actually IS, and Lispers doing their best to respond. "Macro spaghetti" is an obviously judgmental term. One of the Viaweb guys of course wrote the damn book on Lisp macros, so if you look down on his code, you must have something other than programmer talent in mind.
There are ALWAYS external factors, which eventually dominate decisions, largely independent of computer language. But those non-linguistic reasons aside, it's hard to come up with a computer language that dominates Lisp for purely linguistic reasons.
Ah, yes.
But I think you mean to say something like
"No support for DivX. Smaller screen than an Archos. Lame."
>> who can't figure what the foot pedal is supposed to do
> The what?
The "foot pedal" is the classic help-line plot device in which the new computer user figures this oval-shaped thing with a long cord with switches on one end looks just like the foot pedal she used with her trusty electric sewing machine, so she puts it on the floor and puts her foot on top.
That aside, I've contemplated buying some foot pedals to support Shift, Control, Alt, and mouse click as a way to mitigate repetitive strain. There *do* exist USB foot pedals for such operations as medical transcription or industrial environments, where some aspect of the computer has to be controlled in a hands-free way.
The point of the Yahoo! merchant system example is that a small crew of people was able to develop the system (and Lisp was a huge advantage against their competition), and sell it off to Yahoo for big bucks.
Yahoo's decision to rewrite it doesn't change the original win. How many programmers is Yahoo using now compared to how many were needed to develop it? What else did they give up in the translation?
Likewise, ITA solved what was previously believed to be an *intractable problem*. And they used Lisp to do so. And, surprise, they are apparently able to get money from Orbitz because they did it.
Did a Lisper piss in your cheerios or something?
A charitable guess is that Bani is looking at Lisp from an academic functional-language perspective, in which case Lisp is no longer in the forefront of academic language research. Nobody is doing projects to implement Lisp dialects with, just to guess at what is going on, more elaborate type systems, or more purity in functional aspects, or whatever.
Certainly, if I were an academic looking at programming languages from some kind of purist perspective, Common Lisp would look dirty, grungy, without any prospect that it would get "cleaned up" anytime soon.
Meantime, people who want to deliver powerful, novel applications with maximum leverage of programmer talent, can go to a commercial Lisp vendor, and say "gimme some of that Lisp goodness" and actually do real-world development, academic purity be damned.
That's the only reason I can see for a Haskell guy to accuse any other language of not being "successful."
30 dialects of Lisp? Where?
I see Common Lisp and Scheme as the only dialects of other than historical interest.
Lisp Machine Lisp, MACLisp, NIL, InterLisp, Symbolics Lisp, and others I've probably never heard of, all either flowed into Common Lisp or have died out by not doing so. Lisp 1.5 is a museum curiosity. Are you counting T? Previous revisions of the Scheme standard? MDL? I'm still missing 20 or so dialects from your count.
(And, BTW, I can write Lisp on the whiteboard just fine. It just doesn't execute very fast.)
You can order a macivory system assembled direct from symbolics.com.
"*" doesn't count as punctuation: it's a freaking function!
And you should at least count the carriage return at the end of the Python example as punctuation. Isn't the white-space significant?
Plus, you have to use the redundant word "return". Think about why it is not simply
def square(x) x*x
Which is the Lisp example where white-space punctuation replaces explicit parenthesis punctuation.
In any case, the original poster was comparing to C++. Python and Lisp are pretty much on the same side of this debate: use a single consistent punctuation scheme instead of trying to use lots of punctuation to distinguish shades of meaning.